Leer http.log y ssl.log sin descifrar

http.log tiene una fila por petición y su respuesta: el método (GET, POST), el sitio (host), la ruta (uri), el agente de usuario (user_agent), los bytes de cuerpo de cada lado y el código de respuesta. Es mucho más detallado que una conversación de conn.log, porque aquí Zeek sí entiende el protocolo y lo lee.

Pero solo existe para el tráfico que viaja sin cifrar. Una petición dentro de una conversación TLS no genera fila, porque el sensor no puede leerla.

ssl.log anota cada saludo TLS: la versión negociada, el nombre de servidor que el cliente pidió (server_name), si el saludo terminó bien (established) y, cuando se ve, el sujeto del certificado. Las versiones se escriben TLSv10, TLSv12 y TLSv13; las más viejas están desaconsejadas y un sensor es una buena forma de encontrarlas en uso.

Una versión antigua no es un incidente, pero es un hallazgo: alguien, o algo, todavía habla así. Qué equipo y con qué sitio se anota para quien lo mantiene.

El agente de usuario dice qué programa hizo la petición. Los navegadores y los clientes de las aplicaciones de la empresa se presentan con nombres conocidos; un programa que se presenta con un nombre propio y no está en la lista aprobada es una pregunta: ¿quién lo instaló y para qué?

Compara agentes_aprobados con los agentes de http. El agente que sobra habló con un sitio, y ese sitio es lo que va al ticket.

nube-inventario.example aparece dos veces en ssl.log, pero no tiene ninguna fila en http.log. Eso no significa que no se pidió nada: significa que lo que se pidió viajó cifrado y el sensor no lo pudo leer. Es la diferencia entre «no pasó» y «no lo veo».

La consecuencia práctica es que el analista debe decir en su nota cuál de las dos cosas sabe. Una frase que afirma que no hubo peticiones es falsa; una que dice que no se ven peticiones porque van cifradas es verdadera.