El flujo, la unidad de la red en el SIEM

Un router o un cortafuegos puede exportar flujos: por cada conversación que pasa por él, escribe un registro con el origen, el destino, los puertos, el protocolo, los bytes y los paquetes en cada sentido, y el principio y el final. Los formatos se llaman NetFlow e IPFIX, y casi cualquier equipo de red los habla. No guardan el contenido: guardan la forma de la conversación. Por eso caben meses de flujos donde no cabrían horas de capturas.

Zeek, un sensor de red de código abierto que se coloca escuchando una copia del tráfico, escribe algo parecido en su registro de conexiones (conn.log) y añade tres campos que se usan a diario: un identificador por conexión, el protocolo que reconoció dentro y un estado que resume cómo fue. Abre el laboratorio y mira las dos tablas antes de contestar.

La dirección de los bytes cuenta una historia. Un puesto de trabajo, en general, recibe mucho más de lo que envía: abre un archivo del servidor, carga una página, consulta la base de datos. Por eso un flujo donde el puesto envía mucho y recibe casi nada destaca en cuanto se ordena la tabla por lo que sale.

Destacar no es lo mismo que acusar. Una impresora recibe más de lo que contesta, un respaldo sube gigas cada noche y un programa de cámaras manda sus grabaciones a la nube. La asimetría dice dónde mirar primero; el resto de las columnas —el destino, la hora, la duración— y el contexto deciden si es un problema. Ordena los flujos por lo que sale del origen.

Hay una diferencia práctica entre las dos fuentes. El exportador de flujos corta las conversaciones largas: cada cierto tiempo —aquí, media hora— cierra un registro y abre otro, aunque la conexión siga abierta. Zeek, en cambio, escribe una sola línea cuando la conexión termina, con su duración completa. Para encontrar una sesión que lleva horas abierta, Zeek la da hecha; con flujos, hay que sumar los tramos.

Las conexiones muy largas hacia fuera valen una pregunta. Una persona no mantiene una conversación de nueve horas con un servidor de internet; un programa sí: una VPN, un cliente de soporte remoto, un túnel. El identificador de Zeek (uid) es lo que permite seguir esa conexión en sus otros registros —DNS, TLS, HTTP— y lo que se pega en el ticket para que otro analista la encuentre sin buscarla.

La disciplina de este módulo es separar lo que el registro afirma de lo que solo sugiere. Un flujo afirma direcciones, puertos, volúmenes y tiempos. No afirma qué archivo viajaba, ni quién estaba delante del teclado, ni si lo que se mandaba era malicioso: eso se infiere, o se pregunta a otra fuente. Con TLS —casi todo el tráfico web de hoy— el contenido ni siquiera está a la vista del sensor.

Escribir un ticket con esa frontera clara es lo que lo hace útil. «Subió 2 GB a una dirección de fuera en cuarenta minutos» es un hecho que nadie te va a discutir. «Filtró datos de la empresa» es una conclusión que el registro no sostiene todavía, y si resulta que era un respaldo que alguien autorizó, el ticket queda mal y el siguiente lo leen con menos confianza.

La red ve direcciones, no equipos ni personas. Un hallazgo de red se convierte en algo que se puede escalar cuando la dirección tiene nombre: qué equipo es, de qué área y quién responde por él. Eso sale del inventario o del registro del servidor de direcciones (DHCP), que dice qué equipo tenía cada dirección a cada hora. Es un paso corto, y es el que más se olvida.