O que é um ataque DDoS? Técnica, níveis e defesa

Um ataque DDoS é a tentativa de tornar um serviço inacessível através de uma sobrecarga gerada artificialmente, executada ao mesmo tempo por um número muito elevado de remetentes diferentes. A sigla significa Distributed Denial of Service, ou seja, uma negação de serviço provocada de forma distribuída. O que é atacado não é o conteúdo de um servidor, nem uma falha de segurança no seu software, mas sim um recurso que é finito: a largura de banda da linha, a taxa de pacotes da placa de rede, um lugar numa tabela de estados do kernel ou o tempo de processamento que a aplicação gasta num único pedido. Se um destes quatro recursos ficar ocupado, os utilizadores reais deixam de conseguir passar, e isso sem que ninguém tenha entrado no sistema.

Este artigo é a introdução ao tema. Explica os três níveis em que os ataques acontecem, com que fatores de amplificação um byte de pedido se transforma em 51 000 bytes de resposta, de onde vem a capacidade de ataque e quanto custa no mercado, como reconhece um ataque a partir dos seus próprios valores medidos, o que ainda ajuda no próprio servidor e onde passa exatamente essa fronteira. Todos os números são indicados com a respetiva fonte, para que os possa verificar. Se o seu serviço estiver parado neste momento, leia primeiro a secção "O que fazer em caso de ataque" e meça, em vez de mexer nas definições.

O que é tecnicamente um ataque DDoS

Todo o ataque DDoS vive de uma assimetria: enviar um pacote tem de custar menos ao atacante do que custa ao alvo processar esse pacote. Tudo o resto é apenas a questão de saber em que ponto essa assimetria é maior. Há exatamente quatro pontos, e cada um tem um limite máximo absoluto que se consegue calcular.

A largura de banda da linha. Uma ligação de 1 Gbit/s transporta 125 megabytes por segundo, não mais do que isso. Quem enviar mais gera perdas, e essas perdas atingem os pacotes dos seus utilizadores tanto como os do atacante, porque uma ligação cheia não escolhe.

A taxa de pacotes. O pacote Ethernet mais pequeno admissível tem 64 bytes e ocupa, com preâmbulo e intervalo entre pacotes, 84 bytes na linha. Em 1 Gbit/s cabem cerca de 1,49 milhões deles por segundo. Um kernel de servidor normal processa, consoante o CPU e a placa de rede, algumas centenas de milhares antes de começar a descartar. É por isso que a taxa de pacotes é quase sempre o limite que se atinge antes da largura de banda.

As tabelas de estados. O kernel guarda as ligações TCP semiabertas e os fluxos de pacotes. Estas tabelas são limitadas em número, não em bits por segundo. Enchem-se com muito pouca largura de banda, se cada pacote trouxer um novo endereço de remetente.

O tempo de processamento da aplicação. Uma pesquisa, uma tentativa de início de sessão com verificação de palavra-passe ou uma consulta ao servidor que devolve uma lista de mods completa custa ao alvo mil vezes mais do que ao remetente. Aqui, um ataque eficaz muitas vezes nem precisa de 10 Mbit/s.

DoS e DDoS: a diferença que se consegue medir

A base conceptual vem do RFC 4732, "Internet Denial-of-Service Considerations", uma publicação informativa do IETF de novembro de 2006. Ali diz-se literalmente: "A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work." Um ataque DoS está portanto definido pelo efeito, não pelo número de origens. Distribuído, ou seja DDoS, é quando essas origens são numerosas e independentes entre si.

Na prática, a diferença conta num único ponto: no comprimento da sua lista de bloqueio. Um ataque DoS a partir de uma origem termina com uma regra. A Cloudflare documentou em maio de 2025 um ataque proveniente de 122 145 endereços de origem diferentes, de 161 países e de 5 433 sistemas autónomos, em média 26 855 novos endereços por segundo e 45 097 no pico. Contra algo assim não existe lista de bloqueio que cresça com rapidez suficiente, e cada entrada nela custa ainda memória e tempo de pesquisa no equipamento que já está sobrecarregado.

O guia conjunto "Understanding and Responding to Distributed Denial-of-Service Attacks" da CISA, do FBI e do MS-ISAC divide os ataques em exatamente três técnicas: volumétrica, de protocolo e de aplicação. Esta divisão em três é a mais útil que existe, porque descreve ao mesmo tempo qual dos seus quatro recursos está a ser atacado e onde tem de estar a defesa.

Os três níveis de um ataque DDoS

Ataques volumétricos na Layer 3 e 4

Um ataque volumétrico não quer outra coisa senão encher a linha à frente do alvo. A medição faz-se em bits por segundo. O meio é habitualmente um flood UDP, porque o UDP não conhece um estabelecimento de ligação que se possa exigir e porque os endereços de remetente se falsificam com facilidade.

O maior exemplo atualmente documentado em público: a Cloudflare indica, para o período até ao final de 2025, um ataque travado automaticamente com 31,4 Tbit/s, que durou 35 segundos. É a capacidade de cerca de 31 400 ligações de servidor de 1 Gbit/s, ao mesmo tempo, durante mais de meio minuto. No mesmo relatório consta um segundo valor que torna a ordem de grandeza mais palpável do que o valor de pico: em 2025 o mesmo operador travou 47,1 milhões de ataques DDoS, mais 121 por cento do que no ano anterior, em média 5 376 ataques por hora.

