Sobrevivir a un ataque DDoS en tu VPS

Hay dos momentos en los que se aprende cómo funciona realmente la mitigación de DDoS. El primero es tranquilo, en el momento de la compra, leyendo una lista de características que dice «protección DDoS incluida» y dando por hecho, sin pensarlo demasiado, que esa frase lo cubre todo. El segundo es a las tres de la madrugada, cuando el sitio está caído, las gráficas se ven mal de una forma que no tiene sentido, y esa protección incluida no está haciendo nada en absoluto — correctamente, y por diseño.

Ambos momentos involucran el mismo producto y la misma verdad: un proveedor de hosting filtra los ataques que llegan como volumen bruto, porque es dueño de la tubería por la que viajan esos paquetes y tú no. No puede filtrar los ataques que llegan como solicitudes de aspecto normal, porque desde el punto de vista de la red son solicitudes de aspecto normal. Esa línea — entre la inundación que absorbe tu proveedor y la que tienes que sobrevivir tú mismo — es todo el tema. Lo que sigue trata de averiguar en qué lado de esa línea estás, y qué hacer en cada uno.

Dos ataques distintos que comparten un nombre

«DDoS» es una sola palabra que cubre dos problemas que casi no tienen nada en común salvo el resultado. Se detienen en lugares distintos, por personas distintas, con herramientas distintas, y confundirlos es la razón por la que tanto esfuerzo de mitigación termina en la capa equivocada.

Lee otra vez las dos últimas filas, porque ahí está el punto práctico. Si la interfaz está saturada, nada de lo que escribas en el servidor va a ayudar: los paquetes ya han consumido el puerto, y la única parte que puede descartarlos es la que es dueña del router aguas arriba. Si la interfaz está tranquila pero el sitio sigue caído, ocurre lo contrario — tu proveedor no ve nada malo porque, en su capa, no hay nada malo, y el arreglo es enteramente tuyo.

Qué compra realmente la «protección DDoS incluida»

La protección a nivel de red es real, valiosa, y casi siempre se interpreta mal. Cuando un proveedor anuncia filtrado L3/L4, quiere decir que su red monitoriza el tráfico destinado a tu dirección, y que cuando se detecta una inundación, el tráfico se desvía a través de hardware de depuración que descarta la parte maliciosa y reenvía lo que parece legítimo. Ocurre sin necesidad de un ticket de soporte y normalmente sin que notes más que un breve parpadeo.

Esa única frase está haciendo mucho trabajo, así que merece la pena desglosar qué incluye y qué no:

• Cubre los ataques que no puedes sobrevivir solo. Una inundación de amplificación de 200 Gbps contra un servidor con un puerto de 1 Gbps no es un problema de configuración. Es aritmética. La depuración aguas arriba es la única respuesta que existe.
• No tiene estado respecto a tu aplicación. El filtro no sabe cuáles de tus URLs son costosas, qué visitantes han iniciado sesión, ni que una solicitud a tu endpoint de búsqueda cuesta cuatrocientas veces más que una solicitud a tu logotipo.
• Reacciona ante un umbral, no ante tu sufrimiento. La detección se activa por volumen de tráfico. Un ataque que nunca cruza el umbral nunca lo activa, sin importar lo exhaustivamente que haya tumbado tu sitio.
• Puede aplicar brevemente una ruta nula (null-routing) en casos extremos. Toda red tiene un techo. Si un ataque amenaza la infraestructura compartida, la dirección puede quedar bloqueada durante un tiempo — esto es estándar, universal, y conviene saberlo antes de que ocurra y no durante.

Primero, decide si esto es siquiera un ataque

Una proporción considerable de los presuntos incidentes de DDoS son otra cosa disfrazada, y las soluciones no son intercambiables. Antes de limitar la tasa de nada, dedica dos minutos a descartar a los impostores — un diagnóstico equivocado aquí te cuesta una hora y, a veces, tus usuarios reales.

