Identificare correttamente i log dei servizi di Sophos Firewall

In Sophos Firewall ci sono tre livelli importanti per il troubleshooting: i log degli eventi nel Log viewer, gli strumenti diagnostici nel WebAdmin e i file di log o di servizio sul firewall. Il Log Viewer è ideale per domande rapide come “la connessione è stata consentita o bloccata?”. I file sotto /log sono più importanti quando un servizio non si avvia, un tunnel VPN è instabile, i filtri web agiscono inaspettatamente o il supporto richiede dati dettagliati.

Questo articolo classifica i servizi e i file di log più importanti in base ai problemi tipici degli amministratori. È utile anche quando nel dashboard, nella Advanced Shell o in un caso di supporto appare un nome tecnico di servizio e non è immediatamente chiaro quale funzione del firewall vi sia associata. Nomi come zebra, warren, awed, garner o strongswan non sono autoesplicativi nella vita quotidiana.

Scelta dello strumento e prerequisiti

Prima di cercare nei file di log, bisogna chiarire quale strumento fornisce la risposta più rapida. Molti casi possono già essere circoscritti con Log Viewer o Packet Capture. La shell diventa davvero utile solo quando è necessario controllare un servizio oppure il supporto richiede dati di log dettagliati.

Quale strumento di risoluzione dei problemi è adatto?

Non tutti i problemi del firewall iniziano con una shell. Spesso un altro strumento è più veloce:

• Connessione consentita o bloccata? Testare la regola del firewall con Log Viewer, Policy Test e Packet Capture.
• L’intero Log Viewer non mostra nuovi eventi? Verificare filtri, logging e il workaround Garner specifico per la build.
• L’intero firewall si è riavviato inaspettatamente? Prima classificare il riavvio come reboot dell’appliance, failover HA o guasto di un servizio, quindi salvare sysinit.log, syslog.log e il CTR.
• I pacchetti arrivano, ma non è chiaro se proseguono? Utilizzare Sophos Firewall Packet Capture in WebAdmin.
• La cattura pacchetti deve durare più a lungo, essere salvata come PCAP o analizzata in Wireshark? Sophos Firewall tcpdump: catturare pacchetti tramite CLI.
• Una modifica di configurazione è la possibile causa? Verificare i log di Sophos Firewall Audit Trail.
• Una modifica da Sophos Fusion (in precedenza Sophos Central) è bloccata? Verificare la coda delle attività del firewall di Sophos Fusion.
• Servono report o cronologia in Sophos Fusion? Attivare e gestire Sophos Firewall Central Reporting.
• I log devono finire a lungo termine in SIEM, SOC o server di log? Inviare i log di Sophos Firewall a SIEM tramite Syslog.
• Sono centrali flussi di traffico, picchi di banda o pattern di comunicazione? Configurare il monitoraggio sFlow su Sophos Firewall.
• Un servizio non funziona o il supporto richiede log? Questo articolo.
• Salvare log locali per Sophos Support o Avanet? Salvare i log di Sophos Firewall per supporto e analisi.
• Preparare un caso di supporto? Aprire un ticket di supporto Sophos: preparazione e portale.

L’ordine è importante. Il Log Viewer mostra spesso più rapidamente quale regola o modulo ha deciso. Packet Capture dimostra il flusso di pacchetti in WebAdmin. tcpdump è utile quando è necessaria una cattura più lunga, un file PCAP o un filtro CLI molto preciso. I log di servizio e il debug aiutano quando un determinato servizio è il problema o quando è necessario raccogliere dati per il supporto Sophos.

Per le sole verifiche di raggiungibilità, Diagnostics > Tools integra la ricerca nei log con Ping, Traceroute e lookup DNS e delle route. Ping verifica la raggiungibilità, Traceroute il percorso e un lookup la risoluzione dei nomi o la route. I comandi diagnostici di base aiutano a scegliere lo strumento; un test riuscito dal firewall non sostituisce un test dal client interessato.

Accesso rapido per sintomo

Se non è chiaro quale log sia rilevante, conviene partire dal sintomo invece che dal nome del servizio.

• Una singola connessione non funziona: prima controllare Log Viewer con Source, Destination, Service e orario. Poi usare Packet Capture, firewall_rule.log e nat_rule.log.
• Tunnel VPN non disponibile o instabile: controllare stato VPN, Peer-IP, orario e Log Viewer. Poi consultare strongswan.log, charon.log, sslvpn.log e dati diagnostici IPsec.
• WebAdmin, User Portal o SSH non è raggiungibile: controllare Device Access, Local Service ACL e zona interessata. Poi usare apache.log, tomcat.log, sshd.log e Packet Capture sulla porta di destinazione.
• Il filtro web, TLS Inspection o IPS blocca inaspettatamente: controllare modulo Log Viewer e Policy ID. Poi confrontare ips.log, awarrenhttp.log e Packet Capture.
• Un’attività Sophos Fusion resta bloccata: confrontare Central Task Queue e stato locale. Poi controllare centralmanagement.log, sophos-central.log e fwcm-api-executor.log.
• HA si comporta diversamente per nodo: determinare Active Node, Auxiliary Node e percorso di traffico interessato. Poi accedere direttamente al nodo interessato e controllare i log HA.
• Report locali mancanti o spazio di archiviazione in esaurimento: controllare impostazioni dei report, spazio disponibile e Central Reporting. Poi usare reportdb.log, garner.log e analisi dello spazio.

Questa vista evita una trappola tipica: cercare in un file di log di servizio quando prima bisognerebbe dimostrare Rule Matching, Device Access, NAT o routing.

Log Viewer o file di log?

Il Log viewer si apre nella console WebAdmin in alto a destra. Si aggiorna automaticamente, può essere filtrato per modulo, tempo, valori di campo e testo libero e può esportare i log come CSV.

Per proteggere nomi utente e indirizzi IP, MAC ed e-mail nella visualizzazione quotidiana dei log si può utilizzare Data Anonymization per log e report locali. L’effetto in Log viewer non dimostra automaticamente che i file in /log, CTR, Remote Syslog o Central anonimizzino le stesse identità; ogni percorso di output viene verificato separatamente.

I log di risoluzione dei problemi si trovano nella directory /log. Il percorso ufficialmente documentato passa dalla CLI: accedere, scegliere 5 Device Management e poi 3 Advanced Shell. SSH è in genere più comodo per sessioni lunghe con tail, grep o less. La preparazione sicura è descritta in Collegarsi a Sophos Firewall tramite SSH.

