Verifica dei log di audit trail di Sophos Firewall

I log di audit trail aiutano a tracciare le modifiche di configurazione su Sophos Firewall. Questo è importante quando, dopo una modifica, una regola si comporta diversamente, un’interfaccia è stata modificata, manca un oggetto host o in un audit viene chiesto chi ha modificato quale impostazione e quando.

Dalla Sophos Firewall v22, SFOS registra voci dettagliate nel configuration-audit.log. I log mostrano non solo che qualcosa è stato modificato, ma anche i valori prima e dopo la modifica. Con SFOS 22.0 MR1 è stata migliorata anche la tracciabilità delle modifiche tramite Sophos Central, poiché per le modifiche su singole firewall viene registrata l’identità dell’utente di Sophos Central.

Quale articolo sui log è adatto?

I log di audit trail sono solo una parte della risoluzione dei problemi. A seconda della domanda, un altro punto di partenza può essere più rapido:

Questa separazione evita aspettative errate. L’audit trail risponde a domande sui cambiamenti. Per il flusso dei pacchetti, NAT, VPN, Web Protection, IPS o errori di servizio, sono ancora necessari Log Viewer, Packet Capture, Service-Logs, Central Reporting o Syslog.

Quando i log di audit trail sono utili

I log di audit sono particolarmente utili quando la domanda non è “perché il traffico è stato bloccato?”, ma “chi o cosa ha modificato la configurazione?”.

Casi tipici:

• Una regola del firewall è stata modificata, spostata o eliminata.
• Un IP Host, FQDN Host o oggetto di rete è stato modificato.
• Un’interfaccia o una configurazione VLAN appare diversa da quella documentata.
• Dopo una finestra di manutenzione, non è chiaro quale modifica abbia causato un problema.
• Un MSP o un team interno deve assegnare le modifiche a più amministratori.
• Per conformità, NIS2, ISO 27001 o processi di cambiamento interni è necessaria una prova.

Per l’analisi normale del traffico, altri strumenti rimangono più importanti. Se si vuole verificare quale regola ha permesso o bloccato una connessione, è adatto Test delle regole del firewall con Log Viewer, Policy Test e Packet Capture. I log di audit completano questa analisi quando si sospetta che una modifica di configurazione sia la causa.

Cosa registra il configuration-audit

configuration-audit registra le modifiche di configurazione effettuate dagli amministratori nel WebAdmin o tramite CLI. Vengono registrati, tra l’altro:

• Configurazione prima della modifica.
• Configurazione dopo la modifica.
• Timestamp.
• Identità dell’amministratore.
• Indirizzo IP dell’amministratore.
• Console utilizzata o metodo di accesso.

Le voci vengono salvate in configuration-audit.log e scritte in formato XML. Pertanto, sono molto dettagliate, ma non sempre facili da leggere. Per una rapida verifica visiva, spesso basta cercare il nome dell’oggetto, l’amministratore, l’indirizzo IP o l’intervallo di tempo. Per analisi più ampie, può essere utile cercare il file esternamente o importarlo in uno strumento di analisi dei log.

Funzionalità attuale

L’audit trail attualmente copre importanti oggetti di configurazione, in particolare:

• IP Hosts.
• Regole del firewall.
• Interfacce di rete, comprese quelle fisiche, virtuali, wireless e Cellular-WAN.
• Da SFOS v22, anche Hosts and services è incluso nelle aree supportate.

Questo è già molto utile per molte analisi dei cambiamenti, ma non è ancora un sistema completo di gestione dei cambiamenti. I log di audit trail non sostituiscono la documentazione dei cambiamenti, i ticket o il principio del doppio controllo.

⚠️ I log di audit dimostrano che una modifica è stata registrata. Tuttavia, i log non spiegano automaticamente se la modifica era tecnicamente corretta, approvata o completamente testata.

Verifica dello stato del configuration-audit

La configurazione avviene nella Device Console, non nella Advanced Shell.

Lo stato si verifica con:

system configuration-audit show

