¿Qué es un ataque DDoS? Técnica, niveles y defensa

Un ataque DDoS es el intento de dejar un servicio inalcanzable mediante una sobrecarga generada de forma artificial, ejecutada al mismo tiempo desde muchísimos remitentes distintos. La sigla significa Distributed Denial of Service, es decir, una denegación de servicio provocada de forma distribuida. Lo que se ataca no es el contenido de un servidor ni un fallo de seguridad de su software, sino un recurso que es finito: el ancho de banda de la línea, la tasa de paquetes de la tarjeta de red, un hueco en una tabla de estados del kernel o el tiempo de proceso que la aplicación dedica a una única petición. En cuanto uno de esos cuatro recursos queda ocupado, los usuarios reales dejan de pasar, y todo ello sin que nadie haya entrado en el sistema.

Este artículo es la entrada al tema. Explica los tres niveles en los que ocurren los ataques, con qué factores de amplificación un byte de petición se convierte en 51.000 bytes de respuesta, de dónde sale la capacidad de ataque y cuánto cuesta en el mercado, cómo reconocer un ataque a partir de tus propias mediciones, qué sigue sirviendo en el propio servidor y dónde pasa exactamente ese límite. Todas las cifras llevan su fuente indicada para que puedas comprobarlas. Si tu servicio está caído ahora mismo, lee primero el apartado "Qué hacer en caso de ataque" y mide en lugar de ponerte a tocar ajustes.

Qué es técnicamente un ataque DDoS

Todo ataque DDoS vive de una asimetría: enviar un paquete tiene que costarle al atacante menos de lo que le cuesta al objetivo procesar ese paquete. Todo lo demás es solo la cuestión de en qué punto esa asimetría es mayor. Hay exactamente cuatro puntos, y cada uno tiene un límite superior duro que se puede calcular.

El ancho de banda de la línea. Una conexión de 1 Gbit/s transporta 125 megabytes por segundo, y nada más. Quien manda más genera pérdidas, y esas pérdidas afectan igual a los paquetes de tus usuarios que a los del atacante, porque una conexión llena no elige.

La tasa de paquetes. La trama Ethernet más pequeña permitida mide 64 bytes y ocupa en la línea 84 bytes contando el preámbulo y el hueco entre tramas. En 1 Gbit/s caben unos 1,49 millones por segundo. Un kernel de servidor normal procesa, según la CPU y la tarjeta de red, unos cientos de miles antes de empezar a descartar. Por eso la tasa de paquetes es casi siempre el límite que se alcanza antes que el del ancho de banda.

Las tablas de estados. El kernel se guarda las conexiones TCP medio abiertas y los flujos de paquetes. Esas tablas están limitadas en número de entradas, no en bits por segundo. Se pueden llenar con muy poco ancho de banda si cada paquete lleva una dirección de origen nueva.

El tiempo de proceso de la aplicación. Una búsqueda, un intento de inicio de sesión con comprobación de contraseña o una consulta al servidor que devuelve una lista de mods completa le cuesta al objetivo mil veces más que al remitente. Aquí un ataque efectivo no necesita ni 10 Mbit/s.

DoS y DDoS: la diferencia que se puede medir

La base conceptual la da el RFC 4732, "Internet Denial-of-Service Considerations", una publicación de carácter informativo del IETF de noviembre de 2006. Ahí se dice 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." Un ataque DoS se define, por tanto, por su efecto y no por el número de orígenes. Distribuido, es decir DDoS, lo es cuando esos orígenes son numerosos e independientes entre sí.

En la práctica la diferencia cuenta en un punto exacto: en la longitud de tu lista de bloqueo. Un ataque DoS desde un solo origen lo terminas con una regla. Cloudflare documentó en mayo de 2025 un ataque que venía de 122.145 direcciones de origen distintas, de 161 países y 5.433 sistemas autónomos, con una media de 26.855 direcciones nuevas por segundo y un pico de 45.097. Contra algo así no hay lista de bloqueo que crezca lo bastante rápido, y cada entrada en ella cuesta además memoria y tiempo de búsqueda en el equipo que ya está saturado de todos modos.

La guía conjunta "Understanding and Responding to Distributed Denial-of-Service Attacks" de CISA, el FBI y MS-ISAC divide los ataques en exactamente tres técnicas: volumétrica, de protocolo y de aplicación. Esa división en tres es la más útil que existe, porque describe al mismo tiempo cuál de tus cuatro recursos se ataca y dónde tiene que estar la defensa.

Los tres niveles de un ataque DDoS

Ataques volumétricos en las capas 3 y 4

Un ataque volumétrico no quiere otra cosa que llenar la línea que hay delante del objetivo. Se mide en bits por segundo. El medio es por regla general un flood UDP, porque UDP no conoce ningún establecimiento de conexión que se pueda exigir y porque las direcciones de origen se pueden falsificar.

El mayor ejemplo documentado públicamente a día de hoy: Cloudflare informa, para el periodo hasta finales de 2025, de un ataque mitigado de forma automática con 31,4 Tbit/s que duró 35 segundos. Eso es la capacidad de unas 31.400 conexiones de servidor de 1 Gbit/s, a la vez, durante algo más de medio minuto. En el mismo informe hay un segundo dato que hace la magnitud más tangible que el valor de pico: en 2025 ese mismo operador mitigó 47,1 millones de ataques DDoS, un 121 por ciento más que el año anterior, una media de 5.376 ataques por hora.