• Te has vuelto popular. Un enlace en un gran agregador produce una forma de tráfico que parece exactamente una inundación de capa 7, salvo que los referrers son reales y las solicitudes piden páginas que un humano querría ver. Es un problema de capacidad con una causa feliz; limitar su tasa es autolesión.
• Un rastreador perdió los modales. Los scrapers agresivos y los bots de entrenamiento de IA pueden superar a un servidor pequeño con total facilidad. El user-agent suele delatarlo, y el arreglo es robots.txt más un límite específico, no uno general.
• Rompiste algo. Un despliegue que desactivó la caché, una tarea cron descontrolada, una base de datos que perdió un índice — todo se presenta como «carga repentina, sin causa evidente». Si el momento coincide con un cambio que hiciste, cree en el cambio.
• Tu propia monitorización es la inundación. Poco frecuente, embarazoso, y mucho más común de lo que nadie admite. Un bucle de comprobación de salud que reintenta sin backoff puede generar una tasa de solicitudes genuinamente impresionante.

La pregunta que marca la diferencia es simple: ¿el tráfico quiere algo? La carga real — incluso la carga real de aspecto hostil — tiene una forma. Golpea páginas que existen, sigue enlaces, carga activos, y proviene de una dispersión plausible de redes. Un ataque normalmente no se molesta en hacer eso.

Leer el ataque desde el propio servidor

No necesitas un panel para clasificar lo que está pasando. Cuatro comandos, ejecutados en orden, te dirán en menos de un minuto en qué capa estás luchando — y saber eso determina todo lo que haces a continuación.

¿Está la tubería llena? Observa los contadores de la interfaz. Si el rendimiento está clavado cerca del techo del puerto, estás en un ataque volumétrico y tu trabajo es un ticket de soporte, no un cambio de configuración:

• vnstat -tr 10 — rendimiento medio en diez segundos, la lectura honesta más rápida sobre la saturación.
• cat /proc/net/dev dos veces, con un segundo de diferencia — deltas de paquetes y bytes por interfaz, sin necesidad de herramientas.

¿Es una inundación SYN? Las conexiones semiabiertas se acumulan en SYN-RECV. Un puñado es normal; miles no lo es:

• ss -s — la línea de resumen, recuentos de conexiones por estado de un vistazo.
• ss -tn state syn-recv | wc -l — el número concreto que importa.

¿Es capa 7? Si el ancho de banda no llama la atención pero todo va lento, cuenta las solicitudes por cliente en tu log de acceso. Una sola dirección con decenas de miles de peticiones es un aficionado; cien mil direcciones con tres peticiones cada una es lo real:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Cambia $1 por $7 para clasificar en su lugar las rutas solicitadas. Si un endpoint costoso domina, has encontrado el objetivo y la mitad del arreglo.

¿Qué es lo que realmente se ha agotado? El load average por sí solo dice poco. Busca el techo específico que has alcanzado: los procesos de PHP-FPM todos ocupados, las conexiones de la base de datos en su límite, los descriptores de archivo agotados, o workers atascados en estado D esperando al disco. Ese techo — no el tráfico — es lo que tumbó el sitio, y subirlo suele ser más rápido que filtrar nada.

Los primeros diez minutos

Bajo presión, la gente recurre a la palanca más grande disponible, y la palanca más grande suele ser la equivocada. Este es el orden que limita el daño, aproximadamente de más rápido y seguro a menos:

1. Clasifica antes de actuar. Interfaz saturada significa volumétrico; interfaz tranquila con workers ocupados significa capa 7. Treinta segundos invertidos aquí te ahorran una hora arreglando la capa equivocada.
2. Si es volumétrico, abre un ticket de inmediato e incluye la dirección de destino, la hora de inicio, y tus contadores de interfaz. Luego deja de escribir en el servidor — no puedes arreglar esto desde dentro.
3. Si es capa 7, activa la caché primero. Activar un caché de página completa agresivo para visitantes anónimos es la forma más rápida de convertir una caída en un encogimiento de hombros, y es la única medida que también ayuda contra el tráfico real.
4. Luego limita la tasa — primero el endpoint objetivo, después todo lo demás. Empieza de forma conservadora. Un límite que deja fuera a tus propios usuarios es una continuación autoinfligida del ataque.
5. Bloquea solo lo que sea inequívoco. Una docena de direcciones con cien mil solicitudes cada una, un user-agent obviamente falso, un país en el que no tienes usuarios. Resiste el impulso de escribir reglas elaboradas mientras estás bajo fuego; no las recordarás el mes que viene.
6. Reduce carga deliberadamente si es necesario. Servir una página estática de «en mantenimiento» a los visitantes no autenticados mantiene la máquina viva, mantiene tu API en pie, y compra tiempo para pensar. Decidir qué sacrificar es mejor que dejar que lo decidan por ti.
7. Anota lo que hiciste. Cada regla temporal que añadiste es una mina terrestre para tu yo futuro. Las reglas que ayudaron se vuelven permanentes; el resto se retira mañana.

