Extorsión DDoS: qué detiene realmente un ataque a un sitio de clasificados para adultos, y qué no

La mañana en que el directorio deja de cargar sin un motivo que puedas encontrar

Suele empezar siempre igual. El sitio va lento, luego deja de cargar del todo, luego vuelve durante diez minutos y cae otra vez. El panel de hosting no muestra nada raro: ningún despliegue fallido, ninguna base de datos al límite, ningún certificado caducado. Un ticket de soporte al proveedor recibe como respuesta que por su lado todo parece normal, lo cual es técnicamente cierto y completamente inútil, porque el problema no está en su lado, está en el cable entre internet y su lado.

Lo que de verdad ocurre, en la gran mayoría de estos casos, es un ataque de denegación de servicio distribuido: una oleada de tráfico, normalmente desde miles de dispositivos comprometidos, pensada para impedir que el sitio responda a los visitantes reales. No es raro ni exótico. El equipo de inteligencia de amenazas de Cloudflare informó de haber mitigado unos 5.343 ataques DDoS a nivel de red cada hora en su red durante la primera mitad de 2026, una media de unos 128.000 al día. La mayoría de esos ataques son cortos y pequeños comparados con los incidentes más extremos jamás registrados: el 96,62% se mantuvo por debajo de 500 Mbps, y el 90,60% terminó en menos de diez minutos. "Pequeño", sin embargo, es relativo: un ataque de 100 Mbps basta para tumbar un servidor típico sin protección, una fracción de lo que aparece una noche cualquiera de un día de semana contra sitios de los que nadie ha oído hablar.

El motivo de negocio detrás de un ataque concreto casi siempre importa menos de lo que los operadores suponen. Puede ser un directorio rival intentando dejar fuera de línea a la competencia durante un fin de semana de mucho tráfico, un anunciante expulsado que se venga con un servicio barato de ataque por encargo, un oportunista aburrido que encontró el sitio con un escaneo al azar, o el primer movimiento de un intento de extorsión. La respuesta que realmente protege el sitio es casi idéntica sea cual sea el motivo, lo cual es una buena noticia, porque ese motivo casi nunca llega a confirmarse.

Los directorios de clasificados son un objetivo más fácil de lo que sus propietarios tienden a suponer. Muchos funcionan sobre un único VPS económico elegido precisamente porque aceptaba el negocio desde el principio, con el DNS apuntando directamente a ese servidor porque nadie pensó en hacerlo de otra forma cuando se configuró el dominio. Los ingresos dependen del tiempo en línea de una manera que un sitio escaparate no conoce: cada hora fuera de línea es una hora de renovaciones vencidas, registros abandonados, y anunciantes que abren la pestaña de un competidor en vez de volver a comprobar si el sitio original se ha recuperado.

La nota de rescate, y por qué pagarla no cierra nada

Algunos ataques llegan con una exigencia adjunta. El patrón, conocido en el sector de la seguridad como ransom DDoS o RDoS, suele empezar con un breve ataque de demostración o una amenaza directa por correo, seguida de la instrucción de pagar una cantidad, casi siempre en criptomoneda, para frenar un ataque mayor o evitar que empiece siquiera. Grupos construidos exactamente sobre este guion, DD4BC y el Armada Collective entre los primeros, lo usan desde alrededor de 2014, y actores más recientes siguen recurriendo a la misma estructura porque sigue funcionando lo bastante a menudo como para que merezca la pena el esfuerzo.

Pagar parece la salida más rápida cuando cada hora de caída cuesta renovaciones reales, y esa es exactamente la presión que la exigencia está diseñada para crear. El problema es que nada en la transacción obliga al atacante a hacer nada. No hay un contrato de soporte detrás de una nota de rescate. El caso más citado como advertencia es el de ProtonMail en 2015, que pagó y vio que los ataques continuaban igual, concluyendo después públicamente que el pago no había comprado nada. Los investigadores de seguridad que siguen a estos grupos reportan el mismo patrón con la frecuencia suficiente como para tratarlo como el resultado por defecto, no como la excepción.

