Anatomía de una alerta en EVE JSON

Todos los eventos de EVE comparten unos campos: timestamp (la hora, con zona), event_type (qué clase de evento es: alert, http, dns, tls, flow, fileinfo, stats, entre otros), src_ip, src_port, dest_ip, dest_port, proto y, si el sensor reconoció el protocolo de aplicación, app_proto. Hay dos que sirven para unir eventos: flow_id, que es el mismo para todos los eventos de una misma conversación, y community_id, un identificador de flujo pensado para cruzar lo que escribe Suricata con lo de otras herramientas (aparece si se configura).

Si el sensor lee un archivo de captura, pcap_cnt dice el número de paquete dentro de ese archivo, y con él se vuelve a la prueba original. Abre eve-alertas.json.

Dentro de una alerta hay un objeto alert con los campos que describen la regla y lo que hizo el sensor: signature_id (el sid), rev (la revisión), signature (el texto del msg), category (la clasificación, que sale del classtype), severity (un número, donde 1 es la más alta), gid (el grupo, normalmente 1) y action, que vale allowed o blocked.

allowed quiere decir que el tráfico no fue descartado; blocked, que el sensor lo descartó. Es lo que deja ver, de un vistazo, qué alertas ya fueron contenidas y cuáles dejaron pasar el tráfico. Busca en el archivo la única alerta cuya acción fue bloquear y anota la conversación a la que pertenece.

severity es un número que viene de la regla, no del incidente. Una alerta de gravedad 1 dice que la regla fue escrita para algo que se considera grave; no dice que aquí haya pasado algo grave. Una petición a una ruta de administración puede tener la gravedad más alta y terminar en un error del servidor; una conexión cifrada a un servicio no aprobado puede tener una gravedad baja y ser la que importa.

Por eso la gravedad ordena la cola pero no la decide. Lo que decide es lo que se encuentra al abrir los demás registros de la conversación, como se hará en la sala siguiente.

Una alerta no es una prueba: es un apunte del sensor sobre un punto de la captura. Si el sensor leyó un archivo de captura, pcap_cnt es el número de paquete donde se disparó, y con él se abre el mismo archivo en un analizador de paquetes y se mira el tráfico con los propios ojos. Es el puente entre lo que el sensor dijo y lo que el tráfico contiene.

En eve-alertas.json hay una alerta de la regla que vigila las peticiones a una zona de administración. Anota el número de paquete donde saltó.

Que una alerta diga allowed se malentiende a menudo. Quiere decir que el sensor no descartó ese tráfico, no que lo evaluó y lo dio por bueno. Una regla con acción alert solo avisa, así que su allowed es lo esperado; el blocked aparece donde una regla con acción de descarte, como drop, cortó el tráfico.

Por tanto, una alerta con allowed sobre una petición a una zona de administración significa que la petición llegó al servidor. Qué contestó el servidor es otra pregunta, y está en otro registro.