O caso melhor documentado, de maio de 2025, mostra como é um ataque destes quando se decompõe: 7,3 Tbit/s no pico, 37,4 terabytes de dados em 45 segundos, o que dá em média cerca de 830 gigabytes por segundo. Uma linha de 1 Gbit/s teria precisado de mais de três dias para a mesma quantidade de dados. 99,996 por cento do tráfego eram floods UDP puros, distribuídos em média por 21 925 portas de destino ao mesmo tempo, 34 517 no pico. Esta distribuição por todas as portas é típica: o atacante não sabe qual é a porta importante, portanto leva todas.

Ataques ao protocolo: as tabelas, não a linha

Um ataque ao protocolo aproveita o facto de o kernel ter de guardar estados. O exemplo clássico é o SYN flood: o atacante envia pacotes TCP com o bit SYN ativo e endereço de remetente falsificado, o servidor cria para cada um deles uma entrada na sua fila de espera de ligações semiabertas, responde com SYN-ACK a um endereço que nunca respondeu, e espera. A medição faz-se aqui em pacotes por segundo, não em gigabits.

O comprimento desta fila de espera está em net.ipv4.tcp_max_syn_backlog e num servidor normal situa-se na casa dos milhares. Uma fila com 1 024 lugares está cheia, com 1,49 milhões de pacotes SYN por segundo, em menos de um milissegundo. Para isso basta, em termos puramente aritméticos, 1 Gbit/s, e se o alvo for apenas a tabela basta uma fração disso.

À mesma família pertence um método que só foi descrito em 2021: a reflexão TCP através de equipamentos intermédios com estado. O trabalho "Weaponizing Middleboxes for TCP Reflected Amplification" mostra que firewalls e infraestruturas de censura, que seguem o estado TCP apenas de forma parcial, reagem a um único pacote falsificado com páginas inteiras de resposta. Com isso passou a ser possível abusar também do TCP para amplificação, algo que até então era considerado praticamente impossível.

Ataques à aplicação na Layer 7

Um ataque à aplicação parece tráfego normal, porque é tráfego normal, apenas em quantidade errada. A medição faz-se em pedidos por segundo. Chega através de uma ligação completamente estabelecida, sobrevive portanto a qualquer verificação que avalie apenas o estabelecimento da ligação, e precisa de pouca largura de banda: 10 000 pedidos HTTP por segundo são, consoante o tamanho do pedido, menos de 50 Mbit/s e ainda assim suficientes para pôr uma base de dados de rastos.

A referência para isso chama-se HTTP/2 Rapid Reset, divulgada a 10 de outubro de 2023 como CVE-2023-44487. A vulnerabilidade está na capacidade de multiplexagem do HTTP/2: o atacante abre um fluxo de dados, envia o pedido e interrompe o fluxo de imediato. O servidor já começou o trabalho, mas o atacante volta a ter logo um lugar livre na janela. Os valores assim alcançados foram de 201 milhões de pedidos por segundo (Cloudflare), 398 milhões (Google) e 155 milhões (Amazon). Para comparação: o maior ataque de Layer 7 medido pela Cloudflare até então tinha ficado nos 71 milhões de pedidos por segundo.

Nos servidores de jogos, o nível da Layer 7 é o próprio estabelecimento da ligação. Nullping, QuietException e floods de handshake falso contra redes de Minecraft quase não precisam de largura de banda e paralisam conjuntos inteiros de proxies, porque cada pacote obriga o proxy a uma decisão de estado dispendiosa. Como são exatamente estes padrões está em Proteção DDoS e proteção Nullping para Minecraft.

Os três níveis em comparação

Os ataques reais não se prendem a esta divisão. O caso mais desagradável na prática é o ataque em vários níveis: uma parte volumétrica, que mantém a linha ocupada, mais uma parte de Layer 7, que passa no momento em que a atenção está na largura de banda. Um dos ataques filtrados na KernelHost mostrados mais abaixo era composto por mais de doze padrões principais diferentes ao mesmo tempo.

Ataques de amplificação: como um byte se transforma em 51 000

Um ataque de amplificação é um ataque em que o atacante não dispara ele próprio sobre o alvo, mas leva serviços alheios, acessíveis publicamente, a fazê-lo por ele. Envia um pequeno pedido a um serviço aberto e inscreve como remetente o endereço IP da vítima. O serviço responde como lhe compete, só que à vítima, e a resposta é várias vezes maior do que o pedido.

A relação entre o tamanho da resposta e o tamanho do pedido chama-se Bandwidth Amplification Factor, abreviadamente BAF. Um BAF de 50 significa que um atacante com 1 Gbit/s de ligação própria dirige 50 Gbit/s ao alvo. São necessárias duas coisas em conjunto para que isto funcione: um protocolo sobre UDP que responda mais do que aquilo que lhe é perguntado, e a possibilidade de falsificar o endereço de remetente. É por isso que o IP spoofing é a condição indispensável de qualquer ataque de amplificação, e não apenas uma tática de ocultação.

