Network-Hunting con Zeek y Suricata: despliegue, ajuste de reglas, análisis de TLS y procesos Alert-to-Case

El network-hunting con Zeek y Suricata es especialmente eficaz cuando no se interpreta como “otro sensor más”, sino como una disciplina operativa: arquitectura de capture limpia, ajuste controlado de reglas, metadatos TLS fiables y un proceso que convierta las alertas en casos trazables. Zeek (Network Security Monitor, genera metadatos estructurados de protocolos y flujos) y Suricata (motor IDS/IPS, comprueba el tráfico contra firmas y reglas de protocolo) se complementan muy bien, pero solo si el despliegue y la ruta de datos son correctos.

Esta aportación está dirigida a administradores y operadores que quieren empezar de forma pragmática: ¿qué topología de sensores funciona en la práctica? ¿Cómo evita que 10.000 alertas al día paralicen a los equipos? ¿Qué es aún posible al parsear TLS, aunque los contenidos estén cifrados? ¿Y cómo construir un proceso alert-to-case que resista auditorías, respuesta a incidentes y el día a día?

Network-Hunting con Zeek y Suricata en la práctica

Zeek es potente cuando quiere extraer metadatos útiles a partir de paquetes crudos con rapidez: datos de conexión (5-tupla, duración, bytes), eventos de protocolo (p. ej. consultas DNS, cabeceras HTTP, datos del handshake TLS) y metadatos de archivos. Suricata es potente cuando desea detectar patrones conocidos: firmas (clásicamente “Rules”), decodificadores de protocolo, detección de anomalías y —según el modo de operación— también bloqueo inline como IPS.

En setups de hunting, Suricata suele ser más útil como IDS (pasivo), porque un IPS inline puede introducir rápidamente riesgos de disponibilidad: drops falso-positivos, enrutamiento asimétrico, problemas de reensamblado de sesión. Zeek permanece pasivo y suele ser más “honesto” en la calidad de los datos —siempre que el capture y las marcas temporales sean correctas.

Es importante ajustar las expectativas: con TLS normalmente no verá contenidos, pero sí muchos indicadores procedentes del handshake y del comportamiento de la conexión. Eso basta para muchas preguntas (indicadores C2, cadenas de destino inusuales, SNI sospechoso, anomalías en certificados), pero no sustituye a la telemetría del host.

Arquitectura de despliegue: TAP vs. SPAN, colocación de sensores y estrategia de contingencia

La mayor fuente de errores en el despliegue de sensores no es el software, sino el acceso a la red. Para Zeek/Suricata necesita Packet Capture (PCAP) o captura basada en AF_PACKET/DPDK. Lo decisivo es: visibilidad completa, ausencia de pérdida de paquetes y sincronización de tiempo correcta.

TAP o SPAN?

Un TAP (Test Access Point) es una derivación física que suele ser más estable: replica bits sin la “interpretación” del switch. Un puerto SPAN/mirror en switches suele estar disponible más rápido, pero trae problemas habituales: oversubscription (más tráfico del que el puerto mirror puede soportar), visibilidad VLAN incompleta, ráfagas de paquetes y —según la plataforma— efectos sutiles de filtrado.

• TAP: mejor para forense fiable, mayor coste de material, pero operación más reproducible.
• SPAN: rápido, económico, pero debe verificar activamente el riesgo de drops y la completitud de la captura.

¿Dónde colocar?

Para empezar hay tres ubicaciones prácticas:

• Borde de Internet / perímetro: buena visibilidad de entradas y salidas (Egress suele ser para hunting a menudo más importante que Ingress).
• Agregación del centro de datos: tráfico East-West entre redes de servidores – relevante para movimiento lateral.
• Segmento con «joyas de la corona»: bases de datos, backends ERP/CRM, servicios de archivos centrales – ideal para hunting focalizado.

Compromiso típico: comience con un sensor en el perímetro (cobertura máxima) y añada después sensores por segmento de forma dirigida cuando sepa dónde están las hipótesis principales.

Estrategia de retroceso (Rollback) ya en el diseño

