El uid: unir registros de una misma conversación

Cuando Zeek ve una conversación nueva le asigna un identificador, el uid, y lo escribe en todos los registros que hablan de ella. Si una conversación web aparece en conn.log y en http.log con el mismo uid, son la misma conversación vista desde dos ángulos: el resumen de la conexión y el detalle de la petición.

Dentro de una conversación puede haber varias peticiones web (HTTP permite reutilizar la conexión): por eso http.log trae además trans_depth, que numera las peticiones de una misma conexión. Mismo uid, distinta profundidad: misma conexión, otra petición.

El uid une las filas de una misma conversación. Pero una consulta de DNS y la conexión web que viene después son conversaciones distintas: la primera es un intercambio UDP con el servidor de nombres y la segunda una conexión TCP con el servidor web. Tienen uid distintos.

Para atar un nombre pedido con la conexión que lo usó se cruzan otros campos: el mismo originador, la dirección devuelta en answers que reaparece como id.resp_h de la conexión, y la hora, con la conexión poco después de la consulta. Es un cruce con criterio, no una igualdad exacta, y por eso se anota con qué campos se hizo.

Compara dns_log y conn_log: la consulta de las 14:20:03 y la conexión web del mismo equipo.

Pasar de http.log a conn.log por uid da lo que la petición sola no tiene: la duración de la conexión, los puertos y los bytes totales de cada lado, incluidas las cabeceras. request_body_len en http.log es solo el cuerpo de la petición; orig_bytes en conn.log cuenta todo lo que envió el originador, así que casi nunca coinciden.

Filtra http_log por las peticiones que envían un cuerpo al servidor, toma su uid y búscalo en conn_log.

La petición POST trae el nombre de servidor al que se pidió (host). dns_log guarda qué dirección devolvió el servidor de nombres para ese nombre. Con esos dos datos se sabe a qué dirección fue la conexión, y se comprueba contra id.resp_h de http_log: si no coincidieran, la conversación se habría hecho sin consultar el DNS o habría otra explicación que buscar.

ts es la hora de inicio de la conversación y duration cuánto duró. Sumando las dos se obtiene la hora en que terminó, que sirve para ordenar un incidente: si un equipo hace otra cosa justo cuando termina la subida, ambos hechos pueden ir juntos en la línea de tiempo.

Toma la conexión de la petición POST, suma su duración a su hora de inicio y descarta las fracciones de segundo.