El caso mejor documentado, de mayo de 2025, muestra cómo es un ataque de este tipo cuando se descompone: 7,3 Tbit/s de pico, 37,4 terabytes de datos en 45 segundos, es decir, unos 830 gigabytes por segundo de media. Una línea de 1 Gbit/s habría necesitado más de tres días para la misma cantidad de datos. El 99,996 por ciento del tráfico eran floods UDP puros, repartidos por 21.925 puertos de destino de media al mismo tiempo, con un pico de 34.517. Ese reparto por todos los puertos es típico: el atacante no sabe qué puerto importa, así que toma todos.

Ataques de protocolo: las tablas, no la línea

Un ataque de protocolo aprovecha que el kernel tiene que recordar estados. El ejemplo estándar es el flood SYN: el atacante envía paquetes TCP con el bit SYN activado y la dirección de origen falsificada, el servidor crea una entrada en su cola de conexiones medio abiertas por cada uno, responde con SYN-ACK a una dirección que nunca ha respondido, y espera. Aquí se mide en paquetes por segundo, no en gigabits.

La longitud de esa cola está en net.ipv4.tcp_max_syn_backlog y en un servidor normal se mueve en el rango de los miles. Una cola con 1.024 huecos se llena, con 1,49 millones de paquetes SYN por segundo, en menos de un milisegundo. Para eso bastan, puramente sobre el papel, 1 Gbit/s, y si el objetivo es solo la tabla, basta una fracción de eso.

A la misma familia pertenece un procedimiento que no se describió hasta 2021: la reflexión TCP a través de dispositivos intermedios con estado. El trabajo "Weaponizing Middleboxes for TCP Reflected Amplification" demuestra que los firewalls y la infraestructura de censura que solo siguen a medias el estado TCP reaccionan a un único paquete falsificado con páginas enteras de respuesta. Con ello se puede abusar por primera vez también de TCP para amplificar, algo que hasta entonces se consideraba prácticamente imposible.

Ataques de aplicación en la capa 7

Un ataque de aplicación parece tráfico normal porque es tráfico normal, solo en la cantidad equivocada. Se mide en peticiones por segundo. Llega por una conexión establecida por completo, así que sobrevive a cualquier comprobación que solo evalúe el establecimiento de la conexión, y necesita poco ancho de banda: 10.000 peticiones HTTP por segundo son, según el tamaño de la petición, menos de 50 Mbit/s y aun así suficiente para poner de rodillas una base de datos.

La referencia en esto se llama HTTP/2 Rapid Reset, revelada el 10 de octubre de 2023 como CVE-2023-44487. La vulnerabilidad está en la capacidad de multiplexación de HTTP/2: el atacante abre un flujo, manda la petición y corta el flujo de inmediato. El servidor ya ha empezado el trabajo, pero el atacante ya tiene otra vez un hueco libre en la ventana. Los valores alcanzados así fueron de 201 millones de peticiones por segundo (Cloudflare), 398 millones (Google) y 155 millones (Amazon). A modo de comparación: el mayor ataque de capa 7 medido hasta entonces por Cloudflare estaba en 71 millones de peticiones por segundo.

En los servidores de juego, el nivel de la capa 7 es el propio establecimiento de conexión. Nullping, QuietException y los floods de handshake falsos contra redes de Minecraft casi no necesitan ancho de banda y tumban conjuntos enteros de proxies, porque cada paquete obliga al proxy a tomar una decisión de estado que le resulta cara. Cómo son exactamente esos patrones lo explica Protección DDoS y protección contra nullping en Minecraft.

Los tres niveles, comparados

Los ataques reales no se atienen a esta clasificación. El caso más incómodo en la práctica es el ataque multicapa: una parte volumétrica que mantiene ocupada la línea, más una parte de capa 7 que pasa justo en el momento en el que la atención está puesta en el ancho de banda. Uno de los ataques filtrados en KernelHost que se muestran más abajo consistía en más de doce patrones principales distintos al mismo tiempo.

Ataques de amplificación: cómo un byte se convierte en 51.000

Un ataque de amplificación es un ataque en el que el atacante no dispara él mismo contra el objetivo, sino que consigue que servicios ajenos accesibles públicamente lo hagan por él. Envía una petición pequeña a un servicio abierto y pone como remitente la dirección IP de la víctima. El servicio responde como es su obligación, solo que a la víctima, y la respuesta es un múltiplo del tamaño de la petición.

La relación entre el tamaño de la respuesta y el de la petición se llama Bandwidth Amplification Factor, abreviado BAF. Un BAF de 50 significa que un atacante con 1 Gbit/s de conexión propia dirige 50 Gbit/s contra el objetivo. Para que eso funcione tienen que darse dos cosas a la vez: un protocolo sobre UDP que responda más de lo que se le pregunta, y la posibilidad de falsificar la dirección de origen. Por eso la falsificación de la dirección de origen (IP spoofing) es el requisito de todo ataque de amplificación y no una simple táctica de ocultación.

