Como funciona a proteção DDoS, etapa por etapa

O que sobrevive à absorção é tráfego que pelo menos quer abrir uma conexão. Este é o nível das enxurradas SYN: quantidades enormes de tentativas de conexão, muitas vezes falsificadas, projetadas para esgotar o estado de rastreamento de conexões em vez da banda. A filtragem acontece no kernel da nossa própria rede (AS216013), antes que qualquer coisa chegue ao espaço de usuário, com limites de taxa por origem e orçamentos de conexão.

A camada 4 sabe que uma conexão chegou. Ela não sabe o que a conexão disse — não consegue distinguir um jogador de um bot, porque nesta camada nenhum dos dois disse nada ainda. O que passa por ela é uma conexão TCP de aparência legítima, e daqui em diante as perguntas deixam de ser sobre volume.

Agora o tráfego é lido. Boa parte do que completa um handshake não fala Minecraft de jeito nenhum: scanners de toda a internet, enxurradas HTTP genéricas mirando o que quer que responda, e lixo malformado torcendo para algo travar. Nada disso sobrevive ao contato com um parser que espera o protocolo de Minecraft e recebe outra coisa.

Esta é a primeira camada com a qual um appliance genérico de "proteção para jogos" tem dificuldade, porque exige realmente implementar o protocolo em vez de casar formatos de pacote. É também onde o volume cai o suficiente para que o tráfego restante seja genuinamente perigoso — tudo que passa deste ponto fala a língua do seu jogo.

Tudo que ainda se move agora fala Minecraft fluentemente: handshakes válidos, nomes de usuário plausíveis, versões de protocolo corretas, chegando de milhares de endereços residenciais e de datacenter. Este é o ataque que realmente mata servidores de Minecraft, e ele é invisível para todas as camadas acima — cada conexão é individualmente indistinguível de um jogador real entrando.

• Consciência de hostname — uma conexão pedindo um hostname que você não atende não é um jogador que errou de digitação, e é descartada antes que qualquer outra coisa rode.
• Limites de ritmo de entrada com auto-UAM — orçamentos por IP e globais que apertam automaticamente conforme o ritmo combinado de pings e logins sobe, então a resposta escala com o ataque em vez de ser configurada de antemão.
• Pontuação de risco — país de origem, ASN, faixa de datacenter, comportamento de protocolo e histórico anterior se combinam num veredito antes que a entrada tenha permissão de continuar.
• Tratamento de pings e MOTD — enxurradas de status são respondidas do cache do edge em vez de encaminhadas ao seu servidor para responder vários milhares de vezes por segundo.

No exemplo, esta camada remove 96 % do que chega a ela — 26 Gbps de tráfego que de outra forma teria chegado ao backend como tentativas de entrada aparentemente reais. É o mesmo motor descrito em detalhe em como o Cryo mitiga um ataque.

Um bot bem escrito estuda o antibot. Ele dosa suas entradas, usa nomes plausíveis, conecta de proxies residenciais e não faz nada que pontue como anômalo — porque foi construído justamente para isso. Pontuação sozinha não consegue pegá-lo, e esse resíduo é o que as pessoas chamam de bots de contorno.

Então a última camada para de pontuar e começa a perguntar. Entradas suspeitas são desviadas para o CryoLimbo, um mundo limbo leve, e precisam demonstrar que são um cliente real — movimento que obedece à física do jogo, respostas corretas ao estado do servidor, comportamento que um bot headless tem que realmente implementar em vez de apenas imitar. Passar é barato para um jogador e caro para um atacante, e esse é todo o projeto. Jogadores reais pegos aqui passam e seguem para o seu servidor, geralmente sem perceber.

400 Mbps de jogadores. Seu servidor vê as conexões que teria visto num dia calmo, com os IPs reais dos clientes entregues via protocolo PROXY, então banimentos, detecção de alts e plugins por IP se comportam exatamente como numa conexão direta. De dentro do servidor, o ataque não é um problema menor — ele não é visível de jeito nenhum, e é por isso que o primeiro sinal para um operador costuma ser um alerta no Discord e não um pico de lag.

Vale a pena parar nas proporções. A camada volumétrica removeu 94 % da enxurrada e as duas últimas camadas removeram menos de 0,4 % entre elas — e ainda assim são essas duas que decidem se o servidor fica de pé, porque são as únicas capazes de distinguir um bot de um jogador. Capacidade compra o direito de ter o problema interessante. Ela não o resolve.

Toda camada acima roda antes do seu hardware, e esse é o ponto estrutural, não um detalhe de implementação. Um plugin pode fazer uma versão do trabalho da camada 5 e alguns fazem bem — mas ele roda depois que a conexão já foi aceita, alocada e interpretada pela sua máquina, então está lutando do lado errado do link. Esse trade-off é desenvolvido em antibot no edge vs antibot em plugin, e é por isso que o arranjo sensato é um edge na frente com um plugin atrás como segunda camada, não um no lugar do outro.