Alertas de Suricata con contexto de Zeek

Suricata y Zeek no se conocen entre sí, y cada uno nombra las conversaciones a su manera: Suricata con un flow_id y Zeek con un uid. Para unir sus registros se usa el community_id: una huella que sale de las direcciones, los puertos y el protocolo, y que los dos calculan igual cuando se activa en cada uno.

Con él se pasa de una alerta a la conversación que la provocó sin buscar a mano por dirección y hora. Los valores de la consola están abreviados; en un registro real el campo es un hash más largo.

La regla de la ráfaga de intentos de SSH desde fuera dispara una alerta que dice qué regla coincidió y entre qué direcciones. Lo que el analista necesita después es la fila de Zeek de esa conversación: su uid, para anotarlo, y su estado, para saber qué pasó.

Busca la alerta de esa regla, toma su community_id y encuéntralo en conn.

La alerta de SSH tiene acción allowed: el sensor avisó y dejó pasar. Con eso solo no se sabe si hubo sesión. Zeek sí lo dice: REJ es un intento que el destino rechazó, sin que se estableciera nada, y los bytes de carga están en cero.

Esa es la diferencia entre una alerta de intento y una alerta de acceso. La primera se registra y se vigila; la segunda se escala.

Dos de las cuatro alertas son de la misma regla, la de nombres de servidor en una lista de vigilancia, y vienen de dos puestos distintos. Se parecen tanto que en la cola ocuparían dos filas iguales. Lo que las distingue está en Zeek: cuánto duró cada conversación y cuánto se movió.

Una conversación de unos segundos con poca carga y otra de media hora con megabytes de subida no son lo mismo, aunque la firma sea la misma. El inventario le pone nombre al equipo que hay que revisar primero.