Problemas con las marcas de tiempo PCAP: cuándo inspeccionar, normalizar o reescribir el tiempo de captura

Las marcas de tiempo son parte de la evidencia en la captura de un paquete. Explican el orden, la latencia, el tiempo de retransmisión, las brechas entre solicitud y respuesta y si un problema coincide con el registro de una aplicación. Cuando las marcas de tiempo son incorrectas, toda la investigación puede desviarse.

Pero la reparación de la marca de tiempo es delicada. Cambiar el tiempo de captura puede facilitar el análisis y al mismo tiempo hacer que el archivo sea menos fiel al evento original.

Problemas comunes de marcas de tiempo

Los problemas de marca de tiempo PCAP incluyen:

• los paquetes aparecen fuera de orden
• las marcas de tiempo saltan hacia atrás
• las marcas de tiempo son todas cero
• la resolución es inferior a la esperada
• la captura abarca un rango de tiempo imposible
• El reloj de la máquina virtual o del host cambia durante la captura
• Las capturas fusionadas utilizan diferentes relojes.
• Los supuestos de zona horaria confunden los informes humanos.

Algunos de estos son problemas de visualización. Algunos son problemas de captura. Algunos son problemas de fusión. La estrategia de reparación depende de cuál sea.

Orden separado del significado del reloj de pared

El orden de los paquetes y la hora del reloj de pared están relacionados pero no son idénticos. Una captura puede preservar el orden de los paquetes y al mismo tiempo tener valores de reloj de pared inútiles. Otra captura puede tener valores de reloj de pared plausibles, pero incluir transmisiones fusionadas desde diferentes puntos de captura que hacen que las comparaciones de tiempos sean inseguras.

Antes de reescribir las marcas de tiempo, pregunte:

• ¿Es confiable el pedido de paquetes?
• ¿Es confiable el tiempo relativo?
• ¿Se necesita el tiempo absoluto del reloj de pared?
• ¿La captura está fusionada de múltiples fuentes?
• ¿Los registros de aplicaciones proporcionan un ancla externa?
• ¿Las herramientas posteriores malinterpretarán las marcas de tiempo actuales?

Esas preguntas determinan si es apropiada la inspección, anotación, normalización o reescritura.

Cuando la normalización ayuda

La normalización de la marca de tiempo puede resultar útil cuando el tiempo absoluto original no es importante, pero sí el orden relativo y el espaciado. Por ejemplo, una captura de laboratorio con un reloj del sistema incorrecto aún puede mostrar un tiempo de solicitud-respuesta válido. Normalizar la hora de inicio puede hacer que los informes sean más fáciles de leer sin cambiar el comportamiento relativo.

La salida debe registrar:

• primera marca de tiempo original
• primera marca de tiempo normalizada
• si los deltas se conservaron
• paquetes afectados
• motivo de la normalización

Sin ese registro, un futuro ingeniero no puede decir si la evidencia de tiempo es original o editada.

Cuando reescribir es arriesgado

Reescribir marcas de tiempo es arriesgado cuando la captura debe correlacionarse con:

• registros del servidor
• registros de cámara
• Rastreos USB o seriales
• cronogramas del incidente
• evidencia legal o de cumplimiento
• capturas de red multipunto

En esos casos, cambiar las marcas de tiempo puede hacer que el archivo sea más fácil de inspeccionar pero más difícil de confiar. Un mejor primer paso puede ser la anotación: documentar el problema del reloj y dejar intacta la captura sin formato.

Dónde encaja la cirugía PCAP

La cirugía PCAP se basa en ediciones controladas, no en mutaciones casuales. El trabajo de marca de tiempo debe seguir la misma regla que la suma de verificación o el recorte de paquetes: inspeccionar primero, decidir después, reescribir solo cuando la evidencia lo respalde.

Un buen flujo de trabajo de cirugía PCAP debería ayudar a responder:

• ¿Qué anomalía de marca de tiempo existe?
• ¿Cuántos paquetes se ven afectados?
• ¿El pedido sigue siendo confiable?
• ¿Sigue siendo útil el tiempo relativo?
• ¿Qué reescritura o normalización se aplicó?
• ¿Se puede reproducir el cambio?

Para los ingenieros de protocolos, el valor no es simplemente cambiar un archivo. El valor es producir una captura y un rastro de razonamiento que otro ingeniero pueda validar.