Prima di sessioni shell più lunghe, dovrebbe essere chiaro da quale rete amministrativa ci si connette, se l’impronta digitale SSH è stata verificata e se è davvero necessaria la Advanced Shell. Per molti controlli iniziali, il Log Viewer o Packet Capture in WebAdmin sono sufficienti.

Come regola generale, questa sequenza aiuta:

1. È interessato un singolo flusso di traffico: filtrare il Log Viewer per Source, Destination, Service e orario.
2. Il Log Viewer non mostra una decisione: avviare Packet Capture con un filtro stretto.
3. Packet Capture mostra Incoming, ma nessuna decisione chiara: verificare Rule ID, NAT ID, Firewall ID 0, percorso di ritorno e file di log appropriato.
4. Un servizio specifico sembra instabile: osservare il file appropriato sotto /log con tail -f.
5. Un errore è sporadico o richiede supporto: preparare finestra temporale, filtro, archivio log ed eventualmente tcpdump.
6. I log normali non bastano: attivare il debug solo per il servizio interessato e solo per breve tempo.

In questo modo l’analisi rimane abbastanza piccola. Si raccoglie prima il risultato visibile, si passa poi al flusso di pacchetti e solo successivamente ai log di servizio o al debug. Questo riduce il rischio di attivare troppo presto log di debug ampi o di valutare un file di log errato.

Leggere i file di log nella Advanced Shell

Prima di cercare in /log, il caso di test dovrebbe essere documentato il più strettamente possibile: ora locale, IP di origine interessato, IP di destinazione, porta, utente, modulo e comportamento previsto. Queste informazioni fanno la differenza tra un’analisi dei log utile e una lunga ricerca tra vecchi record.

1. Accedere alla CLI, scegliere 5 Device Management e poi 3 Advanced Shell.
2. Passare alla directory dei log.

cd /log

Comandi utili:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

I comandi più importanti dalla Advanced Shell:

• Leggere live: tail -f /log/<logfilename>.log, ad esempio tail -f /log/ips.log.
• Leggere un file di log statico: less /log/<logfilename>.log, ad esempio less /log/ips.log.
• Cercare un termine: grep <keyword> /log/<logfilename>.log, ad esempio grep error /log/ips.log.
• Leggere lo stato di un servizio: usare service -S oppure limitare la ricerca a un nome, ad esempio service -S | grep ips. Questo controllo non modifica il servizio.

Per un filtro live mirato si può aggiungere la data o l’indirizzo del client:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

La data e 192.0.2.10 sono valori di esempio: vanno sostituiti con la data visibile nel log o con l’IP del client interessato. tail -f mostra solo le ultime righe già presenti e le nuove voci aggiunte, non automaticamente l’intera cronologia della giornata. Per le voci già salvate si usa, ad esempio, grep 2026-10-10 /log/ips.log. Se il filtro non restituisce risultati, verificare prima il formato dell’ora, il fuso orario, l’IP e il file di log, prima di sospettare un logging mancante. In less /log/ips.log, Shift+G porta alla fine del file, Enter avanza di una riga e q chiude la visualizzazione; Ctrl+C interrompe un’acquisizione in corso con tail -f. La pipeline con less restituisce testo filtrato, non una vista interattiva di less. Questi comandi leggono i log, ma non modificano né le regole né lo stato del debug.

Per supporto o un’analisi successiva, non si dovrebbero copiare solo singole righe di log. È meglio avere un chiaro intervallo di tempo, il test riprodotto, screenshot rilevanti dal Log Viewer o Packet Capture e, se necessario, un archivio log completo. I log locali ruotano; pertanto, i dati importanti dovrebbero essere salvati finché l’evento è ancora presente nel periodo interessato. La procedura è descritta in Salvare i log di Sophos Firewall per analisi esterna.

Scaricare i troubleshooting log dal WebAdmin

Non ogni raccolta deve essere assemblata manualmente nella Advanced Shell. WebAdmin raccoglie i file sotto Diagnostics > Tools.

In pratica ci sono due percorsi:

• File di log singoli: aprire Diagnostics > Tools > Troubleshooting logs, selezionare i file di log interessati e scaricarli come file compresso.
• Consolidated Troubleshooting Report (CTR): usare Diagnostics > Tools > Consolidated troubleshooting report quando il supporto ha bisogno di tutti i log più stato del sistema, processi e dati sulle risorse in un unico pacchetto.

È pratico quando basta un pacchetto di log ben delimitato. Il CTR è preferibile quando Sophos Support necessita di un’istantanea ampia del sistema. Inserire un motivo chiaro, ad esempio numero del ticket, intervallo temporale o sintomo. Il report viene scaricato cifrato; il nome del file contiene anche il numero di serie del firewall e non deve quindi comparire in allegati pubblici.

Per impostazione predefinita, un CTR contiene 10.000 righe per ogni service subsystem log. Nella Device Console il valore può essere impostato solo tra 250 e 10.000, quindi può soltanto essere ridotto rispetto al valore predefinito. I default subsystem logs includono invece tutte le righe. Questo limite riguarda solo il CTR; i singoli file completi restano disponibili tramite Troubleshooting logs o Advanced Shell.

Importante: un pacchetto log scaricato non sostituisce i dati di contesto. Il supporto ha comunque bisogno di orario con fuso orario, IP interessati, utente, nome tunnel, Rule ID, NAT ID e una breve descrizione di cosa è stato riprodotto esattamente.

Nei cluster HA va considerato anche questo: log e report non vengono semplicemente sincronizzati tra Primary e Auxiliary. Ogni nodo contiene i log del traffico e dei servizi che ha elaborato direttamente. Per errori specifici di un nodo bisogna quindi controllare il nodo interessato.

Comprendere la rotazione dei log e i dati volatili

I Troubleshooting Logs vengono creati inizialmente in memoria e poi copiati dal firewall nel file system. Se il firewall smette di rispondere, le voci non ancora copiate possono andare perse. Un riavvio imprevisto o un blocco non è quindi un motivo per rimandare la conservazione delle prove: prima si salvano CTR, log e dati temporali disponibili.

Ogni sottosistema ha limiti propri di dimensione e archiviazione, in funzione della criticità e del modello di appliance. Quando il file attivo raggiunge il limite, SFOS lo comprime come .gz e continua a scrivere con il nome originale. Se anche le rotazioni raggiungono il limite del sottosistema, viene eliminato per primo il file compresso più vecchio. Il numero di rotazioni e la profondità dello storico non sono quindi uguali per tutti i servizi.

I file di log e le rotazioni .gz non vanno rinominati o eliminati manualmente. Per l’analisi dello spazio, l’esportazione e i comandi di purge documentati si segue il flusso Gestire in modo controllato lo spazio di archiviazione e i report.

