Resumen

  • Los campos de conn.log expresan el análisis de un sensor Zeek sobre el tráfico que alcanzó su punto de observación; history tampoco es una secuencia completa de paquetes.
  • Para sostener una conclusión hay que conservar registro y esquema originales, versión, scripts, filtro, ubicación, reloj, señales de pérdida y demás registros vinculados por uid.

La reducción fue la solución

El artículo de 1998 en el que Paxson presentó Bro describía una arquitectura de dos decisiones. El motor de eventos recibía un flujo de paquetes filtrados y lo reducía a eventos de nivel superior. Un intérprete de políticas decidía qué importancia tenían para la organización. Así, el mecanismo que observaba no quedaba soldado a la regla local que alertaba o respondía.

La separación permitió vigilar enlaces de gran volumen en tiempo real. También dejó una advertencia que hoy se pierde cuando un dato entra en un lago de seguridad: antes de la fila hubo selección. La interfaz vio un tramo concreto; un filtro aceptó unas tramas y descartó otras; el motor comprobó cabeceras y mantuvo estado; el sistema eligió cuánto registrar. La fila es una representación diseñada.

Paxson trató la pérdida de paquetes como una amenaza contra el propio conocimiento del defensor. Si el filtro se quedaba sin capacidad, el paquete omitido podía ser justamente el que delataba al intruso. Además, el diseño suponía que el atacante conocería el monitor e intentaría evadirlo o saturarlo. Por eso la salud del sensor no es una métrica administrativa separada del incidente. Forma parte de la calidad de la prueba.

Qué afirma cada campo y qué no

La documentación actual de Zeek explica que conn.log registra sobre todo elementos de las capas 3 y 4: quién habló con quién, cuándo, durante cuánto tiempo y mediante qué protocolo. Incluye TCP y UDP; en UDP e ICMP, “conexión” significa flujo, no sesión con el estado de TCP. Incluso el sustantivo principal necesita contexto.

ts marca el primer paquete observado por Zeek. No demuestra que fuera el primer paquete existente en toda la ruta. uid identifica esa conexión dentro del conjunto de registros de Zeek y enlaza actividad relacionada. Permite pasar de conn.log a DNS, HTTP, TLS u otros registros, pero no es una identidad creada o confirmada por los extremos.

conn_state comprime una lectura del estado. S0 indica que se vio un intento sin respuesta; SF, que el establecimiento y el cierre parecieron normales; otros códigos describen rechazo, reinicios o cierres incompletos. Un sensor que sólo ve un sentido, que inicia tarde o que pierde tráfico puede clasificar el mismo intercambio de forma distinta. La etiqueta es válida dentro de su observación, no fuera de ella por decreto.

history guarda una cadena de letras. Las mayúsculas corresponden al originador y las minúsculas al respondedor. Las letras representan SYN, SYN-ACK, ACK, datos, FIN, RST, huecos, retransmisiones y otros eventos. Algunas se registran una sola vez por dirección; otras repiten de manera logarítmica. Sirve para reconocer la forma de una conversación, pero no conserva orden y multiplicidad suficientes para reconstruir cada paquete.

Los contadores también son inferencias instrumentales. En TCP, orig_bytes y resp_bytes se obtienen de números de secuencia y pueden ser inexactos, en especial en conexiones grandes. duration no abarca ciertos paquetes finales que ya no aportan carga nueva, aunque history pueda reflejarlos. Los contadores de paquetes son opcionales según el analizador habilitado. Las marcas de local o remoto dependen de Site::local_nets. Ausencia de campo no equivale automáticamente a ausencia de hecho.

Preguntar qué dejó de ver el sensor

missed_bytes indica bytes omitidos en huecos de contenido. Un valor distinto de cero suele hacer fallar el análisis del protocolo, aunque una parte se haya completado antes. capture_loss.log estima tráfico perdido a partir de discontinuidades en los números de secuencia TCP: Zeek observa un hueco y supone que corresponde a pérdida. La definición muestra tanto la utilidad como el límite del indicador.

reporter.log conserva advertencias y errores internos relacionados con el tratamiento del tráfico y las exigencias de cómputo. Al analizar un intervalo conviene alinear estos registros con los reinicios, cambios de filtro, presión de recursos y estado de la interfaz. No basta con saber que el fichero de conexiones existe.

Un cero en missed_bytes no ve lo que ocurrió antes de la interfaz, ni corrige una ruta asimétrica, ni deshace un filtro demasiado estrecho. Tampoco una estimación de pérdida convierte cada fila en sospechosa. La incertidumbre útil tiene coordenadas: momento, dirección, sensor y etapa de procesamiento.

La unidad de evidencia es un paquete documental

Para revisar una conclusión meses después, la fila debe viajar con el registro bruto y el esquema exacto; la versión de Zeek; los scripts cargados y la configuración relevante; el punto de red, interfaz y filtro; la fuente horaria y sus desvíos; capture_loss.log y reporter.log para la ventana; y los registros relacionados mediante el mismo uid.

Si la política lo permite, se añade un segmento PCAP inmutable o una huella que permita localizarlo bajo control. La captura tampoco ve toda la red y puede tener su propia pérdida o longitud limitada. Su valor es otro: deja que un revisor contraste la inferencia compacta con observaciones de menor nivel.

Cuando no hay PCAP, la respuesta profesional no es fingirlo. “El sensor Zeek situado en X observó y resumió…” define una afirmación comprobable. Decir “los paquetes fueron…” elimina una condición que los datos no eliminan.

También hay que congelar el significado de las columnas. La documentación señala que ip_proto apareció en Zeek 7.1. Los scripts pueden incorporar campos y alterar el registro. Sin versión, cabecera o esquema, un proceso posterior puede leer una fila antigua con una semántica nueva.

Fuentes