Les erreurs de somme de contrôle PCAP ne sont pas toujours des paquets défectueux : comprendre les preuves de déchargement

Les captures de paquets affichent souvent des erreurs de somme de contrôle TCP, UDP ou IP. Parfois, ces erreurs sont le signe d’une véritable corruption. Parfois, ils signifient que la capture a été effectuée avant que la carte réseau n'ait rempli la somme de contrôle. Si les ingénieurs traitent chaque avertissement de somme de contrôle comme un paquet défectueux, ils peuvent rechercher le mauvais problème ou réécrire des preuves valides.

Le déchargement de la somme de contrôle est l’une des sources les plus courantes d’interprétation trompeuse du PCAP.

Pourquoi le déchargement crée des captures déroutantes

Les adaptateurs réseau modernes peuvent calculer des sommes de contrôle dans le matériel. Le système d'exploitation peut transmettre un paquet à l'adaptateur avec des champs de somme de contrôle réservés. Si la capture a lieu avant la fin du matériel, le PCAP peut afficher une somme de contrôle invalide même si le paquet placé sur le câble était correct.

Ceci est particulièrement courant dans les captures sortantes locales. Le fichier de capture enregistre ce que l'hôte a préparé, pas nécessairement l'image filaire finale exacte après le déchargement.

Demandez où le paquet a été capturé

L'interprétation de la somme de contrôle dépend de la position de capture :

• capturé sur l'hôte expéditeur avant le déchargement de la carte réseau
• capturé sur un port miroir ou appuyez après la transmission
• capturé sur l'hôte récepteur
• capturé à l'intérieur d'une VM ou d'une limite de conteneur
• capturé sur un adaptateur virtuel

Un avertissement de somme de contrôle sortant sur l’expéditeur n’est pas la même chose qu’un échec de somme de contrôle observé lors d’un tap indépendant. Le point de capture fait partie des preuves.

Ne réécrivez pas les sommes de contrôle trop tôt

Il peut être tentant de recalculer immédiatement les sommes de contrôle. Cela peut rendre les outils en aval plus silencieux, mais cela modifie également les preuves. Avant de procéder au montage, décidez à quelle question la capture doit répondre.

Si l’objectif est le débogage de la couche application, le recalcul des sommes de contrôle pour plus de lisibilité peut être acceptable s’il est clairement documenté. Si l’objectif est de prouver la corruption des câbles, la réécriture des sommes de contrôle peut effacer les preuves mêmes faisant l’objet d’une enquête.

Un workflow contrôlé enregistre :

• quels champs de somme de contrôle ont été marqués
• direction du paquet
• point de capture
• si le déchargement est probable
• si le fichier de sortie a réécrit les octets de la somme de contrôle
• quels paquets ont changé

La modification doit être délibérée et non automatique.

Distinguer le délestage de la corruption réelle

Signes indiquant que le déchargement de la somme de contrôle peut être impliqué :

• principalement des paquets sortants sur l'hôte de capture
• de nombreuses sommes de contrôle signalées selon un modèle cohérent
• la circulation fonctionne malgré les avertissements
• le point de capture indépendant ne montre pas les mêmes erreurs
• environnement virtualisé ou nécessitant beaucoup de déchargement

Signes indiquant qu’une véritable corruption peut être impliquée :

• chutes côté récepteur
• un appui indépendant confirme les sommes de contrôle invalides
• la perte ou la retransmission de paquets correspond aux échecs de la somme de contrôle
• des erreurs apparaissent dans les deux sens sans explication de déchargement
• la couche de liaison ou le matériel de capture signale les erreurs

Le but n’est pas d’ignorer les avertissements de somme de contrôle. Le but est de les interpréter dans leur contexte.

La place de la chirurgie PCAP

PCAP Surgery est conçu pour un travail de capture de paquets fondé sur des preuves. Cela devrait aider les ingénieurs à inspecter les métadonnées des paquets, à comprendre pourquoi une capture semble incorrecte et à appliquer des opérations de réécriture contrôlées uniquement lorsqu'elles sont justifiées.

Pour les cas de somme de contrôle, la limite du produit est importante. Il ne devrait pas « réparer » silencieusement les captures et prétendre que rien n’a changé. Un outil chirurgical utile explique :

• source d'avertissement de somme de contrôle
• contexte de déchargement probable
• ensemble de paquets affecté
• valeurs avant et après une fois réécrites
• si le changement est une normalisation ou une réparation

Cela donne aux ingénieurs de protocole une capture qu'ils peuvent défendre, et pas seulement un fichier qui s'ouvre silencieusement.