Advanced Shell o Device Console?

In Sophos Firewall ci sono due aree di console diverse, spesso confuse:

• Device Console: CLI Sophos per comandi specifici del firewall, ad esempio priorità di routing, rotte IPsec o opzioni di sistema.
• Advanced Shell: shell simile a Linux per file system, log e comandi di sola lettura come tail, grep, less e service -S.

Non tutti i comandi funzionano in entrambe le aree. /log, tail -f, grep e service -S appartengono alla Advanced Shell. I comandi documentati system diagnostics ... per limiti CTR, eliminazione dei log e debug dei sottosistemi appartengono invece alla Device Console.

Questa distinzione è importante perché molti errori derivano semplicemente dall’inserimento di un comando corretto nel posto sbagliato.

Il logging deve essere attivo

Non tutte le informazioni attese appaiono automaticamente.

• Nelle regole del firewall, Log firewall traffic deve essere attivo.
• Nelle regole di ispezione SSL/TLS, il logging deve essere attivato.
• In System services > Log settings deve essere definito quali tipi di log vengono inviati localmente, a Sophos Fusion o a Syslog.

Per la conservazione a lungo termine, un server Syslog o Sophos Central Firewall Reporting è utile. Come collegare server di log esterni o un SIEM è descritto in Inviare i log di Sophos Firewall a SIEM tramite Syslog. Per Sophos Fusion, il processo appropriato è Attivare Central Firewall Reporting.

Attivare il debug solo in modo mirato

Il logging di debug genera molti più dati, occupa spazio e può registrare contenuti riservati. Non è quindi un primo passo ragionevole. Prima si definiscono log normale, intervallo temporale e test riproducibile; il debug si usa solo per il sottosistema interessato e per il tempo strettamente necessario.

Sophos documenta due metodi diversi. La forma Advanced Shell service <service>:debug -ds nosync commuta lo stato e non accetta un argomento separato on o off. Per un sottosistema di servizio supportato sono preferibili i comandi espliciti di Device Console documentati da Sophos: system diagnostics subsystems <subsystem> debug on, riprodurre il problema e raccogliere i dati, quindi eseguire system diagnostics subsystems <subsystem> debug off. Per il debug di Packet Capture, ad esempio, il nome del sottosistema è Pktcapd. Il debug è disattivato per impostazione predefinita, ma prima di modificarlo bisogna verificare che nessun altro amministratore o Sophos Support stia già raccogliendo dati. Registrare la modifica e controllare al termine che il debug sia disattivato.

Trattare il debug del controller di sistema CSC come commutatore separato

SFOS 22 documenta un comando Device Console separato per il controller di sistema (CSC):

system diagnostics subsystems CSC debug

Diversamente dalla sintassi del sottosistema di servizio precedente, questo comando non ha un argomento on o off: ogni esecuzione commuta il debug CSC. Va quindi usato come modifica controllata, non come interrogazione dello stato:

1. Controllo preliminare: Confermare con gli altri amministratori e Sophos Support che il debug CSC non sia già attivo o parte di una raccolta in corso. Registrare firewall o nodo HA, ora, motivo e finestra di raccolta prevista. Conservare una copia di riferimento del log CSC pertinente prima della modifica. Non eseguire il commutatore solo per scoprirne lo stato.
2. Attivare e riprodurre: Eseguire il comando esattamente una volta in Device Console. Riprodurre solo il problema delimitato e annotare l’ora del test con il fuso orario.
3. Conservare le prove: Prima del rollback, scaricare il singolo log di troubleshooting pertinente oppure generare il CTR e scaricare il file CTR completato. Limitare l’accesso al CTR cifrato e a ogni archivio di log perché possono contenere dati riservati; non eliminare né sovrascrivere le prove necessarie per il caso.
4. Disattivare / rollback: Tornare in Device Console ed eseguire esattamente una volta lo stesso comando. Questa seconda esecuzione pianificata disattiva nuovamente il debug CSC.
5. Verificare: Eseguire un breve test controllato e confermare nelle nuove righe del log CSC che l’output di livello debug sia cessato e che la crescita del log sia tornata normale. Registrare ora ed esito del rollback. Se lo stato iniziale o il controllo successivo sono ambigui, non ripetere il commutatore; fermarsi e coordinare lo stato con Sophos Support.

⚠️ Debug WAF e reverseproxy.log: con SFOS 22.0 MR2 Build 546, Sophos ha corretto il problema NC-177457: una password era visibile in reverseproxy.log quando il debug WAF era attivo. Sophos non indica né l’inizio dell’intervallo di versioni interessato né il tipo di password. I log di debug WAF, gli archivi di troubleshooting e i file CTR già generati su build precedenti o sconosciute devono quindi essere considerati come potenzialmente contenenti credenziali.

Se viene trovata una credenziale in chiaro: limitare l’accesso, documentare l’incidente e ruotare la credenziale interessata. Non eliminare indiscriminatamente i log prima di aver chiarito i requisiti di supporto, analisi forense e conservazione.

Il tema del logging di debug e dei comandi CLI di base è descritto più dettagliatamente nell’articolo Risoluzione dei problemi CLI di Sophos Firewall: comandi importanti. Per il riavvio di singoli servizi, aiuta anche Riavviare in sicurezza i servizi di Sophos Firewall.

Errori tipici nella ricerca dei log

Molte analisi dei log durano a lungo non a causa della mancanza di dati, ma perché si cerca troppo presto nello strumento sbagliato.

• Attivare direttamente il debug: controllare prima Log Viewer, file di log appropriato e test riproducibile.
• Cercare solo messaggi di errore: limitare anche per Source, Destination, utente, Rule ID, NAT Rule ID e orario.
• Ignorare Packet Capture: se non è chiaro se i pacchetti arrivano o vengono inoltrati, utilizzare presto Packet Capture.
• Interpretare Central Reporting come debug live: usare Central Reporting per cronologia e report, log locali per analisi dettagliata.
• Salvare i log di supporto solo giorni dopo: salvare log, orario e passaggi di riproduzione finché l’evento è ancora tracciabile.
• Lasciare il debug attivo dopo il test: disattivare nuovamente il debug e controllare lo spazio di archiviazione.

Un buon caso di risoluzione dei problemi ha quindi sempre tre cose: un test stretto, la fonte di log appropriata e un orario documentato. Senza questa base, si vedono molte righe di log, ma non necessariamente la causa.

File di log per area funzionale

Le liste seguenti sono pensate come riferimento. Conviene scegliere prima l’area funzionale interessata e poi controllare il file di log appropriato con una finestra temporale stretta.

