SYN_RECV, IPTABLES, Drop DDOS Flood IPs does not work!

[Log in to get rid of this advertisement]
SYN_RECV, IPTABLES, Drop DDOS Flood IPs does not work!
I use this command to block ddos ips

while true; do netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq; netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq > /tmp/ips.txt;for IP in `cat /tmp/ips.txt`; do iptables -A INPUT -s $IP -j DROP;done;service iptables save; sleep 30; done;

but still all the same ips that SYN RECV DDOS me remain active 
I tried iptables restart still wont kill those bad connections
How to really drop them so I wont see them again in netstat

You have new mail in /var/spool/mail/root
[root@vbox2fedora11 ~]# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
[root@vbox2fedora11 ~]#

96.49.250.193
iptables: Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
10.1.231.55
187.146.59.172
188.51.4.221
196.209.198.197
201.165.12.21
201.26.106.227
24.234.86.254
67.167.150.169
69.46.142.122
76.217.95.6
77.183.84.46
77.196.51.125
77.210.98.64
78.50.226.250
82.9.59.77
84.143.187.50
85.157.188.208
87.96.232.60
91.193.220.129
92.153.255.183
94.153.161.250
96.32.251.220
96.49.250.193
iptables: Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
10.1.231.55
187.146.59.172
196.209.198.197
201.26.106.227
217.201.127.118
24.234.86.254
67.167.150.169
69.111.189.49
69.46.142.122
76.217.95.6
77.183.84.46
77.196.51.125
77.210.98.64
78.50.226.250
82.9.59.77
84.143.187.50
85.157.188.208
86.153.68.53
87.96.232.60
91.193.220.129
92.153.255.183
94.153.161.250
96.32.251.220
96.49.250.193
iptables: Saving firewall rules to /etc/sysconfig/iptables: [ OK ]

[root@vbox2fedora11 ~]# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 :http S0106001cdf20124e.vc.:52419 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52414 SYN_RECV
tcp 0 0 :http a88-112-87-22naconsult-lm SYN_RECV
tcp 0 0 :http dsl-187-146-59-172-:houston SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52397 SYN_RECV
tcp 0 0 :http dsl-187-146-59-172-:yo-main SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52416 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52420 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52398 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52395 SYN_RECV
tcp 0 0 :http static-84-166-145-212:14949 SYN_RECV
tcp 0 0 :http 5ad0d533.bb.sk:netbill-auth SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52421 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52422 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52417 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52402 SYN_RECV
tcp 0 0 :http static.unknown.c:dicom-iscl SYN_RECV
tcp 0 0 :http d66-183-27-194.bchsia:60266 SYN_RECV
tcp 0 0 :http 10.1.231.55:edm-manager SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52405 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52393 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52411 SYN_RECV
tcp 0 0 :http 188.51.4.221:46386 SYN_RECV
tcp 0 0 :http dsl-144-98-232.telkoma:3404 SYN_RECV
tcp 0 0 :http bl7-78-16.dsl.telepac:14020 SYN_RECV
tcp 0 0 :http 172.16.127.226:houston SYN_RECV
tcp 0 0 :http p548FBB32.dip.t-di:mps-raft SYN_RECV
tcp 0 0 :http adsl-76-217-95-6.dsl.:60250 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52401 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52407 SYN_RECV
tcp 0 0 :http 125.51.196-77.rev.g:netplan SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52408 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52418 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52399 SYN_RECV
tcp 0 0 :http d66-183-27-194.bchsia:60285 SYN_RECV
tcp 0 0 :http static-84-166-145-212:14950 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52413 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52404 SYN_RECV
tcp 0 0 :http mobile-3G-dyn-BC-190-:52242 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52415 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52394 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52409 SYN_RECV
tcp 0 0 :http bas3-montreal31-12797:61810 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52396 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52423 SYN_RECV
tcp 0 0 :http 217.71.225.75:4497 SYN_RECV
tcp 0 0 :http S0106001cdf20124e.vc.:52412 SYN_RECV

Old 09-02-2009, 08:01 AM #2
cbtshare
Member

Registered: Jul 2009
Posts: 561

