O objetivo deste artigo é, basicamente, explicar como realmente se defende de ataques Syn flood.

Por razões didáticas, porém, muitos conceitos técnicos serão explicados, que podem até serem ignorados por aqueles que não estão familiarizados com os protocolos TCP. No entanto, mesmo para os iniciantes, recomendo a leitura, ao menos par usar a solução proposta.

Inicialmente procuro definir o que são as negações de serviço e quais os tipos que existem.

Após descrevo no que se baseia a técnica de Syn Flood (como ela funciona) e duas soluções furadas, que não funcionam explicando por quê.

Por fim falo da técnica de Syn cookie, inicialmente como se usa ela, e para os mais avançados, descrevo no que ela funciona.

Na conclusão comento sobre como realmente regras de firewall podem ser úteis para combater este tipo de ataque.

Espero que meu objetivo seja alcançado, de contribuir para que se entenda o que é Syn Flood e como realmente se pode realizar uma defesa.

[1] Comentário enviado por phelipe em 29/08/2007 - 11:34h:

Ótimo! Simplesmente ótimo... parabéns! :-)

[2] Comentário enviado por juninho (RH.com) em 29/08/2007 - 11:40h:

Elgio,

que beleza, nunca imaginei que funcionasse desta forma, e muito menos que não estaria protegido apenas com a regra básica do iptables.

Parabéns, tenho certeza que será de bom proveito para muitos, como foi para mim.

[3] Comentário enviado por andersonjackson em 29/08/2007 - 11:59h:

Isso que é artigo :D

Parabens +Favoritos

[4] Comentário enviado por zilli em 29/08/2007 - 12:01h:

Parabéns .... show de bola.
Só fico imaginando como que deve ser o seu script de firewall :-)
Coisa de outro mundo !!!

Abraços,
Daniel

[5] Comentário enviado por removido em 29/08/2007 - 12:05h:

Essas opções do kernel são muito boas, a muitas mais opções como essas que facilitam a vida de muita gente, é so estudar.

Està de parabéns pelo artigo.

[6] Comentário enviado por TSM em 29/08/2007 - 13:11h:

Cara, realmente você tem razão, e o seu artigo é de qualidade, só em ler ele eu já faço idéia do conhecimento que você tem, valeu pelo artigo.

Já esta em meus favoritos.
Abraços.

[7] Comentário enviado por acvsilva em 29/08/2007 - 13:47h:

Pois é. botando as caraminholas para funcionar a gente vai muito mais longe do que pensa!!!

[8] Comentário enviado por engos em 29/08/2007 - 15:42h:

Muito bom o artigo.

Acabo de mudar de emprego para atuar com segurança da informação e o artigo ajudou bastante a me atualizar e me relembrar de alguns detlhes técnicos do TCP/IP.

Me ajudou bastante!

Abraços.

[9] Comentário enviado por capitainkurn em 29/08/2007 - 15:52h:

Estou gostando muito de sua série de artigos acerca do Iptables. Muito bem redigidos e ditáticos.
Parabéns Elgio!

[10] Comentário enviado por edi_oliver em 29/08/2007 - 17:11h:

Apenas uma palavra para resumir este artigo:

SEN-SA-CIO-NAAAAAAAAAAAAAAAAALLLLLL!!!!!!!

[11] Comentário enviado por demattos em 29/08/2007 - 20:21h:

sem palavras, nunca vi de forma clara como funciona o iptables como vc transmite por seus artigos

parabens

[12] Comentário enviado por davis.peixoto em 29/08/2007 - 21:08h:

Elcio, parabéns.

Há tempos que não lia um artigo tão didático e interessante.

Muito obrigado por me tirar do marasmo. Já foi pro meu favoritos.

[13] Comentário enviado por DondaJr em 29/08/2007 - 21:42h:

Kra.. parabens.. aprendi sobre o Syn Flood como nunca.. naum sabia q era assim

[14] Comentário enviado por m4sk4r4 em 29/08/2007 - 22:52h:

Realmente fantástico.

Lendo o tópico sobre Syn Flood, lembrei quando estava estudando sobre NAT Through(NAT TRAVERSAL, Hole Punch).

Não tive sucesso na época, me deu vontade agora de retomar os estudos, você teria algum material ou conehcimento sobre essa técnica.

Abraço

[15] Comentário enviado por Bique em 30/08/2007 - 05:05h:

Sensacional este artigo, a explicação não poderia ser melhor: tudo ao mais pequeno detalhe.

Parabéns

[16] Comentário enviado por elgio em 30/08/2007 - 09:21h:

COMO USAR O HPING?

Me perguntaram...

O hping3 faz tudo isto, tanto o Ip spoofing como o flood. Para testar você pode com sergunça ver em SEU SERVIDOR o efeito. Deixe um tcpump ligado no servidor para ver os ips falsos gerados:

tcpdump -i eth0 -n port 80

Vou mostrar com o meu mesmo, localhost:

# hping3 --rand-source -p 80 -S localhost
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=80 flags=SA seq=4 win=32792 rtt=0.2 ms

E o que eu peguei no tcpdump:
# tcpdump -i lo -n port 80
09:19:18.358407 IP 12.57.241.164.2098 > 127.0.0.1.80: S 934405501:934405501(0) win 512
09:19:19.359121 IP 197.136.235.76.2099 > 127.0.0.1.80: S 1879392267:1879392267(0) win 512
09:19:20.363153 IP 168.176.134.222.2100 > 127.0.0.1.80: S 1555847962:1555847962(0) win 512

Vejam os ips de origem...

Agora o hping é bem comportado, gera um SYN a cada segundo. Achou ele lento?

# hping3 --flood --rand-source -p 80 -S localhost
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown

Fiz isto e meu monitor de rede subiu AO MAXIMO!

Aprecie com moderação.

[17] Comentário enviado por icarooo em 30/08/2007 - 11:27h:

excelente! estava esperando um tutorial desta qualidade, pois ja estava irritando o "control c control v" de amadores

[18] Comentário enviado por ekklesiah em 30/08/2007 - 11:48h:

quero instalar programas no ubuntu sou novo na area

[19] Comentário enviado por marcrock em 31/08/2007 - 16:33h:

Artigo maravilhoso!!!!!

Mais claro que isso impossível!!!!

Parabéns.

Até +!!!!!

[20] Comentário enviado por Gerson Raymond em 02/09/2007 - 08:20h:

Extremamente genial este artigo, parabéns pelo refinamento técnico e qualidade extraordinária.

[21] Comentário enviado por removido em 14/10/2007 - 23:22h:

realmente, refinamento e qualidade, fazia tempo que eu estava afastado do site devido ao padrao caindo, mas sempre há um bom motivo para voltar.

[22] Comentário enviado por cytron em 18/11/2007 - 17:59h:

Este artigo é sem dúvidas uma óbra de arte, seria bom sem todos fizessem dessa maneira, a maioria deixa ao menos um item sem explicar pra que serve, sempre dizem: "execute isso", "altere aquilo". Daí você faz um monte de coisas sem saber qual a função, apenas o objetivo final.

Parabéns!!!

(14-04-2008)

Opa!!! Tive que voltar o valor de tcp_syncookies para 0, pois com valor 1 o tráfego na rede ficou muito estranho, tinha hora que um server não encontrava o outro, bastava colocar 0 novamente e tudo voltava ao normal.

Não sei explicar isso e deve ter solução, mas estou sem tempo agora.

[23] Comentário enviado por agk em 24/11/2007 - 16:11h:

Muito bom, excelente artigo, realmente o autor entende muito bem como funciona o modelo osi e as flags do protocolo tcp.

Também gostei muito dos exemplos do tcpdump, alias, deixo a sugestão para quem conhece e domina bem o tcpdump que faça um artigo detalhando o seu uso, pelo que vejo é uma ferramenta poderosa para análise do tráfego da rede.