Para quem defende, daí decorre uma propriedade incómoda: o tráfego vem de servidores reais e legítimos. São resolvers DNS reais, servidores de hora reais, servidores de jogos reais. Uma lista de bloqueio por endereço de origem ou exclui países inteiros ou não tem efeito.

Os fatores de amplificação dos protocolos abusados

Os fatores seguintes vêm do alerta TA14-017A do US-CERT, ou seja, da CISA, "UDP-Based Amplification Attacks", que é continuamente ampliado desde 2014. É a referência a que todo o setor recorre.

A tabela explica por que razão a lista de portas bloqueadas é parecida em todas as firewalls bem mantidas. O que pode fazer por conta própria é pouco, mas importante: verifique com ss -lnup se no seu servidor está aberto para a rede algum serviço desta tabela. Um memcached que não esteja ligado a 127.0.0.1 transforma o seu servidor numa arma contra terceiros, custa-lhe a sua própria largura de banda de saída e leva o seu endereço IP para listas de bloqueio de onde é difícil sair.

Porque é que os protocolos de query dos jogos entram nesta lista

Os servidores de jogos estão nesta tabela com dois papéis. São amplificadores, porque a sua porta de query responde a um pequeno pacote com nome, mapa, número de jogadores e a lista de mods completa. E são vítimas, porque essa mesma consulta custa tempo de processamento, muitas vezes precisamente no núcleo que sustenta a simulação do jogo.

O fator de amplificação do protocolo Steam é baixo, 5,5, o do protocolo Quake, mais antigo, é alto, 63,9. Mas o efeito não depende apenas do fator, e sim do tamanho da resposta em cada caso concreto: um servidor com 200 mods entrega uma resposta claramente maior do que um servidor sem mods. A Bohemia Interactive documenta para o Arma 3, no ticket T83469 desde 2015, que bastaram 4 Mbit/s de consultas falsificadas dirigidas à porta de query Steam para congelar um servidor. Quatro megabits por segundo é menos do que uma única ligação doméstica consegue produzir.

Daí decorre a regra que vale para qualquer jogo: limitar a porta de query, não bloqueá-la. Quem a bloqueia desaparece da lista de servidores e deixa de ser encontrado por novos jogadores. Qual é essa porta em cada jogo e com que aperto pode ser conduzida está nos artigos específicos de cada jogo mais abaixo, por exemplo para o Arma 3, o CS2 e os títulos Source ou o Rust.

O caso memcached: 1,35 Tbit/s contra o GitHub

A 28 de fevereiro de 2018 o GitHub esteve inacessível das 17:21 às 17:26 UTC e apenas intermitentemente acessível até às 17:30 UTC. O ataque alcançou 1,35 Tbit/s com 126,9 milhões de pacotes por segundo e veio de mais de 1 000 sistemas autónomos diferentes e de dezenas de milhares de endpoints individuais. Foi amplificado através de memcached, com um fator de até 51 000: um byte do atacante gerava até 51 kilobytes em direção ao alvo.

Este caso continua a ser a melhor lição, porque mostra três coisas ao mesmo tempo. Primeiro: a amplificação vence o tamanho do botnet. O atacante não precisou de cem mil equipamentos, precisou de instâncias memcached abertas, das quais havia então mais de 90 000 acessíveis em todo o mundo. Segundo: 126,9 milhões de pacotes por segundo são cerca de 85 vezes mais do que uma linha de 1 Gbit/s consegue transportar. Nenhuma definição no servidor muda isso. Terceiro: a defesa funcionou porque o tráfego foi desviado para uma rede de filtragem, e o tempo de indisponibilidade acabou assim em nove minutos em vez de nove horas.

De onde vem a capacidade para um ataque DDoS

Botnets de equipamentos comprometidos

Um botnet é um conjunto de equipamentos alheios, comprometidos com software malicioso, que um atacante controla remotamente a partir de um ponto central. Os proprietários, em regra, não dão por nada, porque o equipamento continua a fazer aquilo para que foi comprado. São atacados sobretudo os equipamentos que estão permanentemente ligados à rede, são raramente atualizados e trazem palavras-passe predefinidas: routers, câmaras de videovigilância, gravadores de vídeo em rede e boxes de televisão.

A referência é o Mirai, cujo código-fonte foi publicado no final de setembro de 2016. O trabalho "Understanding the Mirai Botnet" (USENIX Security 2017) acompanha a rede durante sete meses e cifra o máximo em mais de 600 000 equipamentos infetados. O ataque ao site de Brian Krebs em setembro de 2016 alcançou 620 Gbit/s e veio de mais de 175 000 equipamentos. No ataque ao operador de DNS Dyn a 21 de outubro de 2016, que tornou o Twitter, o Spotify e o Reddit inacessíveis ao mesmo tempo, foram contados cerca de 107 000 endereços IP atacantes.

Nove anos depois, a ordem de grandeza é outra. A Cloudflare atribui o ataque recorde de 31,4 Tbit/s a um botnet com um tamanho estimado de um a quatro milhões de equipamentos infetados, predominantemente boxes de televisão Android. Na onda de ataques de dezembro de 2025 foram contados 902 ataques hipervolumétricos, em média 53 por dia, com valores de pico de 9 mil milhões de pacotes por segundo, 24 Tbit/s e 205 milhões de pedidos por segundo. O tamanho dos botnets cresceu assim, no espaço de uma década, por um fator de 5, e a largura de banda alcançada por um fator de 50.