Límites de tasa que aguantan, y el error que comete todo el mundo

La limitación de tasa es el instrumento principal para la capa 7, y nginx lo hace bien con dos directivas que resuelven dos problemas genuinamente distintos. limit_req limita la tasa de solicitudes — con qué frecuencia puede preguntar un cliente. limit_conn limita la concurrencia — cuántas conexiones puede mantener abiertas a la vez un mismo cliente. Las inundaciones necesitan lo primero; los ataques Slowloris, que mantienen miles de conexiones casi inactivas para agotar tu grupo de workers, necesitan lo segundo. Si despliegas solo uno, estás cubierto contra la mitad del problema.

Tres detalles separan un límite que funciona de uno que es decorativo:

• Usa un burst, y usa nodelay. Los navegadores reales van a ráfagas — una sola vista de página dispara una docena de solicitudes de activos casi simultáneas. Un límite sin margen estrangula a los visitantes genuinos mientras un atacante que se dosifica justo por debajo del umbral pasa sin problema.
• Limita los endpoints costosos por separado. Tu página de búsqueda, el formulario de inicio de sesión, el restablecimiento de contraseña y cualquier endpoint que escriba en la base de datos merecen un presupuesto mucho más estricto que tus activos estáticos. Los atacantes los encuentran sin esfuerzo, porque son los que hacen daño.
• Devuelve 429, no 503. El código de estado es una señal para los clientes bien educados y para los motores de búsqueda de que esto es limitación y no fallo — y evita que una mala tarde se convierta en un problema de posicionamiento.

La caché es la mitigación más barata que desplegarás jamás

Un límite de tasa rechaza trabajo. Una caché hace que el trabajo no exista. Para todo lo que ve un visitante anónimo, el caché de página completa cambia la economía de todo el ataque: una solicitud que habría costado un viaje de ida y vuelta a la base de datos, el renderizado de una plantilla y un worker de PHP se convierte en una lectura de archivo medida en microsegundos. El mismo servidor que colapsaba a las cuatrocientas solicitudes dinámicas por segundo servirá decenas de miles de solicitudes cacheadas sin inmutarse.

Lo que importa cuando lo activas en pleno apuro:

• Cachea solo para visitantes anónimos. Sáltala con una cookie de sesión. Servir la página de un usuario con sesión iniciada a otro es un incidente mucho peor que la caída que estabas arreglando.
• Sirve contenido obsoleto a propósito. proxy_cache_use_stale de nginx con updating error timeout hace que, cuando tu backend está en apuros, los visitantes reciban una página ligeramente antigua en lugar de un error. Durante un ataque, esta es la diferencia entre un sitio que parece estar bien y uno que parece muerto.
• Colapsa los fallos de caché duplicados. proxy_cache_lock garantiza que mil solicitudes simultáneas de la misma página sin cachear produzcan una sola solicitud al backend, no mil. Sin esto, un ataque que anula la caché la atraviesa directamente y golpea tu base de datos a plena fuerza.
• Neutraliza las cadenas de consulta que anulan la caché. El truco habitual es añadir ? y un valor aleatorio para que cada solicitud sea una clave única y falle siempre. Normaliza tu clave de caché para ignorar los parámetros de consulta que tu aplicación no usa realmente.

Hay una asimetría agradable aquí que merece la pena interiorizar: cada hora que dedicas a la caché también hace que el sitio sea más rápido en su mejor día, más barato de operar, y mejor sobreviviendo al éxito. Casi ninguna otra línea de defensa paga un dividendo cuando no pasa nada malo.

Los techos que deciden si te caes

La mayoría de los servidores no mueren porque se les acabe la CPU. Mueren porque chocan con un techo invisible que nadie fijó deliberadamente — un valor por defecto de hace una década que tenía sentido en un hardware que ya nadie usa. Bajo ataque, esto es lo que realmente se rompe primero:

• Los workers de la aplicación. El pm.max_children de PHP-FPM, tu número de workers de Python, el tamaño de tu clúster de Node. Este es el límite real de concurrencia de tu sitio. Cuando están todos ocupados, cada visitante adicional se pone en cola, y el sitio está caído sin importar lo ociosa que parezca la CPU. Súbelo solo hasta donde lo permita la memoria — el swapping es peor que la cola.
• La cola de aceptación. net.core.somaxconn y tu backlog de escucha deciden cuántas conexiones pueden esperar a ser aceptadas. Un backlog pequeño convierte una ráfaga que se podría sobrevivir en conexiones rechazadas.
• Las cookies SYN. net.ipv4.tcp_syncookies permite que el kernel responda a una inundación SYN sin reservar estado para conexiones que nunca se completarán. Los kernels modernos lo activan por defecto; verifícalo en lugar de darlo por hecho, porque no cuesta nada y te salva de la inundación más común que existe.
• Los descriptores de archivo. Cada conexión es un descriptor. El límite nofile por defecto suele ser más bajo que el número de conexiones que intentas atender, y el modo de fallo — los accepts fallando mientras todo parece sano — es genuinamente confuso a las tres de la madrugada.
• Las conexiones a la base de datos. Subir el número de workers sin subir el pool de conexiones simplemente mueve la cola a un lugar más difícil de ver. Estos dos números deben ajustarse juntos.

Ajusta esto en un día tranquilo, no durante un incidente. El sentido de conocerlos es que, cuando el sitio se caiga, puedas nombrar el techo que golpeó en lugar de adivinar — y un techo con nombre es un techo arreglado.

Poner algo delante del origen

Todo lo anterior ocurre en el servidor. El siguiente paso es decidir si el servidor debería ser lo que recibe el tráfico directamente. Hay tres opciones honestas, y la respuesta correcta depende mucho más de lo que alojas que de lo que puedes permitirte.

El nodo frontal autoalojado merece más atención de la que suele recibir, en particular para cualquiera que eligiera hosting offshore por razones con las que un gran CDN podría no simpatizar. El patrón no tiene nada de glamuroso: nodos proxy baratos delante, origen protegido por firewall para aceptar conexiones solo desde esos nodos, DNS apuntando a los frontales. Si se ataca un frontal, lo sustituyes por una dirección nueva en minutos y el origen ni se entera. La versión completa de esta arquitectura — incluidas las seis formas en que una dirección de origen se filtra de todos modos — es el tema de nuestra guía sobre ocultar la IP de tu servidor de origen.

Un origen oculto vale más que cualquier filtro

Merece la pena decirlo sin rodeos, porque invierte la prioridad habitual: la mitigación de DDoS más barata que tienes a tu alcance es una dirección que el atacante no tiene. Filtrar es lo que haces cuando eso ya ha fallado.

Esto importa más de lo que parece, porque las direcciones de origen se filtran constante y silenciosamente. Los registros DNS históricos de antes de poner un proxy delante sobreviven al cambio durante años. El correo enviado directamente desde la aplicación lleva la dirección en sus cabeceras. Un certificado TLS emitido sobre la dirección en crudo se publica permanentemente en los registros de Certificate Transparency. Una página de error, una redirección, o un subdominio olvidado que nunca se proxeó, todo lo delata. Si has puesto un CDN delante de un servidor que antes estuvo expuesto, da por hecho que la dirección antigua es conocida hasta que la hayas cambiado.

Elegir hardware y ubicación para que los ataques resulten aburridos

Parte de esto se decide antes de que ocurra ningún ataque, en el momento en que eliges un plan. Tres propiedades importan mucho más de lo que sugiere la hoja de especificaciones:

• Ancho de banda ilimitado. En un plan medido, un ataque no es solo una caída — es una factura. El tráfico que nunca pediste y no pudiste rechazar sigue contando contra tu asignación. La transferencia ilimitada convierte un riesgo financiero en uno puramente técnico, que es una clase de problema mucho mejor.
• Si el puerto es tuyo. En un host virtualizado compartido, un vecino bajo ataque puede degradarte a ti, y tu propio techo de protección es compartido. El hardware dedicado con su propio puerto elimina ambos efectos. Para un proyecto que espera atención hostil, esta es la razón más clara para dar el salto desde un VPS — más que los núcleos o la RAM.
• Dónde está la red. Una red europea bien conectada con capacidad de tránsito real absorbe una inundación que una mal conectada no absorberá, y la jurisdicción que elegiste por razones legales también tiene características de red. Merece la pena comprobar ambas cosas al elegir entre las ubicaciones disponibles.