No mais só posso dizer que o artigo é 10, parabéns!!!

[24] Comentário enviado por Pinguim Gigante em 08/02/2008 - 19:16h:

Caraca Maluco!!!

[O.O]

Esse cara é bom!

[25] Comentário enviado por jpgribeiro em 19/02/2008 - 12:39h:

Excelente, simples e objetivo, adorei!!!

[26] Comentário enviado por alexandre_mpm em 28/03/2008 - 17:25h:

Boa tarde elgio

Muito bom o seu artigo excelente, com certeza ja está nos favoritos mas eu tenho um dúvida gostaria de sua ajuda para entender, o que eu endendia dessa regra:

# Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 10/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP

é que se a conexão não fosse estabelecida dentro de 10 segundos ela seria descartada, sendo assim não alocaria por tanto tempo recursos da máquina, ou seja receberia quantas conexões fossem solicita mas as que não forem estabelecida em 10 segundo era descartada, não é isso?

ahh além do hping3 temos também o netwox, que muiiiiiiiiiiiiiiiiitoo bom tem mais de 220 opções de teste só nele.

[27] Comentário enviado por elgio em 28/03/2008 - 18:10h:

Pois é alexandre!

o limit é quantos pacotes CASAREM com o syn por segundo, e não conexões estabelecidas.

Contudo, mesmo que fosse conexões estabelecidas, como imaginaste, mesmo assim o iptables não se livraria do Flood. Porque estarias (dentro do que tu imaginou) dando um tempo de 10s para completar o handshake e isto é MUITO TEMPO.

Umas das formas, inclusive, de MINIMAR o ataque é justamente diminuir este tempo nas configurações de cada servidor. Mas NÃO RESOLVE!!

[28] Comentário enviado por alexandre_mpm em 29/03/2008 - 15:48h:

opá muito obrigado elgio pela atenção mas eu não entendi com conexão estabelecida mas sim a serem estabelecidas, imaginamos o seguinte:

Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 2/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP

O cliente envia um pacote com a flag SYN

O server iria receber normalmente, mas se a conexão não fosse estabelecida dentro de 2 segundos essa conexão seria descartada liberando recursos do server.

ah não sei se conhece a ferramenta netwox é muito boa da para realizar diversos testes também mas o hping3 é muito bom também.

[29] Comentário enviado por elgio em 29/03/2008 - 16:18h:

Mas não é assim que o iptables faz.

Mesmo porque, não entendi o seu raciocício, pois se o servidor recebe o SYN, já está criado o cenário para SYN flood. O que o iptables FARIA depois dos dois segundos? Impediria novos pacotes desta conexão semi-aberta? Mas em um ataque de syn float não haverão novos pacotes desta conexão semi-aberta...

"O server iria receber normalmente, mas se a conexão não fosse estabelecida dentro de 2 segundos essa conexão seria descartada liberando recursos do server."

O iptables no roteador iria enviar um alerta para o server para que ele desaloque recursos??? Veja, aqui é uma questão de firewall de rede, onde ele tem que proteger VÁRIOS SERVIDORES, não firewall de host. Firewall e servidor NÃO SÃO A MESMA MÁQUINA.

E repito: mudar o tempo de espera de uma conexão semi estabelecida se faz configurando os tempos de TCP em /proc.

[30] Comentário enviado por agk em 31/03/2008 - 09:05h:

Protege contra os ataques do tipo Syn-flood
iptables -A FORWARD -p tcp --syn -m limit --limit 2/s -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP

Nesse cenário o que o limit faz é limitar o número de conexões SYN a 2/s, ou seja o que passa de 2 conexões por segundo é descartado.

Usando o hping3 é possível deixar indisponível um servidor usando apenas uma estação.

Um jeito de minimizar isso foi bloqueando os pacotes da rede interna que vem de IPs diferentes da minha faixa de rede local.

Ex:
REDE_LOCAL=192.168.0.0/24
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s ! $REDE_LOCAL -j DROP

