Reglas de firmas con Snort y Suricata

Snort y Suricata son los dos principales motores IDS/IPS de código abierto. Comparten un lenguaje de reglas prácticamente compatible, por lo que una regla escrita para uno suele ejecutarse en el otro.

Suricata añade multihilo, analizadores nativos de protocolos, extracción de archivos y registros detallados (EVE JSON); Snort 3 modernizó su propio motor de forma similar. Aprender la sintaxis de las reglas una sola vez le permite aprovechar ambos.

Cada regla tiene dos partes: un encabezado y un cuerpo de opciones entre paréntesis. El encabezado establece la acción, el protocolo y la dirección del tráfico; el cuerpo define qué debe coincidir y cómo informar del resultado.

El encabezado se lee de izquierda a derecha:

• acción — alert, drop, reject, pass
• protocolo — tcp, udp, icmp, ip (o protocolos de aplicación en Suricata: http, dns, tls)
• IP/puerto de origen y IP/puerto de destino
• dirección — -> unidireccional, o <> bidireccional

Las variables como $HOME_NET y $EXTERNAL_NET provienen de su configuración, para que las reglas sigan siendo portátiles entre distintos sitios.

La acción determina si la regla se comporta como IDS o IPS:

• alert — registra y notifica, pero no detiene el tráfico (IDS)
• drop — descarta el paquete silenciosamente (IPS, solo en línea)
• reject — descarta y envía un restablecimiento TCP o un mensaje ICMP de destino inalcanzable
• pass — permite explícitamente el tráfico y omite las reglas posteriores

El mismo motor funciona como IDS o IPS según si se implementa en línea y las acciones que se utilizan.

La palabra clave content busca un patrón de bytes en la carga útil. El texto se escribe entre comillas; los datos binarios se escriben entre barras verticales en formato hexadecimal.

Las palabras clave de anclaje hacen más precisas las coincidencias: offset, depth, distance y within restringen dónde puede aparecer el patrón, lo que mejora tanto la exactitud como el rendimiento.

Las reglas modernas buscan coincidencias en búferes sensibles al protocolo en lugar de hacerlo en el flujo sin procesar. Después de una palabra clave de búfer, las coincidencias posteriores de content se aplican a esa parte del protocolo analizado.

• http_uri — el URI de la solicitud
• http_header — los encabezados de la solicitud o la respuesta
• http_user_agent — el User-Agent
• tls_sni / dns_query — el nombre del servidor TLS / la consulta DNS

Esto es mucho más fiable que buscar una subcadena en todo el paquete.

Cuando las cadenas fijas no son suficientes, pcre proporciona expresiones regulares compatibles con Perl. Combine un filtro previo económico de content con pcre para que la expresión regular solo se ejecute en los paquetes candidatos y se conserve el rendimiento.

El modificador nocase hace que la coincidencia de contenido no distinga entre mayúsculas y minúsculas, algo importante para los encabezados y los campos controlados por el usuario que los atacantes pueden variar.

La opción flow limita una regla al estado y la dirección de la conexión, lo que reduce los falsos positivos y el coste.

• established — solo en sesiones TCP completadas
• to_server / to_client — dirección de la solicitud frente a la respuesta

Buscar respuestas del servidor solo cuando la conexión está establecida y la dirección es to_client evita que la regla se active con paquetes aislados o falsificados.

Las opciones de gestión mantienen un conjunto de reglas fácil de mantener:

• sid — identificador único de firma (use 1000000+ para las reglas locales)
• rev — número de revisión; increméntelo con cada edición
• msg — el texto de la alerta que ven los analistas
• classtype — categoría que determina la prioridad
• reference — enlace a un CVE o aviso de seguridad

Los sid estables y los rev incrementales permiten realizar el seguimiento y actualizar las reglas sin romper los paneles ni las supresiones.

Aunque son compatibles a nivel de reglas, los motores difieren en sus capacidades:

• Suricata utiliza varios hilos, analiza protocolos de aplicación de forma nativa, extrae archivos, calcula JA3 y genera EVE JSON
• Snort 3 reescribió su motor para mejorar el rendimiento y ofrecer un sistema modular de plugins

Algunas palabras clave son específicas de cada motor. Suricata añade palabras clave de la capa de aplicación (tls.sni, dns.query, http.method) y funciones de conjuntos de datos y flowbits. Al compartir reglas, diríjalas al mínimo común denominador o mantenga conjuntos de reglas específicos para cada motor.

Para evitar que una regla inunde la consola, aplique umbrales. detection_filter se activa solo después de N eventos dentro de una ventana; threshold con limit limita el volumen de alertas.

Esto es esencial para detectar ataques de fuerza bruta y escaneos, en los que un solo evento no tiene significado, pero una ráfaga sí constituye una señal.

Lea una regla y prediga su comportamiento.

Ahora puede leer y escribir firmas de Snort/Suricata:

• Una regla consta de un encabezado (acción, protocolo, origen/destino y dirección) y opciones del cuerpo
• La acción determina si funciona como IDS o IPS: alert, drop, reject, pass
• content, junto con offset/depth y las coincidencias hexadecimales, busca bytes en la carga útil
• Los búferes adhesivos (http.uri, tls.sni, dns.query) buscan coincidencias en campos del protocolo analizado
• pcre y nocase gestionan patrones variables
• flow limita la búsqueda al estado y la dirección
• sid/rev/msg/reference mantienen las reglas fáciles de gestionar
• Los umbrales moderan el ruido de los ataques de fuerza bruta y los escaneos

A continuación: detección de amenazas sin ninguna firma.