El registro de flujo y lo que no dice

Un flujo es un conjunto de paquetes que pasan por un punto de observación durante un intervalo de tiempo y comparten propiedades de sus cabeceras: origen, destino, puertos y protocolo. Un equipo de red lo cuenta y, cuando el flujo termina, exporta un registro. Los formatos se llaman NetFlow (la versión 9 está descrita en el RFC 3954) e IPFIX (el estándar del IETF, RFC 7011, construido sobre la versión 9). Los nombres de los campos de IPFIX están en un registro público de la IANA: por ejemplo octetDeltaCount (bytes), packetDeltaCount (paquetes), tcpControlBits (las banderas TCP vistas) y flowEndReason (por qué se cerró el registro).

Mira la tabla del laboratorio: flujos trae cuándo empezó y cuándo terminó, las dos direcciones y puertos, el protocolo, los bytes, los paquetes, las banderas y el motivo del cierre. Es la forma de la conversación. Por eso cabe un año de flujos donde no cabría una semana de capturas.

En lo habitual cada registro cuenta un solo sentido: la ida y la vuelta de una misma conversación son dos filas, con origen y destino invertidos. Ejecuta flujos y busca el par de las 09:02:11.

El exportador no espera a que una conversación termine para escribir su registro: si fuera así, una sesión de ocho horas no existiría en los datos hasta la noche. Tiene dos relojes configurables. El tiempo de inactividad cierra un registro cuando no han llegado paquetes en un rato (el flujo se da por terminado). El tiempo máximo corta un registro que lleva abierto demasiado y abre otro de inmediato, aunque la conversación siga.

El resultado es que una sola sesión larga queda repartida en varias filas con el mismo origen, destino y puertos, una a continuación de la otra, y la última con el cierre normal. La columna motivo_cierre lo cuenta. Si cuentas filas pensando que cada una es una conversación, cuentas mal.

Ejecuta flujos | where motivo_cierre == "tiempo-maximo" y fíjate en qué comparten las dos filas.

Un flujo no trae contenido, ni la dirección web visitada, ni el nombre del equipo, ni la persona que lo usaba. Esos datos vienen de otras fuentes: el inventario, el DNS, el registro del proxy, la telemetría del equipo. El flujo dice cuánto, cuándo y con quién; no dice qué.

Tampoco dice si lo que ocurrió fue legítimo. Cuatro gigas subidos por la noche pueden ser la copia de seguridad o un robo: el registro es idéntico. Y hay límites de la propia medida: si el exportador cierra por tiempo máximo, una conversación parece varias; si el sentido de cada fila es uno solo, hay que juntar las dos para ver la conversación entera; si pasa por una traducción de direcciones, el origen que se ve puede no ser el del equipo.

Algunos exportadores no cuentan todos los paquetes: con muestreo miran uno de cada N y el colector estima el total multiplicando. En un enlace grande es la única forma de no ahogar al equipo, pero tiene un precio: se ven bien las conversaciones grandes y se pueden perder las pequeñas, como una sola consulta de unos pocos paquetes. Con muestreo, un flujo ausente no demuestra que no hubo conversación.

El muestreo y los tiempos de cierre se configuran en cada exportador y pueden ser distintos entre equipos de la misma red. Antes de sacar una conclusión de unas cifras hay que saber con qué se midieron. Abre la tabla exportadores y lee la configuración de los dos.

Los dos registros del router de borde dicen que el origen es una dirección pública, la misma en ambos. Es la dirección que toda la oficina usa para salir a Internet: la traducción de direcciones ya se hizo antes de que el router los viera. Ejecuta flujos | where ip_origen == "192.0.2.109" y inventario para confirmarlo.

Con esa pieza sola no se sabe qué puesto fue. La respuesta está en otro punto de observación: el firewall interno ve las mismas conversaciones antes de la traducción, con la dirección de cada puesto. Cruzar los dos exige hora, destino y puertos: no hay un campo que una un registro con otro.