Na primeira regra você libera a volta dos pacotes, que obviamente vem com ips diferentes da sua rede local e na segunda regra é descartado sumariamente todo e qualquer pacote que não esteja dentro da faixa de rede local.
Lembre-se também que é muito importante deixar a policy do FORWARD em DROP, para as regras acima funcionarem.

Só que isso somente ainda não resolve, apenas minimiza.
Syn Flood em rede local ainda é um problema.

[ ]'s.

[31] Comentário enviado por alexandre_mpm em 31/03/2008 - 09:31h:

Iai agk tudo bem

Era exatamente isso que eu estava querendo dizer, o que passa de 2 segundos e que não for estabelecida a conexão é descartado.

Agora achei interessante sua regra, haja vista que um ataque Syn Flood de uma rede local, pode ser de um prejuízo enorme.

[32] Comentário enviado por elgio em 31/03/2008 - 09:47h:

NÃO É ESTE o comportamento limit!

No caso é somente 2 syn/s independente se for ou não estabelecido. O limit NÃO IMPÕE um tempo para que a conexão seja estabelecida.

Coloque APENAS estas regras no teu firewall:

iptables -A FORWARD -p tcp --syn -m limit --limit 1/minute -j ACCEPT
iptables -A FORWARD -p tcp --syn -j DROP

(sem mais nada)
e tu verás que só conseguirá enviar syn, início de conexão, no ritmo de 1 por minuto, porém poderá enviar QUANTOS acks quiser (com hping3 por exemplo).

Por isto que SEMPRE em qualquer regra de firewall deve-se deixar passar conexões estabelecidas/relacionadas.

Este outro conjunto de regras, por exemplo, seria um DESASTRE:

iptables -A FORWARD -p tcp -m limit --limit 1/minute -j ACCEPT
iptables -A FORWARD -p tcp -j DROP
(sendo APENAS ELAS)

Agora eu limitei todo e qualquer pacote TCP, sendo syn, ack...
Nem mesmo o handshake será completado (pois ele faz passar TRES pacotes e em menos de 1 minuto).

O limit apenas CONTA QUANTOS, por tempo, e não é um timeout para estabelecer.

Lembrando que APENAS os dois primeiros pacotes do handshake possuem o syn ligado e APENAS O PRIMEIRO (inicio de conexão) possui SYN ligado e ACK desligado. O parâmetro --syn do iptables casa com SYN=1, ACK=0, logo, cada com APENAS o primeiro pacote do handshake.

Desta forma estamos apenas limitando o número de início de conexão TCP a X por segundo ou minuto. Nada a ver com tempo de timeout para que a mesma seja estabelecida.

[33] Comentário enviado por elgio em 31/03/2008 - 09:51h:

"Era exatamente isso que eu estava querendo dizer, o que passa de 2 segundos e que não for estabelecida a conexão é descartado."

Não é "o que passa de dois segundos". É o que passa de DOIS por segundo.
E apenas QUANTOS e não um tempo para estabelecer.

O limit não mexe no tempo para estabelecimento de uma conexão.

[34] Comentário enviado por elgio em 31/03/2008 - 09:55h:

E um ataque dentro de uma rede local (SYN FLOOD) pode, ser defendido pela mesma técnica de syn cookie, já que ela é implementada em cada servidor (independe de firewall de rede).

Mas ai já é outra polêmica: um usuário com poder de root em seu micro pode fazer muito mais estrago em uma rede local do que apenas um syn flood! Pode controlar TODA A REDE LOCAL (arp spoofing de gateway, por exemplo).

Ai danou-se por completo!

Por isto que muitas empresas, ou não deixam que seus funcionários entrem com seus notebooks, onde eles serão root (podem usar apenas as máquinas da empresa, sem privilégio) ou criam uma rede seperada para os notebooks, em outra VLAN, com um firewall próprio, enfim.

[35] Comentário enviado por elgio em 31/03/2008 - 10:12h:

Oi agk!

