Proteção contra DDoS para Servidores de Jogos: Um Runbook para a Era dos Ataques de 10 Minutos

Sua fila de matchmaking trava às 21:14. Às 21:19, volta. Você olha o gráfico e encontra um pico de 620 Mbps, seis minutos de largura, já desaparecido antes de o alerta chegar ao seu celular. Ninguém no seu time de duas pessoas viu ao vivo, e seus jogadores classificaram como "lag".

Esse formato de ataque agora é o padrão. O DDoS Threat Report do Q3 2026 da Cloudflare contabilizou 18,2 milhões de ataques de camada de rede mitigados no trimestre — cerca de 8.226 por hora, ou um a cada 0,44 segundos. Desses, 96% terminaram em menos de 10 minutos e 98% ficaram abaixo de 1 Gbps. Ataques hiper-volumétricos acima de 1 Tbps caíram de 805 no Q2 para 251 no Q3, uma queda de ~69% que o relatório atribui a derrubadas pela aplicação da lei das botnets IoT Aisuru, KimWolf, JackSkid e Mossad.

Menos gigantes. Mais enxames. E o enxame é o modelo de ameaça para o qual um backend de jogos pequeno está menos preparado, porque é simultaneamente pequeno demais para acionar o nível de mitigação do seu provedor e grande o suficiente para saturar uma única instância de jogo.

Este é um runbook para essa faixa de banda.

O que o Q3 2026 realmente mudou

Três mudanças importam se você opera servidores de jogos. A primeira é a duração. Um aumento de 208% ano a ano em ataques de rajada curta e baixa banda é a assinatura operacional dos serviços "booter" de DDoS por aluguel: baratos, repetíveis e disparados em rajadas. Espere 40 ataques ao longo de uma noite, não um só.

A segunda é a rotatividade de vetores. A reflexão CLDAP — controladores de domínio públicos abusados na UDP 389 — despencou 99,5% trimestre a trimestre para apenas 0,05% dos ataques, depois de operar intensamente durante o H1. Os atacantes não pararam; eles rotacionaram. A amplificação de DNS saltou 215% para 3,43% dos ataques de camada de rede, e os floods UDP genéricos subiram de 14,06% para 31,31%.

A terceira é que os alvos se ampliaram. Mídia continuou sendo a indústria mais atacada, mas perdeu cerca de três quartos da sua participação do Q2. Infraestrutura de internet subiu de fora do top 10 para a posição #6, e Serviços ao Consumidor e Entretenimento Adulto entraram em #8 e #9. Jogos ficam exatamente nesse cluster de alvos voltados ao consumidor e sensíveis à latência.

A lição para quem defende: não monte seu playbook em torno do vetor do último trimestre. Monte-o em torno das quatro categorias — flood UDP, amplificação de DNS, abuso de reflexão e exaustão de SYN — e assuma que os pesos continuam mudando.

O que quebra primeiro em um backend de jogos

Nem tudo falha ao mesmo tempo, e saber a ordem evita que você combata o incêndio errado.

• A porta do jogo. Um flood UDP na porta autoritativa do servidor consome as filas da NIC antes da CPU. Seu servidor parece "no ar" para o health check do orquestrador porque o processo está vivo, enquanto os pacotes estão sendo descartados no kernel.
• Endpoints de sessão e login. Floods HTTP atingem a autenticação. Jogadores que desconectam no meio da rajada não conseguem voltar, e os que já estão no jogo saem porque o loop de reconexão falha.
• Leituras de leaderboard. Este é o caminho de leitura mais amplificado na maioria dos backends de jogos: uma requisição de cliente se expande em um range scan no banco de dados. 5.000 requisições por segundo é trivial de enviar e caro de servir.
• Ingestão de telemetria. Frequentemente sem autenticação ou com rate limit frouxo, geralmente é o endpoint mais barato de bombardear.
• A tabela conntrack. Preenchê-la derruba todos os serviços do host, incluindo seu acesso SSH, e é assim que um ataque de quatro minutos vira uma indisponibilidade de quatro horas.

