Préparer la capture réseau pour des preuves légales

Préparer la capture réseau pour des preuves légales

Une capture réseau préparée après l’incident sert surtout à confirmer qu’aucune preuve n’existe. La bonne approche consiste à capter peu de points, mais les bons, puis à rendre chaque fichier exploitable, daté et vérifiable sans dépendre d’un récit reconstruit à la hâte.

Explication de la marmotte

Préserver des échanges numériques ressemble à conserver les enregistrements d’un lieu surveillé : filmer chaque centimètre du pays ne sert à rien, mais ignorer l’entrée principale rend toute enquête bancale. Le but est de pouvoir montrer ce qui s’est passé, sans pouvoir réécrire l’histoire après coup.

→ Lire l’explication complète de la marmotte

Compromis de capture réseau : visibilité contre coût et exposition

Le compromis central est brutal : plus la capture couvre de trafic et dure longtemps, plus elle aide l’investigation, mais plus elle coûte en stockage, en traitement, en données sensibles conservées et en surface d’attaque. Capturer tout le réseau en permanence est rarement défendable. Une sonde qui collecte des mots de passe, des jetons et des données personnelles sans propriétaire, sans durée et sans contrôle d’accès devient elle-même un incident en attente d’un nom de projet.

La recommandation est de capturer intégralement les flux aux frontières et autour des actifs dont la compromission aurait un effet systémique. Pour le reste, conserver des métadonnées de flux et déclencher une capture ciblée lors d’un signal crédible. Les principes d’observabilité restent valables : une donnée sans horloge fiable, durée de conservation, responsable et chemin d’accès n’est pas une preuve, c’est un fichier volumineux avec des ambitions.

Une capture complète permet de reconstruire les charges applicatives non chiffrées, les négociations de protocole, les transferts de fichiers et certains mouvements latéraux. Elle ne déchiffre pas Transport Layer Security (TLS), ne révèle pas le contenu d’un tunnel chiffré sans clés de session, et ne prouve pas l’identité humaine derrière une adresse. La corrélation doit venir des journaux d’identité, des journaux système et des horodatages cohérents. La capture n’est pas une boule de cristal avec un port Ethernet.

Étape 1 : positionner les TAP et ports miroir

Un TAP (Test Access Point) est un équipement passif inséré sur un lien afin de fournir une copie du trafic à une sonde. Un port miroir, aussi appelé port mirroring ou Switched Port Analyzer (SPAN), est une fonction de commutateur qui réplique le trafic d’un ou plusieurs ports vers un port de supervision.

Privilégier un TAP pour les liens critiques, notamment entre pare-feu Internet et cœur de réseau, entre pare-feu et zone démilitarisée, ou devant une passerelle de sortie. Un TAP ne dépend pas du processeur du commutateur et ne peut pas être désactivé par une modification de configuration du switch. Il introduit en revanche une contrainte physique : une coupure ou un mauvais câblage sur un lien en ligne a des conséquences immédiates. Prévoir un modèle compatible avec le débit, les interfaces et le média optique réellement employés.

Utiliser un port miroir lorsque le lien ne peut pas être interrompu ou lorsque le besoin est temporaire. Documenter le commutateur source, les ports surveillés, les directions de trafic, le port destination et le débit maximal. Un miroir surchargé jette des paquets sans toujours fournir un signal exploitable. L’enquête conclura alors que le trafic n’existait pas, alors que le commutateur l’a discrètement sacrifié pour préserver la production. C’est une forme de mensonge très industrielle.

Positionner les points de capture selon les chemins réels :

1. Passerelle Internet : capturer les flux entrants et sortants après la traduction d’adresses si l’objectif est d’associer les flux à des hôtes internes, et avant cette traduction si les adresses publiques doivent être prouvées. Lorsque les deux vues sont nécessaires, les capturer séparément.
2. Zone d’administration : surveiller les accès aux bastions, consoles d’administration, services d’annuaire et infrastructures de virtualisation.
3. Segments critiques : placer une sonde aux frontières des réseaux de sauvegarde, de gestion, de paiement, de production industrielle ou de données sensibles.
4. Interconnexions cloud : capter sur la passerelle virtuelle, le pare-feu de transit ou l’appliance de réseau virtuel. Une sonde dans une machine virtuelle ne voit que ce que son interface reçoit. Le réseau virtuel ne distribue pas généreusement ses secrets.
5. Résolution de noms et authentification : prévoir au minimum la visibilité des flux Domain Name System (DNS) et des protocoles d’authentification. Ces échanges relient souvent une activité réseau à une identité ou à un équipement.

Vérifier que la sonde reçoit les deux directions d’une conversation. Sur certains TAP, les flux entrant et sortant arrivent sur deux interfaces distinctes et doivent être agrégés sans modifier les paquets. Ne jamais raccorder une interface de capture en émission sur un port miroir : une sonde de preuve doit être physiquement ou logiquement incapable d’injecter du trafic.