Serviços de booter e de stresser e quanto custa um ataque

Entre o botnet e quem encomenda o ataque está um serviço que vende a capacidade de ataque por subscrição. Estes serviços apresentam-se como "booter", "stresser" ou "IP stresser" e afirmam nos seus termos de utilização que servem para testes de carga dos sistemas próprios. Nunca verificam se o alvo indicado pertence ao utilizador, e é exatamente essa a diferença entre uma ferramenta e uma oferta.

A utilização passa por uma interface web com três campos: alvo, porta, duração. Há processos de pagamento, apoio ao cliente e programas de revenda. Os pacotes de entrada situam-se em cerca de 10 a 20 euros por mês, os pacotes maiores, com mais largura de banda e maior duração de ataque, em algumas centenas de euros por mês. Fica assim respondida a pergunta de por que razão também os projetos pequenos são atingidos: um ataque que tira a um gameserver o sábado à noite custa a quem o desencadeia menos do que dois bilhetes de cinema e nenhum conhecimento técnico.

Do outro lado existe uma pressão permanente de perseguição criminal. Na semana de ação da operação internacional PowerOFF, em abril de 2026, as autoridades de 21 países assumiram o controlo de 53 domínios destes serviços, detiveram quatro pessoas e realizaram 25 buscas domiciliárias. Os investigadores obtiveram acesso aos dados de mais de três milhões de contas de utilizador, e mais de 75 000 utilizadores identificados foram notificados por escrito. Em dezembro de 2024 tinham sido desligadas 27 plataformas na mesma operação. Quem paga um serviço destes deixa portanto um rasto de pagamento numa base de dados que, mais tarde ou mais cedo, é apreendida.

Como reconhece um ataque DDoS

O que os utilizadores comunicam, e o que isso já diz

A primeira informação vem quase sempre dos utilizadores, e é mais aproveitável do que parece. Quatro relatos têm um significado claro:

• "Caiu tudo ao mesmo tempo." Uma quebra simultânea em todos os utilizadores aponta para a linha ou para o processo do serviço, não para ligações individuais. Um problema de carga atinge os utilizadores uns após os outros.
• "O ping salta de 20 para 400 e volta." Uma latência oscilante com a ligação a manter-se é o padrão de uma fila de espera cheia à frente do alvo, não de um processo sobrecarregado.
• "A lista de servidores mostra-nos como offline, mas eu consigo ligar-me." Este é o indício de um flood de query: a porta de query já não responde, a porta de jogo ainda responde.
• "Pela rede móvel entro, pela minha ligação não." Um comportamento diferente por rede de acesso aponta para o facto de não ser o seu servidor, mas sim um caminho até ele, que está saturado.

Os quatro valores a medir no servidor

Depois mede-se, e por esta ordem: taxa de pacotes, largura de banda, estados de ligação, contadores de descarte. A indicação de utilização do CPU vem em último lugar, porque num ataque à rede muitas vezes não chama a atenção.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 dá os pacotes e os bytes por segundo em cada interface ao longo de dez segundos. Decisiva é a relação entre eles: muitos pacotes com poucos bytes significa pacotes pequenos, ou seja, um ataque ao protocolo. Poucos pacotes com muitos bytes significa pacotes grandes, ou seja, um ataque de amplificação. ip -s link show mostra nas colunas dropped e overrun se o kernel já está a descartar. ss -tn state syn-recv conta as ligações semiabertas: um valor de três dígitos é normal, um de cinco dígitos é um SYN flood. E o nstat dá os contadores que ficam, mesmo depois de o ataque ter acabado.

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo funciona normalmente. Sem um valor normal não consegue dizer se 40 000 pacotes por segundo são muito ou se é simplesmente um sábado à noite. Com apt-get install -y vnstat sysstat a medição fica sempre a correr. As instruções detalhadas para a interpretação estão em Detetar um ataque DDoS.

As linhas de log que são inequívocas

Quatro mensagens no log do kernel e no log do servidor web são praticamente prova. dmesg -T | tail -50 mostra as três primeiras:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

A primeira linha significa que a fila de espera das ligações semiabertas transbordou e que o kernel passou para SYN cookies. Se ali estiver em vez disso Dropping request, então net.ipv4.tcp_syncookies está a 0 e o servidor descarta pedidos, incluindo os legítimos. A segunda linha significa que o seguimento de ligações está cheio, e a partir desse momento o servidor descarta também tráfego legítimo. A terceira linha é um efeito secundário: o kernel suprime mensagens, porque de outra forma estaria ocupado a registar logs. A quarta linha desloca o problema para a aplicação.

No log de acessos do servidor web há duas coisas reveladoras. Uma proporção subitamente elevada do código de estado 499 significa que o cliente fecha a ligação antes de a resposta estar pronta, e é precisamente isso que faz um ataque de Layer 7 que só quer desencadear trabalho e não ler o resultado. E um campo de referrer vazio em quase todos os pedidos distingue um ataque de um afluxo real de visitantes, que traz consigo referrers de motores de busca e de redes sociais.

