Ataque SYN Flood | Exaustão de Estado TCP e Defesa L4

Um ataque SYN Flood é uma forma de DDoS que explora o processo de estabelecimento de conexão TCP para esgotar as estruturas de estado pendente do kernel do servidor alvo, impedindo que conexões legítimas sejam aceitas.

Como funciona um ataque SYN Flood?

O handshake de três vias e as filas de conexão

O handshake de três vias (three-way handshake) é o processo que estabelece qualquer conexão TCP. O cliente envia um segmento TCP com a flag SYN ativa, sinalizando desejo de conectar. O servidor responde com SYN-ACK e registra a requisição como uma conexão pendente, aguardando o ACK final do cliente. Somente após receber esse ACK a conexão é promovida ao estado ESTABLISHED e a aplicação é notificada.

No Linux, há uma distinção conceitual importante entre duas filas que operam nesse processo:

1. Fila de requisições SYN (SYN queue ou incomplete connection queue): mantém as requisições de conexão que receberam SYN e aguardam a conclusão do handshake com o ACK final. O parâmetro net.ipv4.tcp_max_syn_backlog está associado à pressão nessa fila.
2. Fila de accept (accept queue ou complete connection queue): mantém as conexões já estabelecidas que aguardam a aplicação executar accept(). O tamanho efetivo desta fila é limitado pelo menor valor entre o argumento listen(backlog) da aplicação e net.core.somaxconn.

O SYN Flood pressiona principalmente a fila de requisições SYN. Em ataques de grande volume, os efeitos se espalham: CPU, softirq, conntrack do Netfilter, capacidade de firewall e largura de banda também podem ser esgotados.

Os detalhes internos dessas estruturas — nomes, tamanhos e comportamentos — variam conforme a versão do kernel, a distribuição Linux e as configurações aplicadas. Os conceitos descritos aqui refletem o comportamento geral; sempre valide no ambiente de destino.

A assimetria que torna o ataque eficiente

O atacante envia segmentos TCP com a flag SYN — encapsulados em pacotes IP, com tamanho variável conforme as opções TCP negociadas e eventuais encapsulamentos. O custo para o atacante é mínimo: enviar e esquecer.

Para cada SYN recebido, o kernel precisa alocar memória e temporizadores associados ao handshake — estruturas internas cuja implementação varia conforme o kernel, as opções negociadas, o estado do Netfilter/conntrack, os módulos carregados e a política de SYN Cookies ativa. O servidor mantém essas estruturas por todo o tempo de espera pelo ACK final.

Com falsificação de IP (IP spoofing) — endereços de origem fabricados pelo atacante — o ACK final nunca chega. Cada requisição ocupa a fila de requisições SYN até expirar. Quando a fila satura, novos SYNs são descartados e usuários legítimos começam a receber erros de conexão.

O ataque em operação

O atacante envia um fluxo contínuo de pacotes SYN com endereços de origem falsificados. O servidor responde a cada SYN com um SYN-ACK direcionado ao IP falsificado, que não retorna o ACK. A fila de requisições SYN satura em segundos. Serviços que dependem de TCP — HTTP/S, SSH, bancos de dados, APIs — ficam inacessíveis mesmo com o servidor operando normalmente em hardware.

A tabela abaixo mostra indicadores que diferenciam tráfego normal de um SYN Flood em andamento. Os valores são exemplos iniciais; calibre com o baseline histórico do seu ambiente antes de usá-los como limiar de alerta.

Variações do ataque

SYN Flood distribuído via botnet

Em vez de um único host com IP falsificado, o atacante usa uma botnet de dispositivos comprometidos, cada um enviando SYNs com seu IP real. Os endereços de origem são genuínos, o que limita a eficácia do BCP38 como única defesa. A detecção requer análise comportamental: padrão de timestamps, volume por IP e ausência de ACKs subsequentes são os indicadores relevantes.