Rep: Reputation: 42
I’d suggest if you have cpanel use csf plugin.If not install APF and DDos Deflate(be careful not to change the APF setting to 1 until your sure the server is fine,you can get locked out) In DDOS D you can set the rules that defines a bad connection and it will use iptables or APF to block the automatically.Configured correctly can be a great ease to Sys Admins.Software is no match for hardware though , if the attacks become too great , software will falter.

SYN Flood
Origem: Wikipédia, a enciclopédia livre.
Question book.svg
Esta página ou secção não cita nenhuma fonte ou referência, o que compromete sua credibilidade (desde outubro de 2010).
Por favor, melhore este artigo providenciando fontes fiáveis e independentes, inserindo-as no corpo do texto por meio de notas de rodapé. Encontre fontes: Google — notícias, livros, acadêmico — Scirus — Bing. Veja como referenciar e citar as fontes.

Uma conexão normal cliente-servidor. O aperto de mão em três etapas é realizado corretamente

Conexão com SYN flood. O atacante envia diversas vezes pacotes maliciosos com SYN e recebe respostas válidas. O servidor é sobrecarregado e novas requisições válidas não são realizadas com sucesso
SYN flood ou ataque SYN é uma forma de ataque de negação de serviço (também conhecido como Denial of Service – DoS) em sistemas computadorizados, na qual o atacante envia uma sequência de requisições SYN para um sistema-alvo visando uma sobrecarga direta na camada de transporte e indireta na camada de aplicação do modelo OSI.
Quando um cliente tenta começar uma conexão TCP com um servidor, o cliente e o servidor trocam um série de mensagens, que normalmente são assim:
O cliente requisita uma conexão enviando um SYN (synchronize) ao servidor.
O servidor confirma esta requisição mandando um SYN-ACK(acknowledge) de volta ao cliente.
O cliente por sua vez responde com um ACK, e a conexão está estabelecida.
Isto é o chamado aperto de mão em três etapas (Three-Way Handshake).
Um cliente malicioso, que implemente intencionalmente um protocolo TCP errado e incompleto, pode não mandar esta última mensagem ACK. O servidor irá esperar por isso por um tempo, já que um simples congestionamento de rede pode ser a causa do ACK em falta.
Esta chamada conexão semi-aberta explora a boa-fé do protocolo TCP que espera por um certo tempo e algumas tentativas de restabelecimento de um sinal ACK válido para retomar a comunicação. A resposta maliciosa ao comando SYN gerada pelo cliente pode ocupar recursos no servidor (memória e processamento) ou causar prejuízos para empresas usando softwares licenciados por conexão (aumento de conexões “ativas”). Pode ser possível ocupar todos os recursos da máquina, com pacotes SYN. Uma vez que todos os recursos estejam ocupados, nenhuma nova conexão (legítima ou não) pode ser feita, resultando em negação de serviço. Alguns podem funcionar mal ou até mesmo travar se ficarem sem recursos desta maneira.
Algumas contra-medidas para este ataque são os SYN cookies. Apenas máquinas Sun e Linux usam SYN cookies.
Ao contrário do que muitos pensam, não se resolve negação de serviço por Syn flood limitando conexões por minuto (como usar o módulo limit ou recent do iptables), pois as conexões excedentes seriam descartadas pelo firewall, sendo que desta forma o próprio firewall tiraria o serviço do ar. Se eu, por exemplo, limito as conexões SYN a 10/seg, um atacante precisa apenas manter uma taxa de SYNs superior a 10/s para que conexões legítimas sejam descartadas pelo firewall. O firewall tornou a tarefa do atacante ainda mais fácil. Em “Iptables protege contra SYN Flood?” tem uma boa descrição dos motivos pelos quais uma configuração de firewall não resolve.
Um ataque de Syn Flood é feito com os ips forjados (spoof), para que o atacante não receba os ACKs de suas falsas solicitações.
Ligações externas[editar | editar código-fonte]
Iptables protege contra SYN Flood?
Aviso oficial da CERT sobre ataques SYN (em inglês)

http://pt.wikipedia.org/wiki/SYN_Flood
http://www.linuxquestions.org/questions/linux-server-73/syn_recv-iptables-drop-ddos-flood-ips-does-not-work-751982/

Deixe um comentário Cancelar resposta