Le associazioni principali tengono conto di SFOS 22.0 e 23.0; i file OAuth SSO differiscono tra queste versioni, come indicato di seguito. Nelle installazioni meno recenti o nei vecchi archivi di supporto possono comparire anche i nomi usati in precedenza: app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log e crreportdb.log. Sophos non li elenca negli elenchi dei log SFOS 22/23 considerati qui; pertanto non bisogna darne per scontata la presenza in una build attuale.

I log generali di sistema e configurazione vanno controllati in aggiunta a quelli del modulo interessato. Un file può servire a più funzioni: ciò che conta è il suo significato nel problema specifico, non soltanto il nome del servizio.

Sistema, gestione e servizi di base

• Avvio del sistema: sysinit.log; da controllare per primo in caso di problemi di avvio e di modalità failsafe.
• Messaggi di sistema a livello kernel: syslog.log; verificare anche l’ora, i riavvii e gli eventi delle interfacce. Confrontare anche gli eventi di sistema e quelli avviati dagli amministratori nel Log Viewer.
• Server web Apache per WebAdmin e User Portal: apache.log, apache_access.log e error_log.log; verificare anche Device Access e Local Service ACL.
• Applicazione WebAdmin e User Portal: server di applicazioni web Jetty, file di log tomcat.log; verificare anche gli errori della GUI, il carico elevato e lo stato del servizio. Il nome del file non corrisponde al nome del server di applicazioni web attuale.
• SSH: sshd.log; verificare anche Device Access, la rete di origine e il login con chiave pubblica.
• Errori GUI/CLI: error_log.log; verificare anche la modifica recente, il browser e l’azione dell’amministratore.
• Modifiche alla configurazione: applog.log, csc.log; verificare anche Audit Trail e Config Studio.
• Database di configurazione: postgres.log; verificare anche lo spazio di archiviazione, il backup/ripristino e il caso di supporto.
• Canale di comunicazione tra determinati componenti e i relativi servizi: garner.log; per Central Management e Reporting, verificare anche le voci dei rispettivi plugin.
• API: apiparser.log; verificare anche validation.log, l’ACL dell’API, il token e Central Task Queue.
• Validazione: validation.log, validationError.log; verificare anche oggetti o importazioni errati.
• Licenze: licensing.log; verificare anche lo stato della licenza, la sincronizzazione con Central e il caso particolare Air Gap.
• Aggiornamenti di sistema: u2d.log; verificare anche lo stato dei pattern, DNS/HTTPS e lo spazio di archiviazione.

Per problemi di gestione non bisogna controllare solo i log WebAdmin. Molto spesso sono Device Access, una Local Service ACL Exception Rule o una rete sorgente errata a decidere se WebAdmin, SSH, User Portal, VPN Portal, DNS o SNMP sono raggiungibili. Per questa parte il punto di partenza migliore è Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Firewall, NAT e Packet Capture

• Corrispondenza delle regole del firewall: firewall_rule.log; verificare anche il modulo Firewall nel Log Viewer.
• Log del firewall relativi alle connessioni: fwlog.log; la loro generazione dipende dal logging della regola del firewall e da Log settings. Usare anche Packet Capture.
• Regole NAT: nat_rule.log; verificare anche NAT Rule ID nel Log Viewer.
• DNAT con Link Load Balancing: verificare anche dgd.log quando è coinvolta la selezione del gateway o del link.
• Packet Capture nel WebAdmin: pktcapd.log; verificare anche Diagnostics > Packet capture.
• Gestione della larghezza di banda / QoS: bwm.log; verificare anche Traffic Shaping Policy.
• Virtual Host / pubblicazione di server precedente: vhost.log; verificare anche NAT e WAF.
• Web Server Protection / WAF: reverseproxy.log; alcuni dettagli della configurazione WAF si trovano anche in firewall_rule.log. Verificare la regola WAF, Hosted address e la raggiungibilità del backend.

Il NAT non riguarda soltanto nat_rule.log: l’impostazione NAT di una connessione IPsec site-to-site si verifica in charon.log, mentre un comando NAT eseguito tramite CLI si verifica in applog.log. In questo modo è possibile distinguere una configurazione del tunnel da una normale regola NAT.

In caso di problemi DNAT, verificare sempre insieme regola del firewall e regola NAT. NAT traduce solo, ma non consente il traffico. Maggiori dettagli: Comprendere NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall utilizza per le connessioni del firewall, tra gli altri, IP tables, ARP table, IPset e conntrack. Per QoS o gestione della larghezza di banda viene utilizzato IMQ. Queste informazioni sono utili quando si vedono messaggi di log o output di supporto con termini tecnici dal percorso di rete Linux.

IPS, Application Control e TLS Inspection

• Intrusion Prevention: servizio ips, file di log ips.log.
• Application Control: servizio ips / Application Filter, file di log ips.log.
• DPI e TLS Inspection: DPI Engine, file di log ips.log.
• Antivirus nel percorso di rete: servizio avd, file di log avd.log.
• Zero-Day Protection / Sandbox: servizio Sandbox, file di log sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR nel percorso di rete; prima Log Viewer, a seconda del modulo anche ips.log.
• MDR Threat Feeds: ATR / stato MDR Feed, file di log atr.log; la guida operativa correla Audit ID, Task Queue e prova del traffico locale.
• Aggiornamenti delle firme: Signature Updater, file di log sig_upgrade.log.
• Migrazione delle firme: Signature Migration, file di log sigmigration.log.

appcached.log contiene anche la cache temporanea delle applicazioni categorizzate prima del loro salvataggio nel database; il suo utilizzo per Application Based Routing è indicato più avanti. Per i feed di minacce MDR e di terze parti, atr.log mostra lo stato della licenza e della configurazione; da solo non dimostra una decisione sul traffico. Per gli IoC di indirizzi IP si controlla anche firewall_rule.log. Per gli IoC di domini o URL, i log del firewall, del DNS, dell’ispezione SSL/TLS e del proxy web vanno analizzati insieme: firewall_rule.log, dnsd.log, ips.log, httplogd.log e, a seconda del percorso di elaborazione, awarrenhttp.log. I moduli coinvolti implementano Active Threat Response in base al tipo di IoC.

Molte moderne funzioni di protezione vedono abbastanza dettagli solo quando HTTPS viene decrittografato. Se TLS Inspection non è attivo, i filtri web, Application Control, IPS e Malware Scan sono meno significativi a seconda del traffico.

Se non è chiaro se IPS è attivo, quale policy è in uso o perché una firma blocca, aiuta prima Configurare e testare in sicurezza IPS su Sophos Firewall. Successivamente, si possono combinare ips.log, Log Viewer e Packet Capture in modo più mirato.

