La catena dei log: chi genera, chi consegna, chi archivia

I log di rete li generano i Security Gateway e i Cluster Member, in base alla Security Policy installata su ciascuno. Gli audit log li genera il Management Server, e raccontano le azioni degli amministratori. Sono due flussi distinti, con due origini distinte: tenerli separati è metà del lavoro di diagnosi.

La destinazione si sceglie nell’oggetto del gateway in SmartConsole, vista Gateways & Servers, sezione Logs: si inviano i log al Security Management Server, a un Log Server dedicato scelto dall’elenco, oppure si salvano localmente sul gateway. Dopo la modifica servono tre gesti che si dimenticano volentieri: confermare, pubblicare la sessione e installare la policy sul gateway. Quando si cambia l’assegnazione del Log Server o se ne modificano le impostazioni va inoltre eseguito Install Database sul Log Server remoto. Un vincolo da ricordare: Log Server e Security Management Server devono avere la stessa major version.

C’è poi un comportamento che spiega parecchie sparizioni apparenti. Se i Log Server primari non sono disponibili, il gateway invia al primo Backup Log Server configurato e prosegue lungo la catena dei backup; se nessun server è raggiungibile, scrive i log localmente. Quei log non sono persi: verranno inoltrati secondo una pianificazione, oppure importati a mano. Quindi «non vedo i log in SmartConsole» non significa «i log non esistono»: possono essere altrove.

Non generati o non consegnati: la prima biforcazione

Davanti a un buco nei log la domanda che ordina tutto il resto è se quei log siano mai stati prodotti.

Se la regola che gestisce quel traffico ha Track impostato su None, il log non esiste e nessuna indagine sulla consegna lo farà comparire. None è il valore predefinito nella Access Control policy, quindi il caso è tutt’altro che raro. Il controllo si fa in SmartConsole sulla colonna Track della regola che il traffico sta colpendo davvero, che non sempre è quella che ci si aspetta.

Se invece il tracking c’è, il problema è nella consegna, e il perimetro del buco indica dove guardare. Mancano i log di un solo gateway: l’oggetto di quel gateway, la sua destinazione di log, la sua comunicazione con il Log Server. Mancano quelli di tutti: il Log Server. Mancano da un certo istante in poi: cerca che cosa è cambiato in quel momento, per esempio una nuova destinazione pubblicata senza installare la policy o un Install Database mai eseguito.

Terza possibilità, la più insidiosa: i log arrivano ma non si vedono, e il difetto sta nell’indicizzazione. cpwd_admin list mostra i processi sotto WatchDog, fra cui INDEXER, SOLR, SMARTVIEW e SMARTLOG_SERVER: STAT a T o un #START che cresce indicano un processo che muore e riparte, e un motore di ricerca fermo produce il sintomo «la Logs view è vuota» mentre i file sul disco crescono.

Il lab: attivare il guasto, seguire la catena, ripristinare

L’esercizio del modulo percorre la catena sempre nello stesso verso. Si parte dalla fotografia sana: quali gateway mandano log, a chi, quanto spazio resta sul Log Server. Poi si attiva il guasto, uno solo per volta, e si osserva a quale anello la catena si interrompe. Il primo anello è la generazione, e si verifica dal Track della regola. Il secondo è la consegna, e la prova che la chiude sono i file di log locali sul gateway: se il gateway scrive in locale, il trasporto verso il Log Server è caduto. Il terzo è l’archiviazione, dove lo spazio su disco va escluso per primo perché si manifesta senza rompere nulla di visibile.

Per lavorare sui file servono due comandi. fw logswitch chiude il file di log attivo, lo rinomina e ne apre uno nuovo: agisce su $FWDIR/log/fw.log, e con l’opzione -audit sul file di audit $FWDIR/log/fw.adtlog. Senza un nome esplicito il file chiuso prende il formato data e ora. fw fetchlogs recupera i file da un server Check Point remoto e li porta in $FWDIR/log/ sul server locale, con il nome del server di origine in testa, cancellandoli dall’origine dopo un trasferimento riuscito. I due comandi vanno insieme: i file attivi non si recuperano senza prima un logswitch.

Il lab si chiude come si è aperto: rimosso il guasto, ripristinata la destinazione dei log, ripubblicata la sessione e reinstallata la policy, si verifica che i nuovi eventi compaiano davvero in SmartConsole.

Trappole tipiche d’esame

  • Log mai generati contro log non consegnati. La domanda descrive un traffico che passa e non compare nei log, e offre risposte sul Log Server, sulla rete, sul disco. Se nella traccia c’è una regola con Track su None, il traffico non ha mai prodotto un log: nessuna correzione sulla consegna lo farà apparire. Cerca sempre prima il tracking della regola, poi la catena.
  • Lo spazio disco del Log Server è l’ipotesi che si dimentica. Un disco pieno ferma l’archiviazione senza rompere niente di appariscente: policy installata, gateway sano, comunicazione in piedi, log assenti. Negli scenari in cui tutto risulta corretto è quasi sempre lì la risposta, ed è un controllo che costa un comando.
  • Network log e audit log hanno origini diverse. I log di rete nascono sui Security Gateway e sui Cluster Member, gli audit log li genera il Management Server per le azioni degli amministratori. Se lo scenario chiede perché non si vedono le modifiche fatte da un amministratore, guardare la Track di una regola o la destinazione dei log del gateway è la strada sbagliata.