De la alerta a la acción

La alerta dice que el sensor vio tráfico que coincide con lo que la regla describe. No dice si la petición funcionó. Eso está en el registro del servidor: un error 404 es «aquí no hay nada», un 403 es «hay, pero no te dejo» y un 200 con un cuerpo grande es «aquí tienes».

El orden sano es confirmar con ese registro, avisar al dueño del servicio con lo que se sabe y solo entonces actuar sobre el origen. Bloquear de inmediato una dirección por una sola alerta puede ser un acierto y puede ser cortar a un cliente: la decisión se apoya en evidencia.

En la cola conviven alertas de dos tipos: las que el sensor solo anotó y las que además descartó porque la regla estaba en prevención. De las segundas, el paquete no llegó; de las primeras, sí. Por eso la columna de la acción del sensor es la primera que se lee: separa «hay que investigar si funcionó» de «ya no llegó».

Consulta alertas. Una de las cinco la bloqueó el sensor.

De las alertas que el sensor solo anotó, la importante es la que el servidor contestó con la página. Une cada evento con su fila en respuesta_del_servidor y quédate con el que no fue bloqueado y obtuvo un código 200 con un cuerpo grande, de decenas de kilobytes.

Un ticket que solo dice una dirección no sirve. Debe decir qué equipo es, para qué se usa y de quién, para que quien lo reciba sepa a quién llamar. El inventario traduce de una cosa a la otra.

Cruza el destino del evento de la tarea anterior con inventario.

Cada acción sobre el perímetro tiene su aprobador, y no es el mismo para todas. El procedimiento distingue el bloqueo temporal, que el analista de turno puede hacer en minutos para contener, del bloqueo permanente, que cambia el conjunto de reglas del cortafuegos y se aprueba más arriba. Conocer esa diferencia evita dos errores: esperar un día para contener algo urgente, y dejar permanente algo que se hizo con prisa.

Consulta procedimiento.