Protección DDoS para servidores de juego: un runbook para la era del ataque de 10 minutos

Tu cola de matchmaking se detiene a las 21:14. A las 21:19 vuelve. Revisas la gráfica y encuentras un pico de 620 Mbps, de seis minutos de ancho, que ya desapareció antes de que la alerta llegara a tu teléfono. Nadie en tu equipo de dos personas lo vio en vivo, y tus jugadores lo archivaron como "lag".

Esa forma de ataque es ahora la predeterminada. El informe de amenazas DDoS de Cloudflare del Q3 2026 contabilizó 18,2 millones de ataques a nivel de red mitigados en el trimestre — aproximadamente 8.226 por hora, o uno cada 0,44 segundos. De esos, el 96% terminó en menos de 10 minutos y el 98% se mantuvo por debajo de 1 Gbps. Los ataques hipervolumétricos por encima de 1 Tbps cayeron de 805 en el Q2 a 251 en el Q3, una caída de ~69% que el informe atribuye a las acciones policiales contra las botnets IoT Aisuru, KimWolf, JackSkid y Mossad.

Menos gigantes. Más enjambres. Y el enjambre es el modelo de amenaza para el que un backend de juego pequeño está peor preparado, porque es a la vez demasiado pequeño para activar el nivel de mitigación de tu proveedor y lo bastante grande para saturar una sola instancia de juego.

Este es un runbook para esa banda de ancho de banda.

Lo que el Q3 2026 cambió realmente

Hay tres cambios que importan si operas servidores de juego. El primero es la duración. Un aumento interanual del 208% en ataques de ráfaga corta y bajo ancho de banda es la firma operativa de los servicios "booter" de DDoS por encargo: baratos, repetibles y lanzados en ráfagas. Espera 40 ataques a lo largo de una noche, no uno.

El segundo es la rotación de vectores. La reflexión CLDAP — controladores de dominio públicos abusados en UDP 389 — se desplomó un 99,5% trimestre contra trimestre hasta solo el 0,05% de los ataques, después de estar activa durante el H1. Los atacantes no se detuvieron; rotaron. La amplificación DNS saltó un 215% hasta el 3,43% de los ataques a nivel de red, y las inundaciones UDP generales subieron del 14,06% al 31,31%.

El tercero es que los objetivos se ampliaron. Los medios siguieron siendo la industria más atacada, pero perdieron alrededor de tres cuartas partes de su cuota del Q2. La infraestructura de internet pasó de estar fuera del top 10 al #6, y los Servicios de Consumo y el Entretenimiento para Adultos entraron en el #8 y el #9. Los juegos están justo en ese grupo de objetivos orientados al consumidor y sensibles a la latencia.

La lección para los defensores: no construyas tu playbook en torno al vector del trimestre pasado. Constrúyelo en torno a las cuatro categorías — flood UDP, amplificación DNS, abuso de reflexión y agotamiento SYN — y asume que los pesos seguirán moviéndose.

Qué se rompe primero en un backend de juego

No todo falla a la vez, y conocer el orden te evita combatir el incendio equivocado.

• El puerto del juego. Un UDP flood en el puerto autoritativo de tu servidor consume las colas de la NIC antes que la CPU. Tu servidor aparece "activo" para el health check de tu orquestador porque el proceso sigue vivo, mientras los paquetes se descartan en el kernel.
• Los endpoints de sesión y login. Los HTTP floods golpean la autenticación. Los jugadores que se desconectan a mitad de la ráfaga no pueden volver a entrar, y los que ya están en partida se van porque el bucle de reconexión falla.
• Lecturas de leaderboard. Son la ruta de lectura más amplificada en la mayoría de los backends de juego: una petición de cliente se convierte en un range scan de base de datos. 5.000 peticiones por segundo es trivial de enviar y caro de servir.
• Ingesta de telemetría. A menudo sin autenticación o con rate limiting laxo, y casi siempre el endpoint más barato de golpear.
• La tabla conntrack. Llenarla tumba todos los servicios del host, incluido tu acceso SSH, y así es como un ataque de cuatro minutos se convierte en una caída de cuatro horas.

Los ataques de reflexión merecen una nota específica: el tráfico llega desde resolvers DNS legítimos y otros servidores de terceros, por lo que el bloqueo por reputación de IP falla por diseño. Te está golpeando infraestructura inocente.

Detección: las señales que saltan antes que las gráficas

Tus dashboards van con retraso. Los contadores del kernel no. El pre-indicador que más importa es la proporción entre paquetes por segundo y bits por segundo. Un tráfico de juego legítimo de 300 Mbps son aproximadamente 25.000-40.000 paquetes por segundo con tamaños de payload típicos. Un UDP flood de 300 Mbps con paquetes de 64 bytes se acerca a 500.000 pps. Mismo ancho de banda, 15 veces más paquetes, y matará el host mientras tu gráfica de ancho de banda parece moderada.

