Zeek:

convertir el tráfico de red en registros que un analista puede leer

Análisis de red  |  unfantasmaenelsistema.com

Wireshark te enseña paquetes. Suricata te avisa cuando un paquete coincide con una firma conocida. Zeek hace algo distinto de los dos: observa el tráfico y escribe un diario. Cada conexión TCP, cada consulta DNS, cada handshake TLS, cada fichero transferido queda anotado en un registro estructurado, con marca de tiempo, direcciones, duración y bytes. No busca ataques concretos; construye el material con el que un analista busca cualquier cosa, incluida la que todavía no tiene firma.

Este artículo explica qué es Zeek y qué no, cómo son sus registros, dónde se despliega, cómo se analiza una captura offline y cómo se usan `conn.log` y `dns.log` para detectar patrones de beaconing y de exfiltración. Cierra el trío de análisis de red con nuestros artículos de Wireshark y de Suricata, y alimenta el trabajo de threat hunting.

1. Zeek no es un IDS: es un motor de registros

La confusión más habitual es meter a Zeek en el mismo saco que Snort o Suricata. Aquellos comparan cada paquete con un conjunto de firmas y disparan una alerta al coincidir. Zeek analiza el tráfico a un nivel más alto — entiende protocolos, sigue el estado de cada conexión — y su salida por defecto no son alertas, son hechos: «a las 10:03:17 el host 10.0.0.5 abrió una conexión al puerto 443 de 93.184.216.34, duró 2,1 segundos y transfirió 4 KB de subida y 12 KB de bajada; el nombre SNI era ejemplo.com».

Sobre esa base de hechos se pueden escribir detecciones (Zeek tiene su propio lenguaje de scripting y un `notice.log` para las que merecen atención), pero el valor principal está en tener semanas de historial estructurado y consultable. Cuando aparece un indicador nuevo — un dominio, una IP, un hash — el analista pregunta a los logs de Zeek «¿hemos hablado alguna vez con esto?» y tiene la respuesta en segundos.

2. Los registros y sus campos

Dos campos de `conn.log` merecen una nota. El `service` lo determina Zeek analizando el contenido, no el número de puerto: si ve HTTP por el 8443, escribe `http`, y si ve algo que no es TLS por el 443, lo dice. El `conn_state` resume el ciclo de vida de la conexión (`SF` establecida y cerrada limpiamente, `S0` intento sin respuesta, `REJ` rechazada), muy útil para distinguir un escaneo de una comunicación real.

3. Dónde se despliega un sensor Zeek

• Zeek necesita ver el tráfico: un puerto SPAN/mirror del switch o un TAP de red que copie lo que pasa entre la red interna y la frontera (el cortafuegos, el proxy)
• El sensor es una máquina Linux dedicada con una interfaz de captura sin dirección IP (solo escucha) y otra de gestión. Para enlaces con mucho tráfico se usa Zeek en clúster: varios procesos worker repartiéndose los flujos, un manager y un logger
• Es habitual correr Zeek y Suricata sobre el mismo tráfico: Suricata aporta las alertas de firma (reglas de amenazas conocidas), Zeek aporta el contexto y el historial. Se complementan
• Los logs se envían a un SIEM. Existen módulos de ingesta de Zeek para casi todos; el formato JSON de Zeek facilita el trabajo

Distribuciones que empaquetan Zeek con todo lo anterior ya montado: Security Onion y Corelight (la versión comercial). Para un laboratorio basta con instalar el paquete `zeek` en una VM y apuntarlo a la interfaz de captura.

4. Analizar un .pcap offline

No hace falta un sensor para empezar. Zeek procesa un fichero de captura y genera los mismos logs que generaría en vivo. Es la mejor forma de practicar y de analizar la captura de un incidente o de un reto.

# Generar todos los logs a partir de una captura (crea conn.log, dns.log, etc. en el directorio actual)
mkdir analisis && cd analisis
zeek -r ../captura.pcap
 
# conn.log: origen, destino, puerto, servicio, duracion y bytes, en columnas
zeek-cut ts id.orig_h id.resp_h id.resp_p service duration orig_bytes resp_bytes < conn.log | head
 
