Quando un utente dice che «il traffico non passa», il Gateway ha già registrato la propria versione dei fatti in tre posti: i log della policy, i contatori di monitoraggio e i pacchetti stessi. Il mestiere è scegliere quale dei tre interrogare per primo.

A che cosa serve un packet capture, e quale strumento usare

Un packet capture stabilisce un fatto che nessun log può dare: se il pacchetto è arrivato, com’era fatto e fin dove è andato. Su Check Point gli strumenti sono più di uno.

fw monitor cattura il traffico ai Chain Modules nei due sensi e, soprattutto, in quattro punti di ispezione: i pre-inbound, prima del modulo FireWall VM in ingresso; I post-inbound, dopo; o pre-outbound; O post-outbound. L’output li stampa accanto all’interfaccia, nella forma eth4:i. Esistono punti aggiuntivi per la VPN, e ed E in uscita, id e ID in ingresso, che mostrano il pacchetto prima e dopo la cifratura. I filtri si scrivono con -e come espressione INSPECT o con -F come filtro del kernel a cinque campi (IP e porta sorgente, IP e porta destinazione, protocollo); -o salva in formato RFC 1761, leggibile da Wireshark, e -T aggiunge il timestamp. Due limiti da ricordare: può girare una sola istanza per volta, e i filtri INSPECT -e non si applicano al traffico accelerato.

tcpdump resta disponibile ma aumenta in modo sensibile il carico di CPU sul Gateway. Per questo Check Point fornisce cppcap, simile nell’uso e capace di catturare anche il traffico accelerato da SecureXL: richiede Expert mode, sceglie l’interfaccia con -i, il filtro pcap-filter con -f, il file di uscita con -o.

C’è infine il Packet Capture allegato al log: il Gateway lo invia al Log Server insieme al log e in SmartConsole, nella vista Logs and Events, il campo Packet Capture apre quel file. Per alcune blade è attivo di default nella Custom Threat Prevention Policy e si toglie dalla colonna Track.

Log e tracking: chiedere alla regola la cosa giusta

Un log esiste solo se qualcuno lo ha chiesto. Nella colonna Track, None non genera alcun log ed è l’impostazione predefinita nell’Access Control policy: la regola che «non logga» spesso non è rotta, è configurata così. Log è l’opzione normale; Accounting aggiorna il log ogni dieci minuti con byte caricati, byte scaricati e tempo di navigazione; Detailed Log mostra l’applicazione riconosciuta anche se la regola non la specifica e richiede Application and URL Filtering, Content Awareness o Mobile Access; Extended Log aggiunge l’elenco completo di URL e file. Le ultime due pesano di più sulle prestazioni. A parte si sceglie l’alert — None, Alert, SNMP, Mail, User Defined Alert — e la granularità: per Connection, predefinita per il Firewall, genera un log per ogni connessione; per Session, predefinita per Application Control, ne genera uno per l’intera sessione.

Conta anche dove finiscono. I Security Gateway generano i log di rete, il Management Server gli audit log delle azioni amministrative; la destinazione può essere il Management Server, un Log Server dedicato o il Gateway stesso in local logging. Se tutti i Primary Log Server sono irraggiungibili il Gateway passa al primo Backup Log Server configurato, e se mancano anche quelli scrive in locale. Ecco perché «non vedo il log» non prova che il traffico non sia passato.

Seguire il flusso e capire dove si rompe

I quattro punti di ispezione servono a questo. Se il pacchetto compare in i ma non in I, l’ispezione in ingresso lo ha scartato: Rule Base, anti-spoofing, blade. Se compare in I ma non in o, il Gateway lo ha accettato e non sa dove mandarlo: è routing, o NAT che ha riscritto l’indirizzo. Se esce in O e il problema resta, il Gateway ha fatto la sua parte e l’indagine si sposta a valle. Se in i non compare affatto, non è mai arrivato.

Salvata la cattura, Wireshark completa il lavoro: i display filter isolano la conversazione, Follow Stream ricostruisce il dialogo, Expert Information raccoglie ritrasmissioni e anomalie, Statistics offre Conversations, Endpoints, Flow Graph e IO Graphs.

Monitorare attività e prestazioni

SmartView Monitor separa due famiglie di viste. Le Traffic views osservano il traffico: Services, IPs and Network Objects, Security Rules, Interfaces, Connections, Tunnels, Virtual Link, Packet Size Distribution e QoS servono a capire chi consuma, quale regola viene colpita davvero e quali tunnel sono attivi. I System Counters misurano invece l’uso delle Software Blade e le prestazioni del Gateway, mentre sul Gateway CPView segue in tempo reale CPU, memoria e contatori delle blade.

Trappole tipiche d’esame

  • Leggere i log senza aver prima tracciato la regola. Prima si stabilisce quale regola quel traffico dovrebbe colpire e che cosa ha nella colonna Track; solo dopo l’assenza di un log diventa un’informazione.
  • Confondere un problema di policy con uno di routing. È la distinzione che i punti i, I, o, O risolvono in un colpo: scartato fra i e I significa ispezione, perso fra I e o significa instradamento.
  • Non verificare lo stato del logging prima di concludere. Track su None, log dirottati su un Backup Log Server o scritti in locale sul Gateway producono tutti lo stesso sintomo apparente.
  • Dare per scontato che la cattura veda tutto. I filtri INSPECT di fw monitor non si applicano al traffico accelerato, e una sola istanza può girare per volta: se serve vedere l’accelerato, lo strumento è cppcap.