Saltar para o conteúdo 
Cookies TCP SYN No kernel do Linux, mantêm a carga do handshake baixa, codificando criptograficamente as informações de estado no Número de Sequência Inicial (Initial Sequence Number) e só estabelecendo completamente uma ligação após receberem um ACK válido. Desta forma, evito que as inundações de SYN entupam a fila de ligações semiabertas e bloqueiem os clientes legítimos.
Pontos centrais
- Funcionalidade: Cookie no ISN, estado só após o ACK
- Controlo Linux: net.ipv4.tcp_syncookies com os modos 0/1/2
- Benefício: baixo consumo de memória durante a carga de ataque
- Limites: não é eficaz contra ataques à largura de banda ou a aplicações
- Afinação: Definir cuidadosamente os valores de backlog e de nova tentativa
Como os ataques SYN-Flood atrasam o handshake TCP
Um atacante sobrecarrega o servidor com Pacotes SYN e ignora as respostas SYN/ACK seguintes, o que faz com que as entradas semiabertas ocupem a fila SYN. Verifico então que as novas solicitações legítimas não encontram espaço e os tempos de espera excedidos se acumulam. É precisamente aqui que entram Syncookies O kernel, inicialmente, não armazena o estado da ligação e transfere os dados necessários para o número de sequência. Só um ACK correto comprova a existência de um destinatário real, pelo que o estabelecimento da ligação prossegue normalmente. O LWN.net e a documentação da TUM descrevem este princípio como uma proteção de handshake consolidada e eficaz, sem elevado consumo de memória. Esta arquitetura mantém o servidor capaz de receber tráfego, mesmo em caso de picos de tráfego, uma vez que só cria estados dispendiosos numa fase muito tardia.
Processo técnico: cookie em vez do antigo sistema de estado
O kernel responde a um SYN com um SYN/ACK especialmente codificado, cujo ISN é derivado de uma chave secreta, opções TCP e intervalos de tempo. Se chegar um ACK com o número correspondente, reconstruo os parâmetros da sessão a partir do ISN e abro o socket normalmente. Se a resposta não chegar, não existe um estado semiaberto ocupado, o que poupa memória e CPU. Esta abordagem reduz drasticamente a vulnerabilidade da fase de aceitação, sem alterar permanentemente o caminho regular. De acordo com a documentação do Ubuntu e da Red Hat, esta técnica funciona de forma fiável há várias gerações do kernel e só entra em ação quando a fila corre o risco de ficar sobrecarregada.
Ativar e verificar: tcp_syncookies na prática
Sobre o parâmetro sysctl net.ipv4.tcp_syncookies controlo o comportamento: 0 = desativado, 1 = apenas em caso de sobrecarga, 2 = permanente. Em ambientes de produção, costumo definir o modo 1, para que o handshake padrão permaneça intacto e a proteção só seja ativada quando necessário. Consigo verificar rapidamente o estado na shell e aplico as alterações através do `sysctl` ou de forma permanente em `/etc/sysctl.d/`. Um artigo de fundo adequado sobre o comportamento dos sockets e os padrões de ataque ajuda a planear tudo; aprofundo os detalhes no artigo Proteção contra inundações SYN. Utilizo regularmente os seguintes comandos:
# Mostrar estado
sysctl net.ipv4.tcp_syncookies
# Ativar temporariamente (até ao reinício)
sudo sysctl -w net.ipv4.tcp_syncookies=1
Definir # de forma permanente
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Limitações: O que os cookies SYN não conseguem fazer
Os cookies SYN destinam-se principalmente a Syn-Queue e impedem que estados semiabertos ocupem memória. No entanto, não são eficazes contra uma linha sobrecarregada, uma lógica de aplicação sobrecarregada ou a saturação da CPU. No caso de ataques volumétricos, preciso de filtros a montante, QoS e, se necessário, scrubbing. Também os ataques ao nível da aplicação, como as inundações de HTTP-GET, exigem controlos, limites e caches adicionais. Por isso, integro sempre os syncookies numa defesa em várias camadas, que combina a rede, o kernel e o nível dos serviços.
Otimização: atrasos, filas e novas tentativas
Antes de uma situação de emergência, eu... Atrasos e as tentativas de repetição, para que picos legítimos não ativem desnecessariamente o modo de proteção. O tcp_max_syn_backlog influencia a fila de ligações semiabertas, enquanto o somaxconn determina o comprimento máximo da fila de aceitação para as ligações em espera do accept(). Com tcp_synack_retries, determino quantas vezes o kernel tenta repetir um SYN/ACK antes de desistir. Backlogs mais elevados absorvem picos de carga de curta duração, mas consomem memória; um número menor de tentativas libera slots mais cedo, mas acarreta o risco de afetar demasiado os clientes remotos. Testo estes compromissos sob carga realista com ferramentas como o hping3 ou o tcp_syn_flooder numa rede isolada.
#: Configurações para picos de carga
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Comparar modos de funcionamento: implicações e aplicações
Para o dia-a-dia, escolho a Modos conscientemente, pois influenciam o diagnóstico, as métricas e o comportamento sob pressão. Os cookies permanentes (2) evitam qualquer inicialização antecipada do estado, mas alteram os valores medidos para novas tentativas e podem influenciar casos extremos raros com opções TCP. O modo adaptativo (1) permite que a pilha funcione normalmente e intervém em caso de risco de sobrecarga. A opção «desativado» (0) só faz sentido, no máximo, em situações laboratoriais ou em redes fechadas. A tabela seguinte resume tudo isto de forma concisa:
| Modo | Descrição | Vantagem | Efeito secundário potencial | Exemplo |
|---|---|---|---|---|
| 0 | Desativado, sem cookies | Comportamento de referência claro | O atacante enche a fila Syn | Rede de testes isolada |
| 1 | Adaptativo, apenas em caso de transbordamento | TCP normal em estado de repouso | Calibrar o ponto de comutação | Serviços públicos |
| 2 | Obrigatório, sempre ativo | Alívio precoce | Os valores das análises variam | Situação de ataque difícil |
Efeitos mensuráveis: latências e taxa de sucesso
Sob pressão, o Requisitos de memória é evidente logo no início da ligação, uma vez que não se cria um estado semiaberto. Assim, os «SYN Cookies» mantêm a taxa de aceitação elevada e as rajadas curtas provocam menos interrupções. Observo uma recuperação mais rápida em situações de tráfego intenso, assim que a fonte se esgota. As diretrizes do Ubuntu e da Tenable recomendam uma utilização adaptativa, para que os clientes normais continuem a funcionar sem alterações. Para os testes de regressão, verifico as retransmissões, as taxas de perda e a latência do servidor durante a transição para o modo de cookies.
Camadas de proteção adicionais: firewall e limites
Resolvo os «syncookies» com Regras de filtragem e limites de taxa, para que a carga nem sequer chegue à pilha TCP. No Linux, prefiro utilizar regras do nftables para limitar ou rejeitar precocemente os infratores com base nas taxas de ligação. O guia oferece uma visão geral concisa sobre os filtros de pacotes modernos nftables vs. Netfilter. Além disso, os cenários SYNPROXY nas firewalls de perímetro ajudam a encerrar o handshake e a permitir apenas ligações válidas. Para as portas expostas, defino aberturas rigorosas, limiares de registo e um número máximo de tentativas de ligação por endereço de origem.
Abordagens de alto desempenho: XDP e outras tecnologias.
Quando os ataques em massa atingem a Taxa de PPS Para otimizar o desempenho, transfiro a lógica de filtragem, através do XDP, para a periferia da rede da placa de rede (NIC). Desta forma, rejeito os SYNs suspeitos ainda antes da camada de socket, o que reduz a carga da CPU e alivia a fila de aceitação. A apropriação desta técnica é facilitada por uma introdução à Processamento de pacotes XDP. Em combinação com os cookies SYN, cria-se um sistema de duas fases: primeiro, uma seleção preliminar na tabela; depois, uma verificação fiável do handshake no kernel. Esta cadeia reduz sensivelmente a superfície de ataque e mantém os serviços acessíveis.
Diagnóstico: interpretar corretamente as métricas e as mensagens de registo
No caso de Intervalos Verifico as estatísticas do netstat/ss, as mensagens do dmesg e os painéis do Grafana com as taxas de ligação. Uma percentagem crescente de SYN-RECV, um número elevado de retransmissões e de pacotes perdidos indicam a ativação do modo de proteção. Estou atento às mensagens de «syn backlog overflow» e correlaciono-as com a carga da CPU e das IRQ. As capturas de pacotes com o tcpdump comprovam a lógica dos números de sequência e ajudam a identificar falsos positivos. Com os contadores do iptables/nftables, medo adicionalmente a situação de acertos nas regras de limitação de taxa.
Compatibilidade: opções TCP e casos extremos
Programação de kernels modernos Opções como MSS, SACK ou Timestamp, de forma a que os cookies sejam transportados de modo a permitir a sua reconstrução. As pilhas mais antigas ou pouco comuns podem apresentar peculiaridades; por isso, verifico os caminhos críticos antes da implementação. Especialmente no caso de proxies, NAT e topologias anycast, observo o comportamento minuciosamente. O LWN.net discute detalhes de conceção que explicam por que razão as implementações atuais funcionam de forma fiável. Em cenários muito específicos, o modo de funcionamento forçado (2) continua a ser uma ferramenta que utilizo apenas de forma seletiva.
Equívocos comuns: o que costumo corrigir
Os Syncookies não substituem Defesa contra DDoS na periferia, protegem sobretudo a fase de handshake. Um valor elevado de somaxconn, por si só, não impede os transbordamentos se o SYN/ACK nunca for respondido. Da mesma forma, é errada a suposição de que os cookies permanentes (2) são sempre a melhor opção; os diagnósticos e os casos especiais são prejudicados por isso. Sem monitorização, faltam-me sinais para ajustar os pontos de comutação e os limites. Os testes de carga continuam a ser indispensáveis para que a configuração e o hardware se adaptem à dinâmica real de acesso.
Análise prática: passos para uma hipótese sólida
Começo por Modo 1 para o tcp_syncookies e verifico o ponto de intervenção sob carga. Depois, aumentei moderadamente o tcp_max_syn_backlog e o somaxconn, ao mesmo tempo que reduzi o tcp_synack_retries e medi as taxas de sucesso. Os limites de taxa do firewall e os filtros geográficos/ASN filtram o ruído antes da pilha. Guardo os filtros XDP ou SmartNIC para situações de PPS elevado, de modo a utilizar os recursos de forma direcionada. Por fim, documento as métricas para que os ajustes posteriores se baseiem em dados concretos.
IPv6 e Dual-Stack: o mesmo comutador, a mesma lógica
Em ambientes Dual-Stack, o comportamento é o seguinte: IPv4 e IPv6 consistente no contexto dos cookies. O botão net.ipv4.tcp_syncookies controla a proteção globalmente para o TCP, ou seja, também para os sockets v6. Por isso, testo a transição para o modo «cookie» em ambos os protocolos — especialmente quando os dispositivos a montante no IPv6 utilizam outros caminhos de filtragem. Importante: os cookies SYN protegem exclusivamente o TCP. Os serviços UDP ou QUIC requerem limites de taxa e políticas de borda próprias, para que o tráfego volumétrico não sobrecarregue a CPU.
Métricas no kernel: indicadores fiáveis
Para uma monitorização fiável, recorro a contadores do kernel que identificam explicitamente os cookies. Além de ss -s E, no que diz respeito às distribuições de estado, observo os contadores de cookies enviados, aceites e com falha. Desta forma, consigo verificar se a proteção está a funcionar, se os clientes legítimos conseguem passar e se existem erros de configuração.
Visão geral do #
ss -s
ss -ant state syn-recv | wc -l
Contador de cookies do # (Kernel: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
Visualização em tempo real do #
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Indícios no registo (mensagem de exemplo)
O comando # dmesg apresenta, entre outros:
# TCP: Possível inundação de SYN na porta 443. A enviar cookies. Verificar contadores SNMP.
Subir Excessos de lista e ListenDrops em paralelo a SyncookiesSent ajusto os backlogs, as tentativas de repetição e os filtros a montante. Ficam SyncookiesRecv isso indica que se trata de uma enxurrada de bots; por outro lado, se forem frequentes SyncookiesFailed, verifico os percursos NAT/proxy e eventuais manipulações ao longo do caminho.
Proxies, balanceadores de carga e Kubernetes
Em Cadeias de proxy e de balanceamento de carga determina a localização da proteção de cookies. Se um balanceador de carga L4/L7 interromper o handshake TCP, uma inundação de SYN nem sequer chega aos backends; nesse caso, ativo os cookies na borda. Se o balanceador de carga funcionar apenas de forma passiva (DSR, ECMP), os nós de back-end têm de se proteger de forma autónoma. No Kubernetes, ajusto os sysctls nos nós de trabalho, especialmente em cargas de trabalho com NodePort ou HostNetwork. Para controladores de entrada com defesa SYN própria (SYNPROXY, eBPF), ajusto as políticas de forma a que não se interfiram mutuamente. Tenho em conta as verificações de integridade do balanceador de carga nos testes, pois, caso contrário, janelas de teste curtas com poucas tentativas de repetição podem causar falsamente a impressão de instabilidade.
Casos-limite em pormenor: opções, intervalos de tempo, NAT
Os cookies apenas codificam parâmetros limitados. As implementações modernas do Linux costumam reconstruir o MSS, o SACK e o Window Scaling de forma fiável; no entanto, os carimbos de data/hora e algumas opções menos comuns podem apresentar limitações, dependendo da versão do kernel. Por isso, considero preferível o modo de funcionamento (1), para que o caminho padrão prevaleça e os cookies só sejam utilizados em caso de ultrapassagem. A validade de um cookie está ligada a intervalos de tempo – em percursos fortemente assimétricos ou picos de atraso, um ACK legítimo pode situar-se ligeiramente fora da janela. Em cenários de WAN e de satélite, medo, por isso, a variância de ida e volta antes de reduzir as tentativas de reenvio. NAT e dispositivos intermediários que alteram números de sequência ou opções são outros candidatos a casos extremos; com capturas específicas, comprovo onde os bits se perdem.
Inundações de ACK/RST e variantes para além da tempestade de SYN
Nem todos Ataque de transporte trata-se de um ataque de inundação de SYN puro. Os ataques de inundação de ACK ou RST visam a CPU e os percursos dos pacotes, sem desencadear o handshake – os cookies pouco ajudam neste caso. Nesses casos, utilizo filtros precoces (nftables/XDP) com lógica de estado ou limitação mínima da taxa de ACK. No caso específico de ondas de RST contra ligações estabelecidas, interrompo-as através de um conjunto de regras que rejeita RSTs inesperados sem janela adequada. Também abordo os repetidores semiabertos (SYN com spoofing mais ACKs tardios) através de limites de taxa por espaço de rede de origem.
Outros ajustes: filas de lista/aceitação e erros rápidos
Para além dos parâmetros clássicos, utilizo interruptores complementares que determinam o comportamento em condições extremas:
- Backlog vs. somaxconn: O valor em listas (pendentes) por processo é determinado por net.core.somaxconn limitado. Asseguro que o software do servidor e o kernel funcionem em sintonia; caso contrário, as otimizações perdem o efeito.
- tcp_abort_on_overflow: Se, quando a fila de aceitação estiver cheia, a resposta seja silenciada ou se for enviada ativamente uma resposta RST. Em APIs de elevado volume, um erro rápido pode permitir que o cliente efetue uma nova tentativa rapidamente; no caso de clientes TLS ou legados, prefiro geralmente a rejeição por predefinição.
- Gestão de portas e do tempo de espera (TIME-WAIT): Os cookies não evitam Engarrafamento na porta efémera. Estou a planear ip_local_port_range Seja generoso e utilize as otimizações TIME-WAIT com prudência, para que a reutilização não dê origem a Heisenbugs.
- SO_REUSEPORT: Várias filas de aceitação por porta distribuem a carga pelos processos de trabalho e reduzem os sobrecarregamentos em CPUs individuais.
Métodos de ensaio: reprodutíveis e significativos
Simulo cargas em condições próximas às reais e medo o ponto de comutação para o modo «cookie», a taxa de sucesso das ligações legítimas, bem como o tempo de recuperação após o pico de carga. Para tal, combino fluxos sintéticos de pacotes SYN com pedidos reais de aplicações.
Gerar tráfego de inundação # (Laboratório!)
sudo hping3 -S -p 443 --flood --rand-source
Variar as condições de rede #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Misturar tráfego legítimo
wrk -t8 -c512 -d60s https:///
# Observação em paralelo
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Com estes passos, consigo identificar se as tentativas de repetição estão a diminuir de forma excessiva, se as firewalls a montante estão a filtrar indevidamente os carimbos de data/hora ou se as filas de aceitação de cada trabalhador estão a transbordar de forma desproporcional. Documento os indicadores-chave (aproximação à taxa de sucesso de 100% para ligações legítimas, taxa de acerto de cookies, comportamento da latência) para poder efetuar ajustes posteriores com base nos dados.
Operação e manutenção: garantir a estabilidade ao longo da vida útil
Em funcionamento contínuo, pretendo Rotação secreta (automaticamente ao nível do kernel) e observo se as mudanças de intervalo de tempo têm efeitos visíveis em percursos com RTT muito longo. Mantenho o kernel e os controladores atualizados para que as melhorias na implementação do Cookie (melhor codificação de opções, intervalos de tempo robustos) surtam efeito. Para auditorias, registo quando o modo de proteção foi ativado, quantas ligações permitiu e se foram ativados filtros adicionais. Em caso de alterações no MTU, no offloading ou nas pilhas NF (por exemplo, novos conjuntos nftables), repito testes rápidos para detetar precocemente eventuais interações indesejadas.
Versão abreviada para quem tem pressa
Os cookies SYN mantêm a Carga do handshake pequenas, ao criarem estados apenas após um ACK confirmado, protegendo assim a fila de SYN contra inundações. Ativo o Modo 1, ajusto cuidadosamente os backlogs e as tentativas de reenvio e avalio os efeitos com métricas claras. Camadas adicionais, como limites de taxa do nftables, SYNPROXY e XDP, restringem o tráfego ainda antes da pilha TCP. Em suma, protejo assim os serviços Web, de e-mail, VPN e API contra inundações de SYN, sem prejudicar os clientes regulares. Quem implementar estas medidas de forma rigorosa reforça a disponibilidade e reduz sensivelmente as falhas em caso de carga de ataques.