Para quien defiende, de ahí se sigue una propiedad incómoda: el tráfico viene de servidores reales y legítimos. Son resolutores DNS reales, servidores de hora reales, servidores de juego reales. Una lista de bloqueo por dirección de origen deja fuera, por tanto, a medios países o no sirve de nada.

Los factores de amplificación de los protocolos de los que se abusa

Los factores siguientes proceden de la alerta TA14-017A del US-CERT, hoy CISA, "UDP-Based Amplification Attacks", que se amplía de forma continua desde 2014. Es la referencia a la que se remite todo el sector.

La tabla explica por qué la lista de puertos bloqueados se parece tanto en cualquier firewall bien mantenido. Lo que puedes hacer tú es poco, pero importante: comprueba con ss -lnup si en tu servidor hay algún servicio de esta tabla abierto a la red. Un memcached que no esté enlazado a 127.0.0.1 convierte tu servidor en un arma contra terceros, te cuesta tu propio ancho de banda de salida y lleva tu dirección IP a listas de bloqueo de las que es difícil salir.

Por qué los protocolos de consulta de los juegos entran aquí

Los servidores de juego aparecen en esta tabla con dos papeles. Son amplificadores, porque su puerto de consulta responde a un paquete pequeño con el nombre, el mapa, el número de jugadores y la lista de mods completa. Y son víctimas, porque esa misma consulta cuesta tiempo de proceso, a menudo justo en el núcleo que sostiene la simulación del juego.

El factor de amplificación del protocolo de Steam es bajo, 5,5, y el del protocolo más antiguo de Quake es alto, 63,9. Pero el efecto no depende solo del factor, sino del tamaño de la respuesta en cada caso concreto: un servidor con 200 mods entrega una respuesta bastante mayor que uno sin ninguno. Bohemia Interactive documenta para Arma 3, en el ticket T83469 y desde 2015, que bastaban 4 Mbit/s de consultas falsificadas contra el puerto de consulta de Steam para congelar un servidor. Cuatro megabits por segundo son menos de lo que da de sí una sola conexión doméstica.

De ahí se sigue la regla que vale para cualquier juego: limitar el puerto de consulta, no bloquearlo. Quien lo bloquea desaparece de la lista de servidores y los jugadores nuevos ya no lo encuentran. Qué puerto es en cada juego y cuánto se puede apretar está en los artículos específicos de cada juego, más abajo, por ejemplo para Arma 3, CS2 y los títulos Source o Rust.

El caso memcached: 1,35 Tbit/s contra GitHub

El 28 de febrero de 2018 GitHub estuvo inaccesible de 17:21 a 17:26 UTC y solo de forma intermitente hasta las 17:30 UTC. El ataque alcanzó 1,35 Tbit/s con 126,9 millones de paquetes por segundo y venía de más de 1.000 sistemas autónomos distintos y de decenas de miles de puntos finales. Se amplificó mediante memcached, con un factor de hasta 51.000: un byte del atacante generaba hasta 51 kilobytes en dirección al objetivo.

Ese caso sigue siendo hoy la mejor lección, porque muestra tres cosas a la vez. Primera: la amplificación gana al tamaño del botnet. El atacante no necesitó cien mil dispositivos, necesitó instancias de memcached abiertas, de las que entonces había más de 90.000 en la red en todo el mundo. Segunda: 126,9 millones de paquetes por segundo son unas 85 veces más de lo que una línea de 1 Gbit/s puede transportar siquiera. Ningún ajuste en el servidor cambia eso. Tercera: la defensa funcionó porque el tráfico se desvió a una red de filtrado, y así el tiempo de caída terminó en nueve minutos y no en nueve horas.

De dónde sale la capacidad para un ataque DDoS

Botnets de dispositivos tomados

Un botnet es un conjunto de dispositivos ajenos, tomados con software malicioso, que un atacante controla en remoto desde un punto central. Los propietarios no suelen notar nada, porque el dispositivo sigue haciendo aquello para lo que se compró. Se atacan sobre todo dispositivos que están permanentemente en la red, que se actualizan poco y que llevan contraseñas por defecto: routers, cámaras de vigilancia, grabadores de vídeo en red y decodificadores de televisión.

La referencia es Mirai, cuyo código fuente se publicó a finales de septiembre de 2016. El trabajo "Understanding the Mirai Botnet" (USENIX Security 2017) sigue la red durante siete meses y cifra su máximo en más de 600.000 dispositivos infectados. El ataque contra la página de Brian Krebs en septiembre de 2016 alcanzó 620 Gbit/s y venía de más de 175.000 dispositivos. En el ataque contra el operador de DNS Dyn del 21 de octubre de 2016, que dejó inaccesibles a la vez Twitter, Spotify y Reddit, se contaron unas 107.000 direcciones IP atacantes.

Nueve años después la magnitud es otra. Cloudflare atribuye el ataque récord de 31,4 Tbit/s a un botnet con un tamaño estimado de entre uno y cuatro millones de dispositivos infectados, en su mayoría decodificadores de televisión con Android. En la oleada de ataques de diciembre de 2025 se contaron 902 ataques hipervolumétricos, una media de 53 al día, con picos de 9.000 millones de paquetes por segundo, 24 Tbit/s y 205 millones de peticiones por segundo. El tamaño de los botnets ha crecido así en una década por un factor de 5, y el ancho de banda alcanzado por un factor de 50.

