Leer una alerta con su contexto

Cada alerta trae los campos de siempre: la hora, el sensor, un identificador de flujo (flow_id) que sirve para unirla con otros registros de la misma conversación, las direcciones y los puertos, el protocolo de aplicación y, dentro, la regla que coincidió —sid y rev—, su mensaje, su gravedad (1 es la más alta) y la acción que el sensor tomó con ese tráfico. Todo eso es lo que el sensor vio.

Lo que no dice es lo que pasó después. Que una petición a una ruta de administración coincida con una regla no prueba que el servidor respondiera con nada útil; puede haber contestado un error. La alerta es una pista que apunta a un sitio donde mirar, no un veredicto. Esa es la causa de que una alerta de gravedad 1 pueda estar cerrada en dos minutos y una de gravedad 3 merezca una hora.

Tres de las alertas de la mañana son la misma regla: alguien de fuera pidió una ruta de administración a los portales de la empresa. Se parecen tanto que en la cola ocuparían tres filas iguales. Lo que las distingue está en el registro HTTP, unido por flow_id: el código de respuesta y los bytes devueltos. Un 404 es «aquí no hay nada», un 403 es «hay algo pero no puedes», y un 200 con un cuerpo grande es «aquí tienes».

Une cada flujo de la regla de administración con su fila en http y quédate con el que el servidor contestó con la página.

Una dirección es un dato y un equipo es una persona a la que llamar. Para escalar hace falta el segundo: qué servidor es, para qué se usa y de quién es. El inventario traduce de uno al otro, y es la parada obligada antes de abrir un ticket, igual que en el resto del puesto.

Toma el flujo que encontraste en la tarea anterior, mira a qué dirección de la empresa iba y ponle nombre.

La columna de acción tiene dos valores en este registro. allowed significa que el sensor avisó pero dejó pasar el tráfico: así actúa un sensor de detección con cualquier regla, y también uno en línea con una regla que solo alerta. blocked significa que el sensor descartó el tráfico: solo un sensor en línea con una regla de acción drop puede producirlo.

Eso cambia qué hay que mirar. Con allowed, la pregunta es si la petición funcionó, y se responde con el código del servidor. Con blocked ya no hay nada que preguntarle al servidor: nunca la recibió. Cuando el registro HTTP trae un guion donde iría el código, es esa señal.

No todas las alertas son de fuera hacia dentro. La última de la mañana es una regla de salida: alguien de la empresa habló con un destino externo usando un agente de usuario que la casa no aprobó. En ese caso el equipo de dentro es el protagonista, y el destino externo es solo el sitio al que habló. Lo que se escala es qué equipo es, de dónde y de quién.

Sigue la alerta del agente no aprobado hasta el equipo que la originó y ponle el nombre que le da el inventario.