Parte: 1 — Redes y seguridad de redes · Fuente: Applied NSM, C. Sanders & J. Smith; docs de Snort y Suricata ⏱️ Duración estimada: 140 min · Nivel: Intermedio
Desplegar y operar sistemas de detección/prevención de intrusiones basados en firmas con Snort y Suricata: entender la diferencia entre IDS e IPS, escribir y afinar reglas, procesar tráfico en vivo y desde pcap, e interpretar las alertas resultantes. Es el pilar de la detección basada en firmas dentro de un SOC.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | IDS vs. IPS; modos de despliegue | Detectar vs. bloquear |
| 2 | Arquitectura de Suricata (multihilo) | Rendimiento en redes rápidas |
| 3 | Conjuntos de reglas (ET Open, Talos) | No reinventar firmas |
| 4 | Anatomía de una regla | Escribir detección propia |
| 5 | Opciones: content, pcre, flow, flowbits | Precisión de la firma |
| 6 | Salida EVE JSON y logs | Integración con SIEM |
| 7 | Afinado y falsos positivos | Detección usable en producción |
Un IDS observa una copia del tráfico y avisa; un IPS se sitúa en el camino del tráfico y puede descartarlo. La misma herramienta —Suricata lo es— hace las dos cosas según cómo se despliegue, y la elección tiene consecuencias que van mucho más allá de lo técnico. En modo IDS, sobre un SPAN o un TAP, un falso positivo genera una alerta molesta; en modo IPS, en línea, un falso positivo corta tráfico legítimo y produce una incidencia de negocio. Y como el IPS está en el camino, si se cae o se satura se convierte en un punto único de fallo para toda la red que protege.
Por eso el patrón habitual en organizaciones sensatas es empezar en modo IDS, afinar las reglas hasta que el ruido sea manejable, y solo entonces pasar en línea las firmas de las que se tiene confianza alta. El bloqueo se gana; no se activa el primer día.
Una firma de Suricata o Snort se lee de izquierda a derecha como una oración con dos
partes. La cabecera dice qué hacer y sobre qué tráfico: acción (alert, drop,
pass), protocolo, dirección de origen con puerto, el operador de dirección (->) y
destino con puerto. Las opciones, entre paréntesis, refinan la condición y aportan
los metadatos.
alert http $EXTERNAL_NET any -> $HOME_NET any ( \
msg:"Descarga de ejecutable desde host recien registrado"; \
flow:established,to_client; \
http.content_type; content:"application/x-msdownload"; \
classtype:trojan-activity; sid:1000010; rev:1; )
Las opciones que más determinan la calidad de una firma son cuatro. flow acota la
dirección y el estado de la conexión, y evita que la regla dispare sobre tráfico suelto
o en el sentido equivocado. Los buffers de protocolo —http.uri, http.user_agent,
tls.sni, dns.query— restringen la búsqueda al campo correcto en lugar de rastrear
todo el paquete, lo que multiplica la precisión y el rendimiento. content busca una
cadena literal y es barato; pcre aplica una expresión regular y es caro, así que la
práctica correcta es poner primero un content que descarte la mayoría del tráfico y
solo después el pcre. Y flowbits permite encadenar estado entre paquetes:
marcar en un paquete y comprobar la marca en otro, que es como se detectan secuencias en
lugar de eventos aislados. El sid identifica la regla —el rango local empieza en
1000000— y el rev su versión.
Un despliegue con ET Open completo genera decenas de miles de alertas diarias en una
red mediana, y un SOC que recibe eso deja de mirar las alertas en una semana. El trabajo
de verdad es el afinado: desactivar categorías que no aplican a tu entorno, crear
excepciones por origen para escáneres de vulnerabilidades y sistemas de monitorización
propios, ajustar threshold y suppress para limitar repeticiones, y medir cuántas
alertas se investigan de verdad. Una regla que nadie mira nunca es peor que no tener la
regla, porque da una sensación de cobertura que no existe.
Conviene también conocer los límites del método. La detección por firma solo reconoce lo
que alguien ya describió: no ve un ataque nuevo, y no ve dentro del tráfico cifrado.
Con TLS omnipresente, lo que queda visible son los metadatos —el SNI, el certificado,
los tamaños y tiempos, la huella JA3—, y por eso este bloque desemboca de forma natural
en el análisis de metadatos de las clases 043 a 045. La salida EVE JSON de Suricata
es la pieza que conecta todo eso con un SIEM: un evento estructurado por línea, con
alertas y también con registros de transacción HTTP, DNS y TLS.
content: cadena o bytes a buscar en el payload; núcleo de la mayoría de firmas.flow: restringe la regla a una dirección/estado de la conexión (to_server,established).| Término | Definición concisa |
|---|---|
| IDS | Detecta y alerta observando una copia del tráfico |
| IPS | Se sitúa en línea y puede descartar el tráfico |
| Modo en línea | Despliegue en el camino del tráfico; un fallo corta el servicio |
| Firma / regla | Descripción de un patrón de tráfico considerado malicioso |
| Cabecera de regla | Acción, protocolo, origen, dirección y destino |
flow |
Acota dirección y estado de la conexión en la que aplica la regla |
| Buffer de protocolo | Campo concreto donde buscar (http.uri, tls.sni, dns.query) |
content |
Búsqueda de cadena literal; rápida |
pcre |
Expresión regular; precisa pero costosa, se pone tras un content |
flowbits |
Marca de estado que encadena condiciones entre paquetes |
sid / rev |
Identificador y versión de la regla; el rango local empieza en 1000000 |
| ET Open | Conjunto de reglas abierto de Emerging Threats |
| Afinado (tuning) | Reducir el ruido para que las alertas sean investigables |
threshold / suppress |
Limitar repeticiones y silenciar orígenes conocidos |
| EVE JSON | Salida estructurada de Suricata: alertas y transacciones, una por línea |
| JA3 | Huella del cliente TLS; identifica software sin descifrar el tráfico |
sudo apt install suricata. Actualiza reglas con suricata-update.sudo apt install snort o compilación oficial.suricata-update las trae).jq para el EVE JSON, tail, un pcap de prueba.⚠️ Nota ética: para probar firmas generarás tráfico que simula ataques (escaneos, patrones maliciosos). Hazlo solo en tu laboratorio aislado. Un IPS mal configurado en producción puede cortar servicio; prueba primero en modo IDS.
bash
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml # test de config
bash
sudo suricata -r /tmp/lab027.pcapng -l ./salida/
jq 'select(.event_type=="alert") | .alert.signature' ./salida/eve.json
bash
sudo suricata -i eth0 -l /var/log/suricata/
sudo tail -f /var/log/suricata/fast.log
/etc/suricata/rules/local.rules:text
alert icmp any any -> $HOME_NET any (msg:"ICMP ping detectado en laboratorio"; itype:8; sid:1000001; rev:1;)
alert http any any -> any any (msg:"Posible user-agent de escaneo"; flow:to_server,established; http.user_agent; content:"Nmap"; nocase; sid:1000002; rev:1;)
Añade local.rules a rule-files en el YAML y recarga.
5. Dispara la regla: desde otra VM ping <IP-de-un-host-en-HOME_NET> (una IP concreta de tu red de laboratorio; no uses $HOME, que la shell expande a tu directorio personal) y un curl -A "Nmap NSE" http://...; observa las alertas en fast.log.
6. Compara con Snort 3 (opcional):
bash
snort -c /etc/snort/snort.lua -r /tmp/lab027.pcapng -A alert_fast
suricata-update --disable-conf o un umbral (threshold.config).pcre que detecte una cadena en URL con expresión regular.flowbits para correlacionar dos eventos de una misma sesión.jq todas las consultas registradas por Suricata.threshold) para limitar alertas repetidas de una misma firma.Despliega Suricata en modo IDS en tu laboratorio, escribe una regla propia que detecte un patrón de ataque concreto (p. ej. una petición HTTP a /admin con cierto user-agent), genera el tráfico que la dispara y entrega: la regla, la línea de fast.log correspondiente y el objeto de alerta del eve.json extraído con jq.
Criterio de aceptación: la regla tiene sid propio válido, la alerta aparece con el msg exacto al generar el tráfico, y no se dispara con tráfico legítimo similar (bajo falso positivo).
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| "Signature has no sid" | Falta sid: en la regla; añade un SID único ≥ 1000000 para reglas locales |
| La regla no dispara | $HOME_NET mal definido o flow incorrecto; revisa variables en el YAML y la dirección |
| Suricata no captura en vivo | Interfaz equivocada o sin permisos; verifica -i y ejecuta con privilegios |
| Miles de alertas ruidosas | Reglas demasiado genéricas activas; afina con suricata-update y umbrales |
| IPS corta tráfico legítimo | Firma con falso positivo en modo inline; valida siempre primero en modo IDS |
❓ ¿Snort o Suricata? Suricata es multihilo (mejor en redes rápidas) y trae EVE JSON nativo. Snort 3 también es moderno. Ambos comparten en gran medida el formato de reglas; aprende Suricata como base.
❓ ¿La detección por firmas detecta amenazas nuevas? No las desconocidas (zero-day) sin firma. Por eso se combina con detección por anomalías y con NSM (clases 043–045).
❓ ¿Qué es HOME_NET?
La variable que define tu red a proteger. Firmas y direcciones (-> $HOME_NET) dependen de configurarla bien en el YAML.
❓ ¿Puedo usar las mismas reglas en Snort y Suricata? En gran medida sí, comparten sintaxis, pero hay opciones específicas de cada motor. Verifica compatibilidad al portar reglas.
Clase 034 — Firewalls: tipos, iptables y nftables