Suricata mostró cómo entrenar sistemas de detección de ataques basados en ML con tráfico real

Suricata mostró cómo entrenar sistemas de detección de ataques con ML en tráfico real

El IDS basado en firmas Suricata puede ser no solo una herramienta de detección, sino también una fuente de etiquetado para un modelo de ML de detección de ataques. Los autores del estudio probaron esta idea en tráfico corporativo real y encontraron un escenario viable, aunque no universal, para entrenar un ML IDS sin realizar ataques artificiales en el recurso protegido.

Cómo se configuró el experimento

El experimento se desplegó en el banco de pruebas de la empresa Ideco. Un servidor recibía tráfico corporativo real y lo pasaba a través de un NGFW con un Suricata IDS modificado y firmas actuales. Un segundo servidor analizaba el mismo flujo de tráfego con su propia utilidad session_analyzer, que recopilaba características para cada sesión de red.

Los autores deliberadamente no construyeron una infraestructura de laboratorio con ataques sintéticos: el objetivo era entender si un modelo podría entrenarse directamente en una red ya funcionando y con eventos reales de seguridad. La recopilación duró dos semanas—del 26 de junio al 10 de julio de 2025. Después del filtrado, permanecieron 55.

548.971 conexiones de red. De las 118 características originales, seleccionaron información de direcciones y 10 de las características de sesión más informativas, luego las compararon con las detecciones de Suricata y asignaron etiquetas de Benign o Attack.

El resultado fue un conjunto de datos binario donde el papel de "maestro" para el modelo fue desempeñado no por personas o etiquetado manual, sino por un IDS basado en firmas ya ajustado.

Dónde falla el esquema

El problema principal resultó no estar en la selección de algoritmo, sino en la calidad del etiquetado. El tiempo del evento en Suricata no coincide con el tiempo de inicio de la conexión de red: una detección puede referirse a un paquete que llega segundos después del inicio de la sesión, y para ataques lentos la brecha superaba 20 segundos. Adicionalmente, el mismo tráfego podía observarse tanto antes como después del gateway, lo que significa que un ataque correspondía a dos conexiones con información de dirección diferente. Si tales casos no se tienen en cuenta, el ruido entra en el conjunto de datos y el modelo comienza a aprender de ejemplos contradictorios.

• no todos los SIDs de Suricata son adecuados para etiquetado, especialmente reglas ligadas solo a IP, SNI o URLs específicas;
• para algunos ataques, incluyendo varios tipos de escaneo de puertos, el conjunto actual de características es simplemente insuficiente;
• la muestra de entrenamiento debe cubrir al menos una semana de tráfico real, incluyendo días laborales y fines de semana;
• el modelo debe reentrenarse cuando aparecen nuevos tipos de ataques, cambian las firmas, cambia la infraestructura de red o cambia el perfil de trabajo de los empleados.

De esto surgió el hallazgo clave sobre vectores "malos": si dos conexiones tienen características iguales o casi iguales pero etiquetas diferentes, la calidad de la clasificación cae drásticamente. Ni siquiera el gradient boosting fuerte como CatBoost ayuda en este caso. Algunos eventos de Suricata ayudan al modelo, mientras que otros solo agregan falsos positivos. Algunas firmas finalmente tienen más sentido excluir del etiquetado y devolver las conexiones correspondientes a la clase Benign, de lo contrario el ML IDS hereda errores de la capa de firmas subyacente.

Lo que mostraron los resultados

A pesar de todas las limitaciones, la hipótesis fue confirmada en general: un ML IDS de nivel de red puede construirse en una red ya operativa, utilizando eventos de Suricata como fuente de etiquetas. Esto es conveniente porque las reglas de firma bien ajustadas filtran de antemano una porción significativa de alertas ruidosas a las que los operadores no responderían de todos modos. En este modo, Suricata se convierte no solo en un sistema de detección sino también en un filtro de calidad para el conjunto de entrenamiento.

El mejor resultado práctico en el estudio fue una puntuación F1 de 0,98 con etiquetado correcto del conjunto de datos. Pero los autores honestamente señalan los límites del enfoque. Primero, resolvieron un problema de clasificación binaria, pero para un NGFW real esto es insuficiente: el negocio necesita entender qué clase exacta de ataque fue detectada y cómo responder a ella.

Segundo, el experimento se condujo en una red corporativa de usuario, no en un servicio específico protegido como un servidor web, por lo que transferir los hallazgos a otras redes requiere verificación separada.

Qué significa esto

El estudio muestra un camino práctico de la protección basada en firmas a un modelo de ML sin un polígono de prueba costoso y etiquetado manual de millones de sesiones. Pero también nos recuerda el punto principal: en ciberseguridad, la calidad del ML comienza no con la selección de algoritmo, sino con qué tan cuidadosamente conectas alertas reales, características de red y contexto de infraestructura.