SYN_RECV, IPTABLES, Drop DDOS Flood IPs does not work!<\/p>\n
Conex\u00e3o com SYN flood. O atacante envia diversas vezes pacotes maliciosos com SYN e recebe respostas v\u00e1lidas. O servidor \u00e9 sobrecarregado e novas requisi\u00e7\u00f5es v\u00e1lidas n\u00e3o s\u00e3o realizadas com sucesso <\/p>\n
[Log in to get rid of this advertisement]
\nSYN_RECV, IPTABLES, Drop DDOS Flood IPs does not work!
\nI use this command to block ddos ips<\/p>\n
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;<\/p>\n
but still all the same ips that SYN RECV DDOS me remain active \uf04c
\nI tried iptables restart still wont kill those bad connections
\nHow to really drop them so I wont see them again in netstat<\/p>\n
You have new mail in \/var\/spool\/mail\/root
\n[root@vbox2fedora11 ~]# sysctl -p
\nnet.ipv4.ip_forward = 0
\nnet.ipv4.tcp_syncookies = 1
\nnet.ipv4.conf.default.rp_filter = 1
\nnet.ipv4.conf.default.accept_source_route = 0
\nkernel.sysrq = 0
\nkernel.core_uses_pid = 1
\n[root@vbox2fedora11 ~]#<\/p>\n
96.49.250.193
\niptables: Saving firewall rules to \/etc\/sysconfig\/iptables: [ OK ]
\n10.1.231.55
\n187.146.59.172
\n188.51.4.221
\n196.209.198.197
\n201.165.12.21
\n201.26.106.227
\n24.234.86.254
\n67.167.150.169
\n69.46.142.122
\n76.217.95.6
\n77.183.84.46
\n77.196.51.125
\n77.210.98.64
\n78.50.226.250
\n82.9.59.77
\n84.143.187.50
\n85.157.188.208
\n87.96.232.60
\n91.193.220.129
\n92.153.255.183
\n94.153.161.250
\n96.32.251.220
\n96.49.250.193
\niptables: Saving firewall rules to \/etc\/sysconfig\/iptables: [ OK ]
\n10.1.231.55
\n187.146.59.172
\n196.209.198.197
\n201.26.106.227
\n217.201.127.118
\n24.234.86.254
\n67.167.150.169
\n69.111.189.49
\n69.46.142.122
\n76.217.95.6
\n77.183.84.46
\n77.196.51.125
\n77.210.98.64
\n78.50.226.250
\n82.9.59.77
\n84.143.187.50
\n85.157.188.208
\n86.153.68.53
\n87.96.232.60
\n91.193.220.129
\n92.153.255.183
\n94.153.161.250
\n96.32.251.220
\n96.49.250.193
\niptables: Saving firewall rules to \/etc\/sysconfig\/iptables: [ OK ]<\/p>\n
[root@vbox2fedora11 ~]# netstat
\nActive Internet connections (w\/o servers)
\nProto Recv-Q Send-Q Local Address Foreign Address State
\ntcp 0 0 :http S0106001cdf20124e.vc.:52419 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52414 SYN_RECV
\ntcp 0 0 :http a88-112-87-22naconsult-lm SYN_RECV
\ntcp 0 0 :http dsl-187-146-59-172-:houston SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52397 SYN_RECV
\ntcp 0 0 :http dsl-187-146-59-172-:yo-main SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52416 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52420 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52398 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52395 SYN_RECV
\ntcp 0 0 :http static-84-166-145-212:14949 SYN_RECV
\ntcp 0 0 :http 5ad0d533.bb.sk:netbill-auth SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52421 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52422 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52417 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52402 SYN_RECV
\ntcp 0 0 :http static.unknown.c:dicom-iscl SYN_RECV
\ntcp 0 0 :http d66-183-27-194.bchsia:60266 SYN_RECV
\ntcp 0 0 :http 10.1.231.55:edm-manager SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52405 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52393 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52411 SYN_RECV
\ntcp 0 0 :http 188.51.4.221:46386 SYN_RECV
\ntcp 0 0 :http dsl-144-98-232.telkoma:3404 SYN_RECV
\ntcp 0 0 :http bl7-78-16.dsl.telepac:14020 SYN_RECV
\ntcp 0 0 :http 172.16.127.226:houston SYN_RECV
\ntcp 0 0 :http p548FBB32.dip.t-di:mps-raft SYN_RECV
\ntcp 0 0 :http adsl-76-217-95-6.dsl.:60250 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52401 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52407 SYN_RECV
\ntcp 0 0 :http 125.51.196-77.rev.g:netplan SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52408 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52418 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52399 SYN_RECV
\ntcp 0 0 :http d66-183-27-194.bchsia:60285 SYN_RECV
\ntcp 0 0 :http static-84-166-145-212:14950 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52413 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52404 SYN_RECV
\ntcp 0 0 :http mobile-3G-dyn-BC-190-:52242 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52415 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52394 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52409 SYN_RECV
\ntcp 0 0 :http bas3-montreal31-12797:61810 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52396 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52423 SYN_RECV
\ntcp 0 0 :http 217.71.225.75:4497 SYN_RECV
\ntcp 0 0 :http S0106001cdf20124e.vc.:52412 SYN_RECV<\/p>\n
Old 09-02-2009, 08:01 AM\t #2
\ncbtshare
\nMember<\/p>\n
Registered: Jul 2009
\nPosts: 561<\/p>\n
Rep: Reputation: 42
\nI’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.<\/p>\n
SYN Flood
\nOrigem: Wikip\u00e9dia, a enciclop\u00e9dia livre.
\nQuestion book.svg
\nEsta p\u00e1gina ou sec\u00e7\u00e3o n\u00e3o cita nenhuma fonte ou refer\u00eancia, o que compromete sua credibilidade (desde outubro de 2010).
\nPor favor, melhore este artigo providenciando fontes fi\u00e1veis e independentes, inserindo-as no corpo do texto por meio de notas de rodap\u00e9. Encontre fontes: Google \u2014 not\u00edcias, livros, acad\u00eamico \u2014 Scirus \u2014 Bing. Veja como referenciar e citar as fontes.<\/p>\n
Uma conex\u00e3o normal cliente-servidor. O aperto de m\u00e3o em tr\u00eas etapas \u00e9 realizado corretamente<\/p>\n
Conex\u00e3o com SYN flood. O atacante envia diversas vezes pacotes maliciosos com SYN e recebe respostas v\u00e1lidas. O servidor \u00e9 sobrecarregado e novas requisi\u00e7\u00f5es v\u00e1lidas n\u00e3o s\u00e3o realizadas com sucesso
\nSYN flood ou ataque SYN \u00e9 uma forma de ataque de nega\u00e7\u00e3o de servi\u00e7o (tamb\u00e9m conhecido como Denial of Service – DoS) em sistemas computadorizados, na qual o atacante envia uma sequ\u00eancia de requisi\u00e7\u00f5es SYN para um sistema-alvo visando uma sobrecarga direta na camada de transporte e indireta na camada de aplica\u00e7\u00e3o do modelo OSI.
\nQuando um cliente tenta come\u00e7ar uma conex\u00e3o TCP com um servidor, o cliente e o servidor trocam um s\u00e9rie de mensagens, que normalmente s\u00e3o assim:
\nO cliente requisita uma conex\u00e3o enviando um SYN (synchronize) ao servidor.
\nO servidor confirma esta requisi\u00e7\u00e3o mandando um SYN-ACK(acknowledge) de volta ao cliente.
\nO cliente por sua vez responde com um ACK, e a conex\u00e3o est\u00e1 estabelecida.
\nIsto \u00e9 o chamado aperto de m\u00e3o em tr\u00eas etapas (Three-Way Handshake).
\nUm cliente malicioso, que implemente intencionalmente um protocolo TCP errado e incompleto, pode n\u00e3o mandar esta \u00faltima mensagem ACK. O servidor ir\u00e1 esperar por isso por um tempo, j\u00e1 que um simples congestionamento de rede pode ser a causa do ACK em falta.
\nEsta chamada conex\u00e3o semi-aberta explora a boa-f\u00e9 do protocolo TCP que espera por um certo tempo e algumas tentativas de restabelecimento de um sinal ACK v\u00e1lido para retomar a comunica\u00e7\u00e3o. A resposta maliciosa ao comando SYN gerada pelo cliente pode ocupar recursos no servidor (mem\u00f3ria e processamento) ou causar preju\u00edzos para empresas usando softwares licenciados por conex\u00e3o (aumento de conex\u00f5es “ativas”). Pode ser poss\u00edvel ocupar todos os recursos da m\u00e1quina, com pacotes SYN. Uma vez que todos os recursos estejam ocupados, nenhuma nova conex\u00e3o (leg\u00edtima ou n\u00e3o) pode ser feita, resultando em nega\u00e7\u00e3o de servi\u00e7o. Alguns podem funcionar mal ou at\u00e9 mesmo travar se ficarem sem recursos desta maneira.
\nAlgumas contra-medidas para este ataque s\u00e3o os SYN cookies. Apenas m\u00e1quinas Sun e Linux usam SYN cookies.
\nAo contr\u00e1rio do que muitos pensam, n\u00e3o se resolve nega\u00e7\u00e3o de servi\u00e7o por Syn flood limitando conex\u00f5es por minuto (como usar o m\u00f3dulo limit ou recent do iptables), pois as conex\u00f5es excedentes seriam descartadas pelo firewall, sendo que desta forma o pr\u00f3prio firewall tiraria o servi\u00e7o do ar. Se eu, por exemplo, limito as conex\u00f5es SYN a 10\/seg, um atacante precisa apenas manter uma taxa de SYNs superior a 10\/s para que conex\u00f5es leg\u00edtimas sejam descartadas pelo firewall. O firewall tornou a tarefa do atacante ainda mais f\u00e1cil. Em “Iptables protege contra SYN Flood?” tem uma boa descri\u00e7\u00e3o dos motivos pelos quais uma configura\u00e7\u00e3o de firewall n\u00e3o resolve.
\nUm ataque de Syn Flood \u00e9 feito com os ips forjados (spoof), para que o atacante n\u00e3o receba os ACKs de suas falsas solicita\u00e7\u00f5es.
\nLiga\u00e7\u00f5es externas[editar | editar c\u00f3digo-fonte]
\nIptables protege contra SYN Flood?
\nAviso oficial da CERT sobre ataques SYN (em ingl\u00eas)<\/p>\n
http:\/\/pt.wikipedia.org\/wiki\/SYN_Flood
\nhttp:\/\/www.linuxquestions.org\/questions\/linux-server-73\/syn_recv-iptables-drop-ddos-flood-ips-does-not-work-751982\/<\/p>\n","protected":false},"excerpt":{"rendered":"
SYN_RECV, IPTABLES, Drop DDOS Flood IPs does not work! Conex\u00e3o com SYN flood. O atacante envia diversas vezes pacotes maliciosos com SYN e recebe respostas v\u00e1lidas. O servidor \u00e9 sobrecarregado e novas requisi\u00e7\u00f5es v\u00e1lidas n\u00e3o s\u00e3o realizadas com sucesso [Log in to get rid of…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_angie_page":false,"page_builder":"","footnotes":""},"categories":[12],"tags":[],"class_list":["post-2803","post","type-post","status-publish","format-standard","hentry","category-iptables"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts\/2803","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/comments?post=2803"}],"version-history":[{"count":0,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts\/2803\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=2803"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=2803"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=2803"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}