Assegnare correttamente i Service Log 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 Central è bloccata? Verificare la coda delle attività di gestione del firewall di Sophos Central.
• Servono report o cronologia in Sophos Central? 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.

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 Central 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 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 Central 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 Central, 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 seguono la documentazione SFOS 22.0 attuale. Nelle installazioni meno recenti o nei vecchi archivi di supporto possono comparire anche i nomi usati in passato 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 più nell’attuale lista dei log di SFOS 22.0; pertanto, non bisogna presupporre che esistano su una build attuale.

Sistema, gestione e servizi di base

• Avvio del sistema: sysinit.log; controllare prima questo file in caso di problemi di avvio e Failsafe.
• Messaggi di sistema: syslog.log; controllare anche orario, reboot ed eventi di interfaccia.
• WebAdmin Webserver: apache.log, apache_access.log; controllare anche Device Access e Local Service ACL.
• Applicazione WebAdmin: tomcat.log; controllare anche errori GUI, carico elevato e stato del servizio.
• SSH: sshd.log; controllare anche Device Access, rete sorgente e accesso con chiave pubblica.
• Errori GUI/CLI: error_log.log; controllare anche modifica recente, browser e azione admin.
• Modifiche di configurazione: applog.log, csc.log; controllare anche Audit Trail e Config Studio.
• Database di configurazione: postgres.log; controllare anche spazio, backup/restore e caso di supporto.
• Canale di comunicazione tra determinati componenti e i relativi servizi: garner.log; per Central Management e reporting controllare anche le rispettive voci dei plugin.
• API: apiparser.log; controllare anche validation.log, API ACL, token e Central Task Queue.
• Validazione: validation.log, validationError.log; controllare anche oggetti o import difettosi.
• Licensing: licensing.log; controllare anche stato licenza, Central Sync e caso Air-Gap.
• System Updates: u2d.log; controllare anche stato pattern, DNS/HTTPS e spazio disponibile.

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

• Matching delle regole del firewall: firewall_rule.log; controllare anche il modulo Log Viewer Firewall.
• Elaborazione generale del firewall: fwlog.log; usare anche Packet Capture.
• Regole NAT: nat_rule.log; controllare anche NAT Rule ID nel Log Viewer.
• DNAT con Link Load Balancing: controllare anche dgd.log quando sono coinvolte scelta gateway o link.
• Packet Capture nel WebAdmin: pktcapd.log; controllare anche Diagnostics > Packet capture.
• Bandwidth Management / QoS: bwm.log; controllare anche Traffic Shaping Policy.
• Virtual Host / pubblicazione server legacy: vhost.log; controllare anche NAT e WAF.
• Web Server Protection / WAF: reverseproxy.log; controllare anche regola WAF, Hosted address e raggiungibilità del backend.

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.

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

• HTTPS Proxy: servizio awarrenhttp, file di log awarrenhttp.log.
• HTTPS Proxy Access: awarrenhttp Access Log, file di log awarrenhttp_access.log.
• Web Categorization / Reputation: servizio nSXLd, file di log nSXLd.log.
• Legacy HTTP/FTP Proxy: servizio skein, file di log skein.log.
• FTP Proxy: servizio ftpproxy, file di log ftpproxy.log.
• Web Application Firewall: Reverse Proxy, file di log reverseproxy.log.

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 i siti web della categoria highly objectionable criminal activity in modo predefinito e oscura il nome di dominio nei log e nei report. Se una voce in questa area sembra intenzionalmente anonima, potrebbe 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.

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 utente: Access Server / AAA, file di log access_server.log.
• NTLM / NASM: servizio nasm, file di log nasm.log.
• Chromebook SSO: backend SSO Chromebook, file di log chromebook-sso-backend.log.
• OAuth SSO Captive Portal: file di log oauth_sso_captive.log.
• OAuth SSO WebAdmin: file di log oauth_sso_webadmin.log.
• OAuth SSO VPN: file di log oauth_sso_vpn.log.
• RADIUS SSO: Associazione utente-IP tramite accounting in access_server.log. RADIUS SSO con accounting spiega configurazione e collaudo.
• STAS: STAS / contesto Access Server, a seconda del contesto del servizio e 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, Device Access, gruppi e successiva corrispondenza delle regole.

DNS, DHCP e Rete

• DNS Service: servizio dnsd, file di log dnsd.log.
• 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.
• Servizio di rete: servizio networkd, file di log networkd.log.
• FQDN Hosts: servizio fqdnd, file di log fqdnd.log.
• Dead Gateway Detection: servizio dgd, file di log dgd.log.
• Dynamic DNS: client Dynamic DNS, file di log ddc.log.
• NTP Client: 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 illustrate 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: servizio bgpd, file di log bgpd.log. Configurare e verificare BGP su Sophos Firewall spiega la configurazione e la verifica; zebra.log aiuta inoltre a stabilire se una route appresa è stata installata nel sistema.
• OSPFv2 e OSPFv3: servizi ospfd e ospf6d, file di log ospfd.log e ospf6d.log. Il file aggiuntivo zebra.log indica se la route dinamica è stata installata nel sistema. Configurare e verificare OSPF su Sophos Firewall spiega la configurazione e la verifica.
• RIP: servizio ripd, file di log ripd.log. Configurare e verificare RIPv2 su Sophos Firewall spiega configurazione e verifica; zebra.log mostra inoltre se una route appresa è stata installata nello stack di routing.
• PIM-SM: servizio pimd, file di log pimd.log. Configurare e verificare PIM-SM su Sophos Firewall spiega configurazione e collaudo.

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.

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 Central, Heartbeat e Central Management

