Catturare pacchetti su un Security Gateway non è come catturarli su un portatile: il gateway è in mezzo al traffico di tutti, la cattura costa CPU e disco, e ogni strumento vede una porzione diversa del percorso che il pacchetto compie dentro la macchina. Scegliere male lo strumento non produce un errore: produce un file che non contiene la prova che cercavi.

Che cosa costa una cattura, e che cosa non vede

Il primo limite è prestazionale e dichiarato. fw monitor accetta un solo processo per volta, e la documentazione avverte che catturare su tutti i punti della catena con -p all genera un carico molto alto sulla CPU. cppcap esiste proprio perché tcpdump ha un costo prestazionale rilevante sui gateway Check Point, e nasce per contenerlo.

Il secondo limite è di visibilità. Di default una cattura non salva tutto il pacchetto: fw monitor registra solo l’intestazione a meno che non si chieda -w, e cppcap prende 96 byte per frame se non si cambia -c. Un payload troncato non è un difetto dello strumento, è un’impostazione che ti sei tenuto.

Il terzo limite è l’accelerazione. I filtri INSPECT di fw monitor passati con -e non si applicano al traffico accelerato: se SecureXL gestisce la connessione, quel filtro non la vede. Il filtro kernel -F invece si applica sia al traffico accelerato sia a quello non accelerato, e cppcap cattura anche il traffico accelerato da SecureXL. Una cattura vuota, in Check Point, molto spesso non significa «non passa traffico»: significa che stai guardando dal punto sbagliato.

Gli strumenti, e dove guarda ciascuno

tcpdump lavora al livello delle interfacce del sistema operativo: è lo strumento giusto per rispondere alla domanda «il pacchetto arriva o no alla macchina». Sulle Scalable Platform esiste la variante multi-blade, che cattura sui membri del Security Group con -mcap, -b per scegliere i membri e -view per rileggere il file mostrando l’identificativo del membro.

fw monitor è lo strumento di Check Point e cattura il traffico a ogni Chain Module, nelle due direzioni. I punti di ispezione sono quattro rispetto alla macchina virtuale del firewall: i pre-inbound, I post-inbound, o pre-outbound, O post-outbound, più e ed E prima e dopo la cifratura VPN; si selezionano con -m. L’output si salva con -o nel formato RFC 1761, leggibile da Wireshark. È l’unico strumento che risponde alla domanda «dove nella catena il pacchetto sparisce».

cppcap è l’utilità di cattura proprietaria: scrive su file con -o, ruota con -w e -W, filtra con espressioni pcap tramite -f, restringe la direzione con -d, sceglie le interfacce con -i e -I. Richiede Expert mode e, sulle Scalable Platform, va eseguito su ogni Security Group Member.

cpmonitor non cattura: analizza offline i file prodotti da tcpdump o da fw monitor. È il pezzo che chiude il giro, ed è l’unico che trasforma una cattura in numeri.

Per decidere dove mettere la sonda serve la mappa della catena: fw ctl chain elenca i moduli inbound e outbound in ordine di priorità, dalle opzioni IP e dalla decifratura VPN fino ad accounting e streaming.

Investigare un problema di flusso

Il metodo è per esclusione, dall’esterno verso l’interno. Prima si verifica con tcpdump che il pacchetto arrivi sull’interfaccia attesa. Se arriva ma non esce, si passa a fw monitor con tutti e quattro i punti: quello in cui la lettera manca è il punto in cui il pacchetto è stato scartato, e la posizione rispetto alla macchina virtuale del firewall dice se a scartarlo è stata la policy o qualcosa prima o dopo. Se fw monitor non vede nulla mentre tcpdump vede traffico, il sospetto è l’accelerazione: si ripete con -F, oppure con cppcap.

Vedere la richiesta in uscita e non la risposta in entrata sposta invece il problema fuori dal gateway.

Misurare attività e prestazioni

Una cattura serve anche a misurare, non solo a trovare. cpmonitor legge un file di cattura e restituisce pacchetti al secondo, connessioni al secondo, connessioni concorrenti e throughput, con le classifiche delle connessioni, dei server e dei servizi più pesanti e la distribuzione delle dimensioni dei pacchetti. Il Navigate mode con -n serve a isolare i picchi finestra per finestra, -g esporta il grafico temporale in CSV e -t le tabelle dettagliate: è così che si dimostra con un numero quello che il cliente descrive come «a volte è lento».

Della stessa famiglia è la funzione Packet Capture dei log: la cattura viene allegata al log, inviata al Log Server e si apre da Logs & Events cliccando il collegamento nel campo Packet Capture. È attiva per impostazione predefinita nella Custom Threat Prevention Policy e si disattiva dalla colonna Track della regola.

Trappole tipiche d’esame

  • Scegliere lo strumento sbagliato per il punto che ti interessa. tcpdump risponde «arriva alla macchina», fw monitor risponde «dove si perde nella catena», cppcap risponde anche per il traffico accelerato, cpmonitor non risponde affatto perché non cattura. Se la domanda nomina un punto della catena e la risposta propone tcpdump, è sbagliata.
  • Ignorare il costo su un gateway in produzione. Una sola istanza di fw monitor, -p all che fa salire la CPU, tcpdump che pesa: la risposta corretta è quasi sempre la cattura più stretta e più breve, non la più completa.
  • Filtrare troppo largo. Senza -F, senza espressione pcap, senza limite di pacchetti, il file cresce e la prova annega. Ma vale anche il contrario: un filtro -e su traffico accelerato non restringe, esclude e basta.