SYN-ACK Flood refletido

O atacante envia SYNs com o IP da vítima como origem para servidores públicos de terceiros. Esses servidores respondem com SYN-ACKs direcionados ao IP da vítima, que recebe volumes massivos de SYN-ACKs não solicitados. Diferente do SYN Flood clássico — que esgota as filas de conexão —, o SYN-ACK Flood esgota largura de banda e força processamento de pacotes não solicitados. A mitigação requer inspeção stateful para descartar SYN-ACKs que não correspondem a conexões iniciadas localmente.

ACK Flood

Inunda o alvo com pacotes ACK referentes a conexões TCP inexistentes. Para cada pacote, a pilha TCP precisa realizar um lookup de estado e classificar o pacote. Dependendo da pilha TCP, do estado local e das regras de firewall, pacotes ACK inválidos podem ser descartados silenciosamente, classificados como inválidos, registrados ou resultar em resposta TCP em contextos específicos. O efeito principal é o custo de processamento de pacotes e a pressão sobre CPU e dispositivos stateful, não necessariamente a geração de RSTs.

SYN Flood como distração em campanhas de intrusão

Em algumas campanhas de extorsão e intrusão, ataques DDoS podem ser usados como distração operacional enquanto outras atividades maliciosas são realizadas em paralelo — exfiltração de dados, abuso de APIs internas, instalação de ransomware. Organizações sem segmentação eficiente de alertas e sem correlação de eventos são particularmente vulneráveis a esse padrão.

A recomendação é correlacionar alertas DDoS com outras fontes de telemetria: EDR, SIEM, logs de identidade, logs de API e telemetria de rede. Um SYN Flood isolado no perímetro, combinado com atividade anômala em sistemas internos, é sinal de campanha coordenada.

Técnicas de defesa em camada 4

SYN Cookies — RFC 4987

A técnica mais eficaz contra SYN Floods com IPs falsificados. Definida formalmente na RFC 4987, o mecanismo de SYN Cookies reduz ou elimina a necessidade de manter estado de handshake pendente antes da validação do cliente.

Em vez de alocar estruturas de estado para cada SYN recebido, o servidor codifica informação verificável diretamente no Initial Sequence Number (ISN) do SYN-ACK, usando um hash criptográfico: ISN = hash(src_ip, src_port, dst_ip, dst_port, timestamp, secret_key).

Quando o cliente responde com o ACK, o número de acknowledgment deve ser ISN + 1. O servidor recalcula o hash e valida que o cliente genuinamente recebeu o SYN-ACK — confirmando que o IP de origem é real. Apenas então cria o estado completo necessário para a conexão. IPs falsificados nunca retornam o ACK correto e, portanto, nunca forçam alocação de memória.

SYN Cookies são particularmente eficazes contra SYN Floods com spoofing, em que o ACK final não retorna ao alvo. Não resolvem diretamente ataques de botnets que usam IPs reais e completam o handshake — nesses casos, são necessárias técnicas complementares como rate limiting por IP, detecção comportamental e limitação de conexões concorrentes.

Limitações e trade-offs: o espaço disponível no ISN (32 bits) limita a quantidade de informação que pode ser codificada. O tratamento de opções TCP como Window Scaling, SACK e timestamps depende da implementação e da versão do sistema operacional. Implementações modernas podem preservar parte dessas opções em determinados cenários; outras podem não preservar. Avalie o comportamento no seu kernel e distribuição específicos antes de depender dessa preservação.

SYN Cookies devem ser usados como proteção sob pressão, e não como substituto para planejamento de capacidade, filtragem de origem e mitigação upstream.

Linux: net.ipv4.tcp_syncookies=1 normalmente habilita SYN Cookies sob pressão ou ao detectar overflow na fila de requisições pendentes — o limiar exato depende da versão e configuração do kernel. Não recomende SYN Cookies permanentes (tcp_syncookies=2) como prática padrão de produção sem validação prévia do impacto nas opções TCP e na performance do ambiente específico.

