Sophos Firewall Log Viewer non mostra nuovi log

Se Log Viewer non mostra nuovi eventi, non si dovrebbe riavviare immediatamente un servizio. 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 è:

1. In Log Viewer, controllare Pause, modulo, intervallo temporale e filtri attivi, quindi eseguire Reset e Refresh.
2. Nella regola firewall interessata, verificare Log firewall traffic e, in System services > Log settings, controllare il tipo di log Firewall per Local reporting.
3. Generare una breve connessione da un client di test noto e annotare l’orario.
4. Usare Packet capture per verificare se il traffico raggiunge il firewall e quale Rule ID viene elaborata.
5. Solo se mancano anche altri eventi attesi, salvare la versione SFOS, la build completa e l’orario dell’ultimo log visibile.
6. Usare il workaround Garner solo su SFOS 21.5 MR1 Build 261 e solo per il caso descritto di seguito.

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.
• 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:

1. In Rules and policies > Firewall rules, controllare che la regola prevista abbia attivo Log firewall traffic.
2. In Log Viewer, eseguire Reset, selezionare il modulo Firewall e un intervallo temporale adeguato, quindi filtrare per 10.20.30.25.
3. Attendere alcuni secondi ed eseguire una volta un refresh manuale, perché l’evento firewall può apparire solo dopo la chiusura della sessione.
4. Se la voce manca, usare un filtro ristretto come host 10.20.30.25 in Diagnostics > Packet capture e ripetere lo stesso test.

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. Packet Capture nel WebAdmin di Sophos Firewall ne spiega l’utilizzo e i valori di stato.

Verificare NC-175936 su SFOS 21.5 MR1 Build 261

Sophos documenta l’errore NC-175936 per SFOS 21.5 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.

L’attuale Sophos Known Issues List non indica un campo univoco per la versione corretta in 21.5 MR2. Il workaround seguente non deve quindi essere applicato ad altre 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 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. 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.

Altre build e guasti ricorrenti

Sophos ha corretto altri errori relativi al database di Log Viewer, ma non sono identici. SFOS 22.0 MR1 Build 490 include con NC-152553 una correzione per un meccanismo di ripristino non riuscito di active.db; NC-169237, relativo alla perdita di eventi di Log Viewer a causa della corruzione del database, è elencato per SFOS 21.5 MR2 Build 323 e SFOS 22.0 GA Build 411. Queste Issue ID non dimostrano una correzione di NC-175936 né identificano automaticamente la causa di un guasto attuale.

Su una build precedente, pianificare prima un percorso di aggiornamento firmware SFOS supportato. Su una build attuale o dopo un riavvio Garner senza successo, non provare altri interventi 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;
• 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, storage, servizio e versione senza che ripetuti tentativi di riparazione nascondano la causa originale.