# Las 20 IPs de destino con mas bytes de SUBIDA (candidatas a exfiltracion)
zeek-cut id.resp_h orig_bytes < conn.log \
  | awk '{ sub[$1] += $2 } END { for (h in sub) print sub[h], h }' | sort -rn | head -20
 
# Dominios consultados por DNS, ordenados por frecuencia
zeek-cut query < dns.log | sort | uniq -c | sort -rn | head -30

`zeek-cut` es la navaja suiza para estos logs: recibe el log por la entrada estándar y saca solo las columnas que le pides, en texto plano listo para `awk`, `sort` y `uniq`. Si prefieres trabajar con JSON, `zeek -r captura.pcap LogAscii::use_json=T` y luego `jq`.

5. Detectar beaconing con conn.log

Un implante de mando y control (C2) que «llama a casa» cada cierto tiempo deja una huella muy característica en `conn.log`: muchas conexiones al mismo destino, a intervalos regulares, con un tamaño de datos parecido en cada una. A ojo no se ve; con una agregación sencilla, sí.

• Agrupa las conexiones por par origen-destino y mira cuántas hubo, cada cuánto (la diferencia de tiempo entre conexiones consecutivas) y con qué regularidad (poca varianza en ese intervalo es sospechosa)
• Un patrón de «cada 60 segundos, más o menos 2, durante 8 horas, siempre 400 bytes de subida» no es tráfico humano ni de la mayoría de aplicaciones legítimas
• Herramientas que automatizan esto sobre logs de Zeek: RITA (Real Intelligence Threat Analytics) y AC-Hunter. Calculan una puntuación de «beacon» por cada par de hosts
• Ojo con los falsos positivos: actualizaciones de software, sincronización de relojes NTP, clientes de correo y telemetría de sistemas también son periódicos. El contexto (¿a dónde llama? ¿es un dominio conocido?) decide

6. Detectar exfiltración con dns.log y conn.log

La exfiltración de datos se ve de dos maneras en los logs de Zeek. La directa: una conexión saliente con `orig_bytes` desproporcionadamente grande hacia un destino con el que la organización no tiene relación. La agregación por destino del ejemplo de la sección 4 la saca a la primera.

La encubierta por DNS es más sutil: el implante codifica los datos en los nombres que consulta (`ZXhmaWx0cmFjaW9u.datos.ejemplo.com`) y el servidor autoritativo del atacante los recibe. En `dns.log` se manifiesta como un volumen anómalo de consultas a subdominios de un mismo dominio padre, con nombres largos, de alta entropía y muchos tipos `TXT` o `NULL`.

# Dominios padre con mas subdominios distintos consultados (tunel DNS candidato)
zeek-cut query < dns.log \
  | awk -F. '{ print $(NF-1)"."$NF }' \
  | sort | uniq -c | sort -rn | head -20
 
# Consultas con nombres muy largos (posible codificacion de datos)
zeek-cut query < dns.log | awk '{ if (length($1) > 60) print length($1), $1 }' | sort -rn | head

7. El lenguaje de scripting, a vista de pájaro

Zeek trae un lenguaje propio, orientado a eventos. Se escriben manejadores para eventos como `dns_request`, `ssl_established` o `file_new`, y desde ahí se puede correlacionar, mantener estado y generar entradas en `notice.log`. La mayoría de organizaciones empieza sin tocarlo: cargan los scripts de la comunidad (el Zeek Package Manager, `zkg`) para detecciones habituales — fuerza bruta, escaneos, certificados autofirmados, dominios recién registrados — y solo más tarde escriben los suyos.

Conclusión

Zeek cambia la pregunta. Con un analizador de paquetes preguntas «¿qué hay en este paquete?»; con un IDS de firmas, «¿algún paquete coincide con un ataque conocido?». Con Zeek preguntas «¿con quién ha hablado esta red, cuándo, cuánto y por qué protocolo?», y esa pregunta se puede hacer sobre semanas de historial y sobre indicadores que aún no existían cuando el tráfico pasó.

Para empezar no hace falta infraestructura: `zeek -r captura.pcap`, un rato con `zeek-cut`, `awk` y `sort`, y un par de agregaciones por destino y por dominio ya destapan beaconing y exfiltración que ninguna alerta había cazado. El salto a un sensor permanente que alimente el SIEM viene después, cuando el valor ya está claro.

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