BCP38 e uRPF — filtragem de IP spoofing na origem

O BCP38 (RFC 2827) define a política de filtragem de origem que ISPs devem implementar para eliminar a falsificação de IP: pacotes saindo de uma rede de cliente com endereços de origem que não pertencem ao bloco IP alocado àquele cliente devem ser descartados no roteador de borda do provedor, antes de entrar na internet.

O Unicast Reverse Path Forwarding (uRPF), definido na RFC 3704, é uma das técnicas de implementação possíveis. O roteador de borda verifica cada pacote recebido em relação à sua tabela de roteamento:

• uRPF estrito: exige que a rota de retorno para o IP de origem utilize exatamente a mesma interface pela qual o pacote chegou. Pode ser inadequado em topologias assimétricas ou multihomed.
• uRPF loose: verifica apenas a existência de uma rota para o endereço de origem, sem exigir a mesma interface de entrada. Mais compatível com roteamento assimétrico, porém com menor capacidade de filtrar spoofing sofisticado.

BCP38 é uma política/prática de filtragem de origem; uRPF é apenas uma das formas de implementá-la. A adoção do BCP38 permanece incompleta e desigual entre redes e provedores — o que mantém o IP spoofing como vetor disponível em grande parte da internet.

Ajuste de tcp_synack_retries e do tamanho da fila

Reduzir net.ipv4.tcp_synack_retries (padrão: 5) diminui o número de retransmissões do SYN-ACK antes de abandonar a conexão pendente, reduzindo o tempo que cada requisição ocupa a fila. O tempo efetivo de expiração depende do número de retransmissões, do algoritmo de backoff, da versão do kernel e das condições de rede — não há um valor universal em segundos.

Risco operacional: reduzir tcp_synack_retries excessivamente pode prejudicar usuários legítimos em redes móveis, congestionadas, com alta perda de pacotes ou alta latência. Teste e valide em ambiente representativo antes de aplicar em produção.

Aumentar net.ipv4.tcp_max_syn_backlog expande a capacidade da fila de requisições SYN. Em ataques moderados, isso adia a saturação — mas não é solução definitiva para ataques de grande escala. Use em conjunto com SYN Cookies, BCP38 upstream e terminação no edge.

Firewall stateful com limitação de conexões half-open

Firewalls com inspeção stateful rastreiam o estado de cada conexão TCP e podem descartar SYNs que excedam limiares por IP de origem, por sub-rede ou globalmente. A limitação é que firewalls on-premise têm capacidade de estado finita — ataques acima de volumes elevados frequentemente saturam o próprio firewall antes de saturar o servidor alvo.

Terminação TCP no edge — proxy stateful como defesa estrutural

A defesa mais robusta contra SYN Flood não é proteger o servidor de origem diretamente — é impedir que SYNs incompletos cheguem até ele. Redes de borda distribuídas atuam como proxies stateful: absorvem o handshake de três vias nos próprios data centers de borda e encaminham ao servidor de origem apenas conexões completamente estabelecidas.

Nesse modelo, os nós de borda recebem os SYNs, executam o handshake TCP com o cliente e, após validar que a conexão foi completada com sucesso, abrem uma nova conexão TCP entre o edge e o servidor de origem — transmitindo apenas tráfego de aplicação validado. Conexões com IPs falsificados não completam o handshake e, portanto, não alcançam a origem.

Em conjunto com roteamento Anycast, essa arquitetura distribui o volume de ataque geograficamente: um alto volume de SYNs direcionado a um único bloco de IPs é absorvido pelos data centers mais próximos da fonte, cada um processando uma fração do volume total. Para detalhes sobre as diferenças entre esse modelo e o scrubbing center tradicional via BGP, consulte o artigo específico.

SYN Flood vs. QUIC Flood — comparativo entre pilhas de protocolo

