Salida estructurada de alertas y eventos

Todo evento de EVE trae los campos comunes: timestamp, event_type, la tupla de red (src_ip, src_port, dest_ip, dest_port, proto) y un flow_id. Ese identificador es el mismo para todos los eventos que pertenecen a una misma conexión: la alerta, el registro del flujo, la consulta de nombres.

Una alerta dice qué regla coincidió, pero casi nunca dice qué ocurrió alrededor. Para eso se busca, en el mismo archivo, los demás eventos con ese mismo flow_id.

La alerta de una regla de nombres solo trae su mensaje. El detalle —el nombre exacto que se consultó y lo que el servidor contestó— vive en el evento de tipo dns del mismo flujo.

Consulta la alerta de las 07:41 y trae los eventos de su flujo con la consulta WHERE flow_id. Lee la respuesta del evento de nombres.

La sección eve-log de suricata.yaml decide qué tipos de evento se escriben. La documentación avisa de que activarlos todos baja el rendimiento y llena el disco, así que se activa lo que se va a usar. El riesgo es el contrario: apagar un tipo y descubrir, en medio de una investigación, que esa evidencia nunca se guardó.

Consulta salidas_eve y piensa qué tipo de evento daría el nombre de servidor y el certificado de las conexiones cifradas.

El campo alert.action de una alerta toma dos valores: allowed, si el paquete siguió su camino, y blocked, si el sensor lo retuvo. Contar los bloqueados mide lo que el sensor hizo, y no lo que las reglas dicen que harían.

Consulta los eventos de tipo alert del extracto y cuenta los que quedaron bloqueados.

Cada alerta trae una severity, un número del 1 al 3 que sale de la clase o de la regla. Un detalle que confunde al principiante: 1 es la más grave y 3 la menos. Ordenar la cola de mayor a menor número pone al fondo justo lo que más importa.