Capture de paquets à distance : le capteur reste sur place, l'analyste travaille à distance

La capture de paquets appartient là où les paquets circulent déjà, et l'analyste distant y est rarement. La disposition viable est un capteur sur le segment observé plus un VPN qui transporte l'administration et la récupération, pas toute la liaison mise en miroir. Cette séparation garde l'ordinateur portable de l'analyste hors du chemin de capture et conserve les charges sensibles sur site. Les étapes ci-dessous choisissent l'interface, bornent le fichier et ne déplacent que ce dont la question a besoin.

Un portable distant n'est pas un point de capture

Rejoindre le réseau par VPN donne à votre machine une route vers le capteur, pas une visibilité sur le trafic entre d'autres hôtes. Une capture prise sur votre portable ne voit que les paquets livrés à l'interface de votre portable. Observer une liaison commutée exige que le propriétaire du réseau fournisse un miroir ou un point de capture alimentant un capteur sur site. Même alors le miroir a des limites, car les destinations surchargées abandonnent des trames et une passerelle ne voit jamais le trafic qui reste à l'intérieur du même VLAN.

Un flux chiffré reste aussi chiffré au niveau du capteur, puisque la charge TLS appartient aux extrémités. La capture livre des en-têtes, du temps et du volume, pas du texte en clair.

Choisissez l'interface qui voit le flux

Avant de filtrer quoi que ce soit, listez les interfaces et confirmez laquelle porte le chemin sur lequel on vous a interrogé. Deviner entre un port physique, une agrégation et un pont est une façon courante de collecter un fichier vide.

ip -br link
dumpcap -D

Faites correspondre le nom de l'interface au point d'observation du journal des changements, pas à un nom dont vous vous souvenez d'un autre hôte. Si le compteur de paquets reste à zéro alors que le service est visiblement occupé, le capteur est sur le mauvais segment ou le miroir est configuré pour l'autre direction. Prouvez d'abord le chemin par un échange connu, afin qu'un miroir défectueux ne soit pas pris pour une application silencieuse. Écrivez les détails de l'interface et du miroir dans les notes de capture pendant qu'ils sont encore frais.

Bornez la capture par un filtre et un anneau

Une capture sans bornes remplit le disque et collecte plus que la question n'en exige. Placez la source, la destination et le protocole autorisés dans le filtre, puis bornez la taille du fichier et le nombre de fichiers.

tcpdump -i eth0 -n -s 128 -c 5000 -W 4 -C 25 -w /var/tmp/cap.pcap 'host 203.0.113.10 and tcp port 443'

L'adresse et le port ci-dessus sont des exemples de la plage de documentation, remplacez-les donc par les valeurs approuvées et gardez la fenêtre assez courte pour que les preuves survivent à l'anneau. La longueur d'instantané tronque la charge tout en gardant les en-têtes, ce qui suffit généralement pour une question de connectivité et est bien plus facile à stocker. Lisez la ligne de perte du noyau que tcpdump imprime à la sortie, car un nombre élevé de pertes signifie que la capture est incomplète et non silencieuse. Conservez la fenêtre dont vous avez besoin avant que l'anneau ne l'écrase, et notez la chaîne de filtre à côté du nom du fichier.

Déplacez le fichier, pas toute la liaison

Récupérez la capture terminée par le canal d'administration au lieu de diffuser le miroir sur le WAN. Un seul transfert est plus facile à autoriser, à journaliser et à supprimer qu'une exportation continue.

scp [email protected]:/var/tmp/cap.pcap ./

Gardez le fichier lisible uniquement par le compte opérateur et supprimez-le du capteur une fois la copie d'analyse vérifiée. Si l'exportation en direct est réellement l'exigence, dimensionnez l'encapsulation du miroir et le transport ensemble, car la surcharge peut dépasser le budget de la liaison. Notez les angles morts de visibilité dans tous les cas, car une capture est une preuve avec un point d'observation connu et non un relevé complet du réseau.