SYN flood

Falar um pouco sobre o ataque SYN flood. Essa semana eu li bastante sobre o assunto e implementei algumas políticas de segurança.
Então, para falar sobre o SYN flood é necessário dar uma pincelada sobre o protocolo TCP.

TCP é um protocolo do nível da camada de transporte, sobre o qual assentam a maioria das aplicações, como o SSH, FTP, HTTP e outros. Para que exista conexão é necessário que o cliente converse com o servidor, essa conversa é realizada pelo handshake, o mesmo é um mecanismo de estabelecimento e finalização de conexão a três e quatro tempos, respectivamente, o que permite a autenticação e encerramento de uma sessão completa. O TCP garante que, no final da conexão, todos os pacotes foram bem recebidos.

Para que exista essa conexão o TCP especifica três fases, sendo elas: estabelecimento da ligação, transferência e término de ligação. Vou focar apenas na parte de estabelecimento de ligação, pois é onde o SYN flood ocorre.

Em uma conexão temos um servidor(que abre um socket e espera passivalmente por ligações) num extremo e no outro temos o cliente. A ligação acontece em 3 passos sendo eles:

1. O cliente envia uma solicitação de conexão, com um pacote TCP sem dados, possuindo o flag de SYN(synchronize) ligado e os demais desligados. Se, durante um determinado espaço de tempo, esse pacote não for recebido ocorre um timeout e o pacote SYN é reenviado.

2. Se o servidor quiser e puder atender, devolve um pacote ao cliente ainda sem dados, com os flags de SYN e de ACK(acknowledge) 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).

Vale lembrar que o servidor quando quer atender ao primeiro pedido de SYN ele deve alocar recursos de hardware(memória e processamento) para atender a conexão. Ou seja, é possível alocar todos os recuros do hardware apenas com pacotes SYN, dessa forma, com todos os recursos ocupados, nenhuma conexão pode ser realizada, resultando em negação de serviços. Como isso é possível ? Vamos pensar um pouco!

O cliente pode muito bem não responder no terceiro passo onde envolve o envio do ACK ligado e SYN desligado, fazendo com que a máquina deixe os recursos alocados, mas isso fica para sempre ? Não, depois de um certo tempo em que o servidor não recebe o ACK ele desaloca, liberando recursos alocados. Aí que entra o SYN flood, onde o atacante gera quantos pacotes SYN a máquina dele for capaz e não responde nenhum, em alguns casos usam até várias máquinas, com ip spoofing, gerando o que conhecemos como negação de serviço distríbuido.

Existem algumas formas de tratar o SYN flood, entre elas: iptables, blocked ip, syn cookies. Duas técnicas furadas e uma que funciona de fato. Em um novo post vou falar um pouco sobre iptables e syn cookies e como implementar os dois. O syn cookies exige um pouco de conhecimento sobre hash.

É isso, valeu! Vou dormir, tô cansado!

Posted in: