Un gateway che blocca correttamente e non lo racconta a nessuno è, dal punto di vista operativo, un gateway cieco. R82 divide il racconto fra tre strumenti che rispondono a domande diverse, e sotto tutti e tre c’è un solo componente che decide se le risposte arrivano in fretta o non arrivano affatto: il Log Server.
Tre strumenti, tre domande
La Logs and Monitor view di SmartConsole, il motore SmartLog, risponde a «che cosa è successo»: cerca nei log indicizzati prodotti da gateway e Management Server e mostra il singolo record, con il dettaglio delle informazioni che il Security Gateway ha usato per fare match sulla connessione.
SmartEvent risponde a «che cosa conta». La SmartEvent Correlation Unit legge i log dai Log Server e li correla in eventi; il SmartEvent Server li conserva nel proprio events database e li serve a SmartConsole e alla SmartView Web Application. È l’unico dei tre che trasforma migliaia di righe in un numero ridotto di cose da guardare.
Il Monitoring Software Blade, con SmartView Monitor, risponde a «come sta adesso»: stato dei Security Gateway e dei Software Blade, Traffic views, System Counters, VPN tunnel, Remote Users. Questi dati non arrivano dai log ma dal protocollo AMON su canale SIC, e il Security Management Server raccoglie lo stato dai gateway a intervalli definiti, di default 60 secondi, modificabili in Global Properties, Log and Alert, Time Settings.
Dove finiscono i log
Per impostazione predefinita i log restano sul Security Management Server. Un Log Server dedicato si introduce per togliere carico al Management e per rendere veloci le query; la documentazione consiglia di mettere su macchine dedicate sia il Log Server sia il SmartEvent Server.
La scelta si fa in SmartConsole, nell’oggetto del Security Gateway, pagina Logs, fra tre possibilità: mandare i log al Management Server, selezionare un Log Server dall’elenco, oppure “Save logs locally, on this server”. Dopo la modifica servono Publish e installazione della policy, più un Install Database quando si cambiano i server di logging. Due vincoli da ricordare: Log Server e Security Management Server devono avere la stessa major version, e fra SmartEvent, Log Server e Management Server deve esistere trust SIC. La Correlation Unit raggiunge i Log Server sulla porta 18184.
Per la continuità si configura un Log Server secondario: quando il gateway non riesce a contattare il primario invia i log al secondario, e una stessa Correlation Unit può leggere da più Log Server mantenendo la correlazione sull’intero flusso.
Tuning del Log Server
Il Log Server apre un nuovo file quando quello corrente raggiunge la dimensione massima definita e mantiene un indice dei log per rispondere in fretta alle query. L’indice è il punto delicato: la SmartLog Indexing mode non è abilitata di default dopo un upgrade o una nuova installazione su Smart-1 205, Smart-1 210 e Open Server con meno di 4 core. Sul dispositivo giusto è la differenza fra una ricerca immediata e una ricerca che non finisce.
La ritenzione si governa con due parametri: per quanti giorni conservare i log indicizzati e per quanti giorni in più conservare i file di log, con un totale massimo di 3.664 giorni. La cancellazione dei più vecchi avviene ogni giorno a mezzanotte in base alle soglie configurate, mentre gli audit log restano protetti durante la manutenzione d’emergenza. Dimensionare le partizioni è parte del tuning quanto i giorni: la guida chiede una root di almeno 20 GB e la partizione dei log più capiente possibile.
Sul carico esiste una leva architetturale: la Dynamic Log Distribution, disponibile dalla R81.10, fa distribuire ai Security Gateway i propri log fra i Log Server attivi, riducendo uso di risorse e traffico di rete. Per misurare, cpview mostra il rate di generazione dei log sul gateway e le metriche di elaborazione su Management Server e Log Server.
Trappole tipiche d’esame
I log che non ci sono. Prima di accusare il filtro, verifica dove vengono scritti: con “Save logs locally, on this server” restano sul gateway e nella Logs and Monitor view non compaiono finché non li si importa con fw fetchlogs. Stessa famiglia di errore: una modifica ai server di logging pubblicata ma senza Install Database e senza installazione della policy.
Il tuning che cancella le prove. Una ritenzione generosa su una partizione piccola non allunga la storia: alla mezzanotte successiva i log più vecchi vengono eliminati comunque. E concentrare Management Server, Log Server e SmartEvent sulla stessa macchina è la causa più comune di query lente, oltre a non essere supportato in ambiente Multi-Domain.
Cercare veloce senza indice. Se l’indicizzazione non è attiva la ricerca non è soltanto più lenta: la vista può sembrare vuota e portare alla conclusione sbagliata che quel traffico non sia mai passato.
Leggere male gli indicatori di stato. Lo stato in SmartView Monitor arriva via AMON su SIC ed è campionato a intervalli: un gateway che risulta senza dati può avere un problema di SIC o di blade di monitoraggio invece che essere fuori servizio, e un valore appena cambiato può semplicemente non essere ancora stato raccolto.