Servicios de booter y de stresser y lo que cuesta un ataque

Entre el botnet y quien encarga el ataque hay un servicio que vende la capacidad de ataque por suscripción. Esos servicios se presentan como "booter", "stresser" o "IP stresser" y afirman en sus condiciones de uso que sirven para probar la carga de sistemas propios. Nunca comprueban si el objetivo introducido pertenece al usuario, y justo ahí está la diferencia entre una herramienta y una oferta de ataque.

El manejo es una interfaz web con tres campos: objetivo, puerto, duración. Hay procesos de pago, atención al cliente y programas de revendedores. Los paquetes de entrada están en unos 10 a 20 euros al mes, y los paquetes grandes, con más ancho de banda y más duración de ataque, en algunos cientos de euros al mes. Con eso queda contestada la pregunta de por qué también les toca a los proyectos pequeños: un ataque que le cuesta a un servidor de juego el sábado por la noche le cuesta a quien lo lanza menos que dos entradas de cine y ningún conocimiento técnico.

Al otro lado hay una presión de persecución permanente. En la semana de acciones coordinadas de la operación internacional PowerOFF de abril de 2026, las autoridades de 21 países se hicieron con 53 dominios de esos servicios, detuvieron a cuatro personas y practicaron 25 registros domiciliarios. Los investigadores obtuvieron además acceso a los datos de más de tres millones de cuentas de usuario, y a más de 75.000 usuarios identificados se les envió un aviso por escrito. En diciembre de 2024, en la misma operación, se habían cerrado 27 plataformas. Quien paga un servicio así deja, por tanto, un rastro de pago en una base de datos que antes o después acaba incautada.

Cómo reconocer un ataque DDoS

Lo que informan los usuarios y qué dice eso ya

La primera información llega casi siempre de los usuarios, y es más aprovechable de lo que parece. Cuatro avisos tienen un significado claro:

• "Nos hemos caído todos al mismo tiempo." Un corte simultáneo en todos los usuarios apunta a la línea o al proceso del servicio, no a conexiones concretas. Un problema de carga afecta a los usuarios uno detrás de otro.
• "El ping salta de 20 a 400 y vuelve." Una latencia que oscila mientras la conexión sigue en pie es el patrón de una cola saturada delante del objetivo, no de un proceso sobrecargado.
• "La lista de servidores nos muestra como offline, pero yo puedo conectarme." Eso señala un flood de consultas: el puerto de consulta ya no responde, el puerto de juego todavía sí.
• "Por datos móviles entro, por mi conexión de casa no." Un comportamiento distinto según la red de acceso indica que lo saturado no es tu servidor, sino un camino hacia él.

Los cuatro valores que hay que medir en el servidor

Después se mide, y en este orden: tasa de paquetes, ancho de banda, estados de conexión, contadores de descartes. El indicador de carga de la CPU va al final, porque en un ataque de red se queda a menudo sin llamar la atención.

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 entrega paquetes y bytes por segundo por interfaz a lo largo de diez segundos. Lo decisivo es la relación: muchos paquetes con pocos bytes significa paquetes pequeños, es decir, un ataque de protocolo. Pocos paquetes con muchísimos bytes significa paquetes grandes, es decir, un ataque de amplificación. ip -s link show muestra en las columnas dropped y overrun si el kernel ya está descartando. ss -tn state syn-recv cuenta las conexiones medio abiertas: un valor de tres cifras es normal, uno de cinco cifras es un flood SYN. Y nstat entrega los contadores que se quedan ahí incluso cuando el ataque ha pasado.

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo funciona con normalidad. Sin un valor normal no puedes decir si 40.000 paquetes por segundo son muchos o simplemente un sábado por la noche. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. La guía detallada para interpretar los datos está en Detectar un ataque DDoS.

Las líneas de log que son inequívocas

Cuatro mensajes en el log del kernel y en el del servidor web son prácticamente una prueba. dmesg -T | tail -50 muestra los tres primeros:

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

La primera línea significa que la cola de conexiones medio abiertas se ha desbordado y que el kernel ha pasado a usar SYN cookies. Si ahí aparece en cambio Dropping request, entonces net.ipv4.tcp_syncookies está a 0 y el servidor descarta peticiones, incluidas las legítimas. La segunda línea significa que el seguimiento de conexiones está lleno, y a partir de ese momento el servidor descarta también tráfico legítimo. La tercera línea es un efecto colateral: el kernel suprime mensajes porque si no estaría ocupado escribiendo logs. La cuarta línea traslada el problema a la aplicación.

En el log de accesos del servidor web hay dos cosas reveladoras. Una proporción repentina del código de estado 499 significa que el cliente cierra la conexión antes de que la respuesta esté terminada, y eso es exactamente lo que hace un ataque de capa 7 que solo quiere provocar trabajo y no leer nada. Y un campo referrer vacío en casi todas las peticiones distingue un ataque de una avalancha real de visitas, que trae referentes de buscadores y de redes sociales.

