Route hijacking y DDoS: cómo un incidente BGP puede convertirse en caída

Definición del problema

Un origin hijack es un origen AS incorrecto para un prefijo.

Un more-specific o route leak puede atraer tráfico y romper el camino.

Lo peligroso de un hijack es que el servicio puede parecer sano internamente. Servidores y firewalls muestran CPU normal y ningún ataque, porque el tráfico ya fue desviado.

Para evaluar route hijacking y seguridad BGP, conviene separar tres planos: la señal BGP, el tráfico real y la experiencia de usuario. Si se mezclan, el equipo puede creer que la ruta está correcta porque la sesión está estable, mientras el tráfico útil toma un camino distinto o se pierde en un filtro demasiado amplio.

Por qué es importante

Muchos planes DDoS suponen que el tráfico llega a la mitigación.

Si falla el routing, los gráficos de scrubbing pueden no mostrar nada mientras usuarios están offline.

Un atacante no necesita sostener mucho tráfico si puede manipular alcanzabilidad. Un incidente corto de routing crea caída visible, confunde la respuesta y oculta el camino real.

El impacto financiero no aparece solo cuando todo cae. También existe en incidentes parciales: algunos operadores alcanzan el servicio, otros no; ciertos países ven más latencia; las sesiones de juego se cortan; el soporte recibe quejas difíciles de reproducir. Por eso la observabilidad externa debe acompañar la mitigación.

Para SEO y ventas, esta explicación también ayuda a filtrar buenos leads. Un cliente serio no busca solo una cifra de Tbps; quiere saber si el proveedor entiende routing, límites de handoff, falsos positivos y continuidad de servicio.

Cuando el comprador lee un artículo técnico en español, busca señales de seriedad: límites reconocidos, ejemplos concretos, integración posible y ausencia de promesas absolutas. Ese contenido también reduce preguntas repetitivas antes de una reunión comercial.

Soluciones posibles

Higiene de routing: IRR, AS-SET, prefix-limits y filtros.

RPKI/ROA limita orígenes inválidos cuando hay validación.

La monitorización externa detecta cambios de origen y more-specifics.

RPKI debe ir con monitorización. Un ROA válido no ayuda si nadie alerta sobre un origen competidor, y monitorizar sin contactos de escalada solo confirma la caída más rápido.

Una buena decisión técnica debe escribirse como procedimiento: señal que dispara la acción, métrica mínima necesaria, persona o sistema autorizado, duración máxima y condición de retirada. Sin estos límites, una herramienta útil puede convertirse en una fuente de riesgo operacional.

También hay que distinguir entre emergencia y diseño permanente. Una medida agresiva puede ser aceptable durante diez minutos para salvar capacidad, pero no debe convertirse en configuración estable sin revisión. El tráfico normal cambia según hora, país, juego, actualización cliente y comportamiento de usuarios.

El diseño debe tener criterios de aceptación: latencia esperada, pérdida máxima durante mitigación, capacidad de handoff, contactos de escalada y condiciones exactas para usar una medida disruptiva.

Detectar y contener route hijacking antes de la caída

Peeryx integra seguridad de routing en el tránsito protegido.

Antes de activar, ASN, AS-SET, límites y ROA deben estar claros.

Durante incidentes, el diagnóstico debe revisar también el plano BGP.

Peeryx integra seguridad de ruta en la activación. Propiedad del prefijo, AS-SET, objetos route y orígenes esperados se revisan antes de producción crítica.

La ventaja de un proveedor especializado es conectar esas decisiones con el transporte real: BGP, túneles, cross-connect, prefijos, límites de sesión y capacidad. La mitigación no puede estar aislada del camino que usan los paquetes antes y después de ser filtrados.

En Peeryx, el objetivo es que el cliente pueda explicar su arquitectura en una frase simple: dónde entra el tráfico, qué capa lo limpia, qué se filtra upstream, qué se decide localmente y cómo vuelve lo legítimo. Si esa frase no es clara, el diseño todavía no está listo.

En la práctica, Peeryx intenta convertir estos conceptos en decisiones simples: qué prefijo se protege, qué tráfico se espera, qué patrón se considera ataque y qué acción se toma en cada umbral.

Caso concreto o ejemplo

Un hoster anuncia un /24 vía mitigación, pero otro AS anuncia por error el mismo prefijo.

Con ROA, filtros y alertas se detecta más rápido.

El mismo proceso ayuda en cambios planificados. Al mover un prefijo a tránsito protegido, la visibilidad externa confirma que Internet ve el origen esperado.

Durante una prueba previa a producción, conviene simular cambios controlados: retirar una ruta, cambiar un túnel, medir latencia desde varios operadores, comprobar que los logs suben cuando el tráfico se desplaza. Esta preparación ahorra tiempo durante el ataque real.

Este nivel de detalle también facilita comparar proveedores. Dos ofertas pueden parecer iguales en precio, pero una puede incluir integración BGP clara, reglas documentadas y handoff suficiente, mientras la otra solo promete mitigación genérica.

Errores frecuentes

El error es separar seguridad BGP y DDoS.

Un error común es crear ROA con max-length demasiado amplio. Facilita operación, pero debilita protección contra anuncios más específicos no autorizados.

Finalmente, no hay que optimizar solo para el día de instalación. El diseño debe seguir siendo comprensible tres meses después, cuando se añade un cliente, otro prefijo, un segundo tránsito o un nuevo PoP. La documentación operacional es parte de la protección.

• ROA max-length demasiado amplio.
• IRR/AS-SET sin mantener.
• Sin prefix-limits.
• Monitorizar solo servidores.

FAQ