Trovare in trenta secondi le dieci righe che contano dentro milioni di log, e distinguere un sistema che sta soffrendo da uno che sta soltanto lavorando: sono due mestieri diversi, e l’esame li chiede insieme perché in produzione si alternano nella stessa mezz’ora.

Query predefinite e query personalizzate

La Logs and Monitor view di SmartConsole parte da viste e query predefinite — traffico per Software Blade, audit, attività di un singolo gateway — che conviene usare come punto di partenza e poi restringere. Una query personalizzata si costruisce combinando i campi del log (source, destination, service, action, rule, blade, utente) con l’intervallo temporale, e si conserva per riusarla: il valore di una query non è averla scritta una volta, è averla scritta in modo che un collega la ritrovi.

Due sorgenti vanno tenute distinte perché rispondono a domande diverse: i log di traffico, generati dai Security Gateway secondo la colonna Track della regola che ha fatto match, e gli audit log, generati dal Management Server per registrare le azioni degli amministratori. Un’indagine su chi ha modificato una regola non si risolve nei log di traffico.

La stessa analisi si fa dal browser con la SmartView Web Application, all’indirizzo https://IP-del-Management-Server/smartview/, percorso sensibile alle maiuscole. Offre le schede General Overview, Audit Logs e Logs View, filtri per applicazione e per utente ed esportazione in CSV fino a un milione di record; è disponibile anche per utenti non amministratori, che si autenticano con Check Point Password. È lo strumento giusto quando chi deve guardare i log non ha SmartConsole installata.

Stato e prestazioni dei sistemi

Il monitoraggio di stato non passa dai log. SmartView Monitor riceve i dati dai Security Gateway tramite il protocollo AMON su canale SIC, e il Security Management Server raccoglie lo stato a intervalli definiti, di default ogni 60 secondi, modificabili in Global Properties, Log and Alert, Time Settings. Le viste coprono stato dei gateway e dei Software Blade, Traffic views, VPN tunnel, Remote Users e i System Counters, che raccolgono informazioni su stato e attività dei prodotti Check Point, sia in tempo reale sia in forma storica.

Le soglie si impostano dalla vista Gateways Status con il tasto destro sull’oggetto e “Configure Thresholds”, scegliendo fra “Use global settings”, “None” e “Custom”. Al superamento si sceglie l’azione: log, alert con finestra popup, mail, snmptrap oppure useralert, che esegue uno script definito in Global properties, Log and Alert, Alert Commands.

Quando il monitoraggio trova qualcosa che non può aspettare l’installazione della policy ci sono le Suspicious Activity Rules: si creano da SmartView Monitor indicando Source, Destination e Service, con azione Notify, Drop o Reject e un Expiration time. Si applicano immediatamente, senza installare la Security Policy, e quelle attive si leggono nella finestra Enforced Suspicious Activity Rules.

Dal dato alla decisione

Una query utile ha tre gambe: l’intervallo temporale giusto, un filtro abbastanza stretto da restare leggibile e abbastanza largo da non escludere proprio il caso che si cerca, e un campo di partenza scelto bene. Conviene partire da ciò che è certo — un indirizzo IP, un utente, un gateway — guardare il volume dei risultati e poi aggiungere un criterio alla volta. Il contrario, scrivere subito il filtro perfetto, è il modo più rapido per ottenere zero risultati e credere che non sia successo niente.

Sul versante dello stato la regola è simmetrica: un indicatore va letto insieme al suo intervallo di raccolta e alla soglia che lo colora. Un contatore che oscilla sotto soglia non produce alcun alert, e un alert ricevuto non dice da solo per quanto tempo la soglia è rimasta superata.

Trappole tipiche d’esame

Il filtro che nasconde l’alert. Le cause ricorrenti, in ordine di frequenza: l’intervallo temporale ereditato da una query precedente; la regola che ha fatto match ha Track impostato su None, quindi quel traffico non ha mai prodotto un log da filtrare; la ricerca condotta nella vista sbagliata, per esempio cercare una modifica di configurazione fra i log di traffico invece che negli Audit Logs.

Confondere assenza di log e assenza di traffico. Una query vuota può significare che il gateway scrive i log altrove, che l’indicizzazione non è attiva o che si sta interrogando il Log Server sbagliato. L’assenza di una riga non è la prova che la connessione non sia avvenuta.

Leggere gli indicatori senza il loro contesto. Lo stato arriva via AMON ed è campionato: un dato fermo può essere un campione non ancora aggiornato o un canale SIC in errore, non un gateway in salute. E una soglia lasciata su “None” per quell’oggetto non genera alert qualunque cosa accada: il silenzio non è un buono stato di salute.

Dimenticare l’Expiration time di una SAM rule. Una Suspicious Activity Rule agisce subito e senza installare la policy, ma resta in vigore finché non scade o non la si rimuove: senza scadenza pesa sulle risorse e continua a bloccare traffico che nessuno ritrova più nel Rule Base, perché lì quella regola non c’è.