Se la funzione è attiva, il firewall dovrebbe segnalare che il Configuration Audit è acceso. Se non è chiaro se si sta lavorando nella console giusta, aiuta la distinzione in Risoluzione dei problemi di Sophos Firewall: Servizi e log.

Attivare o disattivare l’audit trail

Il logging di audit è attivato di default. Se è stato disattivato, può essere riattivato nella Device Console:

system configuration-audit enable

La disattivazione è tecnicamente possibile:

system configuration-audit disable

In ambienti produttivi, il logging di audit dovrebbe normalmente rimanere attivo. Se viene disattivato per un motivo specifico, dovrebbe essere documentato e limitato nel tempo.

⚠️ Il logging di audit non dovrebbe essere disattivato come prima misura solo perché il file sembra grande o difficile da leggere. Soprattutto in caso di problemi dopo modifiche, questi dati sono spesso la prova decisiva.

Scaricare il configuration-audit.log

Il file si chiama:

configuration-audit.log

Il download avviene tramite i log di risoluzione dei problemi. Il percorso WebAdmin è:

Diagnostics > Tools > Troubleshooting logs

Lì è possibile scaricare singoli file di log o generare un Consolidated troubleshooting report (CTR). Per un’analisi mirata dell’audit, il download singolo del file di audit è spesso più pratico di un CTR completo.

Se i log devono essere raccolti per supporto o analisi esterna, è adatto anche Salvare i log di Sophos Firewall per supporto e analisi. Per analisi dirette tramite shell, è rilevante Collegarsi a Sophos Firewall tramite SSH.

Valutare l’audit trail

Per un’analisi accurata, si dovrebbe prima delimitare il periodo di tempo.

Procedura pratica:

1. Determinare il momento del problema o della modifica.
2. Scaricare il configuration-audit.log.
3. Cercare amministratore, nome dell’oggetto, nome della regola, interfaccia o indirizzo IP.
4. Confrontare il valore prima e dopo la modifica.
5. Confrontare la modifica con il ticket, la finestra di manutenzione o la documentazione del cambiamento.
6. In caso di problemi di traffico, controllare anche Log Viewer e Packet Capture.

I log di audit sono particolarmente utili per problemi di regole. Se una regola improvvisamente non funziona più, il Log Viewer mostra solo lo stato attuale. L’audit trail può mostrare se poco prima sono stati modificati origine, destinazione, servizio, funzione di sicurezza, posizione della regola o contenuto dell’oggetto.

Utilizzare correttamente l’audit trail in caso di supporto

In caso di supporto, l’audit trail è più efficace se combinato con un intervallo di tempo specifico e un sintomo riproducibile. Un configuration-audit.log completo senza contesto è difficile da valutare. Meglio è un breve protocollo di cambiamento che fornisce i principali punti di riferimento.

Se una modifica è stata avviata tramite Sophos Central, dovrebbe essere controllata anche la Central Task Queue. La Task Queue mostra se Central ha elaborato l’ordine. L’audit trail mostra poi cosa è tracciabile localmente sul firewall.

Modifiche tramite Sophos Central

SFOS 22.0 MR1 migliora la tracciabilità delle modifiche di configurazione tramite Sophos Central. Quando un singolo firewall viene configurato tramite Sophos Central, l’identità dell’utente di Sophos Central appare nel contesto dell’audit. Questa informazione è disponibile nel Log Viewer del firewall e nei log e report di Sophos Central.

Questo è importante per ambienti con più amministratori o operazioni MSP. Un accesso generico a Central non è sufficiente per una tracciabilità chiara. Dovrebbe essere chiaro:

• Quali persone hanno accesso a Sophos Central?
• Gli amministratori lavorano con account utente propri invece di login condivisi?
• MFA è attivo in Sophos Central e sul firewall?
• I log di Central vengono conservati abbastanza a lungo?
• Esiste un processo per confrontare i cambiamenti da Central con i ticket?