Se si tratta di riconoscimento delle applicazioni, Application Filter o blocchi imprevisti di App-Control, è adatto prima Configurare e testare Application Control su Sophos Firewall.

Per Zero-Day Protection bisogna controllare anche se Web Protection, TLS Inspection, tipo file, dimensione file, policy e azione combaciano. L’articolo operativo corretto è Comprendere e gestire Sophos Firewall Zero-Day Protection. Per Threat Feeds: Configurare e gestire in sicurezza Sophos Firewall Threat Feeds. Maggiori dettagli su TLS Inspection: Distribuire gradualmente TLS Inspection su Sophos Firewall.

Web, Proxy, WAF e filtro web

• HTTP e HTTPS tramite il proxy web: servizio awarrenhttp, file di log awarrenhttp.log.
• Accesso al proxy HTTPS: log di accesso di awarrenhttp, file di log awarrenhttp_access.log. Per SFOS 22/23, le singole richieste al proxy web compaiono qui solo quando awarrenhttp è in esecuzione con il debug attivato; seguire la procedura di acquisizione riportata di seguito.
• Categorizzazione / reputazione web: servizio nSXLd, file di log nSXLd.log.
• Aggiornamenti delle categorie (SFOS 22/23): file di log catUpdateLog – rispettare maiuscole e minuscole, senza estensione .log.
• FTP tramite il proxy HTTP: servizio skein, file di log skein.log.
• Proxy FTP: servizio ftpproxy, file di log ftpproxy.log.
• Web Application Firewall: reverse proxy, file di log reverseproxy.log.

Per raccogliere questo log di accesso, identificare prima il nodo firewall/HA interessato, il caso di test, l’ora e una breve finestra di raccolta, verificare lo spazio su disco e confermare con gli altri amministratori o il supporto che il debug sia disattivato. Non usare il comando di commutazione per interrogare lo stato. Eseguire quindi service awarrenhttp:debug -ds nosync esattamente una volta in Advanced Shell, riprodurre il problema circoscritto e salvare awarrenhttp_access.log in modo protetto. Successivamente, eseguire lo stesso comando esattamente una volta per disattivare nuovamente il debug. Con un breve test controllato, verificare che non compaiano nuove voci di debug e che il log normale torni a crescere al ritmo abituale; documentare il ripristino e il controllo dello spazio su disco. Se lo stato iniziale o la verifica finale non sono chiari, non continuare a commutare e chiarire la situazione con il supporto. Questo metodo si applica qui ad awarrenhttp in SFOS 22/23, non in generale a tutti i servizi o alle versioni.

Per un sospetto loop proxy, block_proxy_loop insieme a un debug awarrenhttp attivato brevemente può produrre Duplicate Via header values, proxy loop. Verificare in sicurezza le impostazioni HTTP Proxy spiega prerequisito, effetto globale e rollback sicuro. Il debug resta attivo solo per il test riproducibile e viene poi disattivato.

Se il traffico web appare bloccato nel Log Viewer, la causa può risiedere in più moduli: Web Policy, SSL/TLS inspection, Application Control, IPS o WAF. Pertanto, selezionare sempre il modulo specifico nel Log Viewer e controllare anche il file di log appropriato.

Sophos blocca sempre i siti web della categoria highly objectionable criminal activity e nasconde il nome del dominio nei log e nei report. Non si tratta di un’azione predefinita selezionabile liberamente. Se una voce in questo ambito sembra deliberatamente anonimizzata, il comportamento può quindi essere intenzionale.

Per categorie web, gruppi di URL, Web Policies e Instant Alerts, è adatto Utilizzare categorie web e Instant Alerts su Sophos Firewall.

VPN

• IPsec da SFOS v17+: servizi strongswan, charon; file di log strongswan.log, charon.log.
• IPsec per connessione: singola connessione IPsec, file di log /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec versioni precedenti: servizio IPsec, file di log ipsec.log.
• IPsec Monitoring: monitor IPsec, file di log ipsec_monitor.log.
• XFRM / route-based VPN: servizio xfrmi, file di log xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, file di log sslvpn.log.
• SSL VPN Status: OpenVPN Status, file di log openvpn-status*.log.
• VPN Portal: file di log vpnportal.log.
• L2TP: servizio l2tpd, file di log l2tpd.log. L2TP Remote Access su Sophos Firewall spiega configurazione e diagnostica.
• PPTP: PPTP VPN, file di log pptpvpn.log.
• Certificati VPN: VPN Certificate Services, file di log vpncertificate.log.
• Clientless SSL VPN: Clientless Access, file di log clientless_access.log.

Sophos Firewall utilizza strongSwan per IPsec VPN e OpenVPN per SSL VPN. Nei problemi IPsec, sono cruciali orario, IP peer, proposta, subnet locali/remoti, NAT-T, routing e regole del firewall.

Queste implementazioni valgono sia per site-to-site sia per accesso remoto. /log/ipsec_conn/ipsec_<connectionname>.log contiene in particolare le azioni WebAdmin specifiche della connessione per attivare, disattivare e connettere il tunnel; <connectionname> va sostituito con il nome effettivo della connessione. Per l’autenticazione degli utenti VPN, verificare anche access_server.log e, in caso di problemi del portale, vpnportal.log. In caso di problemi del client Sophos Connect, anche il report di supporto tecnico del client fa parte dei dati da raccogliere: i soli log del firewall non mostrano l’intero stato del client. La procedura di troubleshooting IPsec aiuta a mettere in relazione i riscontri del client e del firewall.

Per problemi IPsec, l’articolo Risoluzione dei problemi IPsec su Sophos Firewall è la guida passo-passo migliore. Se si tratta di VPN basato su route e rotte IPsec manuali, aiuta Creare una rotta IPsec su Sophos Firewall.

Autenticazione, User Portal e SSO

• Autenticazione, autorizzazione e accounting degli utenti: Access Server / AAA, file di log access_server.log.
• NTLM / NASM: servizio nasm, file di log nasm.log.
• Chromebook SSO: backend Chromebook SSO, file di log chromebook-sso-backend.log.
• Flusso Chromebook SSO: csd.log; da distinguere dal log del backend.
• OAuth SSO Captive Portal (SFOS 22): file di log oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): file di log oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): file di log oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log per gli accessi SSO a WebAdmin, Captive Portal, VPN Portal, IPsec VPN e SSL VPN.
• RADIUS SSO: associazione tra utente e IP tramite accounting in access_server.log. La configurazione e la verifica finale sono spiegate in RADIUS SSO con accounting.
• STAS: contesto STAS / Access Server, in base al contesto del servizio e a access_server.log.

