De la alerta a su conversación

El sensor escribe un evento por cosa que ve: la alerta, la petición web, la consulta de nombres, el resumen del flujo cuando termina. Cada uno trae el flow_id de su conversación, de modo que uniendo por ese número se reconstruye lo que pasó sin abrir ningún paquete. La alerta aporta la regla, el evento http aporta la petición y la respuesta, el evento flow aporta los paquetes y los bytes en cada sentido.

Es el mismo gesto que un analista hace con un registro de acceso y un registro de aplicación: no se discute con una sola fuente. En alertas_dia están las tres alertas; los demás registros se leen por su flow_id.

El evento http guarda lo que la regla no dice: el método, el nombre del servidor, la ruta, el agente de usuario, el estado de la respuesta y su tamaño. El estado es el que separa una petición que consiguió algo de una que chocó con algo: una familia de números empieza por 2 y significa éxito; otra empieza por 4 y significa que el servidor rechazó o no encontró lo pedido.

La alerta de gravedad más alta del día es la de la ruta de administración. Antes de escalarla, mira qué contestó el servidor a esa petición.

El evento http también guarda bytes_respuesta, el tamaño de lo que contestó el servidor, y el evento flow cuenta los paquetes y los bytes en cada sentido: toserver es lo que fue hacia el servidor, toclient, lo que volvió. No son el mismo número, porque el segundo incluye todos los encabezados de la conversación y el primero solo el cuerpo de la respuesta.

El tamaño separa una consulta pequeña de un envío grande. Para la alerta del agente de usuario no aprobado, lee cuántos bytes tenía la respuesta HTTP.

Un ticket no puede decir solo una dirección: tiene que decir qué equipo es y para qué se usa, para que quien lo reciba sepa a quién llamar. El inventario lo da. Cuando la dirección no aparece en él, ese es en sí mismo un hallazgo: un equipo que nadie tenía registrado.

La alerta del agente de usuario sale de una dirección de la casa hacia fuera. Averigua qué equipo es.

La tercera alerta es de una regla que mira el nombre del servidor en el saludo de una conexión TLS. El resto de la conversación va cifrado: el sensor no ve las rutas, los encabezados ni el contenido, solo el saludo, la versión, el nombre y los volúmenes. Por eso el evento tls es corto y el flow pesa mucho.

Esto limita lo que se puede afirmar. Se puede decir con quién habló el equipo, cuándo, cuánto envió y si el servicio está en una lista; no se puede decir qué contenía lo que se envió.