I quattro laboratori del modulo M3 catturano lo stesso traffico con quattro impostazioni diverse, e il senso dell’esercizio sta proprio nel confronto: le stesse connessioni producono file differenti, e la differenza racconta dove ciascuno strumento è posizionato.

fw monitor con il filtro a espressione

Il primo laboratorio usa fw monitor con un filtro INSPECT passato da riga di comando con -e. È la forma più espressiva: consente di descrivere una condizione sui campi del pacchetto invece di limitarsi a una quintupla.

Insieme a -e si usano gli altri parametri che governano la cattura. -m sceglie i punti di ispezione: i pre-inbound, I post-inbound, o pre-outbound, O post-outbound, più e ed E prima e dopo la cifratura VPN. -o salva il risultato su file in formato RFC 1761, lo stesso usato da strumenti come snoop, che Wireshark apre senza conversioni. -w cattura il pacchetto intero anziché la sola intestazione. -ci e -co fermano la cattura dopo un numero prefissato di pacchetti in ingresso o in uscita, ed è il modo più semplice per non lasciare una cattura accesa su un gateway di produzione.

Il vincolo che va imparato qui, e che il laboratorio successivo esiste apposta per mostrare, è che i filtri INSPECT non si applicano al traffico accelerato.

fw monitor con il filtro semplice

Il secondo laboratorio ripete la cattura con il filtro semplice, -F, che prende una quintupla nella forma indirizzo sorgente, porta sorgente, indirizzo destinazione, porta destinazione, protocollo, e ammette fino a cinque istanze nello stesso comando. Uno zero in un campo vale come «qualunque valore».

La differenza non è sintattica, è di collocazione: -F è un filtro di kernel e si applica sia al traffico accelerato sia a quello non accelerato. Su un gateway con SecureXL attivo è spesso l’unico dei due che restituisce qualcosa. Vale anche il resto delle avvertenze operative: si può eseguire un solo processo fw monitor per volta, e chiedere tutti i punti della catena con -p all genera un carico molto alto sulla CPU.

Il confronto fra i due laboratori è la lezione: stesso traffico, stesso comando a parte il filtro, due file diversi. Se il file di -e è vuoto e quello di -F no, non hai trovato un guasto, hai trovato SecureXL.

Cattura con tcpdump

Il terzo laboratorio scende al livello delle interfacce. tcpdump non conosce la catena di ispezione: vede i pacchetti come li vede il sistema operativo, e risponde a una domanda sola ma decisiva, «il pacchetto arriva davvero alla macchina». È il primo passo di ogni indagine e l’ultimo controllo prima di dare la colpa alla rete.

Sulle Scalable Platform la variante multi-blade cattura sui membri del Security Group: -mcap salva su file i pacchetti dei membri indicati, -b seleziona i membri o i siti, -w indica il file di uscita, -r rilegge un file esistente e -view mostra i pacchetti di una cattura con l’identificativo del membro che li ha visti. Le opzioni standard di tcpdump restano valide, e la cattura si chiude con CTRL+C per salvare i dati.

Cattura con Check Point PCAP

Il quarto laboratorio usa cppcap, l’utilità di cattura proprietaria nata per contenere il costo prestazionale di tcpdump sui gateway. Cattura per impostazione predefinita in entrambe le direzioni e vede anche il traffico accelerato da SecureXL.

I parametri da conoscere: -i e -I includono o escludono un’interfaccia, -f applica un’espressione pcap, -d limita la direzione a in o out, -o indica il file di uscita, -w e -W governano rotazione e numero di file, -p e -b fissano un tetto in frame o in byte, -c imposta quanti byte per frame conservare, con un valore predefinito di 96. Serve Expert mode; sulle Scalable Platform il comando va eseguito su ogni singolo Security Group Member, perché non è supportato in forma globale. Attenzione anche a un dettaglio che in laboratorio si scopre a proprie spese: i parametri di visualizzazione a schermo non sono compatibili con la scrittura su file.

Trappole tipiche d’esame

  • Strumento sbagliato per il punto giusto. Se lo scenario chiede in quale punto della catena il pacchetto viene scartato, la risposta è fw monitor con -m: tcpdump quella domanda non la sente nemmeno. Se lo scenario dice che SecureXL accelera la connessione, il filtro -e è la risposta sbagliata anche quando la sintassi è perfetta, perché non si applica al traffico accelerato: servono -F o cppcap.
  • Cattura costosa su un gateway in produzione. Un solo processo fw monitor per volta, -p all che fa salire la CPU, tcpdump che pesa: fra due risposte corrette la giusta è quella che limita, con -ci e -co, con -p o -b in cppcap, con una finestra temporale breve.
  • Filtro troppo largo. Senza quintupla in -F, senza espressione in -f, senza tetto di pacchetti, il file cresce e la prova annega nel rumore. E ricorda il rovescio: -c a 96 byte e la cattura della sola intestazione non riducono il rumore, tagliano il contenuto — se ti serve il payload devi chiedere -w o alzare -c.