A contraprova: ataque, afluxo ou erro próprio

O que ajuda no próprio servidor

No servidor consegue-se mais do que muitas vezes se afirma, e precisamente contra tudo aquilo que se mantém pequeno: bots mal feitos, origens individuais, floods de query e ataques à aplicação. As ferramentas para isso são o nftables, o seguimento de ligações, os SYN cookies e uma limitação de taxa por endereço de origem. Todas as indicações seguintes aplicam-se ao Debian 12, ao Debian 13, ao Ubuntu 22.04 LTS e ao Ubuntu 24.04 LTS e estão escritas para root.

nftables: descartar cedo, calcular pouco

O princípio é este: um pacote que vai ser descartado deve ser descartado o mais cedo e o mais barato possível. Cada regra que corra antes disso custa tempo de processamento vezes taxa de pacotes. O conjunto de regras seguinte para /etc/nftables.conf deixa passar um servidor web e um serviço de jogo e descarta o resto, com uma limitação de taxa para novas ligações TCP por endereço de origem:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Inscreva em adminips o seu próprio endereço fixo antes de carregar, caso contrário tranca-se fora do SSH. A verificação e a ativação fazem-se assim:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Três pontos decidem o efeito. ct state established,related accept está deliberadamente como segunda regra, para que as ligações existentes não percorram todo o conjunto de regras. ct state invalid counter drop remove combinações de flags erradas e fragmentos atrasados, sem que os tenha de descrever um a um. E o counter antes de cada drop é a razão pela qual depois sabe que regra é que atuou: se os contadores ficarem a zero, a regra não está a ser alcançada, e esse é um diagnóstico completamente diferente de um conjunto de regras sem efeito.

SYN cookies e o limite do backlog

Os SYN cookies são um método em que o servidor não guarda a ligação semiaberta, mas escreve os dados necessários, cifrados, no seu próprio número de resposta. Quando o terceiro pacote do estabelecimento da ligação regressa, ele volta a calcular o estado a partir daí. Assim a fila de espera não transborda, porque para essas ligações não existe fila de espera.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Estes valores pertencem a um ficheiro em /etc/sysctl.d/ e são aplicados com sysctl --system, caso contrário desaparecem no reinício seguinte. No Debian e no Ubuntu, o tcp_syncookies vem de origem a 1, o que está correto. O valor 1 não significa "sempre cookies", mas sim "cookies a partir do momento em que a fila de espera transborde".

O preço disso é real e raramente é mencionado. Num cookie não há espaço para as opções TCP do outro lado. O Linux só salva o escalamento de janela e a confirmação seletiva se net.ipv4.tcp_timestamps estiver a 1, porque assim os dados viajam dentro da marca temporal. Sem marca temporal desaparecem, e a ligação corre mais devagar durante o resto da sua vida. Além disso, para o tamanho máximo de pacote só estão disponíveis três bits, ou seja, oito degraus grosseiros em vez do valor exato. Os SYN cookies são um modo de emergência que salva ligações, não uma definição para o funcionamento normal.

conntrack: a tabela que é a primeira a ficar cheia

O seguimento de ligações do kernel cria uma entrada para cada fluxo de pacotes, também para o UDP, apesar de o UDP não conhecer ligações. É precisamente esta tabela o primeiro recurso a esgotar-se num ataque distribuído, e esgota-se muito depressa: com 1,49 milhões de pacotes por segundo, cada um com um novo endereço de remetente, uma tabela de 262 144 lugares fica cheia em menos de um quinto de segundo.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Uma entrada ocupa cerca de 300 bytes, 524 288 entradas dão portanto cerca de 150 megabytes de memória do kernel. O tamanho da tabela de hash não se define por sysctl, mas como parâmetro de módulo, habitualmente num quarto do limite máximo, em /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Para um servidor exclusivamente de jogo ou de voz, a solução mais elegante é não deixar que o tráfego de jogo seja seguido. Isso poupa a tabela por completo:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Atenção: o notrack e as regras com estado excluem-se mutuamente. Quem retira uma porta do seguimento não pode usar mais nenhuma regra com ct state para essa porta, caso contrário a autorização deixa de atuar e o serviço fica fechado.

Limitação de taxa por endereço de origem

Uma limitação de taxa por endereço de origem é a medida individual mais eficaz no servidor, porque atinge exatamente aquilo que um atacante faz e deixa passar exatamente aquilo que um utilizador faz. A diferença é grande: um navegador de servidores real consulta algumas vezes por minuto, um atacante centenas de vezes por segundo. Com o nftables trabalha-se para isso com conjuntos dinâmicos, como no conjunto de regras acima, com o iptables clássico com hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Todos os números em regras deste tipo são valores de partida, não verdades absolutas. Meça primeiro durante uma semana em funcionamento normal, caso contrário expulsa os seus próprios utilizadores, e no pior momento possível. Tenha ainda em conta que as regras puras de iptables desaparecem depois de um reinício (apt-get install -y iptables-persistent, depois netfilter-persistent save) e que, com o UFW, pertencem a /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. O conjunto de regras completo para o funcionamento corrente está em Proteger o servidor contra ataques DDoS.

Onde acaba qualquer filtragem no servidor