La contraprueba: ataque, avalancha o error propio

Lo que sirve en el propio servidor

En el servidor se puede conseguir más de lo que se suele afirmar, y en concreto contra todo lo que se mantiene pequeño: bots mal hechos, orígenes aislados, floods de consultas y ataques de aplicación. Las herramientas para eso son nftables, el seguimiento de conexiones, las SYN cookies y un límite de tasa por dirección de origen. Todos los datos siguientes valen para Debian 12, Debian 13, Ubuntu 22.04 LTS y Ubuntu 24.04 LTS y están escritos para root.

nftables: descartar pronto, calcular poco

El principio dice: un paquete que se va a descartar debe descartarse lo antes y lo más barato posible. Cada regla que corre antes cuesta tiempo de proceso multiplicado por la tasa de paquetes. El siguiente conjunto de reglas para /etc/nftables.conf deja pasar un servidor web y un servicio de juego y descarta el resto, con un límite de tasa para las conexiones TCP nuevas por dirección de origen:

#!/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; }
}

Pon tu propia dirección fija en adminips antes de cargar el conjunto, porque si no te quedas fuera de SSH. Se comprueba y se activa así:

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

Tres puntos deciden el efecto. ct state established,related accept está a propósito como segunda regla, para que las conexiones existentes no recorran todo el conjunto. ct state invalid counter drop retira las combinaciones de flags erróneas y los fragmentos que llegan tarde, sin que tengas que describirlos uno a uno. Y el counter delante de cada drop es la razón por la que después sabes qué regla ha actuado: si los contadores se quedan a cero, la regla no se alcanza, y ese es un diagnóstico completamente distinto a un conjunto de reglas sin efecto.

SYN cookies y el límite del backlog

Las SYN cookies son un procedimiento en el que el servidor no se guarda la conexión medio abierta, sino que escribe los datos necesarios cifrados en su propio número de respuesta. Cuando vuelve el tercer paquete del establecimiento de conexión, recalcula el estado a partir de ahí. Así la cola no se desborda, porque para esas conexiones no hay cola.

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

Estos valores van en un archivo bajo /etc/sysctl.d/ y se aplican con sysctl --system, porque si no desaparecen con el siguiente reinicio. En Debian y Ubuntu tcp_syncookies viene de fábrica a 1, lo cual es correcto. El valor 1 no significa "cookies siempre", sino "cookies en cuanto la cola se desborde".

El precio de esto es real y casi nunca se menciona. En una cookie no hay sitio para las opciones TCP del otro extremo. Linux solo salva el escalado de ventana y la confirmación selectiva si net.ipv4.tcp_timestamps está a 1, porque entonces esos datos viajan dentro de la marca de tiempo. Sin marcas de tiempo se pierden, y la conexión va más lenta durante el resto de su vida. Además, para el tamaño máximo de paquete solo quedan tres bits, es decir, ocho escalones gruesos en lugar del valor exacto. Las SYN cookies son un modo de emergencia que salva conexiones, no un ajuste para el funcionamiento normal.

conntrack: la tabla que se llena primero

El seguimiento de conexiones del kernel crea una entrada por cada flujo de paquetes, también para UDP, aunque UDP no conozca conexiones. Justo esa tabla es el primer recurso que se agota en un ataque distribuido, y se agota muy rápido: con 1,49 millones de paquetes por segundo y una dirección de origen nueva en cada uno, una tabla con 262.144 huecos se llena en menos de un 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

Una entrada ocupa unos 300 bytes, así que 524.288 entradas son unos 150 megabytes de memoria del kernel. El tamaño de la tabla hash no se fija por sysctl, sino como parámetro de módulo, normalmente en un cuarto del límite superior, en /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Para un servidor exclusivamente de juego o de voz, la solución más elegante es no hacer seguimiento del tráfico de juego. Eso ahorra la tabla 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

Atención: notrack y las reglas con estado se excluyen entre sí. Quien saca un puerto del seguimiento ya no puede usar para ese puerto ninguna regla con ct state, porque si no la apertura deja de funcionar y el servicio queda cerrado.

Límite de tasa por dirección de origen

Un límite de tasa por dirección de origen es la medida individual más eficaz en el servidor, porque acierta justo en lo que hace un atacante y deja pasar justo lo que hace un usuario. La diferencia es grande: un navegador de servidores real consulta unas pocas veces por minuto, un atacante cientos de veces por segundo. Con nftables se trabaja para eso con conjuntos dinámicos, como en el conjunto de reglas de arriba, y con iptables clásico con 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

Todas las cifras de reglas así son puntos de partida, no verdades absolutas. Mide primero una semana de funcionamiento normal, porque si no echas fuera a tus propios usuarios, y además en el peor momento. Ten en cuenta también que las reglas de iptables a secas desaparecen tras un reinicio (apt-get install -y iptables-persistent y luego netfilter-persistent save) y que con UFW van en /etc/ufw/before.rules, porque si no desaparecen con el siguiente ufw reload. El conjunto de reglas completo para el día a día está en Proteger un servidor frente a ataques DDoS.

El punto en el que todo filtrado en el servidor se acaba

