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

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.
• 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 è il possibile trigger? 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 down 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.
• Webfilter, TLS Inspection o IPS blocca inaspettatamente: controllare modulo Log Viewer e Policy ID. Poi confrontare ips.log, webproxy.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 storage pieno: 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.

I log di risoluzione dei problemi si trovano sul firewall nella directory /log. Si accede tramite la console WebAdmin o SSH. Per controlli brevi funziona Device Management > Advanced Shell nel browser, ma nella pratica SSH è generalmente più comodo, stabile e migliore per sessioni più lunghe di tail, grep o less. Come preparare in sicurezza SSH è descritto nella guida 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. Collegarsi tramite SSH o aprire Device Management > Advanced Shell nella console WebAdmin.
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 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.
• Controllare un servizio o attivare debug: service <service>:<start/restart/stop/debug> -ds nosync, ad esempio service ips:debug -ds nosync.

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 di log deve essere costruita manualmente con tar dalla Advanced Shell. Per i casi di supporto, nel WebAdmin esiste anche l’area Diagnostics > Tools > Log file details oppure la selezione dei troubleshooting log. Lì è possibile selezionare e scaricare i file di log per modulo.

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 un amministratore non vuole aprire una lunga sessione shell o quando serve solo un pacchetto log chiaramente delimitato. Il CTR è invece migliore quando Sophos Support ha bisogno di uno snapshot ampio del sistema. Durante la creazione del CTR, indicare un motivo breve e chiaro, ad esempio numero ticket, intervallo temporale o sintomo. Il report viene scaricato cifrato e, per i log dei sottosistemi di servizio, contiene normalmente solo un numero limitato di righe. I file di log singoli completi si ottengono in modo più affidabile tramite Troubleshooting logs o direttamente da /log.

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.

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 filesystem, file di log, tail, grep, less, service -S, riavvii di servizio e comandi di debug.

Non tutti i comandi funzionano in entrambe le aree. Se un articolo menziona espressamente Device Console, il comando dovrebbe essere eseguito lì. Se si tratta di /log, tail -f, grep, service -S o debug logging, di solito si intende la Advanced Shell.

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 debug logging è molto utile, ma genera molti dati e può consumare spazio di archiviazione. Il debug dovrebbe essere attivato solo per il servizio rilevante. Successivamente, si riproduce il problema e si disattiva nuovamente il debug.

Esempio:

service ips:debug -ds nosync
service ips:debug -ds nosync off

La sintassi esatta dipende dal servizio. Se il servizio interessato non è chiaro, si dovrebbe prima controllare il file di log normale appropriato.

Sophos distingue due modalità operative. Nella Advanced Shell si usano comandi di servizio come service ips:debug -ds nosync. Nella Device Console sono disponibili anche i comandi system diagnostics subsystems <subsystem> debug on e system diagnostics subsystems <subsystem> debug off per i sottosistemi supportati. Queste varianti non devono essere mescolate: prima chiarire in quale console si lavora, poi usare il comando corretto.

Il tema del debug logging 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.

Sistema, management e servizi di base

• 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 login 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.
• Comunicazione tra componenti: garner.log; controllare anche reporting, Central Reporting ed elaborazione dei log.
• API: apiparser.log, app-feedback.log; controllare anche 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, sig_update.log; controllare anche stato pattern, DNS/HTTPS e spazio disponibile.

Per problemi di management 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, sessiontbl.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.
• Aggiornamenti delle firme: Signature Updater, file di log sig_upgrade.log, sig_update.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 Webfilter

• HTTPS Proxy: servizio awarrenhttp, file di log awarrenhttp.log.
• HTTPS Proxy Access: awarrenhttp Access Log, file di log awarrenhttp_access.log.
• Web Proxy: file di log webproxy.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.

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 IPsec Connection, file di log strongswan-<connection>.log.
• IPsec versioni precedenti: servizio IPsec, file di log ipsec.log.
• IPsec Test Connection: test IPsec, file di log ipsec_Test_Connect.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.
• PPTP: PPTP VPN, file di log pptpvpn.log.
• Certificati VPN: VPN Certificate Services, file di log vpncertificate.log, wc_remote.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.
• 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.

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 successivo matching 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 dhcp6.log.
• Servizio di rete: servizio networkd, file di log networkd.log.
• FQDN Hosts: servizio fqdnd, file di log fqdnd.log, fqdndebug.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 mdev.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

• Static Routing: servizio zebra, file di log zebra.log.
• Application Based Routing: servizio appcached, file di log appcached.log.
• Redis App Cache: Redis, log redis.
• Multicast Routing: file di log mrouting.log.
• BGP: servizio bgpd, file di log bgpd.log.
• OSPF: servizio ospfd, file di log ospfd.log.
• RIP: servizio ripd, file di log ripd.log.
• PIM-SM: servizio pimd, file di log pimd.log.

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 management, la tabella di base si trova sopra in Sistema, management 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.
• 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.

I log HA si trovano sul dispositivo su cui sono stati generati. Per i log grezzi del dispositivo ausiliario, è necessario connettersi direttamente a quel dispositivo, ad esempio tramite la sua porta admin tramite SSH. Per report consolidati, Sophos Central Firewall Reporting è più pratico.

Mail e Anti-Spam

• Antivirus: AV Service, file di log av.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, sessiontbl.log.
• SMTP MTA: servizio smtpd, file di log smtpd_main.log.
• SMTP Fehler: 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, awarrenmta_debug.log.
• POP/IMAP Proxy: servizio warren, file di log warren.log.

In caso di problemi con la posta, verificare sempre se la modalità MTA, la regola del firewall, DNS, certificati e restrizioni del provider 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.
• Wi-Fi Authentication: servizio wifiauth, file di log wifiauth.log.
• Hotspot: servizi hostapd, hotspot, hotspotd; file di log hostapd.log, hotspot.log, hotspotd.log.
• RED: RED Service, file di log red.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.
• SMB-Filesystem: servizi smbnetfs, snireport; file di log smbnetfs.log, snireport.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

• Configuration database: Config DB, file di log confdbstatus.log, crreportdb.log.
• Postgres: servizio postgres, file di log postgres.log.
• Signature database: servizio sigdb, file di log sigdb.log.
• Report database: Report DB, file di log reportdb.log.
• Migration database: Report Migration, file di log sac-feedback.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.

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