O SYN Flood é um dos ataques de negação de serviço mais elegantes — e mais antigos — do livro. Não tenta esgotar a largura de banda do alvo: explora a forma como o próprio protocolo TCP estabelece ligações, deixando milhares de apertos de mão pendurados a meio até o servidor não conseguir aceitar mais ninguém.
O three-way handshake do TCP
Sempre que um computador quer comunicar com outro num cenário em que a correção de erros é importante, o TCP exige um three-way handshake — um aperto de mão a três tempos em que ambos os lados acordam os parâmetros da conversa antes de qualquer dado fluir.
[ CLIENTE ] —— SYN ——→ [ SERVIDOR ]
[ CLIENTE ] ←—— SYN/ACK —— [ SERVIDOR ]
[ CLIENTE ] —— ACK ——→ [ SERVIDOR ]
Ligação TCP estabelecida — agora pode fluir aplicação por cima
O ponto crítico para entender o ataque está no segundo passo: ao receber o SYN, o servidor responde com SYN/ACK e reserva imediatamente recursos — uma entrada na backlog queue de ligações meio-abertas, memória para o estado da ligação, um temporizador à espera do ACK final. Esses recursos ficam comprometidos enquanto o handshake não fechar.
O que muda no SYN Flood
O SYN Flood ocorre quando um alvo é inundado com muitos pedidos SYN, cada um forçando o servidor a responder com SYN/ACK e a reservar recursos para uma conversa que nunca vai começar. A mecânica é simples e cruel: o atacante envia o primeiro tempo do handshake, mas nunca envia o ACK final.
Sem o ACK, o servidor mantém a ligação no estado SYN_RECV até o temporizador expirar — segundos ou dezenas de segundos durante os quais aquele slot da fila está bloqueado. Multiplique isto por dezenas ou centenas de milhares de SYNs por segundo e a fila esgota-se: ligações legítimas começam a ser rejeitadas porque já não há onde guardar o estado.
Cenário Normal
Handshake completo
SYN → SYN/ACK → ACK. O servidor reserva recursos no segundo passo e liberta-os ou consolida-os logo após o terceiro. A entrada na backlog queue dura o tempo de um round trip.
Ocupação típica: dezenas a centenas de slots em qualquer momento.
Sob Ataque
Handshake incompleto
SYN → SYN/ACK → (silêncio). O atacante envia milhares de SYN e nunca devolve o ACK. Cada ligação fica presa em SYN_RECV até o temporizador expirar — frequentemente 30 a 60 segundos.
Resultado: a backlog enche, ligações legítimas são recusadas.
A anatomia do recurso esgotado
O ataque SYN Flood não tenta saturar a rede — tenta saturar tabelas. As tabelas que importam são pequenas, finitas, e vivem dentro do kernel do sistema operativo:
- Backlog queue (
tcp_max_syn_backlogem Linux) — o tamanho máximo da fila de ligações emSYN_RECV. Por defeito, alguns milhares. - Listen backlog da aplicação — passada à syscall
listen(), limita as ligações já estabelecidas à espera deaccept(). - Memória do kernel para os request sockets meio-abertos — pequena por entrada, mas multiplica-se por todas as ligações pendentes.
- Estado em firewalls e balanceadores — também eles guardam ligações em conntrack ou tabelas equivalentes; também eles têm limites.
Adicione a isto que o atacante normalmente falsifica o IP de origem: o servidor envia o SYN/ACK para um destino aleatório, fica à espera de um ACK que jamais chegará e mantém a entrada bloqueada até ao temporizador. O atacante consome muito pouco; a vítima consome até estoirar.
Mitigação
O SYN Flood é estudado há décadas e tem um conjunto bem definido de contramedidas. As mais relevantes:
- SYN cookies: em vez de reservar recursos no SYN/ACK, o servidor codifica o estado da ligação no próprio número de sequência. Só aloca memória se o ACK final chegar com o cookie correto. Em Linux,
net.ipv4.tcp_syncookies = 1. - Aumentar a backlog queue:
net.ipv4.tcp_max_syn_backlogenet.core.somaxconn; útil em conjunto com SYN cookies, não como defesa isolada. - Reduzir os retries do SYN/ACK:
net.ipv4.tcp_synack_retriesbaixo (ex.: 2) liberta mais cedo as entradas presas. - SYN proxy em firewalls e balanceadores (iptables
SYNPROXY, equivalentes em equipamentos de rede): o proxy completa o handshake com o cliente antes de o reencaminhar para o servidor real, absorvendo SYNs falsificados antes de chegarem ao alvo. - Rate limiting de SYNs por IP de origem em firewalls e WAF — limita o impacto de fontes individuais ainda que não derrote uma botnet distribuída.
- BCP 38 / ingress filtering nos ISPs: corta na raiz pacotes com IP de origem falsificada, neutralizando uma das pré-condições do ataque.
- Serviços de mitigação anti-DDoS a montante (scrubbing centers, CDN com proteção L4): essenciais quando o ataque vem de uma botnet com volume e diversidade de origens.
- Monitorização: alertar sobre crescimento anómalo de ligações em
SYN_RECV(ss -tan state syn-recv) e sobre falhas deaccept()nos servidores.
Conclusão
O SYN Flood tira partido de uma propriedade fundamental do TCP — o servidor compromete-se primeiro, confirma depois — para transformar pedidos baratos do lado do atacante em recursos caros do lado da vítima. Não exige largura de banda excecional: exige paciência e volume de SYNs.
A boa notícia é que a defesa está bem mapeada: SYN cookies como base, SYN proxy a montante, BCP 38 nos ISPs e mitigação anti-DDoS quando o ataque é distribuído. Para qualquer serviço exposto à Internet, garantir que estes mecanismos estão ativos e dimensionados é higiene básica — não opcional.