Étape 2 : dimensionner la rétention et la rotation des fichiers

Calculer le stockage à partir du débit observé, pas du débit théorique des interfaces. Une capture brute consomme environ débit moyen en bits/s ÷ 8 × durée, auquel il faut ajouter les en-têtes et une marge de 15 à 25 %. À 100 mégabits par seconde constants, une journée représente déjà environ 1 téraoctet. Les liens n’ont aucun respect pour les tableaux de capacité.

Fixer trois paramètres écrits dans la politique de conservation :

• la durée de rétention cible, exprimée en jours ;
• le budget de stockage alloué par point de capture ;
• le comportement à saturation, qui doit supprimer automatiquement les fichiers les plus anciens après génération d’une alerte.

Éviter les fichiers de plusieurs centaines de gigaoctets. Des segments de cinq à soixante minutes limitent la perte lors d’une corruption, accélèrent le hachage et permettent une exportation ciblée. Pour une passerelle Internet, une heure constitue un point de départ raisonnable. Pour un segment à haut débit, basculer plutôt sur une limite de taille afin de garder des fichiers manipulables.

La rétention doit être séparée en deux niveaux. Le tampon local stocke les captures récentes et tourne automatiquement. L’archive de preuve ne reçoit que les périodes placées sous conservation après une alerte ou une demande formalisée. Sans cette séparation, l’équipe conserve indéfiniment des données qu’elle ne peut ni protéger correctement ni justifier. La conformité ne se résume pas à acheter des disques et espérer que le mot « légal » fera le reste.

Étape 3 : synchroniser l’horodatage et contrôler la perte

Chaque sonde, commutateur, pare-feu, serveur de stockage et source de journaux doit utiliser Network Time Protocol (NTP), le protocole de synchronisation de l’heure. Employer au moins deux sources de temps de confiance, surveiller l’écart mesuré et alerter lorsqu’il dépasse le seuil fixé par la procédure d’investigation. Un décalage de quelques minutes suffit à inverser une séquence entre pare-feu, identité et capture.

Configurer les horodatages en Coordinated Universal Time (UTC). L’heure locale et les changements saisonniers sont très efficaces pour fabriquer des débats inutiles lors d’une reconstitution. Conserver avec chaque lot la zone horaire, la source de synchronisation et l’écart constaté si l’outil le fournit.

Mesurer aussi les pertes de paquets de la sonde. Une interface de capture saturée, un disque incapable de suivre les écritures ou un processeur qui filtre trop tard produisent une preuve incomplète. Conserver les compteurs de l’outil de capture avec les fichiers : paquets reçus, abandonnés par le noyau et rejetés par l’interface. Une absence de paquets n’a de valeur que si la chaîne de capture n’en a pas perdu.

Étape 4 : capturer, tourner et hacher les archives

dumpcap, fourni par Wireshark, est préférable à une exécution interactive de tcpdump pour la capture continue : il sait tourner les fichiers et peut fonctionner avec des privilèges limités. Créer un compte de service sans session interactive, réserver un système de fichiers dédié et monter ce volume avec nodev, nosuid et noexec quand la plateforme le permet.

L’exemple suivant crée des captures horaires, conserve sept jours de tampon et génère un manifeste de hachage SHA-256 (Secure Hash Algorithm 256 bits) pour les fichiers transférés en archive.

#!/usr/bin/env bash
# Capture sur ens5, un fichier par heure, 168 fichiers maximum, soit 7 jours.
# Le filtre Berkeley Packet Filter limite la collecte aux échanges de la passerelle.
dumpcap -i ens5 \
  -f 'not arp and not ether broadcast' \
  -b duration:3600 \
  -b files:168 \
  -w /var/lib/capture/gateway.pcapng

# Après sélection d'un créneau à conserver, créer un manifeste immuable par lot.
# Exécuter depuis le répertoire contenant uniquement les fichiers exportés.
cd /srv/evidence/2026-09-22T1200Z
sha256sum *.pcapng > SHA256SUMS.txt

# Vérifier le manifeste après copie sur le stockage d'archive.
sha256sum --check SHA256SUMS.txt

Ne pas considérer SHA256SUMS.txt comme une preuve autonome. Un attaquant capable de modifier une capture peut recalculer son hachage. Signer le manifeste avec une clé distincte, conservée hors de la sonde, puis archiver le manifeste signé avec les captures. La clé privée de signature relève de la même discipline que les autres secrets : contrôle d’accès, rotation documentée, sauvegarde et procédure de révocation. Les mécanismes décrits dans la gestion des clés s’appliquent ici sans exception romantique pour les scripts d’exploitation.

Étape 5 : établir la chaîne de conservation et la reprise