Sim, uma das primeiras coisas que TODO E QUALQUER firewall de rede deve fazer é o tratamento de ip spoofing!

Quando tu disse rede interna, eu imaginei usuários e servidores EM UMA MESMA REDE. Neste cenário que eu expliquei a teoria do "danou-se".

Colocar servidor e usuários em uma mesma rede já é um baita tiro no pé!

Poxa, hoje com switches 802.1q e Linux tu nem precisa de placas de rede extra para colocar os servidores em uma DMZ e protegê-los até mesmo dos teus "inocentes" usuários... :-D

Na Universidade que administro eu tenho TODOS os servidores em uma rede sozinha (hehehe, no caso TODOS são apenas DOIS!!).

Todos os acessos passam pelo firewall que controla IP spoofing.

Tenho regras do tipo:

iptables -A FORWARD -i PlacaRdInterna -s ! RedeInterna -j REJECT

Sim, REJECT e não DROP, para a máquina já ser chutada com um ICMP na hora. O DROP é útil para ajudar a esconder o IP do firewall (vejam que usei a expressão "ajudar a esconder" e não "esconder"...), pois a máquina DROPADA não recebe um aviso do firewall.

Na rede interna não tem tanto motivo assim para econder algo. Melhor é dar REJECT para que a máquina não fique insistindo...

[36] Comentário enviado por alexandre_mpm em 31/03/2008 - 10:16h:

Bom dia elgio

Agora sim ficou claro para mim, eu imaginava como timeout, e vc disse que não é valeu com certeza esse "pequeno debate" enrriqueceu ainda mais o que ja está ótimo (artigo), valeu mesmo pela atenção, e por esclarecer essa dúvida que acredito seja a de muita gente.

[37] Comentário enviado por alexandre_mpm em 31/03/2008 - 10:25h:

rsrs agora só solta a fonte ai de onde tirou tantas informações boas sobre iptables, rsrs

[38] Comentário enviado por elgio em 31/03/2008 - 10:33h:

A maioria do man iptables

Grandes revelações:

man iptables
(...)

limit
This module matches at a limited rate using a token bucket filter. A
rule using this extension will match until this limit is reached
(unless the ‘!’ flag is used). It can be used in combination with the
LOG target to give limited logging, for example.

--limit rate
Maximum average matching rate: specified as a number, with an
optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the
default is 3/hour.
(...)

E depois, testando em máquinas virtuais para ver o efeito.

[39] Comentário enviado por agk em 31/03/2008 - 10:34h:

Olá Elgio,

Acho que estamos enriquecendo o assunto, agora ficou mais claro pra mim, vou ter que fazer um teste, mas quando eu estava utilizando DROP na regra para descartar ip spoofing era preciso apenas algumas máquinas a mais para congestionar o firewall, sim, eu tenho uma DMZ também. Agora vou testar com o REJECT para ver se melhora.

Já tentou usar o hping3 em umas 5 máquinas atirando no gateway(firewall) da sua DMZ?

Eu sempre uso DROP, nunca sei exatamente quando devo usar DROP ou REJECT nas regras do IPTABLES, tenho que avaliar melhor isso.

Obrigado.

[40] Comentário enviado por alexandre_mpm em 31/03/2008 - 10:39h:

Valeu elgio

Muito obrigado!!!

[41] Comentário enviado por elgio em 31/03/2008 - 10:44h:

Pois é.

Ë que quando tu dá um DROP, a máquina que gerou o pacote não sabe o que aconteceu com ele. Logo ela tenta denovo, e denovo, e denovo... gerando muitos pacotes.

Já um REJECT devolve um icmp tipo 3 (destino inacessível) rapidamente informando a máquina do ocorrido.

Podes fazer um teste se puderes para ver os efeitos. Selecione um destino HTTP como teste e bloqueie ele no firewall:

iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j DROP
iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j LOG

(-I para entrar PRIMEIRO, antes de regras que já tenha)

