La réparation d'un fichier PCAP corrompu commence par des preuves, pas par une conversion aveugle

Comment les ingénieurs de protocoles doivent aborder les fichiers PCAP tronqués ou corrompus avant de les modifier, de les convertir ou de les transmettre à un autre outil.

PCAP, réparation, capture de paquets, dépannage

Un fichier PCAP corrompu peut arrêter une enquête au pire moment possible. La capture peut être la seule preuve provenant d'un site client, d'une reproduction en laboratoire ou d'un incident de production. Lorsqu'un outil refuse de l'ouvrir, l'impulsion la plus rapide est de le convertir, de le découper ou de le faire passer par un autre analyseur.

Cela peut fonctionner. Cela peut également détruire les indices expliquant ce qui n’a pas fonctionné. La réparation doit commencer par des preuves.

Identifier la limite de défaillance

Avant de modifier le fichier, déterminez où il échoue :

  • l'en-tête global ne peut pas être lu
  • le type de lien est inattendu
  • l'en-tête du paquet est incomplet
  • la longueur capturée dépasse la taille restante du fichier
  • la longueur originale et la longueur capturée sont incohérentes
  • les champs d'horodatage semblent invalides
  • les données des paquets sont tronquées
  • les octets de fin restent après le dernier paquet valide

Chaque panne implique une stratégie de réparation différente. Un mauvais en-tête global n’est pas la même chose qu’un dernier paquet tronqué. Un mauvais type de lien n’est pas la même chose qu’une confusion lors du déchargement de la somme de contrôle.

Préserver la capture originale

N’écrasez jamais la capture originale. Un flux de travail de réparation doit créer un nouveau fichier et enregistrer ce qui a changé. Si le fichier d'origine constitue une preuve dans un dossier de support, une révision juridique ou une réclamation auprès d'un fournisseur, les octets d'origine sont importants.

Un flux de travail discipliné permet de conserver :

  • hachage du fichier d'origine
  • emplacement de l'échec de l'analyseur
  • nombre de paquets valides avant l'échec
  • octets coupés ou réécrits
  • index de paquets affectés
  • hachage du fichier de sortie
  • notes expliquant pourquoi la modification était sûre

Ce n'est pas de la bureaucratie. C’est ainsi que les ingénieurs évitent de rendre la capture moins fiable.

Modèles courants de corruption

De nombreux cas PCAP corrompus sont simples :

  • le processus de capture a été interrompu en cours d'écriture
  • le fichier a été copié avant que l'auteur ne le ferme
  • l'espace disque est épuisé
  • un outil a écrit une longueur de paquet invalide
  • le mauvais type de fichier a été renommé « .pcap »
  • les attentes de la couche de liaison ne correspondent pas à la charge utile

La réparation doit correspondre au modèle. Si seul le paquet final est incomplet, la suppression de l'enregistrement partiel final peut récupérer le préfixe utile. Si les longueurs des paquets sont incohérentes dans tout le fichier, la capture peut nécessiter une validation plus approfondie avant toute réécriture.

Ne traitez pas la réparation comme une normalisation

Réparer signifie préserver autant de preuves valables que possible. La normalisation signifie réécrire les données dans une forme préférée. Ce sont des emplois différents.

Par exemple, la modification des horodatages, le recalcul des sommes de contrôle ou la réécriture des en-têtes de couche liaison peuvent être utiles ultérieurement, mais ces opérations ne doivent pas être mélangées à la première étape de récupération. Récupérez d’abord ce qui est fiable. Décidez ensuite si une chirurgie contrôlée est appropriée.

La place de la chirurgie PCAP

PCAP Surgery est conçu pour un examen minutieux des preuves de capture et des flux de travail de réécriture contrôlés. Il ne s’agit pas de devenir un acteur de large pack ou de remplacer tous les outils d’analyse. Son rôle est d'aider les ingénieurs à inspecter les métadonnées de capture, à identifier les échecs d'un fichier et à appliquer les modifications uniquement lorsque les preuves soutiennent l'opération.

Pour un fichier corrompu, le résultat intéressant est :

  • quelle partie du fichier est valide
  • où l'analyse échoue
  • quelle action de réparation a été appliquée
  • quels paquets ou octets ont été affectés
  • si le fichier résultant peut être ouvert par les outils en aval

C'est la différence entre « J'ai utilisé un convertisseur » et « Je peux expliquer la réparation ».