Cómo funciona la protección DDoS, etapa por etapa

Lo que sobrevive a la absorción es tráfico que al menos quiere abrir una conexión. Este es el nivel de las avalanchas SYN: cantidades enormes de intentos de conexión, a menudo falsificados, diseñados para agotar el estado de seguimiento de conexiones más que el ancho de banda. El filtrado ocurre en el kernel de nuestra propia red (AS216013), antes de que nada llegue al espacio de usuario, con límites de tasa por origen y presupuestos de conexión.

La capa 4 sabe que llegó una conexión. No sabe qué dijo la conexión — no puede distinguir un jugador de un bot, porque en esta capa ninguno ha dicho nada todavía. Lo que la supera es una conexión TCP de aspecto legítimo, y a partir de aquí las preguntas dejan de ser sobre volumen.

Ahora se lee el tráfico. Buena parte de lo que completa un handshake no habla Minecraft en absoluto: escáneres de todo internet, avalanchas HTTP genéricas dirigidas a lo que responda, y basura malformada con la esperanza de que algo se caiga. Nada de eso sobrevive al contacto con un analizador que espera el protocolo de Minecraft y recibe otra cosa.

Esta es la primera capa con la que un equipo genérico de "protección para juegos" tiene problemas, porque exige implementar el protocolo de verdad en lugar de comparar formas de paquetes. También es donde el volumen cae lo suficiente como para que el tráfico restante sea genuinamente peligroso — todo lo que pasa de este punto habla el idioma de tu juego.

Todo lo que sigue en movimiento habla ya Minecraft con fluidez: handshakes válidos, nombres de usuario plausibles, versiones de protocolo correctas, llegando desde miles de direcciones residenciales y de centros de datos. Este es el ataque que realmente mata servidores de Minecraft, y es invisible para todas las capas anteriores — cada conexión es individualmente indistinguible de un jugador real entrando.

• Conciencia del nombre de host — una conexión que pide un nombre de host que no sirves no es un jugador que se equivocó al escribir, y se descarta antes de que se ejecute cualquier otra cosa.
• Límites de ritmo de entrada con auto-UAM — presupuestos por IP y globales que se aprietan automáticamente cuando sube el ritmo combinado de pings e inicios de sesión, de modo que la respuesta escala con el ataque en vez de configurarse de antemano.
• Puntuación de riesgo — país de origen, ASN, rango de centro de datos, comportamiento del protocolo e historial previo se combinan en un veredicto antes de permitir que la entrada continúe.
• Gestión de pings y MOTD — las avalanchas de estado se responden desde la caché del edge en lugar de reenviarse a tu servidor para que responda varios miles de veces por segundo.

En el ejemplo, esta capa elimina el 96 % de lo que le llega — 26 Gbps de tráfico que de otro modo habría llegado al backend como intentos de entrada aparentemente reales. Es el mismo motor descrito en detalle en cómo Cryo mitiga un ataque.

Un bot bien escrito estudia el antibot. Dosifica sus entradas, usa nombres plausibles, conecta desde proxies residenciales y no hace nada que puntúe como anómalo — porque fue construido precisamente para eso. La puntuación por sí sola no puede atraparlo, y ese residuo es lo que la gente llama bots de evasión.

Así que la última capa deja de puntuar y empieza a preguntar. Las entradas sospechosas se desvían a CryoLimbo, un mundo limbo ligero, y se les exige demostrar que son un cliente real — movimiento que obedece la física del juego, respuestas correctas al estado del servidor, comportamiento que un bot headless tiene que implementar de verdad en lugar de limitarse a imitarlo. Pasar es barato para un jugador y caro para un atacante, y ese es todo el diseño. Los jugadores reales que caen aquí pasan y continúan a tu servidor, normalmente sin darse cuenta.

400 Mbps de jugadores. Tu servidor ve las conexiones que habría visto un día tranquilo, con las IP reales de cliente entregadas por protocolo PROXY, así que los baneos, la detección de alts y los plugins por IP se comportan exactamente igual que en una conexión directa. Desde dentro del servidor el ataque no es un problema más pequeño — no es visible en absoluto, y por eso la primera señal que suele tener un operador es una alerta de Discord y no un pico de lag.

Vale la pena detenerse en las proporciones. La capa volumétrica eliminó el 94 % de la avalancha y las dos últimas capas eliminaron menos del 0,4 % entre ambas — y sin embargo son esas dos las que deciden si el servidor aguanta, porque son las únicas que podían distinguir un bot de un jugador. La capacidad te compra el derecho a tener el problema interesante. No lo resuelve.

Todas las capas anteriores se ejecutan antes de tu hardware, y ese es el punto estructural, no un detalle de implementación. Un plugin puede hacer una versión del trabajo de la capa 5 y algunos lo hacen bien — pero se ejecuta después de que tu máquina ya haya aceptado, reservado y analizado la conexión, así que pelea en el lado equivocado del enlace. Ese compromiso se desarrolla en antibot en el edge vs antibot en plugin, y por eso la disposición sensata es un edge delante con un plugin detrás como segunda capa, no uno en lugar del otro.