Ejecuta esto en la máquina bajo sospecha:

# 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

Léelos así:

• UdpInDatagrams subiendo mientras tu game loop reporta menos jugadores = flood.
• UdpNoPorts en pico = un escáner barriendo tu rango de puertos, a menudo un precursor.
• TcpExtTCPReqQFullDrop distinto de cero = desbordamiento de la cola SYN, lo que significa que ya estás perdiendo handshakes legítimos.
• conntrack -C por encima del 70% de nf_conntrack_max = estás a minutos de un fallo total del host, no solo del servidor de juego.

Si quieres la vista por endpoint en lugar de la vista del kernel, el protocolo de diagnóstico de caídas del servidor UEFN explica cómo distinguir un bloqueo a nivel de red de uno a nivel de motor, que es la primera decisión en cualquier triaje.

Para la defensa dentro del proceso contra la basura que consigue pasar, un token bucket por fuente en la capa de socket es barato y efectivo. Este ejemplo en C# filtra los paquetes entrantes antes de que lleguen a tu tick de simulación:

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;
    }
}

Sé claro sobre lo que esto hace y lo que no. Filtra la basura por fuente que cabe dentro de tu ancho de banda disponible. No hace nada una vez que el pipe está lleno — en ese punto los paquetes se descartan antes de llegar a tu proceso, sin importar lo que decida tu código.

Runbook de remediación: los primeros diez minutos

Dado que el 96% de los ataques terminan antes de que un humano pueda responder, el trabajo del runbook no es que arregles el ataque. Es que captures evidencia y reduzcas el radio de explosión mientras el ataque se consume.

De T+0 a T+2 minutos — confirma, no escales. Resiste el reflejo de añadir instancias. Escalar hacia un flood multiplica tu factura y tu superficie de ataque. Confirma el vector con los contadores anteriores, anota el pps y el ancho de banda, y comprueba si la tabla conntrack se está llenando. Si es así, pasa inmediatamente a la protección de emergencia del host en T+0.

De T+2 a T+5 minutos — elimina la carga no esencial. Desactiva todo lo que no sea gameplay: batching de telemetría, refresco de leaderboard, polling de la tienda, feeds sociales. Si tu backend soporta configuración remota, esto es un solo cambio de flag en lugar de un deploy.

De T+5 a T+10 minutos — aplica rate limits a nivel de host. El filtrado en el kernel es órdenes de magnitud más barato que el filtrado a nivel de aplicación:

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
    }
}

Cárgalo con nft -f gameguard.nft. Verifícalo con nft list ruleset y nft list set inet gameguard udp_flood. Si lo haces mal y te quedas fuera, habrás convertido un incidente de red en un incidente de acceso físico — pruébalo primero en staging y mantén las reglas bajo control de versiones.

De T+10 minutos en adelante — escala a tu upstream. Necesitas capacidad de scrubbing o blackhole en el borde de la red, no en el host. La mayoría de los proveedores de hosting de juegos gestionado lo ofrecen; si el tuyo no, es un problema de aprovisionamiento que debes resolver antes del próximo ataque. Pregunta específicamente por su umbral de mitigación UDP por debajo de 1 Gbps, porque la mayoría de los SLA publicados están escritos para ataques de terabit que nunca verás.

Durante todo el proceso: mantén un registro con marcas de tiempo. Inicio del ataque, vector, pps máximo, Gbps máximo, qué cambiaste y cuándo. El postmortem vale más que la mitigación.

Playbook de vectores: adaptar la respuesta a la forma

UDP flood (31,31% de los ataques). Puertos aleatorios o dirigidos, que fuerzan al host a comprobar si hay un listener y generar ICMP unreachable. El artículo sobre arquitectura de fallback a nivel de red explica cómo mantener un modo degradado pero jugable cuando el transporte principal está siendo golpeado. Respuesta: rate limit por fuente con nftables, cierra todos los puertos UDP que no sean tu puerto de juego y desactiva la generación de ICMP unreachable en el host.

Amplificación DNS (3,43%, +215%). Consultas con fuente falsificada a resolvers abiertos, con respuestas grandes dirigidas a ti. Respuesta: no puedes bloquear por fuente, porque las fuentes son resolvers legítimos. Solo puedes absorber o filtrar por tamaño y tasa de respuesta. Confirma que no estás ejecutando un resolver abierto con dig +short txt chaos version.bind @your.ip — si responde, ciérralo hoy.

CLDAP (desplomado al 0,05%). Actualmente tranquilo, históricamente enorme. El recordatorio es que la amplificación CLDAP corre sobre UDP 389, así que a menos que necesites LDAP, mantenlo filtrado tanto en el firewall del host como en el de la nube. Los atacantes vuelven a los puertos desprotegidos cuando rotan de nuevo.