Tente acessar de um navegador do teu cliente e observe:
a) a quantidade de logs geradas no teu firewall para o teu IP de teste
b) a demora que teu navegador levou para acusar erro!

Depois remova as regras:
iptables -D FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j DROP
iptables -D FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j LOG

E insira com REJECT:
iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j REJECT
iptables -I FORWARD -s TuaMaqTeste -d IpDestinoTeste -p tcp --dport 80 -j LOG

Verás que APENAS um pacote será logado e teu navegador, no cliente, rapidamente acusará erro.

Qual é melhor?
Depende!
REJECT gera menos trafego, mas conta para todo mundo o IP do teu firewall (Porque o firewall avisa "Joguei fora teu pacote").

DROP gera mais trafego e mais logs, até os clientes desistirim, mas CONTRIBUI para esconder o IP do teu firewall (um atacante descobrindo o ip do teu firewall pode fazer um finger print nele e descobrir vulnerabilidades. É FATO que não se deve ter segurança por obscuridade, ou seja, minha rede deve ser SEGURA mesmo que todos saibam os detalhes dela, mas claro que vou esconder o máximo. Pra que facilitar?)

[42] Comentário enviado por elgio em 31/03/2008 - 11:05h:

Alexandre:

Quando escrevi os dois artigos sobre iptables, mas sem entrar em detalhes statefull, me cobraram referências. Ai eu citei algumas que andei lendo na Internet. Elas estão NÃO NO ARTIGO, mas em um comentário meu postado no artigo:
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834

São elas:

http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html#ss3.1
Howto do netfilter, onde mostra os caminhos de um pacote.

http://iptables-tutorial.frozentux.net/iptables-tutorial.html
Tutorial do iptables. Destaque para a introdução sobre redes. Legal que ele inclusive descreve o novo protocolo SCTP, uma evolução do TCP, digamos assim.

ftp://ftp.registro.br/pub/gts/gts0103/gts-2003-artur_jarbas-iptables.pdf
Slides sobre o netfilter, muito completo, embora desatualizado (já se passaram 4 anos e muitos novos módulos do iptables foram amadurecidos ou construidos)

[43] Comentário enviado por alexandre_mpm em 31/03/2008 - 11:39h:

Muito obrigado elgio

Esse artigo eu li quando saiu do forno
Estrutura do Iptables
http://www.vivaolinux.com.br/artigos/verArtigo.php...

Estrutura do IPTables 2: a tabela nat
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=6834

e está também no meus favoritos!!!

[44] Comentário enviado por elgio em 06/04/2008 - 17:46h:

Guia Foca!

Hoje percebi que a "receita de bolo" para a falsa proteção de SYN FLOOD por iptables está publicada no guia Foca avançado. Entrei em contato com o autor para que ele reveja isto.

[45] Comentário enviado por removido em 06/04/2008 - 21:52h:

Excente artigo!

Slackmaster ( jlgomessouza@hotmail.com)

http://dangercode.awardspace.com

[46] Comentário enviado por equeiroga em 02/06/2008 - 20:18h:

Elgio,

O artigo, realmente, ficou MUITO bom, mas depois de tanto se falar de ataques SYN Flood, acabei ficando um pouco confuso sobre a defesa para este ataque. Minha pergunta é: Basta ativar o "tcp_syncookies" e o problema está resolvido???
Espero não ter sido uma pergunta 'idiota' :)

Enfatizo novamente: O artigo ficou MUITO bom!!!! Show de bola mesmo!!!

[47] Comentário enviado por elgio em 03/06/2008 - 15:55h:

Em agosto de 2007 (comtemporâneo a este artigo) foi publicada uma RFC sobre SYN Flood e formas de defesa. Muito interessante:

http://rfc-editor.org/rfc/rfc4987.txt

[48] Comentário enviado por fsoaress76 em 13/06/2008 - 13:08h:

muito bom esse artigo, nao sabia disso não.

nota:10!

[49] Comentário enviado por elgio em 13/06/2008 - 13:46h:

Fiz uma palestra sobre Negação de serviços no evento TcheLinux. A mesma pode ser BAIXADA no endereço http://gravatai.ulbra.tche.br/tchelinux2008

[50] Comentário enviado por cytron em 14/06/2008 - 02:14h:

Opa!!! Tive que voltar o valor de tcp_syncookies para 0, pois com valor 1 o tráfego na rede ficou muito estranho, tinha hora que um server não encontrava o outro, bastava colocar 0 novamente e tudo voltava ao normal.

Não sei explicar isso e deve ter solução, mas estou sem tempo agora.

[51] Comentário enviado por walterti em 02/07/2009 - 12:10h:

Ótimo artigo!
Simplesmente perfeito

[52] Comentário enviado por murilosilva em 09/07/2009 - 17:00h:

Elgio,

Parabéns pelo artigo. Muito bom mesmo, realmente de qualidade.

Só fiquei com uma duvida no final, onde você diz: "O fato é que a imensa maioria preocupa-se em não ser atacado, e raramente se preocupam em não permitir que seus clientes ataquem!"

Qual seria o risco para o provedor em aplicar uma regra que impede o ip spoofing?

Valeu!

[53] Comentário enviado por linus black em 18/08/2009 - 02:45h:

#
# rc.firewall .By Linus Black For slackware12.2
#
#
#
modprobe ip_tables
modprobe ip_conntrack
modprobe iptable_filter
modprobe iptable_mangle
modprobe iptable_nat
modprobe ipt_LOG
modprobe ipt_limit
modprobe ipt_state
modprobe ipt_REDIRECT
modprobe ipt_owner
modprobe ipt_REJECT
modprobe ipt_MASQUERADE
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
modprobe ip_gre
#
#Limpa as Regras
iptables -F
iptables -X
iptables -F -t nat
iptables -X -t nat
iptables -F -t mangle
iptables -X -t mangle
#
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/accept_source_route
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/log_martians
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "1800" > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1" > /proc/sys/net/ipv4/tcp_ecn
echo "1" > /proc/sys/net/ipv4/tcp_timestamps
echo "::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
echo "=========================================================|"
echo "|:INICIANDO A CONFIGURA\'c7\'c3O DO FIREWALL NETFILTER ATRAV\'c9S:|"
echo "|: DO IPTABLES :|"
echo "=========================================================|"
echo "::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
#Politicas Padrao
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
#
### Ativando Protecoes Contra Ataques ###
# 1 - Protecao contra Trinoo
iptables -N TRINOO
iptables -A TRINOO -m limit --limit 1/s -j LOG --log-level 6 --log-prefix "FIREWALL(Prot. Trinoo): "
iptables -A TRINOO -j DROP
iptables -A INPUT -p tcp -i eth0 --dport 27444 -j TRINOO
iptables -A INPUT -p tcp -i eth0 --dport 27665 -j TRINOO
iptables -A INPUT -p tcp -i eth0 --dport 31335 -j TRINOO
iptables -A INPUT -p tcp -i eth0 --dport 34555 -j TRINOO
iptables -A INPUT -p tcp -i eth0 --dport 35555 -j TRINOO
echo "ativado o bloqueio a tentativa de ataque do tipo Trinoo"
echo "ON .................................................[ OK ]"
# 2 - Protecao contra Trojans
iptables -N TROJAN
iptables -A TROJAN -m limit --limit 1/s -j LOG --log-level 6 --log-prefix "FIREWALL(Prot. Trojan): "
iptables -A TROJAN -j DROP
iptables -A INPUT -p tcp -i eth0 --dport 666 -j TROJAN
iptables -A INPUT -p tcp -i eth0 --dport 666 -j TROJAN
iptables -A INPUT -p tcp -i eth0 --dport 4000 -j TROJAN
iptables -A INPUT -p tcp -i eth0 --dport 6000 -j TROJAN
iptables -A INPUT -p tcp -i eth0 --dport 6006 -j TROJAN
iptables -A INPUT -p tcp -i eth0 --dport 16660 -j TROJAN
echo "ativado o bloqueio a tentativa de ataque do tipo Trojan"
echo "ON .................................................[ OK ]"
# 3 - Protecao contra Worms
iptables -A FORWARD -p tcp --dport 135 -i eth0 -j REJECT
echo "ativado o bloqueio a tentativa de ataque do tipo Worms"
echo "ON .................................................[ OK ]"
# 4 - Protecao contra Syn-Flood
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
echo "ativado o bloqueio a tentativa de ataque do tipo Syn-Flood"
echo "ON .................................................[ OK ]"
# 5 - Protecao contra Ping da Morte
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
echo "ativado o bloqueio a tentativa de ataque do tipo ping "
echo "ON .................................................[ OK ]"
# 6 - Protecao contra Port Scanners
iptables -N SCANNER
iptables -A SCANNER -m limit --limit 1/s -j LOG --log-level 6 --log-prefix "FIREWALL(Port Scanner): "
iptables -A SCANNER -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags ALL NONE -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags ALL ALL -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags ALL FIN,SYN -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -i eth0 -j SCANNER
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -i eth0 -j SCANNER
iptables -A INPUT -p udp -s 0/0 -i eth0 --dport 33435:33525 -j REJECT
iptables -A INPUT -m state --state INVALID -j REJECT
echo "ativado o bloqueio a tentativa de ataque do tipo Scanners"
echo "ON .................................................[ OK ]"
#
#Rotiamento e redirecionamento
#iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
echo "ativado o Rotiamento"
echo "ON .................................................[ OK ]"
#
#Liberando rrede interna
iptables -A OUTPUT -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -s 192.168.0.0/16 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -s 192.168.0.15 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
#
#Mantendo a coneo
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# BLOQUEA O QUE NAO SE ENCAIXA NAS REGRAS ACIMA
iptables -A INPUT -p tcp --syn -j DROP
iptables -P FORWARD DROP
echo "::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
echo "=========================================================|"
echo "|: CARREGAMENTO BEM SUSSEDIDO :|"
echo "|: DO IPTABLES :|"
echo "=========================================================|"
echo "::::::::::::::::::::::::::::::::::::::::::::::::::::::::::"
sera que é isso?
é uma coisinha que estou trabalhando e seu artigo ta 10!

