conn.log: una fila por conversación

Zeek mira el tráfico y, en lugar de guardar cada paquete, anota resúmenes. conn.log tiene una fila por conversación (una conexión TCP, un intercambio UDP, un ping): la hora de inicio ts, un identificador único uid, los dos extremos con sus puertos (id.orig_h, id.orig_p, id.resp_h, id.resp_p), el protocolo proto, el servicio que Zeek reconoció en service, la duration, los bytes de cada lado (orig_bytes y resp_bytes) y el estado final conn_state.

El originador es quien abrió la conversación y el respondedor quien la recibió: no es «cliente» ni «servidor» por definición, es quién empezó. Lo que no hay en una fila es el contenido: dice que hubo 5230 bytes de ida, no qué bytes eran.

conn_state resume el final de la conversación en un código corto. SF es lo normal: se estableció y se cerró bien. S0 es un intento de conexión del que nunca se vio respuesta. REJ es un intento que el otro lado rechazó activamente. RSTO es una conexión establecida que el originador cortó de golpe, y OTH es tráfico visto a mitad de la conversación, sin su inicio.

La columna history cuenta lo mismo letra a letra: en mayúscula lo que hizo el originador y en minúscula lo que hizo el respondedor (S es el primer paquete de apertura, h la respuesta de apertura, A la confirmación, D datos, F cierre y R corte). Un S suelto es un intento sin respuesta.

Consulta estados y conn. Un equipo de Ventas pidió, con un segundo de diferencia, conexión al puerto 23 y al 22 de la misma dirección, y quedaron en estados distintos.

El uid es el nombre propio de la conversación: no se repite y es la llave con la que se buscará esa misma conversación en otros registros. Por eso, cuando un hallazgo se anota para otra persona, se anota el uid, no solo la hora.

Filtra conn por el estado que significa «se vio el intento y no hubo respuesta». Solo una fila lo tiene.

orig_bytes son los bytes de carga que envió el originador y resp_bytes los que envió el respondedor. En una navegación normal el equipo manda poco (una petición) y recibe mucho (la página). Cuando un equipo manda mucho más de lo que recibe, la conversación es una subida, y eso es una pregunta, no una conclusión: puede ser una copia de seguridad o un archivo adjunto pesado.

Un recuento por estado da una idea de la salud del tráfico: casi todo debería ser SF. Las demás conversaciones no son culpables por sí mismas, pero cada una merece una mirada: una cae por un servicio apagado, otra por una regla que bloquea, otra porque la captura empezó tarde.

Cuenta en conn cuántas conversaciones tienen un estado distinto de SF.