La chaîne de conservation relie un fichier à sa collecte, son transfert, ses contrôles et ses détenteurs successifs. Créer un registre par lot avec : identifiant unique, point de capture, interfaces ou ports sources, période UTC, filtre appliqué, version de l’outil, empreinte SHA-256, opérateur ou compte de service, destination et motif de gel. Enregistrer les accès de lecture et les exports.

Utiliser un stockage WORM (Write Once Read Many), c’est-à-dire un stockage empêchant la modification ou la suppression pendant une durée définie, pour les lots gelés. Un verrou de rétention doit être configuré par un rôle distinct de celui qui exploite les sondes. Sinon, l’immutabilité n’est qu’une permission d’administration avec une brochure plus brillante.

Tester la restauration : récupérer un lot archivé, vérifier sa signature et son empreinte, ouvrir le fichier avec un analyseur indépendant, puis comparer ses métadonnées au registre. Répéter ce test à fréquence définie. Une archive non restaurée est une hypothèse coûteuse.

Prévoir la panne : si le stockage local sature, continuer la rotation contrôlée et alerter ; ne pas bloquer le système de production pour sauver une capture. Si NTP devient indisponible, conserver les captures mais marquer la période comme horodatée avec une confiance dégradée. Si la sonde tombe, journaliser l’intervalle aveugle. Une preuve honnête indique ses limites, une preuve maquillée finit généralement par les révéler au pire moment.

🐝 Ce qui arrive si on s’en passe

Sans points de capture décidés à l’avance, la reconstitution repose entièrement sur les journaux des machines concernées, c’est-à-dire sur des sources que l’intrus a pu tronquer ou effacer avant d’être détecté. La capture improvisée démarre après coup, souvent depuis un hôte déjà suspect, ce qui ajoute une collecte contestable à une visibilité déjà absente. Sans trafic de référence antérieur, aucun écart ne peut être qualifié : un flux sortant inhabituel reste indiscernable d’une habitude ancienne. Le volume réellement transféré devient invérifiable, ce qui empêche de délimiter le périmètre touché, donc de répondre aux obligations de notification et aux questions d’un assureur ou d’un juge. L’alternative est alors de déclarer l’incident maximal par défaut, faute de pouvoir démontrer l’inverse.

🦫 Explication de la marmotte 🍫

Avant un incident, il faut décider quels passages du réseau seront enregistrés. On choisit les entrées et sorties vers Internet, les zones qui administrent les systèmes, ainsi que les parties contenant des données ou services sensibles. Enregistrer partout produit trop de fichiers, coûte cher et conserve parfois des informations privées sans raison valable.

Un appareil de copie reçoit une duplication des échanges et les écrit sur un disque réservé. Il doit recevoir les communications dans les deux sens. Les fichiers sont découpés régulièrement et les plus anciens sont supprimés automatiquement du stockage local lorsque la durée prévue est atteinte. Si le disque ou l’appareil n’arrive pas à suivre, des messages d’alerte doivent signaler les données manquantes.

Tous les équipements concernés règlent leur heure sur des sources communes. Cela permet de remettre les événements dans le bon ordre. Les fichiers utilisent une heure universelle, pour éviter les erreurs liées aux changements d’heure.

Lorsqu’une période devient nécessaire pour une enquête, elle est copiée dans une archive protégée contre la modification. Une empreinte mathématique est calculée pour chaque fichier. Cette empreinte permet de détecter une modification, mais elle doit aussi être protégée, sinon elle peut être remplacée avec le fichier. Un registre conserve l’origine, la période, les copies et les personnes ou services ayant accédé aux données. Enfin, il faut tester régulièrement qu’une archive peut être relue et contrôlée.

À lire aussi

• Configurer Suricata sur un segment réseau critiqueGuide pas-à-pas pour déployer Suricata en écoute ou en coupure, charger ET Open, réduire le bruit et valider une première règle personnalisée.
• Exécuter un threat hunting à partir d'une hypothèseGuide pas-à-pas pour préparer, exécuter et pérenniser un exercice de threat hunting fondé sur une hypothèse vérifiable.
• Réagir aux premières minutes d’un incident suspectéChecklist opérationnelle pour isoler une anomalie, alerter les bonnes personnes et préserver les premières preuves avant une réponse à incident spécialisée.
• Analyse mémoire et réseau après un incidentL’analyse mémoire et réseau complète l’analyse disque en préservant les processus, clés et communications visibles au moment de l’incident.

Pages voisines

La citent

• Analyse mémoire et réseau après un incident
• Captures, observabilité et diagnostic multi-couche
• Google Street View Wi-Spy 2010 : trames Wi-Fi en clair et droit

Préparer la capture réseau pour des preuves légales

Elle cite

• ⇄Lien dans les deux sens :Wireshark, capturer et lire des trames réseau avec filtres et TLS
• Assurance cyber couverture et exclusions de contrat
• Forensics numérique et chaîne de conservation après incident

⇄ : les deux pages se citent l’une l’autre.