ML IDS con Suricata: entrenamiento de modelos para ciberseguridad

IDS ML de Próxima Generación: Cómo Suricata Entrena Modelos para una Detección de Intrusiones Eficaz

Los Sistemas de Detección de Intrusiones (IDS) modernos luchan por identificar ciberataques nuevos y modificados debido a su dependencia del análisis basado en firmas. El avance del aprendizaje automático (ML) ofrece una solución prometedora, pero la implementación de IDS ML en redes reales presenta desafíos, particularmente en lo que respecta a la generación de datos etiquetados. Este artículo explora un enfoque innovador para construir IDS ML aprovechando los datos de eventos de seguridad registrados por Suricata para entrenar modelos y mejorar la eficacia de la defensa.

La Evolución de los Sistemas de Detección de Intrusiones: De las Firmas a la Inteligencia

El arsenal de herramientas de seguridad de la información contra los ciberataques incluye firewalls, Sistemas de Detección de Intrusiones (IDS) basados en red y en host, Firewalls de Próxima Generación (NGFW) y sistemas de Gestión de Información y Eventos de Seguridad (SIEM). A pesar de su variedad, la mayoría se basa en el análisis de firmas, que identifica eficazmente las amenazas conocidas pero resulta ineficaz contra ataques nuevos o modificados. Esta debilidad fundamental subraya la urgencia de desarrollar IDS ML capaces de una detección heurística o inteligente.

La tarea de construir IDS ML a nivel de red se aborda típicamente de dos maneras principales:

• Clasificación del Tráfico de Red: Dividir el tráfico en “limpio” y “ataque” (posiblemente con subcategorías de ataque). Esto requiere un conjunto de datos etiquetados, lo cual es un desafío en escenarios del mundo real debido a restricciones éticas, infraestructurales y metodológicas. Crear modelos precisos de recursos protegidos o recopilar datos de ataques sin comprometer la infraestructura en vivo presenta un obstáculo significativo.
• Detección de Anomalías: Identificar conexiones o paquetes de red anómalos cuando solo se conoce el tráfico “limpio”. Este enfoque es menos exigente en cuanto a datos etiquetados, pero puede resultar en una mayor tasa de falsos positivos.

La investigación existente a menudo demuestra una alta precisión para los IDS ML en entornos de laboratorio, donde los modelos se entrenan y prueban en condiciones controladas. Sin embargo, cuando estos modelos se implementan en redes reales, se observa una caída significativa en el rendimiento. Esto se debe a que los vectores de características utilizados para el entrenamiento a menudo dependen en gran medida de la estructura física de la red, las configuraciones de hardware y las especificidades de los servicios de red donde se recopilaron los datos. Las discrepancias en estos parámetros entre los entornos de prueba y producción conducen a errores de clasificación y a una reducción en la precisión general del modelo.

Hipótesis y Metodología: Suricata como Fuente de Conocimiento

Reconociendo estas limitaciones, los autores del artículo se propusieron determinar si se podría construir un IDS ML eficaz en una red ya operativa utilizando datos que no requieran ataques deliberados al recurso. La hipótesis central es la viabilidad de utilizar eventos de seguridad registrados por sistemas de detección de intrusiones tradicionales, como Suricata, para el etiquetado de conjuntos de datos. Este enfoque evita los desafíos de generar datos etiquetados y puede mejorar potencialmente la adaptabilidad de los IDS ML a las condiciones del mundo real.

Para implementar esta hipótesis, se desarrolló una herramienta propietaria llamada session_analyzer. Esta herramienta está diseñada para calcular los valores de los vectores de características para el tráfico de red de cada conexión de red. Es importante señalar que session_analyzer es análogo al popular CICFlowMeter (anteriormente NTLFlowLyzer) pero adaptado para tareas de investigación específicas. Inicialmente, se centra en el protocolo TCP, pero su arquitectura permite extender el análisis a otros protocolos.

Principios de Generación de Vectores de Características en session_analyzer

session_analyzer aplica reglas estrictas para analizar el tráfico de red y extraer características significativas, que luego se utilizan para entrenar modelos de aprendizaje automático. Estos principios aseguran la consistencia y relevancia de los datos generados.

