Dos palabras, dos comportamientos opuestos
Hay dos cosas que un proveedor puede hacer cuando llega una inundación de tráfico, y el sector vende ambas como "protección DDoS". La primera es la absorción: el tráfico se dirige a una capa de scrubbing situada antes de tu servidor, los paquetes de ataque se descartan ahí, los paquetes legítimos continúan, y tu servicio permanece accesible todo el tiempo. La segunda es el blackholing — también llamado null-routing, o RTBH según la RFC 5635 — donde tu dirección IP se retira de la tabla de enrutamiento de forma que nada llega a ella. La inundación deja de golpear el centro de datos. También dejan de llegar tus usuarios, tu monitorización y tu sesión SSH. El atacante obtiene exactamente el resultado por el que pagó.
Ambas son ingeniería real y ninguna es deshonesta en sus propios términos. El blackholing existe porque absorber una inundación grande cuesta dinero de verdad — el tránsito se factura por medición, la capacidad de scrubbing se compra y se aprovisiona — y un proveedor económico que aplica null-route a un cliente para mantener a otros cuatrocientos en línea está tomando una decisión defendible. El truco está en el pronombre. "Protección DDoS" es cierto en ambos casos; lo que cambia es de quién es el servicio que se protege. Lee cada ficha de plan con esa pregunta presente.
| Respuesta | Tráfico de ataque | Tu servicio | Descrito habitualmente como |
|---|---|---|---|
| Scrubbing / absorción | Filtrado antes de llegar, descartado en el borde | Sigue activo, normalmente sin cambio visible | "Mitigación siempre activa", "scrubbing anycast" |
| Blackhole / null-route | Descartado junto con tu tráfico legítimo | Fuera de línea mientras dura — normalmente 1–24 h | "Protección hasta X Gbps", "suspensión temporal de IP" |
| Solo límite de tasa en el borde | Descartado parcialmente, en parte al azar | Degradado — los usuarios reales ven pérdida de paquetes | "Protección básica incluida" |
| Nada (decide el operador) | Llega al rack hasta que un proveedor upstream aplica blackhole al prefijo | Fuera de línea, igual que tus vecinos de rack | "Protección DDoS disponible" |
Leer la letra pequeña antes de pagar
El vocabulario lo delata. "Protección hasta 10 Gbps" es un techo, y la frase que viene justo después — la que habla del tráfico que supera el límite — es la cláusula de null-route. "IP protegida disponible como complemento" significa que la dirección que obtienes por defecto no está protegida. "Por incidente" significa que la factura llega después que el ataque. "Uso razonable" aplicado a la mitigación significa una cuota de ataques al mes, tras la cual te las arreglas solo. Ninguna de estas frases es mentira; simplemente están escritas para pasarse por alto en una lectura rápida.
Un ejemplo concreto y publicado, porque es política documentada y no un rumor: BuyVM vende direcciones filtradas contra DDoS como complemento separado a $3/mes por IP, y las direcciones sin filtrar reciben null-route mientras dura un ataque. Lo describimos sin mucho editorializar en nuestra página de comparación de BuyVM, porque una IP barata sin filtrar es un producto perfectamente razonable cuando sabes que es eso lo que has comprado. El modo de fallo es descubrirlo a las 3:00 con un booter en marcha.
Cuatro preguntas que merece la pena enviar a preventa antes de la primera factura. ¿Cuál es la capacidad de mitigación, y esa cifra es el agregado o la disponible en un único punto de presencia? Una "red de 2 Tbps" que termina en un único centro de scrubbing tiene una sola tubería que llenar. ¿La mitigación está incluida en este plan o es un complemento? ¿Hay un cargo por incidente o una cuota mensual de eventos mitigados? ¿A partir de qué umbral aplican null-route, y durante cuánto tiempo? Un proveedor que responde a esta última con una cifra vale más que uno que responde con adjetivos.
Las tres capas, y por qué la capa decide quién puede solucionarlo
Volumétrico de Layer 3/4. Inundaciones SYN, inundaciones UDP, y reflexión o amplificación a través de servicios NTP, DNS, memcached, CLDAP y SSDP abiertos. El atacante gasta un poco de ancho de banda upstream y recibe de vuelta un múltiplo de ese ancho de banda dirigido contra ti. Es un problema de ancho de banda y de paquetes por segundo (pps), y es categóricamente irresoluble en tu propio servidor: para cuando tu kernel pudiera descartar el paquete, la tubería que lo transporta ya está llena. Nada en nftables te salva aquí. Solo la capacidad por encima de ti lo hace.
Agotamiento de estado en Layer 4. Inundaciones de SYN, ACK y de conexiones dimensionadas no para llenar la tubería, sino para llenar una tabla — el backlog de SYN del kernel, la tabla conntrack, la cola de aceptación de tu aplicación. El ancho de banda puede ser trivial: unos pocos cientos de Mbps tumban un servidor sin ajustar mientras la gráfica del lado del proveedor parece una tarde tranquila. Esta capa es genuinamente medio tuya: es sobrevivible con tcp_syncookies, un nf_conntrack_max bien dimensionado, y límites por origen, y no es sobrevivible sin ellos.
Aplicación en Layer 7. Inundaciones HTTP compuestas por solicitudes individualmente válidas — handshakes TLS reales, cadenas de User-Agent creíbles, a veces navegadores reales — dirigidas a lo que en tu sitio sea costoso: búsqueda, inicio de sesión, carrito, una página de listado respaldada por base de datos. La clase HTTP/2 Rapid Reset demostró qué pocos megabits hacen falta cuando cada solicitud cuesta al servidor más de lo que cuesta al cliente. Un dispositivo de scrubbing no puede ver dentro de una sesión TLS que no termina, así que esta capa se gestiona con reglas en el borde o con tu propio reverse proxy — nunca con pura capacidad volumétrica.
| Layer | Ataque típico | Tamaño típico | Dónde debe detenerse | ¿Se puede solucionar en tu servidor? |
|---|---|---|---|---|
| Volumétrico L3/L4 | Inundación UDP, amplificación DNS/NTP/memcached | 5 Gbps – 1+ Tbps | Upstream, en el borde | No — la tubería se llena primero |
| Agotamiento de estado L4 | Inundación SYN / ACK, agotamiento de conntrack | 0.1 – 10 Gbps | Borde, más ajuste de kernel | Parcialmente — syncookies, dimensionado de conntrack |
| Aplicación L7 | Inundación de solicitudes HTTP(S), slow POST, Rapid Reset | A menudo por debajo de 1 Gbps | Reglas en el borde o tu reverse proxy | Sí — límite de tasa, challenge, caché |
¿Qué tamaño tiene un ataque real, honestamente?
Aproximadamente nueve de cada diez ataques que caen sobre un pequeño servidor offshore proceden de un booter o stresser — un servicio por suscripción que cuesta entre $10 y $30 al mes y revende capacidad de amplificación por minuto. Entregan algo entre 5 y 50 Gbps en ráfagas de pocos minutos, y son a lo que realmente se enfrentan un servidor de Minecraft, una red de IRC, un repetidor de Tor, un foro con un ex-moderador enfadado o un lobby de juego competitivo. Esta banda es totalmente sobrevivible y también es totalmente suficiente para tumbar un VPS de $5 sin proteger.
La siguiente banda — de 100 a 400 Gbps procedentes de una botnet alquilada — es lo que llega cuando alguien tiene un rencor concreto y presupuesto. Es rara contra objetivos pequeños y habitual contra propiedades de apuestas, streaming y contenido para adultos. Por encima de eso están los eventos de categoría récord reportados por los grandes proveedores de mitigación, ahora medidos en múltiples terabits por segundo y cientos de millones de solicitudes por segundo; las cifras trimestrales de Cloudflare Radar son la referencia pública habitual. Casi con toda seguridad tú no eres el objetivo previsto de ninguno de esos.
Aun así puedes convertirte en una víctima colateral, y esta es la parte que nadie pone en la ficha del plan: el daño colateral viaja por prefijo. Si un proveedor aplica blackhole con granularidad /24 — muchos lo hacen, porque es el prefijo más pequeño que la mayoría de los carriers acepta para RTBH — entonces un ataque dirigido a una sola dirección de tu subred tumba todas las direcciones que contiene. Tu uptime depende de los enemigos de un desconocido. El margen de capacidad es lo que evita que esa decisión llegue a tomarse.
Nuestras propias cifras, para calibrar y no para presumir: 1 Tbps de scrubbing anycast L3/L4 repartido en cuatro puntos de presencia, cada uno capaz de absorber unos 300 Gbps por sí solo, con detección automática en menos de dos segundos. El mayor evento que hemos absorbido para un cliente superó los 600 Gbps contra un servidor de juego, y las conexiones de los jugadores no se cayeron. La arquitectura está documentada con más detalle en la página de red.
Incluido, por incidente o por cuota — el modelo comercial importa
Hay tres formas de vender la mitigación y producen facturas muy distintas. Incluida: el coste está integrado en el precio del plan y un ataque no cambia nada de lo que pagas. Por incidente: se te cobra por cada evento mitigado, a veces por hora de mitigación. Por cuota: un número de eventos al mes, o una cláusula de "uso razonable" que deja al proveedor decidir cuándo has tenido suficiente.
El modelo por incidente no es una estafa. El tráfico sometido a scrubbing sigue cruzando el tránsito del proveedor antes de descartarse, y el tránsito se factura al percentil 95 o contra una tarifa comprometida — una campaña sostenida contra un cliente es una partida real en la factura de alguien. El problema no es la equidad, es la previsibilidad: bajo una campaña de dos semanas, un proveedor que cobra por incidente convierte un ataque contra ti en una factura para ti, lo cual es un segundo ataque con pasos adicionales. Pregunta qué modelo se aplica antes de necesitarlo.
Nuestra posición, expuesta con claridad para que pueda comprobarse: el escudo está activo por defecto en todos los planes, desde el Starter de $8.50 hasta el Citadel de $299.50, sin necesidad de activarlo, sin cargo por incidente, sin cuota mensual y sin cláusula de "uso razonable" ligada a la mitigación. Es el mismo tejido tanto en el VPS más barato como en el servidor dedicado más grande — consulta los planes VPS y los niveles dedicados. Lo que escala con el nivel es el uplink y el conjunto opcional de reglas de Layer 7, no si estás defendido o no.
Difusión anycast, y por qué el tiempo de detección gana a la capacidad de titular
Un único centro de scrubbing tiene un techo duro: el tránsito que entra en ese único edificio. También tiene un coste de latencia, porque durante la mitigación el tráfico de todos se desvía primero hacia ese edificio — la razón por la que algunos proveedores se vuelven visiblemente más lentos para los usuarios europeos en cuanto empieza un ataque, y siguen así hasta que termina.
Anycast cambia la aritmética antes de que intervenga ningún hardware. El mismo prefijo se anuncia desde todos los puntos de presencia, así que una botnet distribuida globalmente se reparte entre esos puntos solo por la topología de internet: un ataque de 600 Gbps originado por todas partes llega como unos 150 Gbps en cuatro lugares en lugar de 600 Gbps en uno. La difusión hace la mayor parte del trabajo; el equipo de scrubbing solo tiene que gestionar lo que queda después de que la geografía ya lo haya dividido.
El tiempo de detección es la cifra infravalorada. Una mitigación que se activa en dos segundos es invisible para una sesión TCP; una mitigación que se activa en sesenta segundos llega después de que tus usuarios hayan recargado dos veces y se hayan ido, y después de que un lobby de juego se haya vaciado. Cuando un proveedor cita la capacidad pero no la latencia de detección, pide esa segunda cifra — es la que decide si tus usuarios llegaron a notarlo.
Si aportas tu propio prefijo, el blackholing se convierte en un bisturí que empuñas tú, en lugar de algo que te hacen a ti. Nuestras comunidades BGP cubren la depreferencia por carrier (cs:100:carrier), el prepend regional (cs:200:region) y el blackhole selectivo (cs:666:prefix), así que puedes aplicar null-route a una sola dirección bajo ataque mientras el resto de tu asignación sigue sirviendo. Así se usa el blackholing correctamente: quirúrgico, breve, y decisión tuya.
La complicación offshore: un proxy estadounidense delante anula el propósito
El consejo estándar en todos los foros es "ponlo detrás de Cloudflare, el nivel gratuito ya vale". Para un sitio corriente es un buen consejo. Si elegiste un proveedor offshore por razones jurisdiccionales, esto reimporta silenciosamente todo lo que dejaste atrás: una empresa constituida en EE. UU. ahora termina tu TLS y ve tu texto en claro, recibe quejas de abuso y de derechos de autor y actúa sobre ellas según su propia política, mantiene una cuenta vinculada a una dirección de correo y normalmente a un método de pago, y puede recibir notificación de un proceso legal estadounidense. Que tu proveedor ignore un aviso DMCA vale muy poco cuando tu CDN lo respeta — la mecánica está en la explicación del DMCA-ignored y la exposición jurisdiccional en la guía de los 14 Eyes.
Un proxy tampoco oculta tu origen a menos que restrinjas por firewall el origen a los prefijos del proxy y lo mantengas así. Incluso entonces la dirección se filtra a través del historial de DNS pasivo, de los registros de transparencia de certificados si el origen alguna vez respondió TLS con su propio nombre, del correo enviado directamente desde el servidor, de un registro A antiguo que nunca se eliminó, y de cualquier página de error que refleje el propio hostname del servidor. Los accesos directos al origen son cómo terminan cayendo los sitios "protegidos" de todos modos. La guía de hosting anónimo recorre toda la superficie de fuga.
Si quieres una capa de proxy sin el coste jurisdiccional, gestiónala tú mismo: una segunda instancia pequeña en la misma jurisdicción o en una compatible, terminando el TLS con tu propia clave, con el firewall del origen sin aceptar nada más que esa dirección. Conservas el caching y el filtrado de solicitudes, y ningún tercero se suma a la cadena de confianza. Ambas máquinas están detrás del mismo tejido de scrubbing, así que el proxy no es un nuevo objetivo débil.
Lo que sigue siendo trabajo tuyo, en el servidor
El scrubbing upstream protege la tubería. No ajusta tu kernel, y la banda de agotamiento de estado es donde un servidor sin ajustar muere ante un ataque que la red apenas registró. La lista corta, en el orden en que rinde más: activa net.ipv4.tcp_syncookies y aumenta net.ipv4.tcp_max_syn_backlog (los parámetros están documentados en la referencia ip-sysctl del kernel); dimensiona nf_conntrack_max al número de conexiones que realmente esperas, o usa notrack para tráfico UDP de juego de alta tasa para que la tabla nunca se consulte; añade límites de tasa por origen en nftables en lugar de confiar en que el borde sea quirúrgico.
En el lado de la aplicación, limit_req y limit_conn en nginx no cuestan nada y detienen la mayoría de las inundaciones L7 que no están deliberadamente diseñadas para parecer humanas. Cachea todo lo que se pueda cachear, porque el mejor objetivo de un atacante siempre es esa única página que generas desde la base de datos en cada solicitud. Mantén SSH y cualquier panel de control fuera de la dirección que sirve la carga pública, o detrás de una allowlist.
Una dirección que la gente olvida: no te conviertas en un reflector. Un resolutor DNS abierto, un demonio NTP sin configurar o un memcached expuesto en tu servidor te convierte en parte del ataque de amplificación de otra persona, y el abuso saliente se trata con mucha más severidad que el entrante — el tiempo de respuesta publicado en nuestra AUP es null-route y suspensión en menos de dos horas. Las inundaciones entrantes son algo que te pasa a ti; las inundaciones salientes son algo de lo que eres responsable.
La lista de verificación que conviene repasar antes de comprar
Nueve preguntas, en el orden que separa a los proveedores más rápido. ¿Cuál es la capacidad de mitigación, y es por punto de presencia o agregada? ¿Está incluida en el precio del plan o se vende por IP? ¿Hay un cargo por incidente, o una cuota de eventos mitigados al mes? ¿Cuál es la latencia de detección? ¿Existe siquiera filtrado Layer 7, y en qué niveles? ¿A partir de qué umbral y durante cuánto tiempo aplican null-route, y se te avisa cuando ocurre? ¿La mitigación cambia mi enrutamiento o mi latencia mientras está activa? ¿La protección está en la dirección que obtengo por defecto? Y — la que casi nadie hace — ¿qué se conserva sobre mi tráfico mientras la mitigación está en marcha?
Esa última pregunta importa más en este mercado que en cualquier otro. El scrubbing significa que algo upstream está mirando tus paquetes. Pregunta qué sobrevive al evento. Nuestra respuesta, y no cambia durante un ataque: la detección se basa en contadores agregados en el borde — paquetes y bits por segundo, por prefijo — no en registros por flujo conservados, y la postura permanente de ningún netflow, ningún PCAP y ningún espejado de NIC publicada en la política de privacidad se aplica durante la mitigación exactamente igual que el resto del tiempo. Un proveedor que no pueda responder a esto te está diciendo algo.
Si las respuestas resultan pobres, el recurso es barato: compra un mes del plan más pequeño, apunta una sonda de monitorización hacia él, y pregunta directamente a soporte qué pasa cuando el servidor recibe un golpe. Aquí no hay contrato ni cuota de configuración, así que un proveedor que esquiva la pregunta por escrito te cuesta $8.50 averiguarlo. Despliega un Starter, o lee VPS frente a dedicado si la carga de trabajo es lo bastante grande como para que la respuesta cambie el nivel.