Agora a parte que nenhum ficheiro de configuração resolve. Todas as medidas anteriores correm no seu servidor, ou seja, no fim da linha. Uma regra de firewall decide sobre um pacote que já passou pelo cabo. Pode descartá-lo, mas não pode fazer com que ele não tenha sido enviado. Se a linha à frente estiver cheia, os pacotes dos seus utilizadores já nem chegam a passar, e isso independentemente de quão bom seja o seu conjunto de regras.

Esta tabela responde caso a caso à pergunta de se a proteção própria chega. O ataque ao GitHub, com 126,9 milhões de pacotes por segundo, cabe à justa em taxa de pacotes numa ligação de 100 Gbit/s, mas com 1,35 Tbit/s de volume seriam precisas catorze dessas ligações ao mesmo tempo. O ataque recorde de 31,4 Tbit/s corresponde a 314 ligações de 100 Gbit/s completamente saturadas. Um gameserver está tipicamente ligado a 1 Gbit/s ou a duas vezes 1 Gbit/s: o limite da proteção própria situa-se assim em cerca de 1,5 a 3 milhões de pacotes por segundo, e na prática bastante abaixo disso, porque o kernel desiste antes.

Existe ainda um segundo limite, mais desagradável. A partir do momento em que a linha está saturada, é possível que nem sequer consiga estabelecer a sessão SSH com que queria medir. Quem não tiver então um acesso independente da rede, por exemplo uma consola VNC na área de cliente, já nem consegue ver o que está a acontecer.

O que só ajuda à frente do servidor: filtragem na rede e scrubbing

Só consegue filtrar com eficácia quem tiver mais capacidade do que o ataque. Isso pressupõe um ponto onde muitas linhas convergem, ou seja, uma rede, não uma máquina. Aí existem dois métodos que se complementam.

Filtragem em tempo real na rede. Todo o tráfego passa permanentemente por um andar de filtragem que avalia cada pacote antes de o entregar ao servidor. A vantagem é não haver comutação: a proteção não precisa de reconhecer um ataque primeiro para atuar. É precisamente isso que decide nos jogos, porque um tempo de comutação de dois minutos é uma ronda perdida, e um tempo de comutação de dois minutos num ataque que dura 35 segundos não é defesa nenhuma.

Scrubbing. Se a rede reconhecer um grande ataque volumétrico, o tráfego afetado é desviado para centros de filtragem, ali libertado das partes nocivas e depois entregue em direção ao alvo. O sentido deste desvio é a proximidade: o tráfego de ataque termina no ponto em que entra, em vez de terminar só no datacenter. As regras de filtragem são para isso distribuídas pela rede, tecnicamente descritas no RFC 8955 como Flow Specification.

A contramedida estrutural contra endereços de remetente falsificados é conhecida, aliás, desde o ano 2000 e está no RFC 2827, o BCP 38: quem liga um cliente descarta nessa fronteira todos os pacotes cujo endereço de remetente não pertença a esse cliente. O RFC 3704 amplia isso às redes com várias ligações. Se todos os operadores de rede aplicassem isto, toda a classe dos ataques de amplificação estaria resolvida. Não está, porque basta que alguns não o façam.

E existe um terceiro método que é preciso conhecer, porque muitas vezes é vendido como proteção: o null-routing, tecnicamente Remote Triggered Black Hole Filtering segundo o RFC 5635. Nele, o endereço IP atacado é anunciado na rede como inalcançável, e todo o tráfego dirigido a ele é descartado, o tráfego de ataque tanto como o dos seus utilizadores. Isso protege a rede do fornecedor; para si, o resultado é idêntico ao de um ataque bem-sucedido, e normalmente ainda durante horas depois. Na dúvida, pergunte se filtram ou se aplicam null-routing. A resposta decide mais sobre a sua disponibilidade do que qualquer indicação de hardware.

O que a KernelHost põe do outro lado

A proteção permanente incluída em todos os pacotes de servidor

A proteção DDoS da KernelHost está construída em dois níveis e permanentemente ativa, sem que tenha de ativar, encomendar ou configurar seja o que for:

• Nível 1: 17 Tbps de capacidade de mitigação na rede global de scrubbing. Os ataques volumétricos são limpos perto da sua origem, antes de chegarem ao datacenter.
• Nível 2: filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main. Mesmo à frente do servidor são reconhecidos e descartados os padrões específicos de cada protocolo, pacote a pacote.

Duas características são decisivas. A proteção corre em permanência e está ativa a partir da disponibilização do servidor, pelo que não existem aqueles minutos iniciais de um ataque em que o serviço desaparece. E não é usado null-routing: o seu endereço IP mantém-se na rede e só os pacotes nocivos são descartados. Que jogos e protocolos têm perfis de filtragem próprios é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas, todas as noites à mesma hora e com padrões variáveis. Para esses existe a Advanced DDoS Protection a partir de 50,00 € por mês, PrePaid, sem prazo mínimo e sem taxa de instalação. A diferença não está em mais capacidade, mas sim no controlo:

• IP de proteção dedicado a partir do núcleo de Frankfurt, para o qual o seu servidor é comutado dentro da nossa própria rede. Do seu lado não é preciso qualquer alteração.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente: define separadamente o que é permitido na porta de jogo e o que é permitido na porta de query, podendo assim aproveitar exatamente a assimetria descrita na secção sobre os protocolos de query.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, em vez de esperar por uma janela de manutenção.
• Perfil de proteção adequado a cada serviço, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP.

