Seguir un flujo de punta a punta

Seguir el flujo TCP de un paquete hace dos cosas. Primero, aplica un filtro de visualización de la forma tcp.stream eq N, donde N es el número que el analizador asignó a esa conversación; la lista queda reducida a esa conexión. Segundo, junta los datos de aplicación de todos los paquetes en orden y los muestra como un texto continuo, distinguiendo lo que escribió el cliente de lo que contestó el servidor.

Cuando el protocolo va en claro, el resultado se lee como una conversación. Cuando va cifrado, se ven bytes sin sentido y nada más; entonces se pasa a los metadatos: tamaños, tiempos y nombre de servidor. El analizador no inventa lo que no está en la captura.

La tabla flujos lista las cinco conversaciones numeradas. Tres de ellas son pequeñas peticiones de inventario al servidor de bodega; otra va cifrada hacia un servicio externo; y una más mueve unos dos megabytes en unos segundos. La que más pesa entre las que van en claro es la que conviene leer entera, porque de ahí sale la pregunta de qué se estaba descargando.

En transcripcion está lo que mostró «seguir flujo» en cada conversación. Lo que se pide es el nombre del archivo que se solicitó en la conversación de mayor tamaño.

En una respuesta HTTP en claro, las cabeceras cuentan cosas del servidor: qué tipo de contenido envía, y a veces con qué programa responde y qué versión usa. Esa cabecera es una pista de inventario útil para un defensor —saber qué software atiende en la red— y también un dato que convendría no publicar, por razones de higiene.

No hace falta adivinar nada: se lee tal cual en el seguimiento del flujo.

El número de paquete (frame.number) es la posición en el archivo: el 1 es el primero que se capturó. El número de flujo (tcp.stream) identifica la conversación y lo asigna el analizador en el orden en que aparece el primer paquete de cada una, empezando por cero. Todos los paquetes de una conversación comparten número de flujo, pero cada uno tiene el suyo de paquete, y esos números no tienen por qué ser consecutivos porque las conversaciones se entrelazan.

Confundirlos produce informes que nadie puede reproducir: «mira el 3» no dice si es el paquete 3 o el flujo 3.

La conversación 1 va hacia un servicio externo por el puerto de la web cifrada. «Seguir flujo» solo devuelve bytes ilegibles: el contenido no se puede leer y no hay que intentar lo contrario sin autorización ni claves legítimas. Pero no se queda a ciegas: quedan el nombre de servidor del saludo, la cantidad de datos, la duración y el ritmo. Con eso se puede decir con quién habló y cuánto, y se puede comparar con lo que la empresa espera de ese puesto.

Lo que no se puede decir es qué se envió. La frontera entre lo que se ve y lo que se supone es la que separa un informe sólido de uno que se desmorona.