Una guía práctica con las principales medidas que todo proveedor de internet debe adoptar para resistir y recuperarse rápidamente de ataques DDoS.
Los ataques DDoS son una realidad constante para los proveedores de internet. La buena noticia es que gran parte del impacto puede reducirse o eliminarse con prácticas de ingeniería aplicadas antes de que ocurra el ataque. Este artículo reúne las principales medidas que un ISP debe adoptar para aumentar su resiliencia.
El IPv6 raramente es objetivo de ataques DDoS volumétricos. La gran mayoría de las botnets y herramientas de ataque todavía operan exclusivamente sobre IPv4, pues es donde se concentran los servicios y las direcciones expuestas. Al migrar suscriptores, servidores DNS e interfaces de gestión a IPv6, el proveedor reduce sustancialmente su superficie de ataque.
Otro beneficio directo es la reducción de costos en servicios de mitigación en la nube, que generalmente cobran por el volumen de tráfico IPv4 limpio entregado. Menos IPv4 expuesto significa menos tráfico de ataque a procesar — y una factura menor a fin de mes.
El DNS es uno de los principales vectores de amplificación y un objetivo directo de ataques. Dos recursos combinados aumentan mucho la resiliencia: el hyperlocal y el anycast.
El hyperlocal consiste en mantener una copia local de la zona raíz de internet dentro del propio servidor de resolución recursiva del ISP. Con ello, incluso si los root servers están inaccesibles durante un ataque — o si el enlace del proveedor está saturado —, el DNS interno continúa resolviendo normalmente para los suscriptores.
El anycast distribuye la misma dirección IP de DNS entre múltiples servidores en distintas localidades. Cuando llega un ataque volumétrico, se diluye entre los puntos de presencia en lugar de concentrarse en un único servidor, haciendo mucho más difícil derribarlo.
Los bucles de ruta estática son un multiplicador silencioso de daño. Cuando un ataque dirige tráfico hacia un prefijo que tiene un bucle, el router procesa el mismo paquete repetidamente, consumiendo CPU y ancho de banda simultáneamente en la subida y en la bajada. El impacto final es desproporcionado al volumen del ataque.
Muchos proveedores solo descubren que tienen bucles durante un ataque real, cuando ya es tarde. Lo correcto es realizar una auditoría preventiva de todas las rutas estáticas, asegurándose de que no exista dependencia circular entre next-hops y que las rutas de resumen apunten a descarte (blackhole) y no a interfaces dinámicas.
Un bucle de enrutamiento durante un ataque DDoS puede derribar enlaces que normalmente soportarían bien el tráfico. Corrígelo antes de que un ataque exponga el problema.
MikroTik es ampliamente utilizado en ISPs por su excelente relación costo-beneficio. Sin embargo, a diferencia de equipos con ASICs dedicados al forwarding, RouterOS procesa el tráfico a través de la CPU del equipo. Esto crea un punto de vulnerabilidad específico durante ataques volumétricos.
El error más común es crear reglas de firewall para descartar el tráfico de ataque directamente en el MikroTik. El problema es que, aunque sea descartado, cada paquete aún necesita ser recibido y procesado por la CPU antes del drop — lo que puede bloquear el equipo por completo. La solución más eficaz es retirar el tráfico malicioso antes de que llegue al MikroTik, usando blackhole en el uplink o FlowSpec.
Los enlaces punto a punto entre routers con direcciones IPv4 públicas son objetivos fáciles y frecuentemente ignorados. Un ataque dirigido específicamente a la IP de una interfaz puede sobrecargar el plano de control del router, derribando todo el tráfico que pasa por él — aunque el enlace en sí tenga capacidad para absorber el ataque.
La solución es simple: usa direcciones privadas (RFC 1918) en los enlaces internos. Para enlaces con peers y upstreams, muchos operadores ya aceptan negociar la interconexión en espacio privado. Lo que no tiene dirección pública no puede ser atacado directamente.
Detectar un ataque DDoS manualmente y reaccionar a él es demasiado lento. Herramientas como Wanguard y FastNetMon analizan el NetFlow y el sFlow de la red en tiempo real, identifican anomalías de tráfico y disparan contramedidas automáticamente — todo en cuestión de segundos.
Sin automatización, el proceso de identificar el ataque, localizar el prefijo afectado, contactar al uplink y configurar el blackhole puede llevar minutos o incluso horas. Con un sistema automatizado, este ciclo completo ocurre antes de que la mayoría de los suscriptores perciba cualquier degradación.
FastNetMon tiene una versión open-source funcional que puede ser la puerta de entrada para la automatización de mitigación sin costo inicial. Para entornos más grandes, Wanguard ofrece reportes, integración con múltiples uplinks y scrubbing centers.
Las BGP communities son el principal mecanismo para solicitar acciones a tu upstream durante un ataque. La más importante es la community de blackhole: al anunciar un prefijo con ella, el uplink descarta todo el tráfico destinado a esa IP antes de reenviártelo. El ataque es bloqueado en el borde del uplink, no en tu red.
Al contratar o evaluar un uplink, pregunta qué communities están disponibles. Los mejores ofrecen blackhole por AS de origen, por región geográfica y por tipo de protocolo — lo que permite una mitigación quirúrgica, bloqueando solo el tráfico malicioso sin afectar el legítimo.
Los túneles GRE son muy utilizados para reenviar tráfico limpio desde scrubbing centers de vuelta al ISP. El problema es que el encapsulamiento GRE añade overhead al paquete, y sin el ajuste correcto del TCP MSS (Maximum Segment Size), los paquetes TCP terminan siendo fragmentados. La fragmentación excesiva provoca retransmisiones, aumenta la latencia y degrada la experiencia del usuario — justo cuando la red ya está bajo presión.
Además del ajuste del MSS, una buena práctica es usar GRE sobre IPv6 siempre que sea posible, ya que reduce el riesgo de que la propia dirección del túnel se convierta en objetivo de un ataque.
Una herramienta de mitigación que nunca ha sido probada en producción tiene grandes posibilidades de fallar en el momento en que más importa. Sistemas mal configurados, integraciones rotas o umbrales incorrectos solo aparecen cuando ocurre un ataque real.
Programa pruebas periódicas fuera del horario pico: valida si la detección automática está funcionando, si el blackhole se activa dentro del tiempo esperado y si los contactos y runbooks del equipo NOC están actualizados. Descubrir un fallo durante una prueba controlada es mucho mejor que descubrirlo a las 3 de la madrugada durante un ataque.
Documenta un runbook de respuesta a ataques: quién activa qué, en qué orden, con qué contactos del uplink. Sin eso, cada ataque se convierte en una improvisación.
Las prácticas anteriores cubren bien las necesidades de la mayoría de los proveedores. Pero existen capas adicionales de protección que pocos ISPs implementan completamente y que marcan una diferencia significativa:
Si tienes que elegir un punto de partida, comienza por el RPKI. Es gratuito, mejora la seguridad del enrutamiento de internet en general y puede habilitarse en cualquier router moderno en menos de una hora.