A Advanced DDoS Protection destina-se a clientes da KernelHost e pressupõe um servidor na KernelHost. Se o seu projeto corre atualmente noutro sítio e é ali atacado com regularidade, o caminho é a mudança para cá, não uma assistência remota ao seu endereço anterior.

Os dois níveis em comparação

Seis ataques reais filtrados em funcionamento

Os seis ataques seguintes atingiram servidores de clientes da KernelHost e foram integralmente filtrados em tempo real, sempre sem qualquer falha de serviço. As imagens provêm da monitorização em direto da mitigação.

Servidor de voz TeamSpeak 3, porta 9987 UDP. Ataque complexo com vários padrões em simultâneo, acima de 473,4 Gbit/s e acima de 41,5 milhões de pacotes por segundo. É cerca de 28 vezes a taxa de pacotes de uma ligação de 1 Gbit/s.

Gameserver ARK, porta 7777 UDP. Flood UDP simples, sem estrutura complexa, mas com mais de 112,2 Gbit/s e mais de 8,7 milhões de pacotes por segundo. Como se protege por si próprio um cluster ARK está em Proteger o servidor ARK contra DDoS.

Ataque all-port, portas 0-65535 TCP e UDP. Mais de doze padrões de ataque principais diferentes contra todas as portas ao mesmo tempo, no total mais de 21,3 Gbit/s e mais de 3,9 milhões de pacotes por segundo. Este caso mostra a dispersão por todas as portas que também o caso da Cloudflare de maio de 2025 apresenta, com uma média de 21 925 portas de destino.

Minecraft e OpenVPN, portas 25565 TCP e 1194 UDP. Ataque combinado com mais de dezasseis padrões de ataque principais diferentes, mais de 4 milhões de pacotes por segundo e mais de 8,6 Gbit/s. Ambos os serviços permaneceram acessíveis de forma contínua, apesar de falarem protocolos diferentes.

Flood UDP contra uma única porta de serviço, oito minutos. O mais severo dos seis casos: 745,5 Gbit/s e 73,1 milhões de pacotes por segundo, cerca de 49 vezes a taxa de pacotes de uma ligação de 1 Gbit/s. 99,93 por cento do tráfego foi para uma única porta de destino, e as origens estavam totalmente distribuídas. Depois de oito minutos o ataque terminou, e o serviço permaneceu acessível de forma contínua.

Ataque prolongado ao longo de três horas e 31 minutos. 501,2 Gbit/s e 43,9 milhões de pacotes por segundo, não como um pico isolado, mas como uma sucessão de ondas sem pausa. Sete padrões de ataque em simultâneo, entre eles amplificação por SSDP, MS SQL RS, L2TP e RIPv1. As portas de destino dispersaram-se por todo o intervalo de 1024 a 65535, pelo que mudar de porta não teria servido de nada. Mais sobre os dois casos em Quanto tempo dura um ataque DDoS.

O que fazer em caso de ataque, por esta ordem

A ordem é mais importante do que os passos em si, porque os erros mais frequentes acontecem nos primeiros cinco minutos.

1. Medir, não mexer nas definições. Guarde primeiro num ficheiro os valores de sar -n DEV 1 10, ip -s link show, ss -s e dmesg -T. Depois do ataque desaparecem, e sem eles ninguém o consegue ajudar.
2. Não reiniciar. Um reinício apaga todos os contadores, todos os estados de ligação e todas as provas, e a carga volta depois de poucos segundos.
3. Determinar de que nível se trata. Bytes divididos por pacotes dá o tamanho médio dos pacotes. Abaixo de 100 bytes aponta para um ataque ao protocolo, acima de 1 000 bytes para um ataque de amplificação, tamanhos normais com carga alta do CPU para a Layer 7.
4. Fechar as portas de administração. Painel, base de dados, RCON e tudo o que não tem de ser público deve ficar limitado ao seu próprio endereço. Isso reduz de imediato a superfície de ataque e sem risco para os utilizadores.
5. Definir uma limitação de taxa, apertada na porta de query e larga na porta de utilização. Não bloqueie a porta de query, caso contrário desaparece de todas as listas de servidores.
6. Não mudar o próprio endereço de forma precipitada. Uma mudança de endereço só atua enquanto o novo endereço não estiver outra vez publicado, e um registo DNS antigo esquecido torna a mudança inútil.
7. Envolver o fornecedor com números. Abra um ticket com hora, porta de destino, taxa de pacotes, largura de banda e tamanho médio dos pacotes. Estes cinco dados decidem a rapidez com que as regras de filtragem para o seu endereço são afinadas.
8. Documentar depois. Registe quando começou, quanto tempo durou e qual foi o padrão. Ataques recorrentes à mesma hora são o critério para saber se um projeto precisa de um IP de proteção dedicado.

O procedimento detalhado para um ataque grave e prolongado está em Ataque DDoS grave: o que fazer.

Situação jurídica: um ataque DDoS é um crime

