Problèmes d'horodatage PCAP : quand inspecter, normaliser ou réécrire l'heure de capture

Les horodatages font partie des preuves dans une capture de paquet. Ils expliquent l'ordre, la latence, le délai de retransmission, les écarts entre les demandes et les réponses et si un problème correspond à un journal d'application. Lorsque les horodatages sont erronés, toute l’enquête peut dériver.

Mais la réparation de l'horodatage est sensible. La modification de l'heure de capture peut faciliter une analyse tout en rendant le fichier moins fidèle à l'événement d'origine.

Problèmes d'horodatage courants

Les problèmes d’horodatage PCAP incluent :

• les paquets semblent dans le désordre
• les horodatages sautent en arrière
• les horodatages sont tous nuls
• la résolution est inférieure à celle attendue
• la capture s'étend sur une plage de temps impossible
• L'horloge de la VM ou de l'hôte change pendant la capture
• les captures fusionnées utilisent des horloges différentes
• les hypothèses sur les fuseaux horaires confondent les rapports humains

Certains d'entre eux sont des problèmes d'affichage. Certains sont des problèmes de capture. Certains sont des problèmes de fusion. La stratégie de réparation dépend de laquelle il s’agit.

Séparer la commande de la signification de l'horloge murale

L’ordre des paquets et l’heure de l’horloge murale sont liés mais pas identiques. Une capture peut préserver l'ordre des paquets tout en ayant des valeurs d'horloge murale inutiles. Une autre capture peut avoir des valeurs d'horloge murale plausibles, mais inclure des flux fusionnés provenant de différents points de capture, ce qui rend les comparaisons temporelles dangereuses.

Avant de réécrire les horodatages, demandez :

• la commande par paquets est-elle fiable ?
• le timing relatif est-il fiable ?
• l'heure absolue de l'horloge murale est-elle nécessaire ?
• la capture est-elle fusionnée à partir de plusieurs sources ?
• les journaux d'application fournissent-ils un point d'ancrage externe ?
• les outils en aval interpréteront-ils mal les horodatages actuels ?

Ces questions déterminent si l'inspection, l'annotation, la normalisation ou la réécriture sont appropriées.

Quand la normalisation aide

La normalisation de l'horodatage peut être utile lorsque l'heure absolue d'origine n'est pas importante, mais que l'ordre relatif et l'espacement le sont. Par exemple, une capture de laboratoire avec une horloge système incorrecte peut toujours afficher un timing requête-réponse valide. La normalisation de l'heure de début peut faciliter la lecture des rapports sans modifier le comportement relatif.

La sortie doit enregistrer :

• premier horodatage d'origine
• premier horodatage normalisé
• si les deltas ont été préservés
• paquets affectés
• raison de la normalisation

Sans cet enregistrement, un futur ingénieur ne peut pas dire si les preuves temporelles sont originales ou modifiées.

Quand la réécriture est risquée

Réécrire les horodatages est risqué lorsque la capture doit être corrélée avec :

• journaux du serveur
• journaux de caméra
• Traces USB ou série
• chronologie des incidents
• preuves juridiques ou de conformité
• captures de réseau multipoint

Dans ces cas-là, la modification des horodatages peut rendre le fichier plus facile à inspecter mais plus difficile à faire confiance. Une meilleure première étape peut être l'annotation : documentez le problème d'horloge et laissez la capture brute intacte.

La place de la chirurgie PCAP

La chirurgie PCAP est construite autour de modifications contrôlées et non de mutations fortuites. Le travail d'horodatage doit suivre la même règle que la somme de contrôle ou le découpage des paquets : inspectez d'abord, décidez ensuite, réécrivez uniquement lorsque les preuves le soutiennent.

Un bon flux de travail de chirurgie PCAP devrait aider à répondre :

• quelle anomalie d'horodatage existe-t-il ?
• combien de paquets sont concernés ?
• la commande est-elle toujours fiable ?
• le timing relatif est-il toujours utile ?
• quelle réécriture ou normalisation a été appliquée ?
• le changement peut-il être reproduit ?

Pour les ingénieurs de protocoles, la valeur ne consiste pas simplement à modifier un fichier. La valeur produit une capture et une piste de raisonnement qu'un autre ingénieur peut valider.