{"id":20882,"date":"2026-08-22T08:31:38","date_gmt":"2026-08-22T06:31:38","guid":{"rendered":"https:\/\/webhosting.de\/tcp-syn-cookies-schutz-syn-flood-kernel\/"},"modified":"2026-08-22T08:31:38","modified_gmt":"2026-08-22T06:31:38","slug":"proteccao-contra-syn-cookies-do-tcp-inundacao-de-syn-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"Cookies TCP SYN no kernel do Linux: prote\u00e7\u00e3o contra ataques SYN-Flood"},"content":{"rendered":"<p><strong>Cookies TCP SYN<\/strong> No kernel do Linux, mant\u00eam a carga do handshake baixa, codificando criptograficamente as informa\u00e7\u00f5es de estado no N\u00famero de Sequ\u00eancia Inicial (Initial Sequence Number) e s\u00f3 estabelecendo completamente uma liga\u00e7\u00e3o ap\u00f3s receberem um ACK v\u00e1lido. Desta forma, evito que as inunda\u00e7\u00f5es de SYN entupam a fila de liga\u00e7\u00f5es semiabertas e bloqueiem os clientes leg\u00edtimos.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Funcionalidade<\/strong>: Cookie no ISN, estado s\u00f3 ap\u00f3s o ACK<\/li>\n  <li><strong>Controlo Linux<\/strong>: net.ipv4.tcp_syncookies com os modos 0\/1\/2<\/li>\n  <li><strong>Benef\u00edcio<\/strong>: baixo consumo de mem\u00f3ria durante a carga de ataque<\/li>\n  <li><strong>Limites<\/strong>: n\u00e3o \u00e9 eficaz contra ataques \u00e0 largura de banda ou a aplica\u00e7\u00f5es<\/li>\n  <li><strong>Afina\u00e7\u00e3o<\/strong>: Definir cuidadosamente os valores de backlog e de nova tentativa<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-schutz-8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como os ataques SYN-Flood atrasam o handshake TCP<\/h2>\n\n<p>Um atacante sobrecarrega o servidor com <strong>Pacotes SYN<\/strong> e ignora as respostas SYN\/ACK seguintes, o que faz com que as entradas semiabertas ocupem a fila SYN. Verifico ent\u00e3o que as novas solicita\u00e7\u00f5es leg\u00edtimas n\u00e3o encontram espa\u00e7o e os tempos de espera excedidos se acumulam. \u00c9 precisamente aqui que entram <strong>Syncookies<\/strong> O kernel, inicialmente, n\u00e3o armazena o estado da liga\u00e7\u00e3o e transfere os dados necess\u00e1rios para o n\u00famero de sequ\u00eancia. S\u00f3 um ACK correto comprova a exist\u00eancia de um destinat\u00e1rio real, pelo que o estabelecimento da liga\u00e7\u00e3o prossegue normalmente. O LWN.net e a documenta\u00e7\u00e3o da TUM descrevem este princ\u00edpio como uma prote\u00e7\u00e3o de handshake consolidada e eficaz, sem elevado consumo de mem\u00f3ria. Esta arquitetura mant\u00e9m o servidor capaz de receber tr\u00e1fego, mesmo em caso de picos de tr\u00e1fego, uma vez que s\u00f3 cria estados dispendiosos numa fase muito tardia.<\/p>\n\n<h2>Processo t\u00e9cnico: cookie em vez do antigo sistema de estado<\/h2>\n\n<p>O kernel responde a um <strong>SYN<\/strong> com um SYN\/ACK especialmente codificado, cujo ISN \u00e9 derivado de uma chave secreta, op\u00e7\u00f5es TCP e intervalos de tempo. Se chegar um ACK com o n\u00famero correspondente, reconstruo os par\u00e2metros da sess\u00e3o a partir do ISN e abro o socket normalmente. Se a resposta n\u00e3o chegar, n\u00e3o existe um estado semiaberto ocupado, o que poupa mem\u00f3ria e CPU. Esta abordagem reduz drasticamente a vulnerabilidade da fase de aceita\u00e7\u00e3o, sem alterar permanentemente o caminho regular. De acordo com a documenta\u00e7\u00e3o do Ubuntu e da Red Hat, esta t\u00e9cnica funciona de forma fi\u00e1vel h\u00e1 v\u00e1rias gera\u00e7\u00f5es do kernel e s\u00f3 entra em a\u00e7\u00e3o quando a fila corre o risco de ficar sobrecarregada.<\/p>\n\n<h2>Ativar e verificar: tcp_syncookies na pr\u00e1tica<\/h2>\n\n<p>Sobre o par\u00e2metro sysctl <strong>net.ipv4.tcp_syncookies<\/strong> controlo o comportamento: 0 = desativado, 1 = apenas em caso de sobrecarga, 2 = permanente. Em ambientes de produ\u00e7\u00e3o, costumo definir o modo 1, para que o handshake padr\u00e3o permane\u00e7a intacto e a prote\u00e7\u00e3o s\u00f3 seja ativada quando necess\u00e1rio. Consigo verificar rapidamente o estado na shell e aplico as altera\u00e7\u00f5es atrav\u00e9s do `sysctl` ou de forma permanente em `\/etc\/sysctl.d\/`. Um artigo de fundo adequado sobre o comportamento dos sockets e os padr\u00f5es de ataque ajuda a planear tudo; aprofundo os detalhes no artigo <a href=\"https:\/\/webhosting.de\/pt\/syn-protecao-contra-inundacoes-tratamento-de-tomadas-defesa-do-servidor\/\">Prote\u00e7\u00e3o contra inunda\u00e7\u00f5es SYN<\/a>. Utilizo regularmente os seguintes comandos:<\/p>\n\n<pre><code># Mostrar estado\nsysctl net.ipv4.tcp_syncookies\n\n# Ativar temporariamente (at\u00e9 ao rein\u00edcio)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\nDefinir # de forma permanente\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Limita\u00e7\u00f5es: O que os cookies SYN n\u00e3o conseguem fazer<\/h2>\n\n<p>Os cookies SYN destinam-se principalmente a <strong>Syn-Queue<\/strong> e impedem que estados semiabertos ocupem mem\u00f3ria. No entanto, n\u00e3o s\u00e3o eficazes contra uma linha sobrecarregada, uma l\u00f3gica de aplica\u00e7\u00e3o sobrecarregada ou a satura\u00e7\u00e3o da CPU. No caso de ataques volum\u00e9tricos, preciso de filtros a montante, QoS e, se necess\u00e1rio, scrubbing. Tamb\u00e9m os ataques ao n\u00edvel da aplica\u00e7\u00e3o, como as inunda\u00e7\u00f5es de HTTP-GET, exigem controlos, limites e caches adicionais. Por isso, integro sempre os syncookies numa defesa em v\u00e1rias camadas, que combina a rede, o kernel e o n\u00edvel dos servi\u00e7os.<\/p>\n\n<h2>Otimiza\u00e7\u00e3o: atrasos, filas e novas tentativas<\/h2>\n\n<p>Antes de uma situa\u00e7\u00e3o de emerg\u00eancia, eu... <strong>Atrasos<\/strong> e as tentativas de repeti\u00e7\u00e3o, para que picos leg\u00edtimos n\u00e3o ativem desnecessariamente o modo de prote\u00e7\u00e3o. O tcp_max_syn_backlog influencia a fila de liga\u00e7\u00f5es semiabertas, enquanto o somaxconn determina o comprimento m\u00e1ximo da fila de aceita\u00e7\u00e3o para as liga\u00e7\u00f5es 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\u00e7\u00e3o, mas consomem mem\u00f3ria; um n\u00famero 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.<\/p>\n\n<pre><code>#: Configura\u00e7\u00f5es para picos de carga\nsudo sysctl -w net.core.somaxconn=4096\nsudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192\nsudo sysctl -w net.ipv4.tcp_synack_retries=3\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcpsyncookies_7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparar modos de funcionamento: implica\u00e7\u00f5es e aplica\u00e7\u00f5es<\/h2>\n\n<p>Para o dia-a-dia, escolho a <strong>Modos<\/strong> conscientemente, pois influenciam o diagn\u00f3stico, as m\u00e9tricas e o comportamento sob press\u00e3o. Os cookies permanentes (2) evitam qualquer inicializa\u00e7\u00e3o antecipada do estado, mas alteram os valores medidos para novas tentativas e podem influenciar casos extremos raros com op\u00e7\u00f5es TCP. O modo adaptativo (1) permite que a pilha funcione normalmente e interv\u00e9m em caso de risco de sobrecarga. A op\u00e7\u00e3o \u00abdesativado\u00bb (0) s\u00f3 faz sentido, no m\u00e1ximo, em situa\u00e7\u00f5es laboratoriais ou em redes fechadas. A tabela seguinte resume tudo isto de forma concisa:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modo<\/th>\n      <th>Descri\u00e7\u00e3o<\/th>\n      <th>Vantagem<\/th>\n      <th>Efeito secund\u00e1rio potencial<\/th>\n      <th>Exemplo<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Desativado<\/strong>, sem cookies<\/td>\n      <td>Comportamento de refer\u00eancia claro<\/td>\n      <td>O atacante enche a fila Syn<\/td>\n      <td>Rede de testes isolada<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptativo<\/strong>, apenas em caso de transbordamento<\/td>\n      <td>TCP normal em estado de repouso<\/td>\n      <td>Calibrar o ponto de comuta\u00e7\u00e3o<\/td>\n      <td>Servi\u00e7os p\u00fablicos<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Obrigat\u00f3rio<\/strong>, sempre ativo<\/td>\n      <td>Al\u00edvio precoce<\/td>\n      <td>Os valores das an\u00e1lises variam<\/td>\n      <td>Situa\u00e7\u00e3o de ataque dif\u00edcil<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Efeitos mensur\u00e1veis: lat\u00eancias e taxa de sucesso<\/h2>\n\n<p>Sob press\u00e3o, o <strong>Requisitos de mem\u00f3ria<\/strong> \u00e9 evidente logo no in\u00edcio da liga\u00e7\u00e3o, uma vez que n\u00e3o se cria um estado semiaberto. Assim, os \u00abSYN Cookies\u00bb mant\u00eam a taxa de aceita\u00e7\u00e3o elevada e as rajadas curtas provocam menos interrup\u00e7\u00f5es. Observo uma recupera\u00e7\u00e3o mais r\u00e1pida em situa\u00e7\u00f5es de tr\u00e1fego intenso, assim que a fonte se esgota. As diretrizes do Ubuntu e da Tenable recomendam uma utiliza\u00e7\u00e3o adaptativa, para que os clientes normais continuem a funcionar sem altera\u00e7\u00f5es. Para os testes de regress\u00e3o, verifico as retransmiss\u00f5es, as taxas de perda e a lat\u00eancia do servidor durante a transi\u00e7\u00e3o para o modo de cookies.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-cookies-lnx-protection-4281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Camadas de prote\u00e7\u00e3o adicionais: firewall e limites<\/h2>\n\n<p>Resolvo os \u00absyncookies\u00bb com <strong>Regras de filtragem<\/strong> e limites de taxa, para que a carga nem sequer chegue \u00e0 pilha TCP. No Linux, prefiro utilizar regras do nftables para limitar ou rejeitar precocemente os infratores com base nas taxas de liga\u00e7\u00e3o. O guia oferece uma vis\u00e3o geral concisa sobre os filtros de pacotes modernos <a href=\"https:\/\/webhosting.de\/pt\/netfilter-vs-nftables-tecnologias-modernas-de-firewall-do-linux-shield\/\">nftables vs. Netfilter<\/a>. Al\u00e9m disso, os cen\u00e1rios SYNPROXY nas firewalls de per\u00edmetro ajudam a encerrar o handshake e a permitir apenas liga\u00e7\u00f5es v\u00e1lidas. Para as portas expostas, defino aberturas rigorosas, limiares de registo e um n\u00famero m\u00e1ximo de tentativas de liga\u00e7\u00e3o por endere\u00e7o de origem.<\/p>\n\n<h2>Abordagens de alto desempenho: XDP e outras tecnologias.<\/h2>\n\n<p>Quando os ataques em massa atingem a <strong>Taxa de PPS<\/strong> Para otimizar o desempenho, transfiro a l\u00f3gica de filtragem, atrav\u00e9s 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\u00e7\u00e3o. A apropria\u00e7\u00e3o desta t\u00e9cnica \u00e9 facilitada por uma introdu\u00e7\u00e3o \u00e0 <a href=\"https:\/\/webhosting.de\/pt\/xdp-processamento-de-pacotes-de-alto-desempenho-velocidade-do-kernel\/\">Processamento de pacotes XDP<\/a>. Em combina\u00e7\u00e3o com os cookies SYN, cria-se um sistema de duas fases: primeiro, uma sele\u00e7\u00e3o preliminar na tabela; depois, uma verifica\u00e7\u00e3o fi\u00e1vel do handshake no kernel. Esta cadeia reduz sensivelmente a superf\u00edcie de ataque e mant\u00e9m os servi\u00e7os acess\u00edveis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_tcp_syn_cookies_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagn\u00f3stico: interpretar corretamente as m\u00e9tricas e as mensagens de registo<\/h2>\n\n<p>No caso de <strong>Intervalos<\/strong> Verifico as estat\u00edsticas do netstat\/ss, as mensagens do dmesg e os pain\u00e9is do Grafana com as taxas de liga\u00e7\u00e3o. Uma percentagem crescente de SYN-RECV, um n\u00famero elevado de retransmiss\u00f5es e de pacotes perdidos indicam a ativa\u00e7\u00e3o do modo de prote\u00e7\u00e3o. Estou atento \u00e0s mensagens de \u00absyn backlog overflow\u00bb e correlaciono-as com a carga da CPU e das IRQ. As capturas de pacotes com o tcpdump comprovam a l\u00f3gica dos n\u00fameros de sequ\u00eancia e ajudam a identificar falsos positivos. Com os contadores do iptables\/nftables, medo adicionalmente a situa\u00e7\u00e3o de acertos nas regras de limita\u00e7\u00e3o de taxa.<\/p>\n\n<h2>Compatibilidade: op\u00e7\u00f5es TCP e casos extremos<\/h2>\n\n<p>Programa\u00e7\u00e3o de kernels modernos <strong>Op\u00e7\u00f5es<\/strong> como MSS, SACK ou Timestamp, de forma a que os cookies sejam transportados de modo a permitir a sua reconstru\u00e7\u00e3o. As pilhas mais antigas ou pouco comuns podem apresentar peculiaridades; por isso, verifico os caminhos cr\u00edticos antes da implementa\u00e7\u00e3o. Especialmente no caso de proxies, NAT e topologias anycast, observo o comportamento minuciosamente. O LWN.net discute detalhes de conce\u00e7\u00e3o que explicam por que raz\u00e3o as implementa\u00e7\u00f5es atuais funcionam de forma fi\u00e1vel. Em cen\u00e1rios muito espec\u00edficos, o modo de funcionamento for\u00e7ado (2) continua a ser uma ferramenta que utilizo apenas de forma seletiva.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/developer_desk_tcp_syn_8793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Equ\u00edvocos comuns: o que costumo corrigir<\/h2>\n\n<p>Os Syncookies n\u00e3o substituem <strong>Defesa contra DDoS<\/strong> na periferia, protegem sobretudo a fase de handshake. Um valor elevado de somaxconn, por si s\u00f3, n\u00e3o impede os transbordamentos se o SYN\/ACK nunca for respondido. Da mesma forma, \u00e9 errada a suposi\u00e7\u00e3o de que os cookies permanentes (2) s\u00e3o sempre a melhor op\u00e7\u00e3o; os diagn\u00f3sticos e os casos especiais s\u00e3o prejudicados por isso. Sem monitoriza\u00e7\u00e3o, faltam-me sinais para ajustar os pontos de comuta\u00e7\u00e3o e os limites. Os testes de carga continuam a ser indispens\u00e1veis para que a configura\u00e7\u00e3o e o hardware se adaptem \u00e0 din\u00e2mica real de acesso.<\/p>\n\n<h2>An\u00e1lise pr\u00e1tica: passos para uma hip\u00f3tese s\u00f3lida<\/h2>\n\n<p>Come\u00e7o por <strong>Modo 1<\/strong> para o tcp_syncookies e verifico o ponto de interven\u00e7\u00e3o 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\u00e1ficos\/ASN filtram o ru\u00eddo antes da pilha. Guardo os filtros XDP ou SmartNIC para situa\u00e7\u00f5es de PPS elevado, de modo a utilizar os recursos de forma direcionada. Por fim, documento as m\u00e9tricas para que os ajustes posteriores se baseiem em dados concretos.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/netzsicherheit-datenzentrum-8173.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IPv6 e Dual-Stack: o mesmo comutador, a mesma l\u00f3gica<\/h2>\n\n<p>Em ambientes Dual-Stack, o comportamento \u00e9 o seguinte: <strong>IPv4 e IPv6<\/strong> consistente no contexto dos cookies. O bot\u00e3o <em>net.ipv4.tcp_syncookies<\/em> controla a prote\u00e7\u00e3o globalmente para o TCP, ou seja, tamb\u00e9m para os sockets v6. Por isso, testo a transi\u00e7\u00e3o para o modo \u00abcookie\u00bb em ambos os protocolos \u2014 especialmente quando os dispositivos a montante no IPv6 utilizam outros caminhos de filtragem. Importante: os cookies SYN protegem exclusivamente o TCP. Os servi\u00e7os UDP ou QUIC requerem limites de taxa e pol\u00edticas de borda pr\u00f3prias, para que o tr\u00e1fego volum\u00e9trico n\u00e3o sobrecarregue a CPU.<\/p>\n\n<h2>M\u00e9tricas no kernel: indicadores fi\u00e1veis<\/h2>\n\n<p>Para uma monitoriza\u00e7\u00e3o fi\u00e1vel, recorro a contadores do kernel que identificam explicitamente os cookies. Al\u00e9m de <em>ss -s<\/em> E, no que diz respeito \u00e0s distribui\u00e7\u00f5es de estado, observo os contadores de cookies enviados, aceites e com falha. Desta forma, consigo verificar se a prote\u00e7\u00e3o est\u00e1 a funcionar, se os clientes leg\u00edtimos conseguem passar e se existem erros de configura\u00e7\u00e3o.<\/p>\n\n<pre><code>Vis\u00e3o geral do #\nss -s\nss -ant state syn-recv | wc -l\n\nContador de cookies do # (Kernel: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\nVisualiza\u00e7\u00e3o em tempo real do #\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Ind\u00edcios no registo (mensagem de exemplo)\nO comando # dmesg apresenta, entre outros:\n# TCP: Poss\u00edvel inunda\u00e7\u00e3o de SYN na porta 443. A enviar cookies. Verificar contadores SNMP.\n<\/code><\/pre>\n\n<p>Subir <em>Excessos de lista<\/em> e <em>ListenDrops<\/em> em paralelo a <em>SyncookiesSent<\/em> ajusto os backlogs, as tentativas de repeti\u00e7\u00e3o e os filtros a montante. Ficam <em>SyncookiesRecv<\/em> isso indica que se trata de uma enxurrada de bots; por outro lado, se forem frequentes <em>SyncookiesFailed<\/em>, verifico os percursos NAT\/proxy e eventuais manipula\u00e7\u00f5es ao longo do caminho.<\/p>\n\n<h2>Proxies, balanceadores de carga e Kubernetes<\/h2>\n\n<p>Em <strong>Cadeias de proxy e de balanceamento de carga<\/strong> determina a localiza\u00e7\u00e3o da prote\u00e7\u00e3o de cookies. Se um balanceador de carga L4\/L7 interromper o handshake TCP, uma inunda\u00e7\u00e3o 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\u00f3s de back-end t\u00eam de se proteger de forma aut\u00f3noma. No Kubernetes, ajusto os sysctls nos n\u00f3s de trabalho, especialmente em cargas de trabalho com NodePort ou HostNetwork. Para controladores de entrada com defesa SYN pr\u00f3pria (SYNPROXY, eBPF), ajusto as pol\u00edticas de forma a que n\u00e3o se interfiram mutuamente. Tenho em conta as verifica\u00e7\u00f5es de integridade do balanceador de carga nos testes, pois, caso contr\u00e1rio, janelas de teste curtas com poucas tentativas de repeti\u00e7\u00e3o podem causar falsamente a impress\u00e3o de instabilidade.<\/p>\n\n<h2>Casos-limite em pormenor: op\u00e7\u00f5es, intervalos de tempo, NAT<\/h2>\n\n<p>Os cookies apenas codificam <strong>par\u00e2metros limitados<\/strong>. As implementa\u00e7\u00f5es modernas do Linux costumam reconstruir o MSS, o SACK e o Window Scaling de forma fi\u00e1vel; no entanto, os carimbos de data\/hora e algumas op\u00e7\u00f5es menos comuns podem apresentar limita\u00e7\u00f5es, dependendo da vers\u00e3o do kernel. Por isso, considero prefer\u00edvel o modo de funcionamento (1), para que o caminho padr\u00e3o prevale\u00e7a e os cookies s\u00f3 sejam utilizados em caso de ultrapassagem. A validade de um cookie est\u00e1 ligada a intervalos de tempo \u2013 em percursos fortemente assim\u00e9tricos ou picos de atraso, um ACK leg\u00edtimo pode situar-se ligeiramente fora da janela. Em cen\u00e1rios de WAN e de sat\u00e9lite, medo, por isso, a vari\u00e2ncia de ida e volta antes de reduzir as tentativas de reenvio. NAT e dispositivos intermedi\u00e1rios que alteram n\u00fameros de sequ\u00eancia ou op\u00e7\u00f5es s\u00e3o outros candidatos a casos extremos; com capturas espec\u00edficas, comprovo onde os bits se perdem.<\/p>\n\n<h2>Inunda\u00e7\u00f5es de ACK\/RST e variantes para al\u00e9m da tempestade de SYN<\/h2>\n\n<p>Nem todos <strong>Ataque de transporte<\/strong> trata-se de um ataque de inunda\u00e7\u00e3o de SYN puro. Os ataques de inunda\u00e7\u00e3o de ACK ou RST visam a CPU e os percursos dos pacotes, sem desencadear o handshake \u2013 os cookies pouco ajudam neste caso. Nesses casos, utilizo filtros precoces (nftables\/XDP) com l\u00f3gica de estado ou limita\u00e7\u00e3o m\u00ednima da taxa de ACK. No caso espec\u00edfico de ondas de RST contra liga\u00e7\u00f5es estabelecidas, interrompo-as atrav\u00e9s de um conjunto de regras que rejeita RSTs inesperados sem janela adequada. Tamb\u00e9m abordo os repetidores semiabertos (SYN com spoofing mais ACKs tardios) atrav\u00e9s de limites de taxa por espa\u00e7o de rede de origem.<\/p>\n\n<h2>Outros ajustes: filas de lista\/aceita\u00e7\u00e3o e erros r\u00e1pidos<\/h2>\n\n<p>Para al\u00e9m dos par\u00e2metros cl\u00e1ssicos, utilizo interruptores complementares que determinam o comportamento em condi\u00e7\u00f5es extremas:<\/p>\n\n<ul>\n  <li><strong>Backlog vs. somaxconn<\/strong>: O valor em <em>listas (pendentes)<\/em> por processo \u00e9 determinado por <em>net.core.somaxconn<\/em> limitado. Asseguro que o software do servidor e o kernel funcionem em sintonia; caso contr\u00e1rio, as otimiza\u00e7\u00f5es perdem o efeito.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Se, quando a fila de aceita\u00e7\u00e3o estiver cheia, a resposta seja silenciada ou se for enviada ativamente uma resposta RST. Em APIs de elevado volume, um erro r\u00e1pido pode permitir que o cliente efetue uma nova tentativa rapidamente; no caso de clientes TLS ou legados, prefiro geralmente a rejei\u00e7\u00e3o por predefini\u00e7\u00e3o.<\/li>\n  <li><strong>Gest\u00e3o de portas e do tempo de espera (TIME-WAIT)<\/strong>: Os cookies n\u00e3o evitam <em>Engarrafamento na porta ef\u00e9mera<\/em>. Estou a planear <em>ip_local_port_range<\/em> Seja generoso e utilize as otimiza\u00e7\u00f5es TIME-WAIT com prud\u00eancia, para que a reutiliza\u00e7\u00e3o n\u00e3o d\u00ea origem a Heisenbugs.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: V\u00e1rias filas de aceita\u00e7\u00e3o por porta distribuem a carga pelos processos de trabalho e reduzem os sobrecarregamentos em CPUs individuais.<\/li>\n<\/ul>\n\n<h2>M\u00e9todos de ensaio: reprodut\u00edveis e significativos<\/h2>\n\n<p>Simulo cargas em condi\u00e7\u00f5es pr\u00f3ximas \u00e0s reais e medo o ponto de comuta\u00e7\u00e3o para o modo \u00abcookie\u00bb, a taxa de sucesso das liga\u00e7\u00f5es leg\u00edtimas, bem como o tempo de recupera\u00e7\u00e3o ap\u00f3s o pico de carga. Para tal, combino fluxos sint\u00e9ticos de pacotes SYN com pedidos reais de aplica\u00e7\u00f5es.<\/p>\n\n<pre><code>Gerar tr\u00e1fego de inunda\u00e7\u00e3o # (Laborat\u00f3rio!)\nsudo hping3 -S -p 443 --flood --rand-source \n\nVariar as condi\u00e7\u00f5es de rede #\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Misturar tr\u00e1fego leg\u00edtimo\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Observa\u00e7\u00e3o em paralelo\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Com estes passos, consigo identificar se as tentativas de repeti\u00e7\u00e3o est\u00e3o a diminuir de forma excessiva, se as firewalls a montante est\u00e3o a filtrar indevidamente os carimbos de data\/hora ou se as filas de aceita\u00e7\u00e3o de cada trabalhador est\u00e3o a transbordar de forma desproporcional. Documento os indicadores-chave (aproxima\u00e7\u00e3o \u00e0 taxa de sucesso de 100% para liga\u00e7\u00f5es leg\u00edtimas, taxa de acerto de cookies, comportamento da lat\u00eancia) para poder efetuar ajustes posteriores com base nos dados.<\/p>\n\n<h2>Opera\u00e7\u00e3o e manuten\u00e7\u00e3o: garantir a estabilidade ao longo da vida \u00fatil<\/h2>\n\n<p>Em funcionamento cont\u00ednuo, pretendo <strong>Rota\u00e7\u00e3o secreta<\/strong> (automaticamente ao n\u00edvel do kernel) e observo se as mudan\u00e7as de intervalo de tempo t\u00eam efeitos vis\u00edveis em percursos com RTT muito longo. Mantenho o kernel e os controladores atualizados para que as melhorias na implementa\u00e7\u00e3o do Cookie (melhor codifica\u00e7\u00e3o de op\u00e7\u00f5es, intervalos de tempo robustos) surtam efeito. Para auditorias, registo quando o modo de prote\u00e7\u00e3o foi ativado, quantas liga\u00e7\u00f5es permitiu e se foram ativados filtros adicionais. Em caso de altera\u00e7\u00f5es no MTU, no offloading ou nas pilhas NF (por exemplo, novos conjuntos nftables), repito testes r\u00e1pidos para detetar precocemente eventuais intera\u00e7\u00f5es indesejadas.<\/p>\n\n<h2>Vers\u00e3o abreviada para quem tem pressa<\/h2>\n\n<p>Os cookies SYN mant\u00eam a <strong>Carga do handshake<\/strong> pequenas, ao criarem estados apenas ap\u00f3s um ACK confirmado, protegendo assim a fila de SYN contra inunda\u00e7\u00f5es. Ativo o Modo 1, ajusto cuidadosamente os backlogs e as tentativas de reenvio e avalio os efeitos com m\u00e9tricas claras. Camadas adicionais, como limites de taxa do nftables, SYNPROXY e XDP, restringem o tr\u00e1fego ainda antes da pilha TCP. Em suma, protejo assim os servi\u00e7os Web, de e-mail, VPN e API contra inunda\u00e7\u00f5es de SYN, sem prejudicar os clientes regulares. Quem implementar estas medidas de forma rigorosa refor\u00e7a a disponibilidade e reduz sensivelmente as falhas em caso de carga de ataques.<\/p>","protected":false},"excerpt":{"rendered":"<p>Os \u00abcookies\u00bb TCP SYN oferecem uma prote\u00e7\u00e3o fi\u00e1vel contra ataques SYN Flood no kernel do Linux. Descubra como funciona este mecanismo e como o configurar.<\/p>","protected":false},"author":1,"featured_media":20875,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20882","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"132","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP SYN Cookies","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20875","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}