Incluso con sensores pasivos puede afectar la producción: las configuraciones mirror pueden estar mal, las NIC de los sensores pueden inundar puertos de switch (p. ej. por loops), el almacenamiento puede llenarse y los sistemas de monitoring pueden colapsar por tormentas de logs. Planifique por tanto:

• Mirror/TAP rápidamente desconectable (plan de cambios, puertos claramente etiquetados).
• Operar los sensores en «fail-open» (pasivo); IPS solo con autorización específica.
• Rate-limits y backpressure en la canalización de logs (queue, batch, drop-policy).
• Límites de capacidad: PCAP-Ringbuffer, rotación de logs, umbrales de advertencia de almacenamiento.

Base de hardware y rendimiento: evitar pérdidas (drops) antes de ajustar reglas

El ajuste de reglas no vale de nada si sus sensores pierden paquetes. La pérdida de paquetes genera artefactos: handshakes TLS fragmentados, transacciones HTTP faltantes, reensamblado de streams incorrecto; de ello derivan alertas fantasma y puntos ciegos.

Lista de comprobación mínima para hosts de sensores

• NIC: NIC del servidor con controlador estable; RSS (Receive Side Scaling) activo, tamaño de ringbuffer adecuado.
• CPU: núcleos suficientes, pinning/modelo de workers apropiado; evitar «todo en el Core 0».
• Almacenamiento: volúmenes separados para logs/PCAP; reserva de IOPS para picos; rotación de logs comprobada.
• Tiempo: NTP/Chrony estable; la deriva temporal destruye la correlación y la línea temporal del caso.

Pasos de comprobación: paquetes descartados, desbordamiento de colas, salud de la captura

No compruebe solo «¿el servicio está en funcionamiento?», sino «¿procesamos todo el tráfico?». Según el backend de captura, las métricas difieren. Dos pruebas base prácticas son: estadísticas de interfaz (kernel) y estadísticas del sensor (aplicación).

# Estadísticas de interfaz (drops, errors) – punto de partida
ip -s link show dev eth1

# Contadores del kernel y del driver (según el driver, informativos)
ethtool -S eth1 | egrep -i 'drop|dropped|miss|error|fifo'

# Comprobar ringbuffer/RX-tuning
ethtool -g eth1

# Monitor de CPU/softirq: si ksoftirqd sube, hay riesgo de drops
top -H

Si ya observa aquí pérdidas (drops), las contramedidas típicas son: reducir la carga del mirror (SPAN selectivo), cambiar el backend de captura (AF_PACKET frente a DPDK), aumentar el RX-Ring, ajustar correctamente el balanceo de IRQs o utilizar hardware de sensor dedicado.

Despliegue de Suricata: EVE JSON, conjuntos de reglas y disciplina segura de actualizaciones

Suricata entrega sus resultados típicamente como EVE JSON (eventos estructurados en formato JSON). Para operación e integraciones esto es ideal: SIEM, gestión de logs, bus de mensajería o sistemas de casos pueden parsear los eventos de forma robusta.

Principios de configuración que ayudan en el día a día

• Separe la ruta de operación y la de análisis: Suricata escribe localmente; un forwarder (p. ej. Filebeat/Fluent Bit/Vector) reenvía.
• Versione las reglas: repositorio Git o registro de artefactos; no aplique actualizaciones «en el sensor» mediante clicks.
• Ventanas de actualización: las actualizaciones de reglas son en la práctica cambios de código — con registro de cambios y capacidad de rollback.

Realizar el update de reglas de forma controlada (flujo de ejemplo)

# Beispiel: Regeln aktualisieren (Distribution/Tooling variiert je nach Setup)
# 1) Vorher: aktuelle Regeln sichern
sudo tar -C /etc/suricata -czf /var/backups/suricata-rules_$(date +%F).tar.gz rules

# 2) Update aus kontrollierter Quelle (z. B. internes Repo / signiertes Paket)
# (Hier als Platzhalter – in der Praxis per Paketmanager oder suricata-update)
# sudo suricata-update --no-test --reload-command 'systemctl reload suricata'

# 3) Syntax-/Ladeprüfung und anschließend Reload
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata

# 4) Rückfall: falls Alarmflut oder Fehler
# sudo tar -C /etc/suricata -xzf /var/backups/suricata-rules_YYYY-MM-DD.tar.gz
# sudo systemctl reload suricata

Por qué funciona este flujo: separa la prueba (verificación de configuración/reglas) de la activación. Y dispone de una opción de retroceso rápida antes de que la canalización se inunde con firmas incorrectas.

Despliegue de Zeek: metadatos como base para hunting y un recorte sensato de logs

Zeek genera muchos tipos de logs (p. ej. conn, dns, http, ssl/tls). Para la operación suele cumplirse que menos es más: si activa «todo», aumentan la carga de almacenamiento y de parsing, y los equipos pierden visibilidad. Empiece con un conjunto núcleo que cubra hipótesis típicas:

• conn: conexiones base (quién habla con quién, cuándo, cuánto).
• dns: resolución de nombres (dominios C2, sospecha de DGA, exfiltración por DNS).
• tls/ssl: metadatos del handshake (SNI, certificado, versiones, ALPN).
• files (opcional): metadatos de archivos (hashes) — solo si puede asumir la carga I/O.

Un tropiezo frecuente es la correlación entre sensores: si opera varios sensores necesita IDs de sensor únicas y fuentes de tiempo consistentes. De lo contrario, dos eventos pueden convertirse en «dos verdades».

Pasos de verificación: Zeek-Health y rotación de logs

# Läuft Zeek und schreibt Logs?
sudo systemctl status zeek
ls -lh /opt/zeek/logs/current/

# Rotation/Archive prüfen (Pfad je nach Installation)
find /opt/zeek/logs -maxdepth 2 -type d -name "20*" | tail

# Grober Plausibilitätscheck: wächst conn.log, dns.log, tls/ssl.log?
for f in conn.log dns.log ssl.log tls.log; do
  test -f "/opt/zeek/logs/current/$f" && echo "OK: $f" || echo "MISS: $f";
done

Si los logs no rotan o los archivos de archivo no se limpian, eso no es solo un problema estético: los filesystems que se llenan provocan pérdida de datos y, en el peor de los casos, sensores inestables.

Ajuste de reglas en Suricata: de la avalancha de alertas a señales fiables

Ajustar reglas no significa „desactivar todo hasta que haya calma“, sino: definir expectativas, establecer líneas base, añadir contexto y afinar de forma iterativa. El objetivo es una relación señal/ruido que un equipo pueda gestionar realmente.

Causas típicas de falsos positivos

• Redes incompatibles: las reglas se disparan por monitorización interna, copias de seguridad, escáneres de vulnerabilidades o tráfico de proxy.
• TLS en todas partes: muchas firmas orientadas a protocolos en texto claro son „tocadas“ parcialmente por TLS (SNI/handshake), sin evidencia real.
• Normalización de protocolos: reverse-proxies, NAT, load-balancer cambian la visibilidad y generan flujos „extraños“.
• Reensamblado incompleto: pérdida de paquetes o enrutamiento asimétrico provocan eventos del decodificador que desorientan.

Flujo de trabajo práctico de afinamiento (3 niveles)

1. Nivel 1: Reducir el ruido – excepciones claras para escáneres conocidos, servidores internos de actualizaciones, redes de gestión. Esto no significa „filtrar ataques“, sino eliminar fuego continuo que nadie analiza.
2. Nivel 2: Forzar contexto – alertar solo cuando se cumplen varias condiciones (p. ej. zona objetivo + protocolo + destino raro + puerto inusual).
3. Nivel 3: Vincular al proceso – cada regla restante recibe responsabilidad (¿quién la mantiene?) y un ritmo de revisión.

Importante: el afinamiento debe basarse siempre en datos. Si desactiva reglas, documente el motivo y fije una fecha de revisión. De lo contrario se acumulan „pasivos“ que más tarde generan puntos ciegos.

TLS-Parsing: Qué puede usar de forma fiable sin descifrado

El TLS-parsing consiste en evaluar la parte no cifrada del handshake TLS. Esto incluye, entre otros, SNI (Server Name Indication — el nombre de host solicitado), la cadena de certificados, la versión/selección de cipher y las extensiones. Zeek y Suricata pueden aportar metadatos valiosos aquí, incluso cuando la carga útil está cifrada.