Ataques de reflexão merecem uma nota específica: o tráfego chega de resolvedores DNS legítimos e outros servidores de terceiros, então o bloqueio por reputação de IP falha por design. Você está sendo atingido por infraestrutura inocente.

Detecção: os sinais que disparam antes dos gráficos

Seus dashboards atrasam. Os contadores do kernel não. O pré-indicador que mais importa é a proporção entre pacotes por segundo e bits por segundo. Um tráfego legítimo de jogo de 300 Mbps é aproximadamente 25.000-40.000 pacotes por segundo em tamanhos de payload típicos. Um flood UDP de 300 Mbps com pacotes de 64 bytes fica mais perto de 500.000 pps. Mesma banda, 15x mais pacotes, e isso mata o host enquanto seu gráfico de banda parece moderado.

Execute estes comandos na máquina sob suspeita:

# socket and memory pressure summary
ss -s

# per-protocol counters and the ones that predict a lockup
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|TcpExtListenDrops|TcpExtTCPReqQFullDrop'

# current conntrack table occupancy vs max
conntrack -C && sysctl net.netfilter.nf_conntrack_max

# what is actually arriving on the wire
tcpdump -nn -i eth0 'udp and not port 7777' -c 200

Interprete assim:

• UdpInDatagrams subindo enquanto seu game loop reporta menos jogadores = flood.
• UdpNoPorts em pico = scanner varrendo sua faixa de portas, geralmente um precursor.
• TcpExtTCPReqQFullDrop diferente de zero = overflow da fila de SYN, ou seja, você já está perdendo handshakes legítimos.
• conntrack -C acima de 70% de nf_conntrack_max = você está a minutos da falha total do host, não apenas da falha do servidor de jogo.

Se você quiser a visão por endpoint em vez da visão do kernel, o protocolo de diagnóstico de crash de servidor UEFN mostra como distinguir uma parada na camada de rede de uma na camada de engine, que é a primeira decisão em qualquer triagem.

Para defesa in-process contra o lixo que passa, um token bucket por origem na camada de socket é barato e eficaz. Este exemplo em C# bloqueia pacotes recebidos antes que cheguem ao seu tick de simulação:

using System.Diagnostics;
using System.Net;

public sealed class PacketGate
{
    private readonly Dictionary<IPAddress, Bucket> _buckets = new();
    private readonly int _ratePerSecond;
    private readonly int _burst;

    // A legit client at 30 Hz sends ~30 packets/s. 120/s allows
    // headroom for retransmits without letting a flood through.
    public PacketGate(int ratePerSecond = 120, int burst = 240)
    {
        _ratePerSecond = ratePerSecond;
        _burst = burst;
    }

    public bool Allow(IPAddress source)
    {
        long now = Stopwatch.GetTimestamp();

        if (!_buckets.TryGetValue(source, out var bucket))
        {
            bucket = new Bucket { Tokens = _burst, LastRefill = now };
            _buckets[source] = bucket;
        }

        double elapsed = (now - bucket.LastRefill) / (double)Stopwatch.Frequency;
        bucket.Tokens = Math.Min(_burst, bucket.Tokens + elapsed * _ratePerSecond);
        bucket.LastRefill = now;

        if (bucket.Tokens < 1.0) return false;
        bucket.Tokens -= 1.0;
        return true;
    }

    private sealed class Bucket
    {
        public double Tokens;
        public long LastRefill;
    }
}

Seja claro sobre o que isso faz e o que não faz. Filtra lixo por origem que cabe dentro da sua banda disponível. Não faz nada quando o pipe está cheio — nesse ponto, os pacotes são descartados antes do seu processo, independentemente do que seu código decidir.

Runbook de remediação: os primeiros dez minutos

Como 96% dos ataques terminam antes que um humano possa responder, o trabalho do runbook não é fazer você consertar o ataque. É fazer você capturar evidências e reduzir o raio de impacto enquanto o ataque se esgota.