• Filtrado de Protocolos: Solo se analizan los paquetes de los protocolos Ethernet II, MPLS, VLAN, IPv4, TCP, UDP e ICMPv4. Todos los demás protocolos de capa de enlace, red y transporte se ignoran.
• Identificación de Sesiones de Red (Flow ID): Cada sesión se identifica de forma única utilizando una secuencia de 5 componentes (5-Tupla): IP de Destino - IP de Origen - Puerto de Destino - Puerto de Origen - Protocolo.
• Definición de Sesión de Red: Una sesión se define como una secuencia de paquetes que pertenecen a una única conexión TCP, flujo UDP o flujo ICMP. La pertenencia de un paquete a una sesión se establece haciendo coincidir la información de dirección de la 5-Tupla (ya sea en dirección directa o inversa).
• Criterio de Inicio de Sesión TCP: Una sesión TCP se registra solo con el primer paquete con los flags SYN=1 y ACK=0. Este paquete también determina la dirección de transferencia de datos (cliente-servidor).
• Criterio de Inicio de Sesión UDP/ICMP: Se registra al aparecer el primer paquete con un nuevo identificador. Potencial de error en la determinación de la dirección, por ejemplo, con la primera respuesta DNS observada.
• Criterio de Fin de Sesión de Red (Timeout): Se proporciona un tiempo de espera (timeout) desde el último paquete recibido para todos los tipos de sesión. Valores predeterminados configurables: tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
• Criterio de Fin de Sesión TCP (Flags de Terminación): Se monitorean adicionalmente los paquetes RST o FIN. Al recibir un RST, la sesión se considera cerrada. Al recibir un FIN, se inicia un mecanismo para rastrear los acuses de recibo (ACK) de ambos lados.
• Flujo de Paquetes de Red (Flow): Una secuencia estricta de paquetes dentro de una única sesión, independientemente de la dirección.
• Flujo de Paquetes de Avance (Fwd): Una secuencia estricta de paquetes de cliente a servidor dentro de una sesión.
• Flujo de Paquetes de Retroceso (Bwd): Una secuencia estricta de paquetes de servidor a cliente dentro de una sesión.
• Duración de la Sesión de Red: Se puede calcular de dos maneras: desde el primer hasta el último paquete de la sesión, o desde el primer hasta el último paquete con datos de carga útil (payload > 0). El parámetro is_need_calc_duration_by_last_payload controla esto.
• Flujo de Sesiones de Red (Stream): Un conjunto de sesiones entre una única IP de Origen y un servicio de red especificado (IP de Destino | Puerto de Destino | Protocolo). El stream_id se forma concatenando estos cuatro componentes. Las características con el prefijo "Stream" caracterizan las sesiones paralelas, sus tiempos de creación e intervalos entre ellas.
• Sesiones "Independientes" en un Flujo: Las sesiones se consideran independientes si el tiempo entre su creación excede session_simple_timeout (predeterminado 60000000 microsegundos).
• Intervalos de Tiempo Entre Sesiones en un Flujo:

* session_time_prev_absent: El intervalo entre la sesión actual y la anterior. Si la sesión actual es la primera o el intervalo excede el umbral, se establece el valor session_time_prev_absent (predeterminado 60000000 microsegundos).

* session_time_next_absent: El intervalo entre la sesión actual y la siguiente. Si la sesión actual es la última o el intervalo excede el umbral, se establece el valor session_time_next_absent (predeterminado 60000000 microsegundos).

Estas reglas detalladas permiten a session_analyzer generar un rico conjunto de características que pueden utilizarse para entrenar modelos de ML. El uso de Suricata para el etiquetado permite asociar estas características con amenazas detectadas específicas, creando conjuntos de datos etiquetados sin la necesidad de ataques reales. Esto allana el camino para construir IDS ML más adaptables y precisos, capaces de operar eficazmente en las condiciones dinámicas y únicas de las infraestructuras de red del mundo real.

Ventajas y Limitaciones del Enfoque

El uso de Suricata para el etiquetado de datos ofrece varias ventajas clave:

• Realismo de los Datos: El entrenamiento se realiza con tráfico real e incidentes reales registrados por Suricata, lo que mejora la relevancia del modelo.
• Eficiencia de Recursos: Elimina la necesidad de costosos bancos de pruebas para simular ataques o realizar ataques en sistemas de producción.
• Adaptabilidad: El modelo se entrena con datos de una red específica, lo que le permite adaptarse mejor a las características únicas del tráfico y del equipo.

Sin embargo, también existen limitaciones. La calidad del etiquetado depende directamente de la eficacia de Suricata y de la actualidad de sus firmas. Si Suricata no detecta un nuevo ataque, ese ataque no será etiquetado en el conjunto de datos, y el modelo de ML no aprenderá a identificarlo. Además, el propio proceso de generación de características por session_analyzer puede consumir muchos recursos. No obstante, este enfoque representa un avance significativo para abordar el desafío de crear IDS ML fiables y adaptables para entornos de producción reales.

Puntos Clave

• Los IDS tradicionales son vulnerables a ataques nuevos y modificados debido a su enfoque basado en firmas.
• Los IDS ML son prometedores, pero requieren datos etiquetados, difíciles de obtener en escenarios reales.
• Aprovechar los eventos de Suricata para el etiquetado de conjuntos de datos permite entrenar IDS ML con tráfico real sin realizar ataques.
• La herramienta session_analyzer genera vectores de características detallados para sesiones de red basándose en 14 principios.
• Este enfoque mejora la adaptabilidad de los IDS ML a las características únicas de las redes reales, pero depende de la calidad de las detecciones de Suricata.

— Editorial Team