Iptables protege contra SYN FLOOD?

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

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.

Isso que é artigo :D

Parabens +Favoritos

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

Abraços,
Daniel

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.

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.

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

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.

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

Apenas uma palavra para resumir este artigo:

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

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

parabens

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.

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

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

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

Parabéns

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.

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

quero instalar programas no ubuntu sou novo na area

Artigo maravilhoso!!!!!

Mais claro que isso impossível!!!!

Parabéns.

Até +!!!!!

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

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

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.

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!!!

Caraca Maluco!!!

[O.O]

Esse cara é bom!

Excelente, simples e objetivo, adorei!!!

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.

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!!

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.

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.

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.

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.

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.

"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.

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.

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...

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.

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

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.

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.

Valeu elgio

Muito obrigado!!!

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?)

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)

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!!!

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.

Excente artigo!

Slackmaster ( jlgomessouza@hotmail.com)

http://dangercode.awardspace.com

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 '[*****]' :)

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

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

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

nota:10!

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

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.

Ótimo artigo!
Simplesmente perfeito

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!

Elgio muito bom...

sempre surpreendendo com seus artigos ...

Muito Bom mesmo!

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

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

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

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

Amigao eu sou novo no mundo linux e eu estou precisando montar um firewall, voce poderia me ajudar por favor, pois alguns membros do vol ja mandara eu ter um professor particular, voce poderia me ajudar meu email e dril_jsp@hotmail.com

eigio eu fico muito grato pela ajuda ta ok

caso contrario obrigado

Muito bom.
Nota 10!

Cara!!! Muito bom esse artigo, me ajudou bastante. Já tava quase fazendo uma proteção para Syn Flood no firewall. Muito obrigado !
Mas fica a dica para proximos artigos PAM limits.

Valeu!

Estou começando agora no Linux e estou querendo fazer um iptables faz 3 dias já consigo entender o básico dos comandos paramentos e regras, mas não sabia o que é: syn food, spoofing, etc, que tanto tem nesses iptables de exemplos. Com seu artigo as coisas estão ficando cada vez mais claras.

Parabéns pelo artigo!
Além de syn flood, ping of death e brute force quais outros tipos de ataques devemos nos preocupar em um script de firewall

Parabéns !!!!
artigo muito bem feito e vc soube explicar de uma forma simples e precisa!!
Abraço

Elgio sou novo em iptables
erro no meu iptables uso ipcop será que funciona bem?
Bad argument `192.168.95.0/16'
a placa assinante é meu ip válido ou minha interface de rede com saída pra internet
no caso a placa RED

Parabéns pelo post

Grato