[54] Comentário enviado por magnolinux em 16/11/2009 - 11:21h:

Elgio muito bom...

sempre surpreendendo com seus artigos ...

[55] Comentário enviado por gregorye em 18/02/2010 - 14:51h:

Muito Bom mesmo!

[56] Comentário enviado por guto.rodrigues em 04/03/2010 - 15:11h:

amigo !!! seu artigo é perfeito... vc não tem idéia do favor que vc me fez !!!

[57] Comentário enviado por mxfera em 21/04/2010 - 14:44h:

Muito bom seu artigo amigo, me ajudou muito vlw mesmo..

[58] Comentário enviado por hugoalvarez em 29/04/2010 - 11:06h:

Mto legal esse artigo, eu nem reclamaria se tivesse mais teoria envolvida pq foi mesmo uma aula.

[59] Comentário enviado por fernandoreis em 06/07/2010 - 14:17h:

Prezado Elgio,

excelente a sua explicação sobre o SYN FLOOD. Já tinha lido outras explicações mas nenhuma foi tão clara e objetiva como a sua.

Preciso que vc me esclareça uma duvida:

Liguei meu computador caseiro e logo apareceu uma informação do McAfee Host Intrusion Prevention me informando que eu estava sofrendo um ataque de SYN FLOOD e se eu queria bloquear essa ação? Bloqueei é claro mas por umas 5 vezes , durante os dois dias seguintes , apareceu essa mensagem e depois cessou. Como na sua explicação esse ataque é feito contra servidor e eu estava em um cp em casa , o que ocorreu realmente comigo?

abraço

Fernando