Nelle regole utente, verificare sempre prima se l’utente è effettivamente conosciuto. Se Match known users è attivo e l’autenticazione non funziona, la regola non corrisponde. Per i login classici nel browser, Configurare e testare Captive Portal su Sophos Firewall riunisce Device Access, regola utente, Live users, Log Viewer e access_server.log in un percorso diagnostico completo.

Se non è ancora chiaro se fallisca la selezione del servizio, l’identità, la Main Group, la quota o soltanto il successivo percorso del traffico, Risolvere sistematicamente gli errori di autenticazione su Sophos Firewall riunisce questi livelli in un unico percorso diagnostico.

Se Captive Portal viene utilizzato con Microsoft Entra ID SSO, Configurare Microsoft Entra ID SSO per Captive Portal di Sophos Firewall aiuta nel confronto di oauth_sso_captive.log (SFOS 22; in SFOS 23: oauth_sso_svc.log), Device Access, gruppi e successiva corrispondenza delle regole.

DNS, DHCP e Rete

• Servizio DNS: servizio dnsd, file di log dnsd.log.
• Servizio FQDN wildcard / DNS Grabber: servizio dnsgrabber, file di log dnsgrabber.log.
• DNS Entity / altri componenti DNS: servizi entity, eacd; file di log entity.log, eacd.log.
• DHCP IPv4: servizio dhcpd, file di log dhcpd.log.
• DHCP IPv6: file di log dhcpd6.log.
• Interfacce fisiche e virtuali: servizio networkd, file di log networkd.log.
• Host FQDN: servizio fqdnd, file di log fqdnd.log.
• Dead Gateway Detection e gestione WAN/gateway: servizio dgd, file di log dgd.log; verificare anche il failover dei link, il failover VPN e DNAT.
• DNS dinamico: client DNS dinamico, file di log ddc.log.
• Client NTP: file di log ntpclient.log.
• IPv6 Router Advertisement: servizio radvd, file di log radvd.log.

I problemi DNS e DHCP spesso sembrano problemi di firewall. Pertanto, si dovrebbe prima verificare indirizzo IP, gateway, server DNS e se i client devono utilizzare il firewall come server DNS o DHCP.

Se i domini interni non vengono risolti correttamente, di solito è rilevante Configurare le rotte delle richieste DNS su Sophos Firewall. Per le opzioni DHCP speciali, c’è l’articolo Configurare le opzioni DHCP su Sophos Firewall.

WAN cellulare

• WWAN / Modem USB: controllare inserimento e rimozione di dispositivi USB in modemd.log.
• Configurazione di rete del modem: controllare interfacce e configurazione IP relative al modem in networkd.log.
• USB, Modem e PPP: controllare messaggi Syslog su USB, modem e Point-to-Point Protocol in syslog.log.

In caso di problemi con WAN cellulare, si dovrebbe anche verificare se il modem viene riconosciuto, se PIN/SIM/APN sono corretti e se il firewall crea un gateway appropriato.

Routing

• Route unicast statiche: file di log staticd.log. La configurazione e la verifica sono spiegate in Configurare una route statica su Sophos Firewall.
• Installazione delle route unicast statiche IPv4: servizio zebra, file di log zebra.log.
• Application Based Routing: servizio appcached, file di log appcached.log.
• Routing multicast: file di log mrouting.log.
• BGP e BGP IPv6: servizio bgpd, file di log bgpd.log. La configurazione e la verifica finale sono spiegate in Configurare BGP su Sophos Firewall; zebra.log aiuta inoltre a verificare se una route dinamica IPv4 o IPv6 appresa è stata installata nel kernel.
• OSPFv2 e OSPFv3: servizi ospfd e ospf6d, file di log ospfd.log e ospf6d.log. Anche zebra.log mostra se la route dinamica è stata recepita dal sistema. La configurazione e la verifica finale sono spiegate in Configurare OSPF su Sophos Firewall.
• RIP: servizio ripd, file di log ripd.log. La configurazione e la verifica finale sono spiegate in Configurare RIPv2 su Sophos Firewall; zebra.log mostra inoltre se una route appresa è stata installata nello stack di routing.
• PIM-SM: servizio pimd, file di log pimd.log. La configurazione e la verifica finale sono spiegate in Configurare PIM-SM su Sophos Firewall.

In caso di problemi di routing, verificare anche Routing > SD-WAN routes, gateway e Packet Capture. Il tester di policy non sostituisce un vero test di routing.

Per le route statiche e dinamiche, csc.log fornisce anche informazioni sugli opcode e indicazioni sui riavvii dei servizi. Nel contesto HA si aggiungono ha.log, msync.log e applog.log. Per le route SD-WAN, oltre a appcached.log, si controllano anche applog.log, csc.log e dgd.log; se è coinvolto IPsec, si consultano anche i log IPsec.

Maggiori dettagli: Adattare la priorità di routing su Sophos Firewall.

GUI, CLI e accesso al sistema

Per WebAdmin, SSH, API e servizi locali di gestione, la lista di base si trova sopra in Sistema, gestione e servizi di base. Se WebAdmin o SSH non sono raggiungibili, non controllare solo apache.log, tomcat.log o sshd.log. L’accesso locale è gestito tramite Administration > Device access e Local Service ACL.

Maggiori dettagli: Stabilire una connessione SSH a Sophos Firewall.

Sophos Fusion, Heartbeat e Central Management

• Sophos Central Management: Central Management, file di log centralmanagement.log, sophos-central.log.
• CSC e servizi ausiliari: servizi csc, cschelper, csd; file di log csc.log, cschelper.log, csd.log. cschelper.log riguarda le e-mail generate dal sistema e gli strumenti di autenticazione, csd.log il flusso Chromebook SSO.
• Security Heartbeat e Synchronized Security: heartbeatd.log contiene lo stato degli endpoint e le informazioni sulle applicazioni inviati al firewall; hbtrust.log contiene la comunicazione con Central. I servizi si chiamano heartbeatd e hbtrust; verificare anche csc.log e applog.log.
• Synchronized Application Control: verificare i dati inviati a SophosLabs in sac-feedback.log.
• Ottimizzazione del database SAC (SFOS 22/23): sac-vacuum.log registra l’ottimizzazione settimanale del database di Synchronized Application Control; sac-feedback.log resta il log separato per i dati inviati a SophosLabs.
• Eventi Central, connessione e trasferimento della configurazione: fwcm-eventd.log mostra le informazioni su zone e interfacce inviate per gli oggetti dinamici, fwcm-heartbeatd.log la connessione e fwcm-updaterd.log la configurazione trasferita. I servizi si chiamano fwcm-eventd, fwcm-heartbeatd e fwcm-updaterd; non tutti e tre sono servizi Heartbeat.
• Central API Executor: servizio fwcm-api-executor, file di log fwcm-api-executor.log.
• Active Threat Response: contesto ATR; verificare in base alla versione e al modulo.

In caso di problemi con Sophos Fusion, verificare prima se il firewall è registrato, se i servizi Central sono attivi e se DNS/HTTPS in uscita funzionano. Se una modifica da Sophos Fusion non arriva localmente, bisognerebbe confrontare la coda delle attività del firewall di Sophos Fusion con i log locali. Uno stato verde in Sophos Fusion da solo non dimostra che una policy concreta sia stata elaborata localmente.

Per la registrazione e i token di accesso è rilevante sophos-central.log, mentre per la gestione e il reporting attivati è rilevante centralmanagement.log. La registrazione e la deregistrazione vengono inoltre confrontate con applog.log, gli upgrade del firmware con csc.log. hbtrust.log mostra la comunicazione; in garner.log, le voci del plugin SCM appartengono a Central Management e quelle del plugin CR a Central Reporting. fwcm-api-executor.log contiene anche le analisi MDR trasferite al firewall. La documentazione SFOS 22 considerata qui chiama la piattaforma Sophos Fusion (in precedenza Sophos Central), mentre la documentazione SFOS 23 la chiama Sophos Central; i nomi esistenti dei servizi e dei file restano invariati.

High Availability

• Stato e configurazione HA: log dell’applicazione HA, file di log applog.log.
• Rilevamento del peer HA in QuickHA: servizio ha_pair, file di log ha_pair.log.
• Tunnel SSH tra dispositivi HA tramite il link dedicato: servizio ha_tunnel, file di log ha_tunnel.log.
• Sincronizzazione Conntrack: servizio ctsyncd, file di log ctsyncd.log.
• Msync: servizio msync, file di log msync.log.
• Creazione HA e cambiamenti di stato: ha.log.
• Sincronizzazione dei file di servizi selezionati verso il dispositivo ausiliario: filesync.log.

I log e i report HA non vengono sincronizzati tra i dispositivi. Ogni nodo memorizza solo i dati del traffico elaborato direttamente. Controllare quindi Log Viewer e Diagnostics > Tools > Troubleshooting logs su ogni dispositivo interessato. Per ottenere i troubleshooting log del dispositivo Auxiliary, accedere direttamente alla sua CLI tramite l’indirizzo IP o FQDN dell’interfaccia di amministrazione. Sophos Central Firewall Reporting può combinare i report dei due dispositivi, ma non sostituisce i file di troubleshooting locali dei nodi.

Mail e Anti-Spam

• Antivirus: servizio AV, file di log avd.log.
• Aggiornamenti antivirus: Up2Date AV, file di log up2date_av.log.
• Antispam: servizio sasi, file di log sasi.log.
• Sandbox: servizio sandboxd, file di log sandboxd.log.
• SMTP MTA: servizio smtpd, file di log smtpd_main.log.
• Errori SMTP in modalità MTA: smtpd_error.log per gli errori di scansione della posta, smtpd_panic.log per gli errori interni e smtpd_reject.log per le e-mail rifiutate; il servizio è smtpd.
• Proxy SMTP/S legacy: servizi awarrensmtp, awarrenmta; file di log awarrensmtp.log, awarrenmta.log. La configurazione e il test end-to-end sono spiegati in Mail Protection in modalità legacy.
• Proxy POP/IMAP: servizio warren, file di log warren.log. La configurazione e il test end-to-end sono spiegati in Scansionare POP3 e IMAP su Sophos Firewall.

In caso di problemi con la posta, verificare sempre se la modalità MTA, la regola del firewall, DNS, certificati e restrizioni del fornitore sono compatibili. La procedura per il flusso di posta, lo spool, la quarantena e il relay è descritta in Configurare la protezione della posta su Sophos Firewall in modalità MTA.

Sophos Firewall utilizza Avira e Sophos Antivirus. Il servizio Anti-Spam si avvia solo se è presente una policy di spam in entrata o in uscita. Questa dipendenza è importante se sasi.log rimane vuoto o il servizio Anti-Spam non è in esecuzione.

Wireless, RED, Hotspot e altri servizi

• Controller wireless e comunicazione AP/APX con il firewall: servizio awed, file di log awed.log.
• Client wireless: comunicazione tra client e AP/APX in wc_remote.log.
• SSID LocalWifi: servizio hostapd, file di log hostapd.log; da non confondere con gli eventi hotspot.
• Eventi hotspot: servizio hotspotd, file di log hotspotd.log.
• RED: red.log registra tutti i dispositivi RED configurati, inclusi RED site-to-site e SD-RED. red-<serial ID of RED>.log appartiene al rispettivo dispositivo SD-RED, red-<RED ID>.log alla rispettiva configurazione RED site-to-site. L’ID RED si trova in Network > Interfaces, aprendo il RED site-to-site interessato. I segnaposto vanno sostituiti con il numero di serie o l’ID RED effettivo.
• SNMP: servizio snmpd, file di log snmpd.log.
• Servizio syslog: file di log syslog.log.
• Licenze: servizio di gestione delle licenze, file di log licensing.log.
• Aggiornamenti di sistema: servizio u2d, file di log u2d.log.
• VMware Tools: servizio vmtool, file di log vmtool.log.

In caso di problemi di licenza, Air-Gap o pattern, licensing.log e u2d.log sono i primi punti di riferimento tecnici. Per il flusso operativo con file di licenza, finestra di 180 giorni e aggiornamenti manuali dei pattern, è adatto Gestire la licenza Air-Gap e gli aggiornamenti dei pattern su Sophos Firewall.

Database e Reporting

• Database di configurazione: Config DB, file di log postgres.log.
• Postgres: servizio postgres, file di log postgres.log.
• Database delle firme: servizio sigdb, file di log sigdb.log.
• Database dei report: nuovo database dei report a partire da SFOS 21.0, file di log reportdb.log.
• Database di migrazione: migrazione dei report, file di log reportmigration.log.
• Migrazione della configurazione (SFOS 22/23): file di log migration.log; da non confondere con reportmigration.log per la migrazione dei report.
• Garner: servizio garner, file di log garner.log.
• Visualizzazione dei log nel WebAdmin: servizio iview, file di log iview.log.

Se i report mancano, sono lenti o si verificano problemi di spazio di archiviazione, i log di reporting e database sono rilevanti. Inoltre, si dovrebbe verificare se i report vengono salvati localmente o inviati a Sophos Fusion.