La connessione tra firewall e Central è spiegata nell’articolo Collegare Sophos Firewall a Sophos Central. Per una conservazione più lunga dei log, è adatto Attivare il Central Firewall Reporting.

Considerare i cluster HA

In ambienti HA, secondo la documentazione, Sophos genera log di audit solo sul dispositivo attualmente attivo. In caso di analisi dopo un failover, è quindi necessario prestare attenzione al cambio di ruolo.

Domande importanti:

• Quale firewall era attivo al momento della modifica?
• C’è stato un failover poco prima o dopo?
• I file di log di entrambi i dispositivi sono rilevanti?
• La modifica è stata sincronizzata correttamente sul cluster?

Per il funzionamento HA e l’interpretazione dei log, è adatto Configurare Sophos Firewall High Availability.

Validazione dopo una modifica

L’audit trail mostra che un oggetto è stato modificato. Successivamente, è necessario verificare se la modifica ha l’effetto desiderato e non genera effetti collaterali. Soprattutto per regole del firewall, interfacce, VPN e oggetti host, non ci si dovrebbe fermare al log di audit.

Un flusso di lavoro sensato dopo modifiche critiche:

1. Trovare la modifica nell’audit trail per intervallo di tempo e nome dell’oggetto.
2. Confrontare il valore prima/dopo con il ticket o la documentazione del cambiamento.
3. Verificare la regola del firewall, la regola NAT, la rotta o l’interfaccia interessata nel WebAdmin.
4. Generare traffico di test concreto.
5. Controllare Log Viewer, Policy Test e Packet Capture.
6. Per modifiche Central, controllare anche Task Queue e Central Logs.
7. Nei cluster HA, controllare lo stato del ruolo e la sincronizzazione.

In questo modo, l’audit trail diventa una prova affidabile anziché solo una scoperta nel log. Se l’audit trail mostra una modifica, ma il traffico di test continua a funzionare in modo errato, la causa spesso risiede nell’ordine delle regole, NAT, routing, assegnazione degli utenti, funzione di sicurezza o percorso di ritorno.

Limiti e insidie tipiche

Il log di audit non è un backup

L’audit trail mostra le modifiche, ma non sostituisce un backup di configurazione. Prima di modifiche importanti, è ancora necessario un backup completo e un piano di rollback. Questo è descritto nell’articolo Creare o ripristinare un backup di Sophos Firewall.

XML è dettagliato, ma non bello

Il file è buono per macchine e confronti precisi, ma difficile da leggere rapidamente. Se si devono confrontare molti cambiamenti, Sophos Firewall Config Studio o uno strumento esterno di confronto/log può essere più utile.

Non tutte le analisi appartengono all’audit trail

Se una connessione non funziona, controllare prima il traffico. I log di audit sono rilevanti quando una modifica è sospettata come causa. Per il troubleshooting live, Log Viewer, Policy Test, Packet Capture e Service-Logs sono spesso più diretti.

Account admin condivisi indeboliscono la prova

Se più persone utilizzano lo stesso account admin, l’audit trail è meno significativo. Admin nominati, ruoli, MFA e utenti Central puliti sono quindi parte del modello operativo, non solo un extra di sicurezza.

Lista di controllo operativa

• Verificare system configuration-audit show.
• Lasciare attivo il logging di audit.
• Utilizzare account admin nominati invece di login condivisi.
• Verificare MFA per WebAdmin, VPN Portal e Remote Access.
• Documentare i cambiamenti con ticket o finestra di manutenzione.
• Creare un backup prima di modifiche importanti.
• Dopo problemi, cercare configuration-audit.log per intervallo di tempo e nome dell’oggetto.
• Confrontare i valori prima/dopo con la modifica attesa.
• Per problemi di regole, NAT o VPN, integrare Log Viewer e Packet Capture.
• Nei cluster HA, considerare il nodo attivo e il momento del failover.
• Confrontare le modifiche Central con i log e i report di Sophos Central.

Per MFA sul firewall, è adatto Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access. Per gli accessi di gestione, dovrebbe essere verificato anche Configurare correttamente Device Access.

FAQ