Pagar también cambia cómo se percibe la cuenta la próxima vez. Un objetivo conocido por pagar es un objetivo más atractivo, para el mismo grupo y para otros que se enteran a través de los mismos mercados criminales que venden servicios de ataque por encargo. El incentivo que crea va exactamente en la dirección contraria a la que querría un negocio que preferiría no volver a vivir esto.

Lo que realmente ayuda durante una exigencia activa es aburrido y procedimental: guardar el mensaje con todas sus cabeceras en vez de limitarse a leerlo y borrarlo, avisar de inmediato al equipo de abusos o seguridad del proveedor de hosting y de la CDN, porque puede que ya estén siguiendo al mismo atacante contra otros clientes, y presentar una denuncia ante la unidad policial competente en delitos informáticos aunque no se espere una respuesta rápida, porque son los informes agregados los que con el tiempo permiten a las agencias y a los proveedores de infraestructura actuar contra los grupos reincidentes. Nada de esto detiene el ataque por sí solo. La siguiente sección es lo que de verdad lo detiene.

Qué detiene de verdad el tráfico antes de que llegue al servidor

La solución que funciona es arquitectónica, no negociable: poner una red de distribución de contenido o un proxy inverso delante del sitio, para que el tráfico de ataque se absorba y filtre en el borde de la red, usando la capacidad global de un proveedor, antes de que llegue al pequeño servidor que realmente ejecuta el código del directorio. Es el mismo papel que una CDN ya desempeña para el rendimiento ordinario, extendido a un tráfico que es activamente hostil y no solo simplemente alto.

El coste es menos obstáculo de lo que los operadores suelen suponer. Los grandes proveedores de CDN suelen incluir la mitigación DDoS a nivel de red siempre activa en su nivel gratuito, como parte del servicio base y no como un complemento de pago, precisamente porque absorber este tipo de tráfico a escala les sale más barato hacerlo para todos que revisar y facturar cada ataque uno por uno. La protección básica que necesita un directorio de clasificados suele estar ya disponible sin coste adicional. El problema casi nunca es el precio. Es la configuración.

El error de configuración más habitual es dejar descubierta la dirección IP real del servidor de origen incluso después de poner una CDN delante del dominio principal. Un registro del servidor de correo, un subdominio de pruebas antiguo, un panel de administración con su propio nombre de host, o un registro DNS que nadie se acordó de actualizar al configurar la CDN pueden seguir apuntando directamente al origen. Un atacante que encuentra esa IP, muchas veces con nada más sofisticado que una búsqueda en el historial DNS pasivo, ataca directamente al servidor real y pasa de largo junto a la CDN que debía protegerlo. La solución es una auditoría completa de todos los registros DNS del dominio, comprobando que cada uno pasa por la CDN o que de verdad no necesita ser público, y tratar después la IP de origen como algo que hay que ocultar activamente, no un detalle de fondo del que nadie se acuerda después del día de la configuración.

Este montaje hay que probarlo antes de un ataque, no durante uno. Un operador que nunca ha comprobado de verdad que todos los registros pasan por la CDN, o que no sabe de memoria a qué segunda CDN movería el negocio si la actual se cayera, descubre las grietas en el peor momento posible. Repasar la configuración una vez, en una tarde tranquila, cuesta una hora. Descubrir una grieta en medio de un ataque cuesta mucho más.

Elegir un proveedor que de verdad quiera conservar la cuenta

