BGP Blackhole vs BGP FlowSpec: cómo elegir el filtrado DDoS correcto

Definición del problema

RTBH anuncia una ruta especial para descartar todo el tráfico hacia una IP o prefijo. Es simple y compatible, pero el servicio queda fuera de línea.

FlowSpec transporta reglas de filtrado por BGP: protocolo, puertos, longitud de paquete, flags TCP, fragmentos y acciones. Su precisión es útil, pero una regla amplia puede romper usuarios reales de forma silenciosa.

La diferencia operativa aparece durante la saturación. Blackhole cambia la alcanzabilidad de un destino; FlowSpec cambia el tratamiento de ciertos paquetes dentro de la infraestructura de routing. Por eso una regla FlowSpec necesita un nivel de confianza: campos estables, campos normales para usuarios y una acción que pueda retirarse sin esperar una ventana de mantenimiento.

Para evaluar blackhole y FlowSpec, 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

Una mala elección de mitigación puede costar más que el ataque. Blackhole evita saturación, pero genera una caída total. FlowSpec mal definido puede parecer correcto en gráficas mientras clientes reales fallan.

En tránsito protegido el cliente paga por disponibilidad, no solo por supervivencia del backbone. La decisión debe basarse en pps, Gbps, puertos afectados, perfil de paquetes y estabilidad de la firma.

Un runbook útil define también quién puede propagar una regla upstream. Un drop local se prueba rápido; FlowSpec upstream afecta a un dominio mayor. Para redes que transportan tráfico de terceros, aprobación, registro y caducidad forman parte del producto.

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

RTBH manual sirve cuando un destino amenaza a otros clientes o supera la capacidad disponible. Es un freno de emergencia.

FlowSpec manual funciona con ataques estables y características claras, pero es lento cuando la firma cambia.

El modelo sólido usa automatización controlada: umbrales por puerto, reglas cortas, expiración, medición de tráfico legítimo y blackhole como último recurso.

A veces limitar tasa es más seguro que descartar. Si la firma del ataque se parece al tráfico legítimo, un policer temporal reduce presión mientras capturas y métricas confirman si una regla más estricta es segura.

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.

Elegir blackhole o FlowSpec sin cortar tráfico legítimo

Peeryx usa FlowSpec para reducir volumen upstream antes de saturar puertos, no para sustituir toda la protección DDoS.

Una regla correcta combina destino, protocolo, rangos de puertos, longitud observada y contexto de tráfico. Debe ser corta y reversible.

El tráfico limpio se entrega por GRE, IPIP, VXLAN, router VM o cross-connect, manteniendo un modelo de red comprensible.

Por eso Peeryx separa control de volumen bruto y decisiones cercanas al servicio. Las herramientas upstream reducen la inundación; la mitigación local conserva contexto para no convertir el DDoS en una caída provocada por el propio filtro.

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 servidor de juego recibe 80 Gbps UDP. Blackhole detiene la saturación pero desconecta a todos. Dropear todo UDP al puerto de juego casi igual de malo.

La respuesta correcta observa longitud, puertos origen, ratio pps/Gbps y fragmentos. Una regla combinada elimina ataque sin bloquear clientes reales.

La misma lógica aplica a floods TCP. Una regla sobre flags puede ayudar con patrones SYN o ACK anormales, pero debe compararse con el comportamiento normal de conexiones del servicio protegido.

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

Los errores aparecen cuando se actúa rápido sin evidencias suficientes.

Otro error es olvidar comunicación con el cliente. Si se usa blackhole, debe saber que se sacrifica alcanzabilidad; si se usa FlowSpec, debe saber que la regla es temporal y monitorizada.

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.

• Tratar FlowSpec como firewall aplicativo.
• Dejar reglas activas después del ataque.
• Filtrar por un solo campo.
• Blackholear un prefijo entero por una IP.
• No medir el tráfico legítimo antes y después.

FAQ