SYN flood. Rara vez volumen, siempre agotamiento. Activa las SYN cookies (sysctl -w net.ipv4.tcp_syncookies=1), sube net.core.somaxconn y asegúrate de que la tabla conntrack esté dimensionada para tu peor caso realista en lugar del predeterminado.

Prevención: arquitectura que sobrevive a una ráfaga de cuatro minutos

Primero las matemáticas de capacidad, porque matan muchas ilusiones. Un servidor de 64 jugadores y 100 ticks mueve aproximadamente 15-20 KB/s por jugador — digamos 1,2 MB/s, o unos 10 Mbps por instancia. Un ataque de 400 Mbps es 40 veces el tráfico legítimo de esa instancia. Dado que el 98% de los ataques están por debajo de 1 Gbps, casi todos los ataques en la distribución actual son lo bastante grandes para aplastar una sola instancia de juego y a la vez demasiado pequeños para interesar a la auto-mitigación de un proveedor de scrubbing de nivel 1.

Eso restringe tu arquitectura de tres maneras.

Separa el plano de cuentas del plano de juego. Si tu endpoint de login, las lecturas de leaderboard y los guardados de jugador corren en el mismo host que tus servidores de juego, un flood en el puerto del juego tumba también las cuentas, y los jugadores ni siquiera pueden llegar a una pantalla de "volvemos enseguida". Tener esos servicios ligados a cuentas en horizOn — autenticación, Cloud Save y leaderboards están gestionados allí — significa que una ráfaga contra tu puerto de juego degrada el gameplay sin bloquear a todos los jugadores fuera de su perfil.

Haz que la reducción de funciones sea un cambio de configuración, no un deploy. Cuando llega el flood, tienes segundos. La configuración remota te permite apagar rutas de lectura costosas al instante. Si tu única opción es empujar un build, no lo usarás.

Construye el health check para que vea fallos de red. Un chequeo de proceso reporta "healthy" mientras el kernel descarta el 90% de los paquetes. Comprueba la alcanzabilidad real del gameplay — un cliente sintético que hace un handshake real y espera una respuesta en 250ms — y deja que eso guíe tu failover.

Mejores prácticas: cinco cambios que vale la pena publicar esta semana

1. Alerta por tasa de paquetes, no solo por ancho de banda. Pon un umbral en 2,5 veces tu pps del percentil 95. Alertar solo por ancho de banda pierde por completo las ráfagas cortas; la detección de anomalías en pps detecta un flood de 300 Mbps en un host con un enlace de 1 Gbps que ninguna gráfica de ancho de banda marcaría.
2. Dimensiona la tabla conntrack deliberadamente. Configura net.netfilter.nf_conntrack_max según el pico de sesiones concurrentes, no el valor por defecto de la distro, y alerta al 70% de ocupación. Este único cambio evita la escalada más común de "el ataque se convirtió en caída".
3. Escribe de antemano el ruleset de nftables y pruébalo trimestralmente. Guárdalo en tu repo junto a la configuración de deploy. Una regla de firewall sin probar aplicada durante un incidente es un segundo incidente.
4. Publica un contrato de modo degradado para tus jugadores. Si los leaderboards y el chat se apagan durante diez minutos mientras mitigas, dilo en las notas del parche y en la página de estado. El silencio se lee como un juego muerto. Si quieres un modelo para esto, los patrones de resiliencia del análisis de arquitectura backend post-compromiso se traducen directamente a incidentes de disponibilidad.
5. Registra cada ataque como un evento estructurado. Marca de tiempo, vector, pps máximo, Gbps máximo, duración, mitigación aplicada. Después de cinco verás tu propio patrón — la mayoría de los backends indie reciben golpes el mismo día de la semana, a la misma hora, por el mismo booter.

La conclusión

El perfil de amenazas de 2026 es hostil con los equipos que planifican para ataques de terabit e ignoran la ráfaga de seis minutos a 400 Mbps. Los gigantes han caído un 69%; los enjambres han subido un 208%. Tu mitigación tiene que ser automatizada, barata y estar en el kernel, porque ningún humano va a actuar dentro de un ataque que termina antes de que se lea la alerta.

Empieza por los contadores, no por los dashboards. Añade el rate limit por fuente, dimensiona la tabla conntrack, separa tu plano de cuentas de tu plano de juego y ensaya el runbook de diez minutos hasta que sea aburrido.

Si parte de esa separación es trabajo poco glamuroso que prefieres no asumir — autenticación de jugadores, Cloud Save con control de revisiones, leaderboards, configuración remota que puedas cambiar a mitad de incidente — esa es la parte que gestiona horizOn, para que tu tiempo de guardia vaya a los servidores de juego en su lugar. Pruébalo gratis o lee la documentación antes de tu próxima ventana de lanzamiento.

---

Fuente: Cloudflare DDoS Threat Report 2026 Q3: Más enjambres, menos gigantes