O segredo está na manipulação dos números seqüenciais e de verificação do TCP. Não quero aqui explicar o que são estes números e para que servem, pois o artigo ficaria muito pesado. Mas basta dizer que:

1. quando o cliente envia o primeiro SYN, envia também um número de 32 bits. chamado número de seqüência (vamos chamar de NS-C, número de seqüência do cliente)

2. quando o servidor recebe o SYN, ele também escolhe um NS para si (NS-S, número de seqüência do servidor) e devolve o pacote com dois números: o seu NS-S e o número de verificação, chamando de ACK (diferente do flag, este tem também 32 bits). Este segundo número nada mais é do que NS-C+1.

3. o cliente, ao completar o handshake, devolve NS-C+1 e NS-S + 1.

Um exemplo para clarear as idéias:



Ou seja, em cada pacote a máquina devolve como NACK o SN do outro anterior + 1. Ai está o "pulo do gato" da técnica Syn cookie. Quando o servidor escolhe o seu NS (no exemplo, 200), ele o faz através de uma função hash de 32 bits, onde serão consideradas informações como IP/Porta do cliente e dados que só o servidor tem. O servidor gera este número e esquece! (não aloca recursos, portanto).

O fato é que quando vier o último pacote, com o NACK=201, o servidor refaz o cálculo do HASH, pois nenhum dado foi alterado. Refazendo o cálculo ele encontra 200, que é justamente o número recebido menos um. Ou o cliente é legítimo, pois completou o handshake ou é um cara de muita sorte.

Observe que um atacante está impossibilitado de realizar o SYN flood, pois ele não recebe o pacote SYN/ACK que tem o NS-S= 200. Como ele falsificou o IP (ele precisa) este pacote foi lá para o Ip falso que o atacante inventou. Logo o atacante não conhece o valor de NS-S (200) para poder devolvê-lo com mais um(201). Lhe resta adivinhar ou quebrar o fraco hash de 32 bits. Mas veja, ele é fraco mas resolve. Se o atacante precisar de 3 segundos para quebrar, isto já é uma eternidade para que o SYN flood realmente cause uma negação de serviço.

Conclusão

Ataques de SYN flood são sofisticados, envolvem falsificação de números Ips e diversas máquinas atuando em conjunto. Soluções por firewall são insuficientes.

A utilização de firewalls deveria sim ser empregada no sentido de evitar o ip spoofing, coisa que muitos provedores de acesso não fazem. Se sou um provedor de acesso, por exemplo, e minha faixa de ips é 192.168.0.0/16 (estou usando ips privados por questões éticas), como eu deixo um assinante meu gerar um pacote com ip de origem sendo 172.16.5.4?

Ora, eu deveria, ao menos, ter uma regra bem simples no meu firewall:


Pronto. Impedi que meus clientes façam ip spoofing. Ah se todos os provedores do mundo fizessem isto... 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!