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?
Parte 4: 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!