Chi fa troubleshooting su Quantum parte quasi sempre da una cattura. La parte difficile non è lanciarla: è sapere dove ciascuno strumento si mette in ascolto. La stessa connessione ha un aspetto diverso a seconda del punto della catena in cui la osservi, e una domanda che mostra tre righe di output chiede esattamente questo.

Quattro uscite per lo stesso traffico

tcpdump è lo sniffer di sistema: legge sull’interfaccia, quindi vede il pacchetto come entra dal cavo e come esce verso il cavo, prima e dopo tutto quello che il gateway gli fa in mezzo. Le sue righe riportano orario, indirizzi, porte e flag TCP; di regole, NAT e inspection non sanno nulla.

cppcap è lo strumento Check Point nato per catturare dove tcpdump costa troppa CPU. Cattura anche il traffico accelerato da SecureXL, scrive in PCAP standard e, se non gli indichi un file con -o, stampa a schermo.

fw monitor -e cattura invece dentro la Firewall Virtual Machine, ai punti di ispezione. L’argomento di -e è un’espressione nel linguaggio INSPECT, il modo più espressivo di filtrare, con un limite dichiarato nella documentazione: i filtri INSPECT non si applicano al traffico accelerato.

fw monitor -F usa il filtro semplificato a cinque campi, cioè IP sorgente, porta sorgente, IP destinazione, porta destinazione e numero di protocollo, dove 0 vale come “qualsiasi” e si possono indicare fino a cinque istanze in OR. È l’unico filtro che vale sia per il traffico accelerato sia per quello non accelerato: se la connessione passa da SecureXL, -F è la scelta obbligata.

L’output di fw monitor non somiglia a quello di tcpdump: ogni riga porta il nome dell’interfaccia e la lettera del punto di ispezione, e lo stesso pacchetto compare più volte, una per punto attraversato. Con -o la cattura finisce in un file in formato snoop, che Wireshark apre senza conversioni; senza percorso esplicito nasce nella directory corrente, e su un gateway carico conviene scriverlo sotto /var/log.

I flag di cppcap e la verbosità

La verbosità di cppcap si governa con flag dedicati, uno per livello: -D aggiunge il dettaglio di livello 2 (datalink), -N quello di livello 3 (network), -T quello di livello 4 (transport), -P mostra l’ID del processore, -Q toglie l’orario dalle righe.

Tutto il resto non è verbosità, anche se le somiglia. -c limita i byte catturati per ogni frame, con default 96: se lo lasci com’è il payload viene troncato, e nessuna opzione di visualizzazione te lo restituisce. -f applica il filtro, -o scrive su file, -w fissa la dimensione oltre la quale il file ruota, -W quanti file ruotati conservare. La stessa lettera non vale uguale in strumenti diversi: la pagina dello strumento è l’unica fonte.

CPMonitor: dalla cattura al profilo del traffico

cpmonitor non cattura niente: analizza un file già catturato con tcpdump o con fw monitor, in Expert mode, nella forma cpmonitor [parametri] /percorso/file. Restituisce le statistiche complessive del traffico (pacchetti al secondo, connessioni al secondo, connessioni concorrenti, throughput), l’elenco delle connessioni, dei server e dei servizi più pesanti, la distribuzione della dimensione dei pacchetti e un’analisi secondo per secondo.

Le opzioni che contano: -o salva il report in TXT, -g produce il grafico temporale in CSV, -t esporta le tabelle complete in CSV, -n apre la modalità Navigate per scorrere la cattura a finestre, -s p oppure -s t ordina per pacchetti o per throughput, -q scrive solo i file. Risponde alla domanda cui nessuna singola riga di cattura risponde: quel picco era un attacco, un backup o una sola connessione elefante?

Il metodo, in quattro mosse

Formula l’ipotesi prima di catturare. Restringi il filtro finché il file resta leggibile. Scegli lo strumento in base al punto della catena che l’ipotesi chiama in causa: l’interfaccia con tcpdump o cppcap, la Firewall Virtual Machine con fw monitor. Poi passa il file a cpmonitor per il profilo d’insieme o a Wireshark per il singolo pacchetto.

Trappole tipiche d’esame

  • Leggere un output di fw monitor come se fosse tcpdump. Sono due punti diversi della catena. Se una riga porta un nome di interfaccia seguito da i, I, o oppure O stai guardando fw monitor: quel pacchetto è già dentro il gateway, e vederlo lì non dice nulla su cosa sia davvero uscito sul cavo. Al contrario, tcpdump che mostra il pacchetto non prova che l’inspection lo abbia accettato.
  • Confondere i quattro punti di ispezione. i è pre-inbound, I è post-inbound, o è pre-outbound, O è post-outbound, e la direzione è quella del singolo pacchetto, non della connessione: la risposta del server è inbound sull’interfaccia da cui rientra. Una domanda che chiede dove si perde il pacchetto si risolve solo se le quattro lettere sono chiare.
  • Attribuire a un flag un effetto sulla verbosità che non ha. In cppcap la verbosità sta in -D, -N, -T, -P, -Q; -c tronca, -w e -W ruotano i file, -f filtra. Un output povero perché il frame è stato tagliato a 96 byte non si cura alzando la verbosità.
  • Dimenticare SecureXL. I filtri INSPECT di -e non toccano il traffico accelerato, e nemmeno le posizioni di chain valgono lì: la connessione accelerata la vedi comunque alle posizioni inbound e outbound di default, e per filtrarla serve -F.