O surgimento do HTTP/3 sobre QUIC criou um vetor de exaustão de recursos que opera em camadas e estruturas fundamentalmente diferentes do SYN Flood. QUIC usa UDP como encapsulamento, mas é um protocolo de transporte seguro e multiplexado que exige TLS 1.3. Uma implementação QUIC pode consumir CPU, buffers, tabelas de estado e recursos de user-space — o custo exato depende da implementação, da política de Retry, do rate limiting, do parsing e das operações criptográficas envolvidas.

A diferença estrutural mais importante é a localização do estado: no SYN Flood, o recurso esgotado são as estruturas de estado no kernel — gerenciadas diretamente pelo sistema operacional. No QUIC Flood, o recurso esgotado está no user-space da biblioteca QUIC — o que afeta a aplicação, mas não compromete diretamente o kernel do sistema operacional.

O Retry packet e a validação de endereço do QUIC reduzem a exposição a fontes spoofadas, mas não eliminam ataques feitos por botnets com IPs reais. O requisito de datagramas QUIC Initial de pelo menos 1.200 bytes pode elevar o custo de alguns ataques, mas não deve ser tratado como contramedida equivalente a SYN Cookies.

Telemetria, diagnóstico e detecção

Comandos de verificação de estado TCP no Linux

Atenção: coleta de pacotes local (tcpdump, wireshark) pode ser inadequada em cenários de alto PPS — o próprio processo de captura pode contribuir para a sobrecarga. Prefira contadores de kernel e ferramentas de análise de flows para ambientes de produção sob ataque.

# Resumo de todos os estados de socket, incluindo contagem de SYN_RECV
ss -s

# Lista conexões em estado SYN_RECV com detalhes de endereços
ss -nt state syn-recv

# Contadores TCP do kernel (inclui ListenOverflows, SyncookiesSent, etc.)
nstat -az

# Logs de kernel — mensagens de overflow de fila e ativação de SYN Cookies
journalctl -k
# ou em sistemas sem journald:
dmesg | grep -i "syn\|cookie\|overflow\|flood"

Não use cat /proc/net/stat/nf_conntrack para medir a ocupação da fila de requisições SYN. Esse arquivo mede a tabela de connection tracking do Netfilter — relevante para firewalls stateful, mas não representa a ocupação da fila de handshake pendente de um listener TCP.

Não há necessariamente uma métrica simples, universal e direta de “percentual de ocupação da fila de requisições SYN por listener” disponível em todos os ambientes Linux. A abordagem correta é correlacionar múltiplos indicadores.

Contadores TCP relevantes via nstat -az

Os contadores abaixo são particularmente úteis para detectar SYN Flood. Nomes e disponibilidade podem variar por versão de kernel e distribuição.

Métricas de telemetria e indicadores de anomalia

Os valores de threshold abaixo são exemplos iniciais. Calibre com o baseline histórico do ambiente antes de usá-los como limiar operacional.

Para ambientes de alto volume, complemente com NetFlow, IPFIX ou sFlow — que permitem correlacionar volume de SYNs, volume de SYN-ACKs, ACKs finais válidos e retransmissões de SYN-ACK em escala sem sobrecarregar o host.

Detecção de SYN-ACK Flood refletido

O SYN-ACK Flood refletido é detectado pela presença de SYN-ACKs de entrada sem SYN correspondente no estado da conexão local. Em firewalls stateful, aparecem como pacotes “out-of-state” ou “invalid state”. Em análise de flows, manifesta-se como alto volume de tráfego TCP com flags SYN+ACK chegando de múltiplos IPs, sem sessões TCP estabelecidas correspondentes saindo do servidor.

Erros comuns de mitigação e soluções

Perguntas frequentes