¿Qué señales TLS son útiles en la práctica?

• SNI: a menudo el indicador más fuerte de relaciones destino. Fallará en IP-only, ESNI/ECH (SNI oculto) o túneles TLS.
• Certificado: emisor, Subject, validez, autofirmado, patrones inusuales en SAN. Precaución: Let’s Encrypt no es „malo“, pero se necesita una buena línea base.
• JA3/JA3S: fingerprints a partir de parámetros del handshake cliente/servidor. Útiles para agrupar, pero no como única „prueba de malware“, porque los fingerprints colisionan y cambian.
• ALPN: negociación de HTTP/2, HTTP/1.1, etc. Ayuda en perfiles de protocolo.

Cuándo falla el parsing TLS: con ECH (Encrypted ClientHello) se reduce el valor añadido clásico del SNI. Además, las middleboxes (proxies) pueden „uniformar“ el comportamiento TLS visible, de modo que termine fingerprintando más al proxy que al cliente.

Escollos: mundos de proxy e interceptación de certificados

En muchas empresas un proxy termina TLS y reconstruye la conexión hacia el destino. Entonces, en el perímetro no verá la huella real del cliente, sino la del proxy. Esto no es „malo“, pero debe ajustar sus hipótesis: Hunting basado en „el dispositivo habla directamente con X“ no funcionará; en cambio, Hunting centrado en „el proxy establece conexiones inusuales“ puede funcionar muy bien.

Alert-to-Case: De eventos a procesos gestionables

Una alerta es un evento técnico. Un case es un proceso con contexto, responsabilidad, cronología y decisión. Sin esta transición, el Network-Hunting a menudo acaba como un vertedero de alertas o como un proyecto puntual.

Conjunto mínimo de datos del caso que ha demostrado su eficacia

• Identidad: Case-ID, Sensor, ventana temporal, activos afectados (IP, nombre de host, usuario si existe).
• Justificación: qué regla/heurística activó, qué evidencias están adjuntas (líneas de log de Zeek, alerta de Suricata, referencia a PCAP).
• Contexto: criticidad del activo, tickets de cambio conocidos, ventanas de mantenimiento, lista de IPs de escáneres.
• Decisión: True/False Positive, gravedad, siguiente acción (contain, observe, close).
• Trabajo posterior: tarea de tuning sí/no, propietario de la regla, revisión posterior.

Diseño pragmático de correlación

En la práctica no correlaciona „todo con todo“, sino que construye pocos puentes robustos:

• Alerta de Suricata → Contexto de Zeek: mismo 5-Tuple (origen/destino/puertos/proto) + ventana temporal.
• Zeek TLS/DNS → Asset-DB: IP/nombre de host a CMDB/inventario (¿qué servidor es?).
• PCAP on demand: solo para casos escalados; de lo contrario, los metadatos son suficientes.

Esto reduce costes: PCAP continuo es caro (storage, protección de datos, operación). Un „PCAP-Ringbuffer für 2–6 Stunden“ suele ser un buen compromiso para poder revisar hacia atrás en caso de incidente sin almacenar todo permanentemente.

Tubería de logs y retención de datos: Robustez vor „schönem Dashboard“

La mayor parte de las fallas ocurre entre el sensor y el análisis: log-forwarder bloqueado, la cola se llena, el indexer está sobrecargado, los timestamps son incorrectos, los campos cambian tras actualizaciones. Trate la pipeline como un sistema productivo.

Buenas prácticas para reenvío y backpressure

• Spooling local: el forwarder debe poder encolar en disco (Disk-Queue), si no perderá eventos durante interrupciones cortas.
• Control de esquemas: versionar EVE JSON/Zeek-logs; probar cambios en los parsers antes de pasarlos a producción.
• Separación entre „hot“ y „cold“: búsqueda activa en el índice rápido, retención a largo plazo como archivos comprimidos.

Pasos de comprobación: correlación temporal y estabilidad de campos