Na Áustria, um ataque DDoS cai sob o § 126b do Código Penal austríaco (StGB), "Perturbação da funcionalidade de um sistema informático". O tipo base prevê pena de prisão até seis meses ou pena de multa até 360 dias de multa. Se a perturbação durar um período prolongado, são até dois anos. Se muitos sistemas forem atacados com um programa manifestamente criado para esse fim, são até três anos. E em caso de dano superior a 300 000 euros, de ataque a infraestruturas críticas ou de atuação como membro de uma associação criminosa, a moldura vai de seis meses a cinco anos. Em complemento, o § 126b do StGB é acompanhado pelo § 126c do StGB, que pune já a produção, a difusão e a disponibilização dos programas destinados a esse fim.

Na Alemanha aplica-se o § 303b do Código Penal alemão (StGB), "Sabotagem informática": pena de prisão até três anos ou pena de multa, até cinco anos se o processamento de dados servir um estabelecimento, uma empresa ou uma autoridade pública, e em casos especialmente graves de seis meses a dez anos, por exemplo em caso de atuação a título profissional ou de afetação de infraestruturas críticas. A tentativa é punível, e para os atos preparatórios o § 303b, n.º 5, do StGB remete para o § 202c do StGB.

Os serviços de booter e de stresser não são portanto uma zona cinzenta, mas sim a parte paga de um crime. Três pontos são recorrentemente mal entendidos. Primeiro, a indicação "apenas para testes de carga dos sistemas próprios" não torna nada legal, porque os serviços não verificam a quem pertence o alvo indicado. Segundo, também quem encomenda é punível, não só quem opera: depois da semana de ação de abril de 2026, a Europol notificou expressamente por escrito mais de 75 000 utilizadores identificados, precisamente para esclarecer esse ponto. Terceiro, um teste de carga ao seu próprio servidor através de um serviço destes também não é solução, porque o tráfego de ataque passa pela rede do fornecedor e, com isso, pelas linhas de outros clientes, o que qualquer contrato de alojamento proíbe. Quem quiser mesmo medir a resistência do seu serviço fá-lo de forma anunciada e combinada com o fornecedor. Esta secção reproduz o estado da lei e não é consultoria jurídica.

O guia adequado ao seu serviço

Este artigo explica o princípio. Que porta tem de estar aberta, que diretiva de configuração limita que consulta e onde está o limite em cada jogo: isso está nos artigos sobre cada serviço, sempre com uma tabela de factos das portas.

• Fundamentos e procedimento: Detetar um ataque DDoS, Proteger o servidor contra ataques DDoS, Ataque DDoS grave: o que fazer, Proteção DDoS para jogos com filtragem em tempo real
• Minecraft e voz: Minecraft e Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Roleplay com base em GTA: FiveM, RedM, RAGE MP e alt:V, SA-MP e open.mp, MTA:SA
• Sobrevivência e construção: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Tática e tiro: CS2 e Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Em resumo

• Um ataque DDoS ocupa um de quatro recursos finitos: largura de banda, taxa de pacotes, uma tabela de estados do kernel ou o tempo de processamento da aplicação. Não usa nenhuma falha de segurança, pelo que atualizar por si só não protege.
• O RFC 4732 define um ataque DoS pelo efeito, não pelo número de origens. Distribuído chama-se quando as origens são numerosas: no caso da Cloudflare de maio de 2025 eram 122 145 endereços de 161 países.
• A CISA, o FBI e o MS-ISAC distinguem três técnicas: volumétrica em Gbit/s, de protocolo em pacotes por segundo, de aplicação em pedidos por segundo. Cada uma precisa de uma defesa diferente.
• Os ataques de amplificação abusam de serviços UDP abertos. Os fatores vão de 5,5 no protocolo Steam, passando por 30,8 no SSDP e 556,9 no NTP, até 51 000 no memcached, tal como consta do US-CERT TA14-017A.
• A capacidade vem de botnets de equipamentos comprometidos, de 600 000 no Mirai em 2016 até um a quatro milhões estimados por trás do ataque recorde de 31,4 Tbit/s, e é revendida a partir de cerca de 10 euros por mês.
• No servidor atuam o nftables, os SYN cookies, limites de conntrack ajustados e a limitação de taxa por endereço de origem. Acabam em cerca de 1,5 milhões de pacotes por segundo, porque uma ligação de 1 Gbit/s não transporta mais do que isso.
• Acima desse limite decide exclusivamente a filtragem na rede à frente do servidor. O null-routing não é defesa, é o resultado que o atacante queria.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor sem sobretaxa e fica ativa a partir da disponibilização, sem null-routing: 17 Tbps de capacidade de mitigação na rede global de scrubbing mais filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main. A Advanced DDoS Protection acrescenta-lhe, a partir de 50,00 € por mês, um IP de proteção dedicado e regras autogeríveis por porta.
• Um ataque DDoS é punível na Áustria pelo § 126b do StGB e na Alemanha pelo § 303b do StGB, tanto para quem encomenda como para quem opera os serviços.

Se o seu projeto já estiver alojado na KernelHost, a filtragem está ativa sem que tenha de fazer o que quer que seja. Se, ainda assim, notar anomalias, abra um ticket de suporte com os cinco dados do passo 7, para que as regras de filtragem para o seu endereço IP sejam afinadas. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883.