• Sophos Central Management: Central Management, file di log centralmanagement.log, sophos-central.log.
• CSC: servizi csc, cschelper, csd; file di log csc.log, cschelper.log, csd.log.
• Security Heartbeat: servizi heartbeatd, hbtrust; file di log heartbeatd.log, hbtrust.log.
• Synchronized Application Control: controllare i dati inviati a SophosLabs in sac-feedback.log.
• Heartbeat verso Central: servizi fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; controllare i log dei rispettivi servizi.
• Central API Executor: servizio fwcm-api-executor, file di log fwcm-api-executor.log.
• Active Threat Response: contesto ATR; controllare in base a versione e modulo.

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

High Availability

• Stato e configurazione HA: HA Application Log, file di log applog.log.
• HA Pair Service: servizio ha_pair, file di log ha_pair.log.
• HA Tunnel: servizio ha_tunnel, file di log ha_tunnel.log.
• Conntrack Sync: servizio ctsyncd, file di log ctsyncd.log.
• Msync: servizio msync, file di log msync.log.
• Creazione HA e cambi di stato: ha.log.
• Sincronizzazione dei file di servizi selezionati verso il dispositivo Auxiliary: 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: AV Service, file di log avd.log.
• Antivirus Updates: Up2Date AV, file di log up2date_av.log.
• Anti-Spam: 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: smtpd Error/Panic/Reject, file di log smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Legacy SMTP/S Proxy: servizi awarrensmtp, awarrenmta; file di log awarrensmtp.log, awarrenmta.log. Mail Protection in Legacy mode spiega configurazione e test end-to-end.
• POP/IMAP Proxy: servizio warren, file di log warren.log. Analizzare POP3 e IMAP su Sophos Firewall spiega configurazione e test end-to-end.

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

• Wireless Controller: servizio awed, file di log awed.log.
• Client wireless: controllare la comunicazione tra il client e l’AP/APX in wc_remote.log.
• Hotspot: servizi hostapd, hotspotd; file di log hostapd.log, hotspotd.log.
• RED: RED Service, file di log red.log. A seconda del tipo e dell’istanza RED possono comparire anche red-<serial ID of RED>.log e red-<RED ID>.log.
• SNMP: servizio snmpd, file di log snmpd.log.
• Syslog Service: file di log syslog.log.
• Licensing: Licensing Service, file di log licensing.log.
• System Updates: 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: Report DB, file di log reportdb.log.
• Database di migrazione: Report Migration, file di log reportmigration.log.
• Garner: servizio garner, file di log garner.log.
• iView: 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 Central.

Altri file di log attuali di SFOS 22

I file seguenti sono meno frequenti nel troubleshooting quotidiano del traffico, ma fanno parte della mappatura attuale di SFOS 22. Sono raggruppati per funzione, così da non dedurre troppo rapidamente una causa dal nome di un file:

• Audit, FIPS e accesso al supporto: configuration-audit.log registra la modifica di 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 degli eventi consecutivi; reportdb_v9.log appartiene al vecchio database dei report. dbcleanup.log, readobject.log, fstrim.log e logrotate.log riguardano la pulizia del database, la lettura interna degli oggetti, il trimming del file system e la rotazione dei log.
• ATR, NDR e FastPath: atr-service.log mostra l’avvio e l’arresto del servizio ATR. ndr.log e ndr_agent.log coprono la licenza NDR, la configurazione, l’avvio dell’agente e l’elaborazione dei metadati; vfpdf.log si applica ai metadati NDR 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 gamme.
• TLS e SSL VPN: httplogd.log mostra le connessioni HTTPS non decifrate nel percorso DPI. peruser_cert_sslvpn.log registra i certificati SSL VPN generati per utente; openvpn-status0.log, openvpn-status1.log e gli altri file numerati mostrano le connessioni SSL VPN attive per processo.
• Rete e HA: dhcprelay.log riguarda DHCP Relay. ha.log mostra l’esito della creazione HA e i cambiamenti di stato; filesync.log la sincronizzazione dei file di servizi selezionati verso il dispositivo Auxiliary.
• Central, deployment e ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log e fwcm-frpcd.log coprono le informazioni su zone e interfacce inviate a Central, la connessione, la configurazione trasferita e Fast Reverse Proxy. ssod.log contiene informazioni sul firmware e sui backup Central, zt.log e zerotouch.log le varianti Zero Touch, ztna-connector.log il connettore ZTNA locale.
• Backup, firmware, Air Gap e certificati: interfacemapping.log registra l’assegnazione 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 riguarda gli aggiornamenti Air Gap, cps_messages.log gli errori degli hotfix e letsencrypt.log insieme ad applog.log i certificati Let’s Encrypt.
• Hardware e stato del sistema: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log e xgs-pport-wait.log coprono avvio, comunicazione, firmware, porta seriale, stato di salute della NPU e creazione delle interfacce fisiche. raid.log mostra il RAID software, lcd.log il display hardware. system-monitor/cpu_trigger.log acquisisce lo stato del sistema in caso di carico CPU elevato; system-monitor/memory_trigger.log si applica a SFOS 22 in caso di carico di memoria elevato.
• Servizi cloud e piattaforma: iaasd.log registra il provisioning e la verifica delle licenze in Azure, waagent.log l’agente Azure e il relativo Health Monitoring; vmtool.log riguarda 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