T+0 a T+2 minutos — confirme, não escale. Resista ao reflexo de adicionar instâncias. Escalar para dentro de um flood multiplica sua conta e sua superfície de ataque. Confirme o vetor com os contadores acima, anote o pps e a banda, e verifique se a tabela conntrack está enchendo. Se estiver, caia imediatamente para a proteção emergencial de host do T+0.

T+2 a T+5 minutos — elimine carga não essencial. Desative tudo que não for gameplay: batching de telemetria, refresh de leaderboard, polling de storefront, feeds sociais. Se seu backend suporta configuração remota, isso é um único flag, não um deploy.

T+5 a T+10 minutos — aplique rate limits no nível do host. Filtragem no kernel é ordens de magnitude mais barata que filtragem na aplicação:

table inet gameguard {
    set udp_flood {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

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

        iif lo accept
        ct state established,related accept
        tcp dport { 22, 443 } accept
        tcp dport 7777-7800 accept
        udp dport 7777-7800 accept

        # drop fragmented UDP - your game protocol should never need it
        ip frag-off & 0x1fff != 0 udp drop

        # per-source UDP cap well above a real client's send rate
        udp dport 7777-7800 update @udp_flood \
            { ip saddr limit rate over 200/second burst 400 packets } drop
    }
}

Carregue com nft -f gameguard.nft. Verifique com nft list ruleset e nft list set inet gameguard udp_flood. Se você errar isso e se trancar para fora, converteu um incidente de rede em um incidente de acesso físico — teste em staging primeiro e mantenha as regras no version control.

T+10 minutos em diante — escale para seu upstream. Você precisa de capacidade de scrubbing ou blackhole na borda da rede, não no host. A maioria dos provedores gerenciados de hospedagem de jogos oferece isso; se o seu não oferece, é um problema de compras para resolver antes do próximo ataque. Pergunte especificamente pelo limite de mitigação UDP abaixo de 1 Gbps, porque a maioria dos SLAs publicados é escrita para ataques de terabit que você nunca verá.

Durante tudo: mantenha um log com timestamps. Início do ataque, vetor, pico de pps, pico de Gbps, o que você mudou e quando. O postmortem vale mais que a mitigação.

Playbook de vetores: combinando a resposta ao formato

Flood UDP (31,31% dos ataques). Portas aleatórias ou direcionadas, forçando o host a verificar se há um listener e gerar ICMP unreachable. O artigo sobre arquitetura de fallback na camada de rede mostra como manter um modo degradado, mas jogável, quando o transporte primário está sendo bombardeado. Resposta: rate limit por origem no nftables, feche todas as portas UDP que não sejam a porta do jogo e desative a geração de ICMP unreachable no host.

Amplificação de DNS (3,43%, alta de 215%). Consultas com origem forjada para resolvedores abertos, respostas grandes direcionadas a você. Resposta: você não pode bloquear por origem, porque as origens são resolvedores legítimos. Você só pode absorver ou filtrar por tamanho e taxa de resposta. Confirme se você não está rodando um resolvedor aberto com dig +short txt chaos version.bind @your.ip — se ele responder, feche hoje mesmo.

CLDAP (despencou para 0,05%). Atualmente quieto, historicamente enorme. O lembrete é que a amplificação CLDAP roda na UDP 389, então, a menos que você precise de LDAP, mantenha filtrado tanto no firewall do host quanto no da nuvem. Atacantes voltam para portas desprotegidas quando rotacionam de novo.

Flood SYN. Raramente volume, sempre exaustão. Ative SYN cookies (sysctl -w net.ipv4.tcp_syncookies=1), aumente net.core.somaxconn e garanta que a tabela conntrack esteja dimensionada para seu pior caso realista, não para o padrão.

Prevenção: arquitetura que sobrevive a uma rajada de quatro minutos