Si realiza Hunting, el „tiempo“ es una función central. Compruebe regularmente:

• Deriva entre sensor, colector de logs y indexador SIEM (estado NTP).
• Zonas horarias (UTC vs. hora local) en todas las capas.
• Nombres/tipos de campos tras actualizaciones (p. ej. campos EVE de Suricata, formatos de logs de Zeek).

Resolución de problemas: cuando los resultados no coinciden con su realidad

Es normal que las primeras semanas parezcan „extrañas“. Es crucial comprobar de forma sistemática si el problema está en la red, en la captura, en el parseo o en el proceso.

Síntoma: Muchos alerts TLS, pero sin huellas DNS coincidentes

• Causa: el DNS se cachea/resuelve internamente (resolver), los clientes usan DoH/DoT (DNS over HTTPS/TLS) o un proxy realiza la resolución.
• Verificación: ¿Ve el puerto 53/853? ¿Hay conexiones DoH hacia resolvers conocidos? ¿Pasa todo por un proxy?
• Contramedida: colocar el sensor más cerca de los clientes/resolvers o formular hipótesis a nivel de proxy.

Síntoma: Reglas que disparan sobre “todo”, especialmente durante backups/escaneos

• Causa: los escáneres y las herramientas de backup generan patrones similares a escaneos de exploits (muchos destinos/puertos/requests).
• Verificación: identificar la IP de origen, cotejar ventanas de mantenimiento y la lista de herramientas.
• Contramedida: excepciones con documentación clara; política separada de “ruido” para las redes de gestión.

Síntoma: Registros de protocolos ausentes o inestables

• Causa: pérdida de paquetes, encaminamiento asimétrico, espejo VLAN mal configurado, MTU/fragmentación.
• Verificación: pérdidas/errores como arriba, configuración SPAN, comparación con NetFlow/registros de firewall.
• Contramedida: usar TAP, seleccionar SPAN, ajustar NIC/CPU/backend del sensor.

Propuesta de implementación: en 14 días a una operación de Threat Hunting utilizable

Un plan práctico es mejor que «instalamos y vemos». El siguiente procedimiento ha demostrado ser realista, sin sobrecargar a los equipos:

Fase 1 (día 1–3): Visibilidad y estabilidad

• Instalar el sensor en el perímetro o en un punto de agregación (modo pasivo).
• NTP/Chrony correctamente configurados, definir políticas de almacenamiento y rotación.
• Verificar procesamiento sin pérdida de paquetes (probar en horas pico).

Fase 2 (día 4–7): Hacer los datos utilizables

• Enviar Suricata EVE JSON y los registros núcleo de Zeek al registro central.
• Primeros dashboards/consultas: principales destinos, dominios nuevos, SNI poco frecuentes, puertos inusuales.
• Medir la avalancha de alertas: Top 10 reglas, Top 10 orígenes, Top 10 destinos.

Fase 3 (día 8–14): Afinado y proceso de casos

• Reducción de ruido con excepciones documentadas.
• Definir plantilla de casos (campos, responsabilidades, SLAs a pequeña escala).
• Revisión semanal: qué reglas aportan valor, cuáles no, qué hipótesis faltan.

Conclusión: Hunting es operación — y Zeek/Suricata son su sensorística

Zeek y Suricata proporcionan, juntos, una base muy fiable para Network Hunting si primero asegura la calidad de la captura, luego ajusta las reglas de forma iterativa y clasifica correctamente los metadatos TLS. La palanca más potente no es «más reglas», sino el proceso de Alert-to-Case: responsabilidades claras, evidencia reproducible y un bucle de retroalimentación que mejore continuamente el ajuste y la calidad de los datos.

Si quiere profundizar en este ámbito en relación con la seguridad de APIs, la gestión centralizada de secretos o el registro de accesos remotos, el siguiente paso debe ser siempre el mismo: aumentar la visibilidad de forma dirigida, pero solo donde pueda operacionalizar los hallazgos.

Para este tema también son importantes la arquitectura IDS/NSM y el ajuste de reglas de Suricata. El artículo ordena estos aspectos de forma comprensible y muestra en qué se debe centrar la operativa diaria.