Llega ahora la parte que ningún archivo de configuración resuelve. Todas las medidas anteriores corren en tu servidor, es decir, al final de la línea. Una regla de firewall decide sobre un paquete que ya ha pasado por el cable. Puedes descartarlo, pero no puedes hacer que no se haya enviado. Si la línea que hay delante está llena, los paquetes de tus usuarios dejan de llegar mucho antes, y da igual lo bueno que sea tu conjunto de reglas.

Esta tabla contesta la pregunta de si basta con la protección propia, y lo hace caso por caso. El ataque contra GitHub, con 126,9 millones de paquetes por segundo, cabe justo en la tasa de paquetes de una conexión de 100 Gbit/s, pero para los 1,35 Tbit/s de volumen harían falta catorce de esas conexiones a la vez. El ataque récord de 31,4 Tbit/s equivale a 314 conexiones de 100 Gbit/s saturadas por completo. Un servidor de juego suele estar conectado a 1 Gbit/s o a dos veces 1 Gbit/s: el límite de la protección propia está por tanto en unos 1,5 a 3 millones de paquetes por segundo, y en la práctica bastante por debajo, porque el kernel se rinde antes.

Hay además un segundo límite, más incómodo. En cuanto la línea está saturada puede que ni siquiera te llegue la sesión SSH con la que querías medir. Quien entonces no tenga un acceso independiente de la red, por ejemplo una consola VNC en el área de cliente, no puede ni mirar qué está pasando.

Lo que solo sirve delante del servidor: filtrado en la red y scrubbing

Solo puede filtrar de forma eficaz quien tiene más capacidad que el ataque. Eso exige un punto en el que confluyan muchas líneas, es decir, una red y no una máquina. Ahí existen dos procedimientos que se complementan.

Filtrado en tiempo real en la red. Todo el tráfico pasa de forma permanente por una etapa de filtrado que evalúa cada paquete antes de entregarlo al servidor. La ventaja es que no hay ninguna conmutación: la protección no tiene que reconocer primero un ataque para actuar. Y eso es justo lo decisivo en los juegos, porque un tiempo de conmutación de dos minutos es una partida perdida, y un tiempo de conmutación de dos minutos frente a un ataque que dura 35 segundos no es defensa en absoluto.

Scrubbing. Si la red reconoce un ataque volumétrico grande, el tráfico afectado se desvía a centros de filtrado, allí se limpia de sus partes dañinas y después se entrega en dirección al objetivo. El sentido de ese desvío es la proximidad: el tráfico de ataque termina en el punto en el que entra, en lugar de llegar hasta el centro de datos. Las reglas de filtrado se distribuyen para ello por la red, algo descrito técnicamente en el RFC 8955 como Flow Specification.

La contramedida estructural contra las direcciones de origen falsificadas se conoce, por cierto, desde el año 2000 y está en el RFC 2827, el BCP 38: quien conecta a un cliente descarta en esa frontera todos los paquetes cuya dirección de origen no pertenezca a ese cliente. El RFC 3704 lo amplía a las redes con varias conexiones. Si todos los operadores de red lo aplicaran, toda la clase de los ataques de amplificación estaría liquidada. No lo está, porque basta con que algunos no lo hagan.

Y hay un tercer método que hay que conocer, porque se vende a menudo como protección: el null-routing, técnicamente Remote Triggered Black Hole Filtering según el RFC 5635. Consiste en anunciar en la red la dirección IP atacada como inalcanzable, con lo que todo el tráfico hacia ella se descarta, el de ataque igual que el de tus usuarios. Eso protege la red del proveedor; para ti el resultado es idéntico al de un ataque con éxito, y normalmente durante horas después. En caso de duda, pregunta si se filtra o si se hace null-routing. La respuesta dice más sobre tu disponibilidad que cualquier dato de hardware.

Lo que KernelHost pone frente a esos ataques

La protección permanente incluida en todos los paquetes de servidor

La protección DDoS de KernelHost está estructurada en dos niveles y activa de forma permanente, sin que tengas que activar, pedir ni configurar nada:

• Nivel 1: 17 Tbps de capacidad de mitigación en la red global de scrubbing. Los ataques volumétricos se limpian cerca de su origen, antes de que lleguen al centro de datos.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete.

Dos propiedades marcan la diferencia. La protección funciona de forma permanente y está activa desde el aprovisionamiento del servidor, así que no hay unos minutos al principio de un ataque en los que el servicio esté fuera. Y no se utiliza null-routing: tu dirección IP se queda en la red y solo se descartan los paquetes dañinos. Qué juegos y protocolos tienen perfiles de filtrado propios lo detalla Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas, cada tarde a la misma hora y con patrones cambiantes. Para eso existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid, sin permanencia mínima y sin cuota de instalación. La diferencia no está en más capacidad, sino en el control:

• IP de protección dedicada del núcleo de red de Frankfurt, a la que se cambia tu servidor dentro de nuestra propia red. En tu lado no hace falta ninguna modificación.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: defines por separado qué se permite en el puerto de juego y qué en el puerto de consulta, y puedes así aprovechar exactamente la asimetría del apartado sobre los protocolos de consulta.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso en lugar de esperar a una ventana de mantenimiento.
• Perfil de protección adaptado a cada servicio, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP.