O que diferencia um SYN Flood de um UDP Flood ou DNS Amplification? SYN Flood explora o custo de manter estado de conexão pendente no kernel. UDP Flood e DNS Amplification são primariamente volumétricos e saturam largura de banda de rede — a pilha UDP não mantém estado de handshake por pacote. São tipos de ataque com superfícies de impacto distintas.

SYN Cookies eliminam completamente o risco de SYN Flood? Para SYN Floods com IP falsificado, SYN Cookies são altamente eficazes — reduzem a necessidade de manter estado antes da validação do cliente. Para botnets com IPs reais que completam o handshake, SYN Cookies não ajudam diretamente. Nesses casos, são necessárias técnicas complementares: rate limiting por IP real, detecção comportamental e limitação de conexões concorrentes por IP. SYN Cookies também não substituem planejamento de capacidade, filtragem de origem e mitigação upstream.

O aumento da fila de requisições SYN não resolve o problema definitivamente? Não. Aumentar net.ipv4.tcp_max_syn_backlog expande a capacidade, mas um atacante com volume suficiente simplesmente satura o buffer maior. É uma medida de contenção, não de resolução. A solução estrutural é ou reduzir a necessidade de alocar estado antes da validação (SYN Cookies) ou absorver os SYNs antes de chegarem ao servidor (terminação no edge).

Por que firewalls on-premise são insuficientes para ataques de grande escala? Firewalls stateful mantêm sua própria tabela de estado para rastrear conexões TCP. Um ataque de alto volume pode saturar a tabela de estado do firewall antes mesmo de saturar o servidor de origem — e um firewall saturado descarta tráfego indiscriminadamente, incluindo o legítimo. Além disso, o tráfego precisa chegar à rede da organização antes do firewall agir, podendo saturar o link de uplink no processo.

Como BCP38/uRPF reduz o IP spoofing? BCP38 é uma política de filtragem implementada por ISPs: pacotes com endereço de origem que não pertence ao bloco IP alocado ao cliente são descartados no roteador de borda antes de entrar na internet. uRPF é uma das técnicas de implementação possíveis — na modalidade estrita, verifica se a rota de retorno usa a mesma interface de chegada; na modalidade loose, verifica apenas a existência de rota. A adoção do BCP38 permanece incompleta e desigual entre redes e provedores, o que mantém o IP spoofing como vetor disponível.

Qual é a diferença entre SYN Flood e QUIC Flood em termos de defesa? SYN Flood é mitigado por controles de kernel (SYN Cookies, ajuste de fila, BCP38) e por terminação TCP stateful no edge. QUIC Flood requer terminação QUIC no edge com inspeção TLS, pois todo o tráfego QUIC é criptografado — middleboxes que não terminam QUIC não conseguem inspecionar os pacotes. A superfície de ataque do QUIC está no user-space (CPU e estado na implementação QUIC), não diretamente no kernel (filas de conexão pendente).

Como implementar na Azion

A Azion oferece uma arquitetura de terminação TCP distribuída no edge que pode ajudar a reduzir o impacto de ataques SYN Flood:

1. Terminação TCP stateful no edge: Os data centers da Azion são projetados para absorver o handshake de três vias localmente. O servidor de origem recebe apenas conexões completamente estabelecidas — conexões com IPs falsificados não completam o handshake e não alcançam a origem.
2. DDoS Protection always-on: Detecta e ajuda a mitigar SYN Floods automaticamente, sem necessidade de ativação manual ou convergência BGP.
3. Rede Anycast global: Com data centers distribuídos que anunciam o mesmo bloco de IPs via BGP Anycast, um alto volume de SYNs é distribuído geograficamente entre os pontos mais próximos da fonte, reduzindo a concentração do impacto.
4. Network Shield e filtragem L3/L4: Filtra pacotes TCP malformados, SYN-ACKs refletidos não solicitados e padrões de SYN anômalos nas camadas 3 e 4, antes de qualquer processamento de aplicação.

Saiba mais na documentação de DDoS Protection da Azion.