Suricata:

montar un IDS/IPS en el laboratorio y sacarle señales útiles

Análisis de red  |  unfantasmaenelsistema.com

Wireshark te deja mirar un paquete con lupa, pero no vigila la red por ti mientras duermes. Wazuh recoge lo que pasa dentro de cada máquina, pero no ve el cable. Entre las dos herramientas queda un hueco: alguien que escuche todo el tráfico que entra y sale, lo compare con un catálogo de patrones conocidos y avise cuando algo encaja. Ese es el trabajo de un IDS de red, y Suricata es hoy el motor de referencia en el mundo del software libre para hacerlo.

Este artículo es una guía para montar Suricata en un laboratorio propio —el mismo rango 192.168.56.x que venimos usando en la serie— y, sobre todo, para entender qué genera y cómo convertir ese chorro de datos en señales que un analista pueda usar. No es una receta para desplegarlo en la red de producción de nadie sin haber entendido antes lo que hace.

1. IDS frente a IPS: escuchar o cortar

Un IDS (Intrusion Detection System) observa una copia del tráfico y genera alertas. No está en el camino de los paquetes: si el sensor se cae o se satura, la red sigue funcionando exactamente igual, solo que ciega. Es el modo por defecto y el más fácil de justificar, porque su peor fallo posible es no ver algo.

Un IPS (Intrusion Prevention System) se coloca en línea: todos los paquetes lo atraviesan de verdad, y puede descartar los que coincidan con una regla de bloqueo. El precio es doble. Primero, añade latencia y se convierte en un punto único de fallo —normalmente se acompaña de un bypass por hardware que cortocircuita el enlace si el equipo muere—. Segundo, y más importante, un falso positivo ya no es una alerta molesta: es tráfico legítimo tirado al suelo, y eso son llamadas al servicio de asistencia.

La práctica habitual es empezar siempre en modo IDS, dejar que las reglas maduren durante semanas afinando falsos positivos, y solo entonces promover a modo bloqueo un subconjunto pequeño y muy fiable de firmas. Suricata hace ambas cosas con el mismo binario: lo que cambia es cómo recibe el tráfico y si las reglas usan la acción alert o la acción drop.

2. Dónde se pincha el sensor

Suricata solo puede analizar el tráfico que llega a su interfaz de captura. Elegir bien ese punto es la mitad del despliegue.

2.1 Puerto SPAN o mirror del switch

El switch copia el tráfico de uno o varios puertos (o de una VLAN entera) a un puerto libre donde conectas el sensor. Es la opción más cómoda porque no toca el cableado ni añade hardware. Sus límites: si la suma del tráfico espejado supera la capacidad del puerto de destino, el switch descarta silenciosamente el excedente; y muchos switches de gama baja recortan o no replican bien tramas malformadas, VLAN tags o errores de capa 2, que a veces son justo lo interesante.

2.2 TAP de red

Un TAP es un dispositivo pasivo que se intercala en un enlace y entrega una copia exacta de cada sentido del tráfico por dos salidas separadas. No pierde tramas, no depende de la CPU del switch y es invisible para la red. A cambio, hay que cortar físicamente el enlace para instalarlo y suele necesitar dos interfaces de captura en el sensor (una por sentido), que luego se combinan.

2.3 Bridge transparente (para IPS)

En modo prevención, Suricata recibe el tráfico en una interfaz, lo analiza y lo reenvía por otra, comportándose como un cable con opinión. Se monta con AF_PACKET en modo IPS entre dos NIC, o redirigiendo tráfico del firewall del sistema a NFQUEUE. En el laboratorio esto se simula muy bien con dos redes de solo-anfitrión y una VM con dos tarjetas haciendo de puente.

3. Instalación en el laboratorio

En Debian o Ubuntu recientes Suricata está en los repositorios, aunque el proyecto mantiene un PPA con versiones más nuevas. La instalación básica y la descarga del conjunto de reglas de la comunidad con suricata-update son inmediatas.

# Instalacion (Debian/Ubuntu). El PPA oficial trae versiones mas recientes.
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update && sudo apt install suricata jq
 
# Interfaz de captura y comprobacion de la config
ip -br link
sudo suricata -T -c /etc/suricata/suricata.yaml -v      # test de configuracion
 
# Reglas de la comunidad (ET Open por defecto)
sudo suricata-update
sudo suricata-update list-sources
sudo suricata-update enable-source et/open
 
# Arranque como servicio, leyendo de eth1 (la pata del lab)
sudo systemctl enable --now suricata
sudo tail -f /var/log/suricata/suricata.log