La Advanced DDoS Protection está dirigida a los clientes de KernelHost y requiere un servidor en KernelHost. Si tu proyecto está ahora mismo en otro sitio y allí recibe ataques con regularidad, el camino es traerlo aquí, no una atención remota de tu dirección actual.

Los dos niveles, comparados

Seis ataques reales filtrados en producción

Los seis ataques siguientes golpearon servidores de clientes de KernelHost y se filtraron por completo en tiempo real, en todos los casos sin caída. Las imágenes provienen de la monitorización en vivo de la defensa.

Servidor de voz TeamSpeak 3, puerto 9987 UDP. Ataque complejo con varios patrones simultáneos, más de 473,4 Gbit/s y más de 41,5 millones de paquetes por segundo. Eso es unas 28 veces la tasa de paquetes de una conexión de 1 Gbit/s.

Servidor de juego ARK, puerto 7777 UDP. Flood UDP simple sin estructura compleja, pero con más de 112,2 Gbit/s y más de 8,7 millones de paquetes por segundo. Cómo se asegura además un clúster de ARK por su cuenta está en Proteger un servidor de ARK frente a DDoS.

Ataque a todos los puertos, del 0 al 65535 en TCP y UDP. Más de doce patrones principales de ataque distintos contra todos los puertos a la vez, en total más de 21,3 Gbit/s y más de 3,9 millones de paquetes por segundo. Este caso muestra el reparto por todos los puertos que también presenta el caso de Cloudflare de mayo de 2025, con 21.925 puertos de destino de media.

Minecraft y OpenVPN, puertos 25565 TCP y 1194 UDP. Ataque combinado con más de dieciséis patrones principales de ataque distintos, más de 4 millones de paquetes por segundo y más de 8,6 Gbit/s. Los dos servicios siguieron accesibles en todo momento, aunque hablan protocolos diferentes.

Flood UDP contra un único puerto de servicio, ocho minutos. El más duro de los seis casos: 745,5 Gbit/s y 73,1 millones de paquetes por segundo, unas 49 veces la tasa de paquetes de una conexión de 1 Gbit/s. El 99,93 por ciento del tráfico se dirigió a un único puerto de destino, y los orígenes estaban completamente repartidos. A los ocho minutos el ataque había terminado, y el servicio siguió accesible en todo momento.

Ataque continuado a lo largo de tres horas y 31 minutos. 501,2 Gbit/s y 43,9 millones de paquetes por segundo, no como un pico aislado, sino como una sucesión de oleadas sin pausa. Siete patrones de ataque simultáneos, entre ellos amplificación por SSDP, MS SQL RS, L2TP y RIPv1. Los puertos de destino se repartieron por todo el rango del 1024 al 65535, así que cambiar de puerto no habría servido de nada. Más sobre los dos casos en Cuánto dura un ataque DDoS.

Qué hacer en caso de ataque, en este orden

El orden importa más que cada paso por separado, porque los errores más frecuentes ocurren en los primeros cinco minutos.

1. Medir, no tocar ajustes. Guarda primero en un archivo los valores de sar -n DEV 1 10, ip -s link show, ss -s y dmesg -T. Cuando el ataque pase habrán desaparecido, y sin ellos nadie puede ayudarte.
2. No reiniciar. Un reinicio borra todos los contadores, todos los estados de conexión y cualquier prueba, y la carga vuelve a los pocos segundos.
3. Determinar de qué nivel se trata. Bytes divididos entre paquetes dan el tamaño medio de paquete. Por debajo de 100 bytes apunta a un ataque de protocolo, por encima de 1.000 bytes a un ataque de amplificación, y tamaños normales con una carga de CPU alta apuntan a la capa 7.
4. Cerrar los puertos de administración. El panel, la base de datos, RCON y todo lo que no tenga que ser público deben quedar limitados a tu propia dirección. Eso reduce la superficie de ataque de inmediato y sin riesgo para los usuarios.
5. Poner un límite de tasa, estricto en el puerto de consulta y amplio en el puerto de uso. No bloquees el puerto de consulta, porque si no desapareces de cualquier lista de servidores.
6. No cambiar la propia dirección a la ligera. Un cambio de dirección solo sirve mientras la nueva no vuelva a estar publicada, y un registro DNS antiguo olvidado deja el cambio sin efecto.
7. Implicar al proveedor con cifras. Abre un ticket con el momento, el puerto de destino, la tasa de paquetes, el ancho de banda y el tamaño medio de paquete. Esos cinco datos deciden con qué rapidez se ajustan las reglas de filtrado de tu dirección.
8. Documentarlo después. Anota cuándo empezó, cuánto duró y qué patrón era. Los ataques que se repiten a la misma hora son el criterio para saber si un proyecto necesita una IP de protección dedicada.

El procedimiento detallado para un ataque grave y de larga duración está en Ataque DDoS grave: qué hacer.

Situación legal: un ataque DDoS es un delito

En Austria un ataque DDoS entra en el § 126b del Código Penal austriaco (StGB), "Perturbación del funcionamiento de un sistema informático". El tipo básico prevé pena de prisión de hasta seis meses o multa de hasta 360 cuotas diarias. Si la perturbación dura un tiempo prolongado, son hasta dos años. Si se atacan muchos sistemas con un programa creado de forma reconocible para ello, son hasta tres años. Y con un daño superior a 300.000 euros, en un ataque contra infraestructura crítica o como miembro de una organización criminal, el marco va de seis meses a cinco años. De forma complementaria, el § 126c del StGB castiga ya la fabricación, la difusión y la puesta a disposición de los programas destinados a ello.

En Alemania se aplica el § 303b del Código Penal alemán (StGB), "Sabotaje informático": hasta tres años de prisión o multa, hasta cinco años si el procesamiento de datos sirve a una explotación, a una empresa o a una autoridad, y en los casos especialmente graves de seis meses a diez años, por ejemplo con actuación profesional o con afectación de infraestructura crítica. La tentativa es punible, y para los actos preparatorios el § 303b apartado 5 del StGB remite al § 202c del StGB.

Los servicios de booter y de stresser no son, por tanto, ninguna zona gris, sino la parte pagada de un delito. Hay tres puntos que se malinterpretan con regularidad. Primero, el aviso de "solo para pruebas de carga de sistemas propios" no hace nada legal, porque esos servicios no comprueban a quién pertenece el objetivo introducido. Segundo, quien encarga el ataque también es punible, no solo quien explota el servicio: Europol escribió expresamente, después de la semana de acciones de abril de 2026, a más de 75.000 usuarios identificados para dejar justo eso claro. Tercero, una prueba de carga contra tu propio servidor a través de un servicio así tampoco es una solución, porque el tráfico de ataque pasa por la red del proveedor y con ello por las líneas de otros clientes, algo que cualquier contrato de hosting prohíbe. Quien quiera medir de verdad la resistencia de su servicio lo hace anunciándolo y de acuerdo con el proveedor. Este apartado recoge el estado de la ley y no es asesoramiento jurídico.

La guía adecuada para tu servicio

Este artículo explica el principio. Qué puerto debe estar abierto, qué directiva de configuración limita qué consulta y dónde está el límite en cada juego: eso está en los artículos de cada servicio concreto, siempre con una tabla de datos de los puertos.

• Fundamentos y procedimiento: Detectar un ataque DDoS, Proteger un servidor frente a ataques DDoS, Ataque DDoS grave: qué hacer, Protección DDoS para juegos con filtrado en tiempo real
• Minecraft y voz: Minecraft y nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Rol sobre la base de GTA: FiveM, RedM, RAGE MP y alt:V, SA-MP y open.mp, MTA:SA
• Supervivencia y construcción: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Táctica y disparos: CS2 y Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

En resumen

• Un ataque DDoS ocupa uno de cuatro recursos finitos: ancho de banda, tasa de paquetes, una tabla de estados del kernel o el tiempo de proceso de la aplicación. No aprovecha ningún fallo de seguridad, así que actualizar por sí solo no protege.
• El RFC 4732 define un ataque DoS por su efecto, no por el número de orígenes. Se llama distribuido cuando los orígenes son numerosos: en el caso de Cloudflare de mayo de 2025 eran 122.145 direcciones de 161 países.
• CISA, el FBI y MS-ISAC distinguen tres técnicas: volumétrica en Gbit/s, de protocolo en paquetes por segundo, de aplicación en peticiones por segundo. Cada una necesita una defensa distinta.
• Los ataques de amplificación abusan de servicios UDP abiertos. Los factores van desde 5,5 en el protocolo de Steam pasando por 30,8 en SSDP y 556,9 en NTP hasta 51.000 en memcached, según la alerta TA14-017A del US-CERT.
• La capacidad sale de botnets de dispositivos tomados, desde los 600.000 de Mirai en 2016 hasta los entre uno y cuatro millones estimados detrás del ataque récord de 31,4 Tbit/s, y se revende desde unos 10 euros al mes.
• En el servidor sirven nftables, las SYN cookies, unos límites de conntrack ajustados y un límite de tasa por dirección de origen. Se acaban en torno a 1,5 millones de paquetes por segundo, porque una conexión de 1 Gbit/s no transporta más.
• Por encima de ese límite decide exclusivamente el filtrado en la red que hay delante del servidor. El null-routing no es una defensa, sino el resultado que el atacante quería.
• En KernelHost, la protección permanente en dos niveles está incluida en todos los paquetes de servidor sin recargo y activa desde el aprovisionamiento, sin null-routing: 17 Tbps de capacidad de mitigación en la red global de scrubbing más filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main. La Advanced DDoS Protection la completa desde 50,00 € al mes con una IP de protección dedicada y reglas por puerto autogestionables.
• Un ataque DDoS es punible en Austria según el § 126b del StGB y en Alemania según el § 303b del StGB, tanto para quien lo encarga como para quien explota los servicios.

Si tu proyecto ya está en KernelHost, el filtrado está activo sin que tengas que hacer nada. Si aun así notas algo raro, abre un ticket de soporte con los cinco datos del paso 7 para que ajustemos con más precisión las reglas de filtrado de tu dirección IP. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883.