También hay un argumento de escala que favorece discretamente la sencillez. Un sitio estático detrás de una caché en un servidor modesto es extraordinariamente difícil de tumbar; el mismo contenido en un CMS pesado con un endpoint de búsqueda sin cachear puede romperlo una sola persona decidida con un script. Reducir lo que es dinámico es una mitigación, y es gratis. Si tu proyecto realmente vive bajo carga sostenida, nuestras notas de hosting de alto tráfico cubren el aspecto del dimensionamiento de la misma cuestión.

Cinco cosas que no hay que hacer

Los modos de fallo aquí son lo bastante consistentes como para enumerarlos, y cada uno le ha costado un fin de semana a alguien:

• No apliques null-routing sobre ti mismo. Aplicar un agujero negro (blackholing) a tu propia dirección termina el ataque de la forma más literal posible — nadie puede alcanzarte, incluidos tus usuarios. Es un recurso de último extremo para tu proveedor, no una acción que tomes voluntariamente.
• No trates fail2ban como protección DDoS. Es una buena herramienta contra intentos de fuerza bruta desde unas pocas direcciones. Contra una inundación distribuida, reacciona en minutos a algo que llega en segundos, y una regla que bloquea miles de direcciones puede costar más en procesamiento de firewall de lo que te costó el ataque.
• No pagues un rescate. La inmensa mayoría de los correos de extorsión que amenazan con un ataque devastador vienen de gente sin ninguna capacidad que envía miles de mensajes idénticos. La pequeña minoría que sí puede cumplir volverá, porque has demostrado que pagas.
• No te tomes la revancha. Además de ser ilegal prácticamente en todas partes, las fuentes son terceros comprometidos. Estarías atacando a víctimas, y haciéndolo desde una dirección que es inequívocamente tuya.
• No migres en pánico. Cambiar de proveedor en mitad de un ataque significa que la dirección nueva es pública en minutos y no tienes ninguna configuración funcionando. Estabiliza primero, muévete deliberadamente después — y si te mudas, nuestra guía sobre migrar sin tiempo de inactividad existe precisamente para que la mudanza no sea un segundo incidente.

La versión corta

Despojado del razonamiento, el modelo de trabajo cabe en ocho líneas:

1. Clasifica primero. Interfaz saturada significa volumétrico y le pertenece a tu proveedor. Interfaz tranquila con workers agotados significa capa 7 y te pertenece a ti.
2. Para lo volumétrico, abre un ticket con la dirección, la marca de tiempo y tus contadores — y luego deja de tocar el servidor.
3. Cachea agresivamente para visitantes anónimos, sirve contenido obsoleto bajo estrés, y colapsa los fallos de caché duplicados. Este es el cambio de mayor impacto que puedes hacer.
4. Limita la tasa por frecuencia de solicitudes y por concurrencia, lo más estricto en los endpoints que más cuestan, y devuelve 429.
5. Arregla tu configuración de IP real antes que nada, o todo límite por cliente detrás de un proxy será o bien inútil o bien catastrófico.
6. Conoce tus techos — workers, backlog, descriptores, conexiones de base de datos — y súbelos deliberadamente en un día tranquilo.
7. Mantén la dirección de origen secreta y protegida por firewall, de modo que solo puedan alcanzarla tus nodos frontales. Esto vale más que todos los filtros juntos.
8. Compra ancho de banda ilimitado para que el tráfico que no pediste nunca sea también una factura.

Nada de esto te hace inmune, y quien te venda inmunidad te está vendiendo otra cosa. Lo que sí hace es sacarte de la población a la que un adolescente aburrido puede dejar fuera de línea, y meterte en la que requiere recursos genuinos e intención genuina para perturbarla — algo que, para la inmensa mayoría de los proyectos, es indistinguible de estar a salvo. El resto es el mismo trabajo sin glamour que hace que un servidor sea bueno en todo lo demás: reforzado desde el primer día, restaurable en el peor, y alojado en algún lugar que trate tu tráfico como el negocio que es.