ATAQUE SYN FLOOD: ENTENDO SEU FUNCIONAMENTO E MITIGAÇÃO

Antes de mais nada, quero esclarecer que este artigo não vai trazer uma fórmula mágica para mitigação de um ataque do tipo SYN Flood. Vou abordar boas práticas que vão permitir dificultar o ataque de obter êxito em determinadas situações. Prometer algo infalível não condiz com a realidade atual onde, a cada dia, surgem novas vertentes de ataques.

Os ataques TCP SYN Flood são os mais populares entre os ataques DDOS. Aqui vamos discutir em detalhes a base do ataque TCP SYN e possibilidades de mitigação antes que ele atinja seus servidores servidores.

Já se passaram mais de duas décadas quando o primeiro ataque DDOS foi tentado na Universidade de Minnesota, que derrubou seuse servidores por dois dias. Muitos se seguiram, incluindo um dos maiores da história do DDOS, que era contra o Github e envolvia um ataque de 1,35 TBps contra o site. Os ataques de DDOS representam sérias ameaças a servidores e sites, inundando os servidores alvo com tráfego falso e, portanto, negando o acesso a tráfego legítimo.



Como funcionada a comunicação TCP/IP entre um cliente e um servidor?

De uma maneira bem simples, a comunicação é feita da seguinte forma:

1. O cliente envia um pacote com a flag SYN(Synchronize - Sincronizar) ativa
2. O servidor responde com um pacote com as flags SYN + ACK(Acknowledgement - Reconhecimento)
3. O cliente reponde com um pacote ACK

Este método é conhecido como aperto de mão em três etapas. O problema é quando essa última mensagem (ACK) não é enviada em confirmação do fechamento da conexão com o servidor gerando assim uma conexão semi-aberta e fazendo com que o servidor fique aguardando o fechamento desta.

No ataque Syn flood, várias conexões semi-abertas podem ser geradas no servidor e isso gera um alto consumo de memória. Dependendo da quantidade de requisições dessa natureza, pode acarretar uma negação de serviço indisponibilizando o servidor. Dessa forma, conexões legítimas não serão concretizadas.

O que pode ser feito?

Uma possibilidade a ser utilizada para mitigar um ataque syn flood seria ativar o recurso de syn cookies no kernel do Linux. O syn cookies é uma implementação para a pilha TCP/IP, em vez de armazenar na memória RAM a requisição de um cliente, o servidor responde ao cliente com um cookie(pacote de dados). Quando o servidor cria o número sequencial de início da conexão, não gerado de forma aleatória, onde este contem o "hash" composto pelo timestamp, porta de origem e destino bem como o endereço de IP e o tamanho máximo do segmento. Desta maneira o servidor não precisa armazenar a solicitação na memória e quando o cliente enviar o ACK para o servidor onde este já terá o cookie numerado acrescido de um. Isso permite recalcular o cookie fazendo a operação inversa de checagem afim de determinar a verdadeira idoneidade do pacote legitimando a conexão. Essa sincronização de cookies só vai ocorrer quando a fila de requisições estiver cheia.

Para ativar o syn cookies no Linux, execute o comando:

# sysctl -w net.ipv4.tcp_syncookies=1

Acrescente os comandos abaixo:

# sysctl -w net.ipv4.tcp_max_syn_backlog=2048
# sysctl -w net.ipv4.tcp_synack_retries=3

A fila de backlog é uma estrutura de memória grande usada para manipular pacotes de entrada com o sinalizador SYN definido até o momento em que o processo de handshake de três vias é concluído. Um sistema operacional aloca parte da memória do sistema para cada conexão de entrada. Sabemos que cada porta TCP pode lidar com um número definido de pedidos de entrada. A fila de backlog controla quantas conexões semi-abertas podem ser tratadas pelo sistema operacional ao mesmo tempo. Quando um número máximo de conexões de entrada é atingido, solicitações subseqüentes são ignoradas silenciosamente pelo sistema operacional.


Por causa do 3 way handshake (aperto de mão em três etapas) usado para a realização de uma conexão TCP, uma conexão de entrada passa por um estado intermediário chamado de Syn RECEIVED antes de alcançar o estado de ESTABLISHED e assim poder retornar a aceitar a chamada de sistema de uma aplicação. Há duas implantações para a fila de backlog:

1. Implementação de fila única, cujo tamanho é determinado pelo argumento backlog do syscall(chamada de sistema) de escuta. Quando um pacote SYN é recebido, envia de volta um pacote SYN / ACK e adiciona a conexão à fila. Quando o ACK correspondente é recebido, a conexão muda seu estado para ESTABLISHED e torna-se elegível para handover para o aplicativo. Isso significa que a fila pode conter conexões em dois estados diferentes: SYN RECEIVED e ESTABLISHED. Somente conexões no último estado podem ser retornadas para o aplicativo que realizou a chamada de sistema.
2. Implementação usando duas filas, uma fila SYN (ou fila de conexão incompleta) e uma fila de aceitação (ou fila de conexão completa). As conexões no estado SYN RECEIVED são adicionadas à fila SYN e mais tarde movidas para a fila de aceitação quando seu estado muda para ESTABLISHED, ou seja, quando o pacote ACK no handshake de 3 vias é recebido. Como o nome indica, a chamada de aceitação é então implementada simplesmente para consumir conexões da fila de aceitação. Nesse caso, o argumento backlog do syscall de escuta determina o tamanho da fila de aceitação.

Sob um ataque SYN, podemos modificar a fila de backlog para suportar mais conexões no estado semi-aberto sem negar o acesso a clientes legítimos. Em alguns sistemas operacionais, o valor da fila de backlog é muito baixo e seguindo as boas práticas para mitigação desse ataque, geralmente recomenda-se aumentar a fila SYN quando um sistema está sob ataque.

E o último comando apresentado, syn/ack_retries, representa o número de vezes que uma resposta SYN / ACK para um SYN é repetida. Um valor menor significa menos uso de memória e menor impacto de ataques de inundação SYN. O intervalo de tempo entre cada reenvio é de 3 segundos, e dobrando a cada espera. Como foi configurado para o valor de 3, ficaria assim: 3segundos depois passaria para 6 segundos e por fim para 12 segundos. Somando teríamos 21 segundos e aí seria encerrada uma conexão semi-aberta.


Para tornar esses comandos permanentes, mesmo após uma reinicialização do sistema, inclua-os no arquivo /etc/sysctl.conf.  Para quem usa Mikrotik em sua borda, seguem alguns comandos para mitigação desse ataque:

/ip firewall filter add chain=forward protocol=tcp tcp-flags=syn connection-state=new action=jump jump-target=SYN-Protect comment="SYN Flood protect" disabled=yes

/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn limit=400,5 connection-state=new action=accept comment="" disabled=no


/ip firewall filter add chain=SYN-Protect protocol=tcp tcp-flags=syn connection-state=new action=drop comment="" disabled=no

/ip settings set tcp-syncookies=yes

 Dúvidas, críticas ou sugestões é só postar nos comentários. Se gostou curte e compartilha. Até a próxima!

------------------------

É iniciante na área de Segurança da Informação? Recomendamos o curso de Segurança em Redes de Computadores do Marcos Cavinato. Nele você terá toda a base necessária  para entender os conceitos e melhores práticas de Segurança da Informação. Para mais detalhes, clique aqui ou na imagem abaixo. Bons estudos! :)