Un’indagine su un problema di traffico comincia quasi sempre con una di due frasi: «questa connessione non passa» oppure «non vedo niente nei log». Sembrano problemi diversi e spesso sono lo stesso problema visto da due punti. Per separarli serve sapere che cosa deve succedere perché una decisione presa su un pacchetto diventi una riga consultabile.

La catena che trasforma un pacchetto in un log consultabile

Gli anelli sono quattro e si rompono indipendentemente l’uno dall’altro.

Il Security Gateway valuta il traffico e genera la voce, scrivendola nei propri file sotto $FWDIR/log. Poi la voce viene consegnata a un Log Server o al Management Server. Lì viene indicizzata, cioè resa ricercabile. Infine può essere correlata in un evento.

I componenti della correlazione vanno tenuti separati anche a mente. Il Log Server «store and process logs». Lo SmartEvent Correlation Unit «analyzes logs and detects events». Lo SmartEvent Server «hosts the events database». Il Correlation Unit va configurato esplicitamente «to read logs from the local Log Server»: se gli eventi tacciono mentre i log ci sono, quel collegamento è il primo sospetto, prima delle regole di correlazione.

Da qui la domanda che ordina tutta l’indagine: la voce non è stata generata, non è stata consegnata, o non è stata indicizzata? Sono tre guasti diversi con tre prove diverse, e nessuno si dimostra guardando una console vuota.

Leggere i log alla fonte: fw log e fwm logexport

fw log mostra il contenuto dei file di log Check Point: i log di sicurezza in $FWDIR/log/*.log e quelli di audit in $FWDIR/log/*.adtlog. «If you do not specify the log file explicitly, the command opens the $FWDIR/log/fw.log log file.»

Le opzioni che contano in un’indagine sono poche. -f resta in ascolto: «After the command reaches the end of the currently opened log file, it continues to monitor the log file indefinitely and shows the new entries», ed è il modo per correlare una riproduzione del problema con la riga che produce. -c filtra per azione, fra cui accept, drop e reject. -s ed -e limitano l’intervallo temporale, mentre -b prende un intervallo intero: «You cannot use the -b parameter together with the -s or -e parameters». -n salta la risoluzione DNS e «this significantly speeds up the log processing».

Questa è la prova che separa generazione e consegna: se la riga compare con fw log sul gateway e non compare nella console, il traffico è stato valutato e registrato. Il guasto è a valle, nella consegna o nella ricerca, e non nella policy.

Per portare il materiale fuori dal prodotto c’è fwm logexport, che esporta un file di log di sicurezza o di audit «to an ASCII file». Con -i si sceglie il file di ingresso, con -o la destinazione — senza, il risultato va a schermo. Il formato è tabellare: «The first row lists the names of all log fields included in the log entries», con i campi separati da punto e virgola. Anche qui -n evita la risoluzione DNS e -p quella dei numeri di porta: su volumi grossi sono la parte lenta del lavoro.

Dallo stato del dispositivo all’evento correlato

Prima di scavare nel contenuto conviene chiedere alla console che cosa pensa dei dispositivi. In SmartConsole la vista Gateways & Servers con SmartView Monitor offre diverse prospettive — General, Health, Traffic, Access Control, Threat Prevention, Management, Licenses — e assegna a ogni dispositivo uno stato.

Quegli stati sono diagnostici, non decorativi, e spesso rispondono da soli alla domanda sui log mancanti. «Attention» segnala che «At least one Software Blade has a minor issue», «Problem» che «At least one Software Blade reported a malfunction». «Disconnected» dichiara «Cannot reach the device». «Waiting» dice che «SmartView Monitor waits for the Security Management Server», cioè sposta il sospetto fra monitor e management e non sul gateway. E «Untrusted» dichiara «Cannot make Secure Internal Communication»: poiché SIC abilita anche la trasmissione sicura dei log, quello stato spiega da solo perché da quel dispositivo non arriva più niente.

Le informazioni monitorate coprono CPU, memoria e partizioni, contatori di pacchetti, tunnel VPN e stato del cluster. Sono il contesto che dà senso a una riga di log: un gateway con la policy giusta e la memoria al limite scarta traffico per ragioni che nessun filtro sulla Rule Base spiegherà.

Trappole tipiche d’esame

  • Concludere che un log non esiste quando non è stato consegnato. La console vuota è compatibile con quattro guasti diversi. La prova che la voce esiste si fa alla fonte, con fw log sul dispositivo che l’ha generata, non aggiungendo filtri nella console.
  • Scambiare un guasto della visualizzazione per un guasto della consegna. Se lo scenario dice che i file sul Log Server crescono, la consegna funziona e il problema è più avanti nella catena. Se dice che non crescono, è inutile occuparsi di indicizzazione o di eventi.
  • Alzare il dettaglio dei log senza sapere che cosa si cerca. Più verbosità su un problema non circoscritto produce volume, rallenta il sistema e allontana la riga utile. Prima si fissa l’intervallo temporale e il criterio, poi semmai si aumenta il dettaglio.
  • Ignorare lo stato del dispositivo. Uno stato Untrusted o Disconnected nella vista Gateways & Servers è già la risposta: cercare la causa dentro il contenuto dei log è tempo perso.