Para practicar sin generar tráfico real, Suricata puede leer un fichero .pcap capturado antes —por ejemplo uno de un reto CTF o una captura propia de Wireshark— y producir exactamente los mismos registros que produciría en vivo. Es la forma más segura de aprender a leer su salida.

# Analisis offline de una captura, con salida a un directorio propio
mkdir -p ~/lab/suri-out
suricata -r ~/lab/captura.pcap -l ~/lab/suri-out -k none
 
# Que ha salido
ls -l ~/lab/suri-out/
jq -r '.event_type' ~/lab/suri-out/eve.json | sort | uniq -c | sort -rn

4. Reglas: leer una, escribir una, mantenerlas

Una regla de Suricata tiene una estructura fija: acción, cabecera (protocolo, IPs y puertos de origen y destino con un sentido) y, entre paréntesis, las opciones que describen qué buscar y cómo etiquetar la alerta.

# Anatomia de una regla
#  accion  proto  origen  ->  destino   ( opciones )
 
alert http $HOME_NET any -> $EXTERNAL_NET any ( \
    msg:"LAB Posible descarga de ejecutable por HTTP plano"; \
    flow:established,to_server; \
    http.method; content:"GET"; \
    http.uri; content:".exe"; endswith; nocase; \
    classtype:policy-violation; \
    sid:9000001; rev:1; \
)
 
# Ejemplo de metadatos utiles para el SIEM
alert dns $HOME_NET any -> any any ( \
    msg:"LAB Consulta DNS a dominio en lista propia"; \
    dns.query; content:"malominoso.lab"; nocase; \
    metadata: attack_target Client_Endpoint, created_at 2026_08_27; \
    sid:9000002; rev:1; \
)

4.1 De dónde salen las reglas

• ET Open (Emerging Threats, mantenido por Proofpoint): el conjunto gratuito por defecto, decenas de miles de firmas, actualizado a diario. Cubre malware conocido, C2, escaneos, intentos de exploit y políticas de uso
• ET Pro / rulesets comerciales: cobertura más amplia y rápida, por suscripción — fuera del alcance de un laboratorio doméstico
• Reglas propias: en /etc/suricata/rules/local.rules, con SID a partir de 1000000 (el rango reservado para reglas locales) para no chocar con las de la comunidad
• suricata-update: gestiona fuentes, activa y desactiva conjuntos, aplica listas de desactivación/modificación y recompone el fichero final de reglas

4.2 Rendimiento del motor de reglas

Suricata es multihilo: reparte los flujos entre varios hilos de trabajo y usa el Multi Pattern Matcher (Hyperscan, si está disponible) para descartar de un golpe la inmensa mayoría de paquetes que no pueden coincidir con ninguna regla. En una máquina modesta de laboratorio esto es irrelevante; en enlaces de varios Gbps es la diferencia entre analizar todo o empezar a descartar paquetes (capture.kernel_drops en las estadísticas).

5. El EVE JSON: la mitad del valor está aquí

Si solo miras las alertas, estás desaprovechando Suricata. Además de firmas, el motor hace análisis de protocolo de todo lo que ve y lo vuelca como un flujo de eventos JSON —un objeto por línea— en /var/log/suricata/eve.json. Ese fichero es un registro completo de la actividad de red, haya saltado una regla o no.

5.1 Tipos de evento más útiles

5.2 Exprimir eve.json con jq

# Top de dominios DNS consultados
jq -r 'select(.event_type=="dns" and .dns.type=="query") | .dns.rrname' eve.json \
  | sort | uniq -c | sort -rn | head -20
 
# Huellas JA3 y a que SNI se asocian (util para cazar C2 sobre TLS)
jq -r 'select(.event_type=="tls") | [.tls.ja3.hash, .tls.sni] | @tsv' eve.json \
  | sort | uniq -c | sort -rn | head
 
# Conexiones salientes largas y con poco trafico: candidatas a beaconing
jq -r 'select(.event_type=="flow" and .flow.age>600 and .flow.bytes_toserver<2000)
       | [.dest_ip, .dest_port, .flow.age, .app_proto] | @tsv' eve.json | sort -u
 
# Ficheros descargados por HTTP con su hash SHA-256
jq -r 'select(.event_type=="fileinfo") | [.http.hostname, .fileinfo.filename, .fileinfo.sha256] | @tsv' eve.json

Suricata también puede extraer los ficheros que ve pasar (file-store) y guardarlos en disco junto a su metadato JSON, para pasarlos luego por YARA o por un sandbox. En un laboratorio es una forma excelente de practicar la cadena completa: la red ve la descarga, guarda la muestra, y el análisis estático empieza solo.