Altri file di log per SFOS 22/23

I seguenti file sono necessari meno frequentemente nel troubleshooting quotidiano del traffico, ma fanno parte delle associazioni per SFOS 22/23. Sono raggruppati per funzione, per evitare di dedurre prematuramente una causa dal nome di un file:

• Audit, FIPS e accesso del supporto: configuration-audit.log registra la modifica alla configurazione, l’amministratore e l’ora; fips.log l’avvio in modalità FIPS; uma.log il Support Access.
• Pipeline dei log e manutenzione dei dati locali: syslog-ng.log mostra la soppressione delle voci consecutive dello stesso evento; reportdb_v9.log appartiene al vecchio database dei report. dbcleanup.log riguarda la pulizia del database al riavvio del firewall, readobject.log la lettura interna degli oggetti, fstrim.log il trimming del file system e logrotate.log la rotazione in file .gz.
• ATR, NDR Essentials e FastPath: atr-service.log mostra l’avvio e l’arresto del servizio ATR. ndr.log copre la licenza NDR, la configurazione e l’avvio dell’agente; ndr_agent.log l’avvio del servizio e l’elaborazione dei metadati. vfpdf.log mostra i metadati inviati da FastPath a NDR Essentials esclusivamente su XGS 88/88w, 108/108w, 118/118w e 128/128w. setup_vf_dpdk.log registra l’inizializzazione della memoria FastPath e non si applica proprio a queste quattro serie di modelli.
• TLS e SSL VPN: httplogd.log mostra le connessioni HTTPS non decrittografate nel percorso DPI. peruser_cert_sslvpn.log registra i certificati SSL VPN generati per ciascun utente; openvpn-status0.log, openvpn-status1.log e altri file numerati mostrano le connessioni SSL VPN attive per ciascun processo.
• Rete e HA: dhcprelay.log appartiene al DHCP Relay. ha.log mostra l’esito positivo o gli errori durante la creazione HA e i cambiamenti di stato; filesync.log la sincronizzazione dei file di servizi selezionati verso il dispositivo ausiliario.
• Central, deployment e ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log e fwcm-updaterd.log coprono le informazioni su zone e interfacce, la connessione e il trasferimento della configurazione. fwcm-frpcd.log riguarda il Fast Reverse Proxy durante l’apertura simultanea di più firewall in Central. ssod.log contiene le informazioni sugli upgrade del firmware inviate a Central e i backup del firewall creati lì. Per True/Controlled Zero Touch si controllano zt.log e fwcm-heartbeatd.log; per Zero Touch tramite USB si controlla zerotouch.log, non fwcm-heartbeatd.log. ztna-connector.log contiene gli ID dell’account cliente e del connettore, lo stato del connettore, i tunnel ZTNA, le applicazioni a cui si è acceduto e gli aggiornamenti della configurazione.
• Backup, firmware, Air Gap e certificati: interfacemapping.log registra l’associazione delle interfacce durante il ripristino, legacyconversion.log i backup senza Secure Storage Master Key e fwmgmt.log l’installazione e la gestione del firmware. u2d_airgap.log si applica agli aggiornamenti Air Gap, cps_messages.log agli errori degli hotfix e letsencrypt.log, insieme a applog.log, ai certificati Let’s Encrypt.
• API, ripristino e gestione dei certificati: apiparser.log riguarda la traduzione API tra JSON e XML, validation.log e validationError.log la validazione API. Per backup/ripristino, verificare anche applog.log e postgres.log. vpncertificate.log comprende non solo i certificati VPN, ma anche CA, CSR e CRL.
• Hardware e stato del sistema: npu-startup.log mostra l’avvio della NPU, npu_syslog.log i syslog della NPU e xgs-host.log i driver dell’host durante l’avvio. xgs-npu-fw.log riguarda la verifica della compatibilità, l’upgrade e il ripristino della NPU, xgs-npu-serial.log la porta seriale della NPU e xgs-pport-wait.log la creazione delle interfacce fisiche durante l’avvio. xgs-healthmond.log copre l’utilizzo della CPU, la temperatura, la velocità delle ventole e la porta di gestione della NPU. raid.log mostra il RAID software e lcd.log il display hardware. Sui firewall hardware, virtuali, cloud e software, system-monitor/cpu_trigger.log e system-monitor/memory_trigger.log registrano lo stato del sistema rispettivamente in caso di carico elevato della CPU o della memoria; entrambi sono elencati per SFOS 22/23.
• Syslog FastPath: npu_syslog.log riguarda FastPath basato su NPU e non si applica a XGS 88/88w, 108/108w, 118/118w e 128/128w. syslog.log mostra la comunicazione dell’host con FastPath basato su NPU e con Virtual FastPath. In VMware, oltre al log di VMware Tools vmtool.log, verificare anche syslog.log.
• Servizi cloud e di piattaforma: iaasd.log registra il provisioning della configurazione e la verifica della licenza in Azure, waagent.log il provisioning a livello del sistema operativo e il monitoraggio dello stato da parte dell’agente di provisioning Azure; vmtool.log appartiene a VMware Tools.

La presenza di un file non dimostra un errore in quel modulo. Prima si correlano l’ora dell’evento, il nodo interessato, la piattaforma, lo stato del servizio e un sintomo riproducibile; solo dopo si esegue una ricerca con un filtro ristretto nel file corretto.

Flusso di analisi

1. Annotare esattamente il problema: orario con fuso orario, client, destinazione, porta, utente, azione.
2. Decidere se si tratta di traffico, stato servizio, modifica di configurazione o sincronizzazione Central.
3. Filtrare nel Log Viewer per Source IP, Destination IP, modulo e orario.
4. Verificare la visibilità di Firewall Rule ID, NAT Rule ID, utente, gateway e Policy IDs.
5. Usare Packet Capture se flusso pacchetti, ritorno o vista NAT non sono chiari.
6. Controllare il file di log appropriato con tail -f, less o grep.
7. Riprodurre il problema e documentare l’orario esatto del test.
8. Se necessario, attivare il debug solo per il servizio interessato e solo per breve tempo.
9. Disattivare nuovamente il debug e controllare lo spazio di archiviazione.
10. Salvare i log finché l’errore è stato riprodotto di recente.

Per i casi di supporto, si dovrebbero inoltre documentare tutti i messaggi di errore, i passaggi di riproduzione e i passaggi di risoluzione dei problemi già eseguiti. Queste informazioni accelerano notevolmente i casi di supporto. La procedura appropriata è descritta in Aprire un ticket di supporto Sophos: preparazione e portale.

FAQ