Captura remota de paquets: el sensor es queda al lloc i l'analista treballa en remot

La captura de paquets pertany allà on els paquets ja flueixen, i l'analista remot poques vegades hi és. La disposició viable és un sensor al segment observat més una VPN que transporta administració i recuperació, no tot l'enllaç mirallat. Aquesta separació manté l'ordinador portàtil de l'analista fora del camí de captura i conserva les càrregues sensibles al lloc. Els passos següents trien la interfície, limiten el fitxer i mouen només el que la pregunta necessita.

Un portàtil remot no és un tap

Unir-se a la xarxa per VPN dona a la vostra màquina una ruta cap al sensor, no visibilitat del trànsit entre altres hosts. Una captura feta al vostre portàtil només veu els paquets lliurats a la interfície del portàtil. Observar un enllaç commutat requereix que el propietari de la xarxa proporcioni un mirall o un tap que alimenti un sensor al lloc. I encara així el mirall té límits, perquè les destinacions sobrecarregades descarten trames i una passarel·la mai no veu el trànsit que es queda dins de la mateixa VLAN.

Un flux xifrat també continua xifrat al sensor, perquè la càrrega TLS pertany als extrems. La captura dona capçaleres, temps i volum, no text pla.

Trieu la interfície que pot veure el flux

Abans de filtrar res, llisteu les interfícies i confirmeu quina porta el camí pel qual us han preguntat. Endevinar entre un port físic, un bond i un pont és una manera habitual d'aconseguir un fitxer buit.

ip -br link
dumpcap -D

Feu coincidir el nom de la interfície amb el punt d'observació del registre de canvis, no amb un nom que recordeu d'un altre host. Si el recompte de paquets es queda a zero mentre el servei és visiblement ocupat, el sensor és al segment equivocat o el mirall està configurat per a l'altra direcció. Demostreu primer el camí amb un intercanvi conegut, perquè un mirall trencat no es confongui amb una aplicació tranquil·la. Escriviu els detalls de la interfície i del mirall a les notes de captura mentre encara són frescos.

Limiteu la captura amb un filtre i un anell

Una captura sense límits omple el disc i recull més del que la pregunta requereix. Poseu l'origen, la destinació i el protocol permesos al filtre, i després limiteu la mida del fitxer i el nombre de fitxers.

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'adreça i el port anteriors són exemples del rang de documentació, així que substituïu-los pels valors aprovats i manteniu la finestra prou curta perquè les proves sobrevisquin a l'anell. La longitud de la instantània retalla la càrrega tot conservant les capçaleres, cosa que sol ser suficient per a una pregunta de connectivitat i molt més fàcil d'emmagatzemar. Llegiu la línia de descart del nucli que tcpdump imprimeix en sortir, perquè un recompte alt de descarts vol dir que la captura és incompleta i no silenciosa. Preserveu la finestra que necessiteu abans que l'anell la sobreescrigui i anoteu la cadena del filtre al costat del nom del fitxer.

Moveu el fitxer, no tot l'enllaç

Recupereu la captura acabada pel canal de gestió en lloc de transmetre el mirall per la WAN. Una transferència és més fàcil d'autoritzar, registrar i eliminar que una exportació contínua.

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

Manteniu el fitxer llegible només pel compte d'operador i elimineu-lo del sensor quan la còpia d'anàlisi estigui verificada. Si l'exportació en directe és realment el requisit, dimensiona l'encapsulament del mirall i el transport junts, perquè la sobrecàrrega pot superar el pressupost de l'enllaç. Anoteu les llacunes de visibilitat en qualsevol cas, ja que una captura és una prova amb un punt d'observació conegut, no un registre complet de la xarxa.