No todos los proveedores de CDN o anti-DDoS tratan igual el contenido para adultos legal, y merece la pena comprobarlo antes de montar la infraestructura alrededor de uno, no después. Algunos de los mayores proveedores de infraestructura gestionan su servicio de seguridad y enrutamiento de tráfico de forma realmente neutral respecto al contenido, sirviendo casi cualquier material legal sin aislar por categoría el contenido para adultos, lo cual es parte del motivo por el que de vez en cuando reciben críticas públicas por el puñado de sitios que terminan protegiendo. Otros escriben una prohibición directa de material "obsceno o pornográfico" en su política de uso aceptable estándar, el mismo tipo de cláusula que aparece en los contratos de hosting y de registro de dominios para esta categoría. La reputación de un proveedor como centrado en la seguridad y no en el contenido no le dice a un operador en qué categoría cae; solo leer la política real lo dice.

Es la misma discrecionalidad que ya decide si un host, una CDN o un registrador consideran que un negocio de anuncios no es bienvenido en su infraestructura, un nivel más cerca de la pregunta específica de la mitigación DDoS que del hosting en general. Un proveedor que acepta la cuenta hoy bajo una cláusula vaga o nunca puesta a prueba puede actuar sobre esa cláusula más adelante, y un operador que solo descubre con qué tipo de proveedor trabaja después de un aviso de cierre ya ha perdido la posibilidad de elegir con calma una alternativa.

La comprobación práctica es sencilla y lleva pocos minutos: buscar en la política de uso aceptable o en los términos de servicio del proveedor las palabras adult, pornographic, obscene y escort antes de firmar, en vez de suponer que un proveedor de seguridad es neutral por defecto solo porque no es un procesador de pagos ni un banco. Si la política guarda silencio, ese silencio tampoco es una garantía, solo una cláusula que nadie ha puesto a prueba todavía. Tener en mente un segundo proveedor, y un montaje DNS que pueda apuntar hacia él en una hora y no en un día, importa aquí exactamente igual que importa para el hosting en general.

Cuánto cuesta de verdad una caída una vez terminada

Incluso un ataque mitigado rápidamente deja costes que aparecen después de que el tráfico se detiene. Un sitio inestable durante unas horas, en vez de completamente caído, puede seguir rompiendo los procesos silenciosos de fondo que mantienen en marcha un negocio de suscripción: una red de tarjetas que intenta llegar a un webhook de facturación durante una caída intermitente se comporta igual que un intento de renovación que nunca llega a la red de la tarjeta, y el anunciante al otro lado solo ve una tarjeta rechazada, sin idea de que la causa real fue un ataque que no tenía nada que ver con él.

Los buscadores son igual de implacables al distinguir entre "bajo ataque" y "fuera de negocio". Un dominio inalcanzable durante un tramo prolongado recibe de un rastreador el mismo trato que recibiría en cualquiera de los dos casos, y las páginas que posicionaban bien antes de la caída no vuelven necesariamente a la misma posición una vez que el sitio está de nuevo arriba, lo que añade un segundo coste más lento encima de las horas realmente perdidas.

Un aviso breve y claro a los anunciantes no cuesta nada y evita un resultado peor que el propio ataque: un anunciante que ve errores intermitentes sin explicación tiende a pensar que el negocio ha fracasado en silencio y empieza a mirar a un competidor, mientras que el mismo anunciante, informado con claridad de que el sitio está bajo ataque, de que la facturación está en pausa durante la interrupción y de que el servicio volverá dentro de un plazo indicado, por lo general espera en vez de marcharse.

La versión útil de este artículo es la que se lee antes de que ocurra todo esto, no durante. Comprueba, hoy mismo, que cada registro DNS que apunta al sitio pasa por una CDN en vez de exponer la dirección de origen directamente. Comprueba que la mitigación DDoS de nivel básico de la CDN está realmente activada y no solo se da por supuesta, porque algunos proveedores la dejan desactivada por defecto en ciertos planes. Escribe, en un lugar que sobreviva a que el sitio principal se caiga, los contactos reales de soporte y abusos del host y de la CDN, con los números de cuenta al lado. Nada de esto es tan caro ni tan técnico como para necesitar un especialista. Solo tiene que ocurrir antes de que llegue la primera exigencia, porque no existe ninguna versión de este problema que se vuelva más fácil de resolver mientras ya está ocurriendo.