Cattura pacchetti da remoto: il sensore resta in sede, l'analista lavora a distanza

La cattura dei pacchetti appartiene dove i pacchetti scorrono già, e l'analista remoto raramente si trova lì. La disposizione praticabile è un sensore sul segmento osservato più una VPN che trasporta amministrazione e recupero, non l'intero collegamento rispecchiato. Questa separazione tiene il portatile dell'analista fuori dal percorso di cattura e conserva i payload sensibili in sede. I passaggi seguenti scelgono l'interfaccia, delimitano il file e spostano solo ciò che la domanda richiede.

Un portatile remoto non è un tap

Unirsi alla rete tramite VPN dà alla macchina una rotta verso il sensore, non visibilità sul traffico tra altri host. Una cattura presa sul portatile vede solo i pacchetti consegnati all'interfaccia del portatile. Osservare un collegamento commutato richiede che il proprietario della rete fornisca uno specchio o un tap che alimenti un sensore in sede. Anche allora lo specchio ha limiti, perché le destinazioni sovraccariche scartano frame e un gateway non vede mai il traffico che resta dentro la stessa VLAN.

Un flusso cifrato resta cifrato anche al sensore, poiché il payload TLS appartiene agli endpoint. La cattura restituisce intestazioni, tempi e volume, non testo in chiaro.

Scegliete l'interfaccia che vede il flusso

Prima di filtrare qualsiasi cosa, elencate le interfacce e confermate quale trasporta il percorso per cui siete stati interpellati. Indovinare tra una porta fisica, un bond e un bridge è un modo comune di raccogliere un file vuoto.

ip -br link
dumpcap -D

Abbinate il nome dell'interfaccia al punto di osservazione nel registro delle modifiche, non a un nome che ricordate da un altro host. Se il conteggio dei pacchetti resta a zero mentre il servizio è visibilmente occupato, il sensore è sul segmento sbagliato o lo specchio è configurato per l'altra direzione. Dimostrate prima il percorso con uno scambio noto, così che uno specchio guasto non venga scambiato per un'applicazione silenziosa. Scrivete i dettagli dell'interfaccia e dello specchio nelle note di cattura finché sono ancora freschi.

Limitate la cattura con un filtro e un anello

Una cattura senza limiti riempie il disco e raccoglie più di quanto la domanda richieda. Mettete l'origine, la destinazione e il protocollo consentiti nel filtro, poi limitate la dimensione del file e il numero di file.

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'indirizzo e la porta qui sopra sono esempi dell'intervallo di documentazione, quindi sostituiteli con i valori approvati e mantenete la finestra abbastanza breve perché le prove sopravvivano all'anello. La lunghezza dello snapshot tronca il payload conservando le intestazioni, il che di solito basta per una domanda di connettività ed è molto più facile da archiviare. Leggete la riga di scarto del kernel che tcpdump stampa all'uscita, perché un numero elevato di scarti significa che la cattura è incompleta e non silenziosa. Conservate la finestra necessaria prima che l'anello la sovrascriva e annotate la stringa di filtro accanto al nome del file.

Spostate il file, non l'intero collegamento

Recuperate la cattura finita dal canale di gestione invece di trasmettere lo specchio sulla WAN. Un singolo trasferimento è più facile da autorizzare, registrare ed eliminare di un'esportazione continua.

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

Tenete il file leggibile solo dall'account operatore ed eliminate lo dal sensore una volta verificata la copia di analisi. Se l'esportazione dal vivo è davvero il requisito, dimensionate insieme l'incapsulamento dello specchio e il trasporto, perché il sovraccarico può superare il budget del collegamento. Annotate comunque le lacune di visibilità, poiché una cattura è una prova con un punto di osservazione noto e non un registro completo della rete.