Matemática de capacidade primeiro, porque ela mata muito wishful thinking. Um servidor de 64 jogadores a 100 ticks move aproximadamente 15-20 KB/s por jogador — digamos 1,2 MB/s, ou cerca de 10 Mbps por instância. Um ataque de 400 Mbps é 40x o tráfego legítimo dessa instância. Como 98% dos ataques ficam abaixo de 1 Gbps, quase todo ataque na distribuição atual é grande o suficiente para achatar uma única instância de jogo e pequeno demais para interessar a auto-mitigação de um provedor de scrubbing tier-1.

Isso restringe sua arquitetura de três maneiras.

Separe o plano de contas do plano de jogo. Se seu endpoint de login, leituras de leaderboard e saves de jogadores rodam no mesmo host que seus servidores de jogo, um flood na porta do jogo derruba também as contas, e os jogadores não conseguem nem chegar a uma tela de "já voltamos". Rodar esses serviços ligados à conta no horizOn — autenticação, Cloud Save e leaderboards são todos gerenciados lá — significa que uma rajada na porta do jogo degrada o gameplay sem trancar todos os jogadores fora do perfil.

Transforme o desligamento de funcionalidades em uma mudança de configuração, não um deploy. Quando o flood chega, você tem segundos. Configuração remota permite desligar caminhos de leitura caros instantaneamente. Se sua única opção é subir um build, você não vai usar.

Construa o health check para enxergar falha de rede. Um check de processo reporta "saudável" enquanto o kernel descarta 90% dos pacotes. Faça probe de alcançabilidade real de gameplay — um cliente sintético que executa um handshake de verdade e espera resposta em 250ms — e deixe isso guiar seu failover.

Melhores práticas: cinco mudanças que valem a pena implementar esta semana

1. Alerte sobre packet rate, não só banda. Defina um limite em 2,5x o seu pps do 95º percentil. Alertas só de banda perdem rajadas curtas completamente; detecção de anomalia em pps pega um flood de 300 Mbps em um host com link de 1 Gbps que nenhum gráfico de banda sinalizaria.
2. Dimensione a tabela conntrack deliberadamente. Defina net.netfilter.nf_conntrack_max com base no pico de sessões concorrentes, não no padrão da distro, e alerte a 70% de ocupação. Essa única mudança previne a escalada mais comum de "ataque virou indisponibilidade".
3. Pré-escreva o ruleset do nftables e teste trimestralmente. Guarde no seu repo ao lado da config de deploy. Uma regra de firewall não testada aplicada durante um incidente é um segundo incidente.
4. Publique um contrato de modo degradado para seus jogadores. Se leaderboards e chat ficarem fora por dez minutos durante a mitigação, diga isso nas patch notes e na página de status. Silêncio parece jogo morto. Se você quer um modelo para isso, os padrões de resiliência na análise de arquitetura de backend pós-comprometimento se traduzem diretamente para incidentes de disponibilidade.
5. Registre todo ataque como um evento estruturado. Timestamp, vetor, pico de pps, pico de Gbps, duração, mitigação aplicada. Depois de cinco, você verá seu próprio padrão — a maioria dos backends indie é atingida no mesmo dia da semana, na mesma hora, pelo mesmo booter.

A conclusão

O perfil de ameaças de 2026 é hostil a times que planejam para ataques de terabit e ignoram a rajada de 400 Mbps de seis minutos. Os gigantes caíram 69%; os enxames subiram 208%. Sua mitigação precisa ser automatizada, barata e no kernel, porque nenhum humano vai agir dentro de um ataque que termina antes de o alerta ser lido.

Comece pelos contadores, não pelos dashboards. Adicione o rate limit por origem, dimensione a tabela conntrack, separe o plano de contas do plano de jogo e ensaie o runbook de dez minutos até ficar entediante.

Se parte dessa separação é trabalho sem glamour que você prefere não assumir — autenticação de jogadores, Cloud Save com controle de revisão, leaderboards, configuração remota que você pode mudar no meio do incidente — essa é a parte que o horizOn cuida, para que seu tempo de plantão vá para os servidores de jogo. Experimente grátis ou leia a documentação antes da sua próxima janela de lançamento.

---

Fonte: Cloudflare DDoS Threat Report 2026 Q3: Mais enxames, menos gigantes