6. AF_PACKET y ajuste de rendimiento

El modo de captura recomendado en Linux es AF_PACKET, que entrega los paquetes desde el kernel al proceso con copia cero y permite repartir la carga entre varios hilos mediante «fanout». La configuración vive en suricata.yaml.

# Extracto de /etc/suricata/suricata.yaml
af-packet:
  - interface: eth1
    threads: auto            # un hilo de captura por cola RSS de la NIC
    cluster-id: 99
    cluster-type: cluster_flow   # cada flujo va siempre al mismo hilo
    defrag: yes
    use-mmap: yes
    ring-size: 200000        # subir si aparecen kernel_drops
 
# En modo IPS: dos interfaces que se reenvian entre si
#  - interface: eth1
#      copy-mode: ips
#      copy-iface: eth2
 
# Comprobar perdidas en caliente
sudo suricatasc -c 'iface-stat eth1'
jq 'select(.event_type=="stats") | .stats.capture' /var/log/suricata/eve.json | tail -1

• Desactiva los offloads de la NIC en la interfaz de captura (GRO, LRO, TSO): entregan al sensor segmentos que no se corresponden con lo que viajó por el cable
• Vigila capture.kernel_drops y capture.kernel_packets: si la proporción de descartes sube de un pequeño porcentaje, el sensor va corto de CPU o de «ring buffer»
• Recorta reglas que no apliquen a tu entorno: menos firmas activas es menos trabajo por paquete
• Ajusta la memoria de reensamblado de flujos y streams (flow.memcap, stream.memcap) al volumen real de conexiones

7. Integración con el SIEM y con la timeline

El EVE JSON está pensado para ser ingerido. La ruta más común en un laboratorio es Filebeat o Fluent Bit leyendo eve.json y enviándolo a Elasticsearch/OpenSearch, donde encaja el stack Suricata + Kibana que muchas distribuciones de monitorización (Security Onion, SELKS) traen ya montado. Wazuh también sabe leer eve.json directamente con su módulo de logs y correlacionarlo con la telemetría de endpoint.

• Cada alerta trae flow_id: el identificador que une la alerta con su evento flow, sus eventos http/dns/tls y los ficheros de esa misma conexión. Es la clave para pivotar
• Los campos de metadata y classtype de la regla permiten agrupar alertas por táctica y priorizar en la consola del SIEM
• En una timeline forense (por ejemplo con plaso o Timesketch), los eventos de Suricata aportan el eje de red: a qué hora esa máquina resolvió ese dominio, abrió esa conexión TLS y descargó ese fichero, para cruzarlo con lo que pasó dentro del host
• Reenvía también los eventos stats: son la señal de salud que te avisa de que el sensor está descartando paquetes antes de que descubras el hueco investigando un incidente

8. Suricata, Snort 3 y Zeek

Las tres herramientas se mencionan juntas pero no hacen lo mismo. Suricata y Snort 3 son motores de firmas: comparan el tráfico con reglas y alertan o bloquean. Comparten en gran medida la sintaxis de reglas (ET Open funciona en ambos con matices) y ambos hacen IDS e IPS. Suricata nació multihilo y con el EVE JSON como ciudadano de primera; Snort 3 reescribió su arquitectura para acercarse.

Zeek (antes Bro) juega en otra liga: no tiene reglas de firma en el sentido clásico. Es un motor de análisis y registro de metadatos que produce logs riquísimos y estructurados (conn.log, dns.log, ssl.log, files.log, notice.log) y un lenguaje de scripting para escribir lógica de detección propia sobre esos eventos. Lo habitual en un SOC maduro no es elegir: es correr Suricata para las firmas conocidas y Zeek para la visibilidad y la caza de lo que ninguna firma cubre.

Conclusión

Suricata cubre el punto de vista que ni Wireshark ni un agente de endpoint te dan: una vigilancia continua del tráfico que compara lo que pasa con lo que ya se sabe que es malo y, de paso, registra metadatos de todo lo demás. Montarlo en un laboratorio con capturas .pcap y unas pocas reglas propias es la mejor forma de entender qué significa cada campo antes de acercarlo a una red de verdad.

El error más común es quedarse en la pestaña de alertas. El EVE JSON —flujos, DNS, TLS con JA3, HTTP, ficheros extraídos— es lo que convierte a Suricata de «otra fuente de ruido» en el eje de red de una investigación. Y la regla de oro sigue siendo la misma: empezar en modo escucha, afinar los falsos positivos con paciencia, y solo bloquear cuando una firma se lo haya ganado.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)