Iptables protege contra SYN FLOOD?
Uma das técnicas de negação de serviço mais conhecidas é a técnica de Syn Flood. Mas se encontra em diversos lugares "receitas" e regrinhas iptables para se defender dela. Funciona? É eficaz? Se não é, qual é realmente a defesa necessária?
[ Hits: 413.927 ]
Por: Elgio Schlemer em 29/08/2007 | Blog: https://profelgio.duckdns.org/~elgio
O que é o Syn Flood?
Para entender o Syn Flood é preciso, mesmo que rapidamente, falar um pouco do TCP.
O protocolo TCP é orientado a conexão: primeiro cliente e servidor se conectam e somente após esta etapa é que os dados podem ser trocados. Semelhante a uma ligação telefônica, onde deve-se primeiro discar para o número.
A etapa de "discar" no TCP é chamada de handshake de três vias e os flags TCP são usados para sinalizar qual etapa se está realizando. Antes de qualquer bit de dados, a seguinte troca de pacotes acontece entre cliente e servidor:
1. O cliente envia uma solicitação de conexão, com um pacote TCP sem dados, possuindo o flag de SYN ligado e os demais desligados. Por causa da presença do flag de SYN, este pacote é conhecido como pacote SYN
2. Se o servidor quiser e puder atender, devolve um pacote ao cliente ainda sem dados, com os flags de SYN e de ACK ligados. Esta segunda etapa é conhecida como SYN/ACK.
3. Se o cliente ainda quiser manter a conexão, devolve ao servidor um terceiro pacote sem dados, apenas com o flag de ACK ligado (SYN desligado).
Somente após a terceira etapa é que os dados podem ser trocados.
O mais importante para entender a gravidade do ataque é saber que o servidor, ao receber o primeiro pacote (SYN), se ele quiser atender (exemplo: serviço HTTP, porta 80), precisa antes de responder com o SYN/ACK, alocar recursos de hardware para atender esta nova conexão.
Como o TCP é um protocolo confiável, que trata de desordenamento e perdas de pacotes, estes recursos não são poucos, pois envolvem buffers de envio e de recebimento, controle de números seqüenciais, relógios diversos, enfim, muitos recursos de memória, principalmente.
E o que acontece se uma máquina fizer o SYN (etapa 1), o servidor alocar recursos e responder com o SYN/ACK (etapa 2) mas o cliente não completa o handshake e não realiza a última etapa? Os recursos ficam alocados?
Ficam, mas não para sempre. O servidor fica esperando o ACK do cliente e se o mesmo não chegar depois de certo tempo, os recursos são desalocados. Mas o fato é que estes recursos realmente permanecem alocados por algum tempo, mesmo que curto.
Aí que entra o SYN Flood (tradução literal: inundação de SYN). Nele o atacante gera quantos SYN's a máquina dele for capaz e não responde nenhum deles. Tem-se que o servidor vai alocar recursos para cada um, como se fossem requisições legítimas, só desalocando quando acabar o tempo. É perfeitamente compreensível que o atacante consegue gerar pacotes de SYN muito mais rapidamente e facilmente do que o servidor consegue tratá-los.
Claro, hoje temos hardware com capacidades de memória e recursos gigantescos, mas não existem recursos infinitos. Mais cedo ou mais tarde os recursos se esgotarão e o servidor ficará incapaz de atender clientes legítimos.
Este é o SYN flood!
O protocolo TCP é orientado a conexão: primeiro cliente e servidor se conectam e somente após esta etapa é que os dados podem ser trocados. Semelhante a uma ligação telefônica, onde deve-se primeiro discar para o número.
A etapa de "discar" no TCP é chamada de handshake de três vias e os flags TCP são usados para sinalizar qual etapa se está realizando. Antes de qualquer bit de dados, a seguinte troca de pacotes acontece entre cliente e servidor:
1. O cliente envia uma solicitação de conexão, com um pacote TCP sem dados, possuindo o flag de SYN ligado e os demais desligados. Por causa da presença do flag de SYN, este pacote é conhecido como pacote SYN
2. Se o servidor quiser e puder atender, devolve um pacote ao cliente ainda sem dados, com os flags de SYN e de ACK ligados. Esta segunda etapa é conhecida como SYN/ACK.
3. Se o cliente ainda quiser manter a conexão, devolve ao servidor um terceiro pacote sem dados, apenas com o flag de ACK ligado (SYN desligado).
Somente após a terceira etapa é que os dados podem ser trocados.
O mais importante para entender a gravidade do ataque é saber que o servidor, ao receber o primeiro pacote (SYN), se ele quiser atender (exemplo: serviço HTTP, porta 80), precisa antes de responder com o SYN/ACK, alocar recursos de hardware para atender esta nova conexão.
Como o TCP é um protocolo confiável, que trata de desordenamento e perdas de pacotes, estes recursos não são poucos, pois envolvem buffers de envio e de recebimento, controle de números seqüenciais, relógios diversos, enfim, muitos recursos de memória, principalmente.
E o que acontece se uma máquina fizer o SYN (etapa 1), o servidor alocar recursos e responder com o SYN/ACK (etapa 2) mas o cliente não completa o handshake e não realiza a última etapa? Os recursos ficam alocados?
Ficam, mas não para sempre. O servidor fica esperando o ACK do cliente e se o mesmo não chegar depois de certo tempo, os recursos são desalocados. Mas o fato é que estes recursos realmente permanecem alocados por algum tempo, mesmo que curto.
Aí que entra o SYN Flood (tradução literal: inundação de SYN). Nele o atacante gera quantos SYN's a máquina dele for capaz e não responde nenhum deles. Tem-se que o servidor vai alocar recursos para cada um, como se fossem requisições legítimas, só desalocando quando acabar o tempo. É perfeitamente compreensível que o atacante consegue gerar pacotes de SYN muito mais rapidamente e facilmente do que o servidor consegue tratá-los.
Claro, hoje temos hardware com capacidades de memória e recursos gigantescos, mas não existem recursos infinitos. Mais cedo ou mais tarde os recursos se esgotarão e o servidor ficará incapaz de atender clientes legítimos.
Este é o SYN flood!
Páginas do artigo
1. Como este artigo está organizado2. Mas o que é DoS?
3. Tipos de negação de serviço
4. O que é o Syn Flood?
5. Solução FURADA 1: bloquear o IP do atacante
6. Limitar o número de requisições no iptables funciona?
7. Tudo bem, me convenceu. Qual é a saída?
8. Como funciona o SYN cookie?
Outros artigos deste autor
Cuidado com números em Ponto Flutuante
Criptografia chave simétrica de bloco e de fluxo
Autenticação por desafio e resposta no SSH
Criptografia assimétrica com o RSA
255.255.255.0: A matemática das máscaras de rede
Leitura recomendada
Descobrindo serviço através das portas
Tor no BackTrack 5 - Instalação, configuração e utilização
Comentários
[1] Comentário enviado por phelipe em 29/08/2007 - 11:34h
Ótimo! Simplesmente ótimo... parabéns! :-)
Ó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.
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
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
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.
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.
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 removido em 29/08/2007 - 13:47h
Pois é. botando as caraminholas para funcionar a gente vai muito mais longe do que pensa!!!
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.
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!
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 Ed_slacker em 29/08/2007 - 17:11h
Apenas uma palavra para resumir este artigo:
SEN-SA-CIO-NAAAAAAAAAAAAAAAAALLLLLL!!!!!!!
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
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.
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
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
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
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.
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 removido em 30/08/2007 - 11:27h
excelente! estava esperando um tutorial desta qualidade, pois ja estava irritando o "control c control v" de amadores
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
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é +!!!!!
Artigo maravilhoso!!!!!
Mais claro que isso impossível!!!!
Parabéns.
Até +!!!!!
[20] Comentário enviado por gersonraymond em 02/09/2007 - 08:20h
Extremamente genial este artigo, parabéns pelo refinamento técnico e qualidade extraordinária.
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.
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.
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!!!
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!
Caraca Maluco!!!
[O.O]
Esse cara é bom!
[25] Comentário enviado por jpgribeiro em 19/02/2008 - 12:39h
Excelente, simples e objetivo, adorei!!!
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.
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!!
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.
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.
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.
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.
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.
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.
"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.
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...
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.
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
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.
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.
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.
[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?)
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)
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!!!
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.
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
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!!!
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
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!
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
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.
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.
[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!
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 magnolinux em 16/11/2009 - 11:21h
Elgio muito bom...
sempre surpreendendo com seus artigos ...
Elgio muito bom...
sempre surpreendendo com seus artigos ...
[55] 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 !!!
amigo !!! seu artigo é perfeito... vc não tem idéia do favor que vc me fez !!!
[56] Comentário enviado por mxfera em 21/04/2010 - 14:44h
Muito bom seu artigo amigo, me ajudou muito vlw mesmo..
Muito bom seu artigo amigo, me ajudou muito vlw mesmo..
[57] 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.
Mto legal esse artigo, eu nem reclamaria se tivesse mais teoria envolvida pq foi mesmo uma aula.
[58] 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
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
[59] Comentário enviado por julianderson em 27/09/2010 - 18:15h
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
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
[61] Comentário enviado por pedrorawan em 25/02/2011 - 11:48h
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!
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!
[62] Comentário enviado por rnduart em 29/04/2011 - 16:02h
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.
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.
[63] Comentário enviado por cleristonm em 13/03/2012 - 12:35h
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 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
[64] Comentário enviado por Carlos_Cunha em 05/10/2012 - 13:55h
Parabéns !!!!
artigo muito bem feito e vc soube explicar de uma forma simples e precisa!!
Abraço
Parabéns !!!!
artigo muito bem feito e vc soube explicar de uma forma simples e precisa!!
Abraço
[65] Comentário enviado por donysilva em 02/10/2015 - 08:34h
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
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
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Como renomear arquivos de letras maiúsculas para minúsculas
Imprimindo no formato livreto no Linux
Vim - incrementando números em substituição
Efeito "livro" em arquivos PDF
Como resolver o erro no CUPS: Unable to get list of printer drivers
Tópicos
Não to conseguindo resolver este problemas ao instalar o playonelinux (1)
Excluir banco de dados no xampp (1)
Top 10 do mês
-
Xerxes
1° lugar - 65.395 pts -
Fábio Berbert de Paula
2° lugar - 50.839 pts -
Buckminster
3° lugar - 17.543 pts -
Mauricio Ferrari
4° lugar - 15.308 pts -
Alberto Federman Neto.
5° lugar - 13.919 pts -
Diego Mendes Rodrigues
6° lugar - 13.622 pts -
Daniel Lara Souza
7° lugar - 12.989 pts -
Andre (pinduvoz)
8° lugar - 10.372 pts -
edps
9° lugar - 10.477 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 10.384 pts
Scripts
[Python] Automação de scan de vulnerabilidades
[Python] Script para analise de superficie de ataque
[Shell Script] Novo script para redimensionar, rotacionar, converter e espelhar arquivos de imagem
[Shell Script] Iniciador de DOOM (DSDA-DOOM, Doom Retro ou Woof!)
[Shell Script] Script para adicionar bordas às imagens de uma pasta
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
