En esta página
El problema operativo
Los flags TCP parecen muy expresivos, pero FlowSpec no mantiene el estado de la conexión. Un SYN abre una conexión, un ACK suele pertenecer a una sesión establecida y un RST puede cerrar o recuperar una sesión, pero vistos aisladamente no prueban legitimidad.
Con rutas asimétricas, el problema aumenta. La regla upstream no ve necesariamente el handshake completo, el retorno, NAT o balanceadores. Un filtro ACK o RST demasiado amplio puede cortar tráfico real.
Por qué importa antes del ataque
Los floods TCP pueden agotar backlog SYN, tablas de conexión o recursos de aplicación incluso sin llenar todo el ancho de banda. Los flags ayudan a retirar patrones obvios antes de que lleguen al cliente.
Pero los falsos positivos en TCP son caros: sesiones congeladas, recursos que no cargan, APIs intermitentes. Por eso los flags deben usarse con destino, puerto, tasa y duración definidos.
Enfoques técnicos posibles
Para SYN flood, una regla estrecha hacia un host o puerto atacado puede ser útil, especialmente si hay validación downstream. Para ACK flood, la prudencia debe ser mayor porque puede existir tráfico establecido legítimo.
La solución sólida combina FlowSpec para alivio upstream y filtros con estado o proxy para validar contexto. Ningún flag aislado debe convertirse en política permanente.
Checklist operativo antes de ponerlo en producción
- Revisar la regla de BGP FlowSpec TCP flags cuando el ataque cambia de forma.
Coincidir con SYN no demuestra un ataque
Una API en TCP 443 recibe un SYN flood. Una regla que descarta todos los SYN hacia ese destino también descarta conexiones legítimas. Limitar el destino no hace que la regla sea segura para los usuarios del servicio.
Antes de descartar, identifique un criterio adicional que distinga los paquetes no deseados de las aperturas válidas y compruébelo con tráfico legítimo representativo. Si el router no puede distinguirlos, utilice una validación TCP adecuada en una capa posterior. Un policer limita todo el tráfico coincidente; el ataque también puede consumir ese cupo.
Especifique criterios y acción, verifique cómo interpreta el router receptor la máscara de flags TCP y observe conexiones nuevas y sesiones establecidas. Defina la retirada de la regla y el responsable de su caducidad. FlowSpec no demuestra por sí mismo que un paquete pertenezca a una sesión TCP válida.
