Sophos Firewall Log Viewer non mostra nuovi log

Se Log Viewer non mostra nuovi eventi su SFOS 22, non si dovrebbe riavviare un servizio basandosi solo su un sospetto. Prima bisogna capire se manca solo una voce attesa o se l’intera visualizzazione locale dei log si è bloccata. Per l’uso normale, i filtri e l’interpretazione dei campi, consultare prima Utilizzare correttamente il Log Viewer di Sophos Firewall. La procedura rapida e sicura per una visualizzazione bloccata è:

In Log Viewer, controllare Pause, modulo, intervallo temporale e filtri attivi, quindi eseguire Reset e Refresh.
Nella regola firewall interessata, verificare Log firewall traffic e, in System services > Log settings, controllare il tipo di log Firewall per Local reporting.
Generare una breve connessione da un client di test noto e annotare l’orario.
In Diagnostics > Packet capture > Configure, impostare un filtro BPF ristretto, attivare la cattura e verificare se il traffico raggiunge il firewall e quale Rule ID viene elaborata.
Disattivare la cattura dopo il test. Solo se mancano anche altri eventi attesi, salvare la versione SFOS, la build completa e l’orario dell’ultimo log visibile.
Su SFOS 22 non usare workaround Garner o del database provenienti da versioni precedenti. Controllare la maintenance release attuale e fornire i dati diagnostici a Sophos Support se tutti i log locali sono bloccati.
Il workaround Garner mantenuto più avanti riguarda esclusivamente SFOS 21.5.1 MR1 Build 261 e l’esatto caso documentato.

In questo modo la ricerca del problema rimane tracciabile: un filtro errato o una regola che non registra il traffico non viene confusa con un errore del database di logging.

Perché può mancare una singola voce di log

Normalmente Log Viewer si aggiorna automaticamente. Mostra però solo gli eventi che il modulo selezionato memorizza localmente e che la vista corrente non nasconde.

Le cause frequenti che non indicano un guasto tecnico di Log Viewer sono:

Pause è attivo: I nuovi eventi diventano visibili solo dopo aver ripreso la visualizzazione o eseguito un refresh manuale.
Modulo, intervallo temporale o filtri non corrispondono: Reset rimuove tutti i filtri; in seguito si seleziona nuovamente il modulo pertinente.
Rule Logging è disattivato: Le sessioni del firewall appaiono solo se Log firewall traffic è attivo nella regola che esegue effettivamente il match.
Local reporting è disattivato: In System services > Log settings, il tipo di log richiesto deve essere selezionato nella colonna Local reporting.
La connessione è ancora aperta: Le sessioni del firewall vengono normalmente registrate con l’evento Destroy, quando la connessione termina. Una voce può quindi apparire dopo il primo tentativo di connessione.
La sessione termina senza un evento Destroy: Se, ad esempio, si interrompe la connessione Internet, la sessione può chiudersi senza alcuna voce di log. La voce non è quindi soltanto in ritardo: non viene mai creata.
Il traffico non raggiunge il firewall: L’assenza di una voce di log non dimostra che il firewall abbia scartato il pacchetto. Il client, un router a monte, DNS o un altro percorso possono già impedire la connessione.
Firewall Log suppression raggruppa le ripetizioni: Gli eventi firewall successivi soppressi possono essere riuniti in Log occurrence invece di apparire come molte righe separate.

Se Log Viewer continua a mostrare nuovi eventi di sistema o firewall provenienti da altre prove, la visualizzazione funziona in linea di principio. La causa si trova quindi più probabilmente nel logging della regola, nella selezione del modulo, nei filtri, nella chiusura della sessione o nell’effettivo percorso dei pacchetti. Per distinguere questi casi, è più adatta la procedura per testare la regola con Log Viewer, Policy Tester e Packet Capture.

Generare un flusso di test controllato

Un test riproducibile è più affidabile dell’attesa di traffico casuale degli utenti. Nell’esempio seguente, il client di test usa l’indirizzo IP adattabile 10.20.30.25. Sul client, non nella shell del firewall, si stabilisce una breve connessione HTTPS:

curl -I https://example.com/

example.com è un dominio riservato agli esempi. Per il test si può anche usare un proprio servizio HTTPS noto e consentito. È essenziale che il processo chiuda nuovamente la connessione e che siano noti orario, IP del client e destinazione.

Successivamente, verificare in questo ordine:

In Rules and policies > Firewall rules, controllare che la regola prevista abbia attivo Log firewall traffic.
In Log Viewer, eseguire Reset, selezionare il modulo Firewall e un intervallo temporale adeguato, quindi filtrare per 10.20.30.25.
Attendere alcuni secondi ed eseguire una volta un refresh manuale, perché l’evento firewall può apparire solo dopo la chiusura della sessione.
Se la voce manca, aprire Diagnostics > Packet capture, fare clic su Configure, inserire il filtro ristretto host 10.20.30.25 in Enter BPF string e salvare. Sostituire l’indirizzo IP con quello effettivo del client di test.
Attivare Packet capture, ripetere il test una volta e poi disattivare la cattura. In questo modo la cattura resta limitata al client noto e a un breve intervallo.

L’osservazione determina il passo successivo:

Packet Capture non vede il traffico di test: Cercare la causa prima del firewall o sul client.
Packet Capture mostra una Rule ID diversa: Controllare la regola che esegue effettivamente il match e il relativo logging.
Appaiono altri nuovi eventi in Log Viewer: Log Viewer non è completamente bloccato; continuare a esaminare filtri, tipo di log e regola specifica.
Packet Capture conferma il flusso, Rule Logging e Local reporting sono corretti, ma tutti i nuovi eventi continuano a mancare: Controllare la build e l’elaborazione locale dei log.

Packet Capture mostra il flusso dei pacchetti, ma non ripara la visualizzazione dei log. Se il buffer è pieno e Wrap capture buffer once full non è selezionato, SFOS interrompe automaticamente la cattura; Clear libera il buffer per un nuovo test. Packet Capture nel WebAdmin di Sophos Firewall ne spiega l’utilizzo e i valori di stato.

Classificare il guasto su SFOS 22

La Sophos Known Issues List limita NC-175936 a SFOS 21.5.1 MR1 Build 261 e dichiara esplicitamente che il problema è risolto nella versione 22. Il relativo riavvio di Garner non è quindi una procedura di riparazione per SFOS 22.

Le note di rilascio di SFOS 22 elencano altre modifiche al Logging Framework. SFOS 22.0 GA Build 411 ha corretto NC-169237, in cui la corruzione del database causava la perdita di eventi di Log Viewer. SFOS 22.0 MR1 Build 490 ha corretto NC-152553, un errore nel meccanismo di ripristino di active.db. La versione più recente indicata, SFOS 22.0 MR2 Build 546, migliora le prestazioni di Log Viewer con NC-181520.

Queste voci confermano problemi risolti, ma non identificano la causa di un guasto attuale. Su SFOS 22, registrare versione e build esatte, verificare un percorso di upgrade supportato alla maintenance release attuale e non modificare file del database né riavviare un servizio di logging dalla shell se gli eventi continuano a mancare.

Verificare `NC-175936` su SFOS 21.5.1 MR1 Build 261

Sophos documenta l’errore NC-175936 per SFOS 21.5.1 MR1 Build 261: il file /tmp/eventlogs/active.db può mancare, impedendo a Log Viewer di mostrare nuovi dati. Secondo Sophos, il firewall continua a elaborare il traffico e le funzioni di sicurezza rimangono attive. Questa affermazione descrive il problema noto e non costituisce una verifica generale dello stato di salute di un firewall senza log.

Sophos dichiara inoltre esplicitamente che il problema è risolto nella versione 22. Il seguente workaround legacy non deve quindi essere applicato a SFOS 22 né a un’altra build solo in presenza di un sintomo simile.

Pre-check di sola lettura nella Advanced Shell

Annotare prima la build completa, l’orario, l’ultimo evento visibile e, in HA, il nodo interessato. Se WebAdmin funziona ancora, salvare garner.log e, se possibile, un Consolidated Troubleshooting Report prima della modifica.

Connettersi quindi tramite l’accesso SSH documentato a Sophos Firewall e aprire la Advanced Shell. I comandi seguenti leggono soltanto lo stato dello storage, il file e il log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp mostra se nel file system è ancora disponibile spazio libero. ls -l conferma se active.db esiste; se manca, la shell può mostrare un messaggio come No such file or directory, a seconda della build. In garner.log si cercano gli errori relativi all’orario di test documentato. Associare correttamente i Service Log di Sophos Firewall spiega ulteriori nomi di servizi e file di log.

Se /tmp è pieno, il file è presente, la build è diversa o il sintomo non è univoco, non eseguire il riavvio seguente. I file in /tmp/eventlogs non devono essere eliminati, copiati o creati manualmente.

Riavviare Garner una sola volta in modo controllato

⚠️ Comando che modifica lo stato: Questo workaround si applica solo al caso documentato su SFOS 21.5.1 MR1 Build 261. Salvare prima i log e lo stato del sistema. In un cluster HA, non eseguire il comando su entrambi i nodi senza una procedura verificata. Non riavviare Garner ripetutamente e non riparare o eliminare mai manualmente active.db.

Per NC-175936, Sophos indica esattamente questo comando nella Advanced Shell:

service garner:restart -ds nosync

Il comando è stato ripreso dall’attuale Sophos Known Issues List per questo articolo, ma non è stato testato in laboratorio su un’appliance. Il riavvio di un servizio non può essere annullato; se il file resta assente o gli eventi continuano a non apparire, fermarsi e fornire a Sophos Support lo stato registrato prima della modifica. Dopo il singolo riavvio, controllare nuovamente il file e gli ultimi messaggi Garner con comandi di sola lettura:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Successivamente, eseguire Reset e Refresh in Log Viewer e ripetere lo stesso breve flusso di test. L’intervento ha avuto successo solo quando appare un nuovo evento con un timestamp corrispondente. La sola presenza di active.db non dimostra che l’intero percorso di logging sia nuovamente funzionante.

Se SFOS 22 continua a non mostrare nuovi eventi

Se Packet Capture mostra il flusso di test controllato su SFOS 22, Rule Logging e Local reporting sono corretti e i nuovi eventi continuano a mancare in tutti i moduli, pianificare prima un percorso di aggiornamento firmware SFOS supportato alla maintenance release attuale. Se il problema rimane sulla build corrente, non intervenire sul database o sui servizi.

Per un caso di supporto, raccogliere almeno:

modello dell’appliance, versione SFOS e build completa;
in HA, nodo interessato e relativo ruolo;
timestamp dell’ultima voce visibile in Log Viewer e orario del flusso di test;
modulo, filtri, Rule ID, Source, Destination e Service del test;
stato di Log firewall traffic e Local reporting;
risultato di Packet Capture;
per l’esatto caso 21.5.1 MR1, output di df -kh /tmp e ls -l /tmp/eventlogs/active.db;
garner.log, se necessario fwlog.log e iview.log, nonché, se possibile, un CTR prima di ulteriori modifiche;
informazione sull’eventuale singolo riavvio di Garner e su cosa è cambiato in seguito.

In questo modo Sophos può distinguere tra errori di visualizzazione, database, archiviazione, servizio e versione senza che ripetuti tentativi di riparazione nascondano la causa originale.