Verificare le modifiche alla configurazione di Sophos Firewall con Audit Trail

Con Configuration Audit, a partire da SFOS 22, è possibile risalire a chi ha modificato una configurazione supportata, quando lo ha fatto e quali erano i valori precedenti e successivi. È il punto di partenza corretto se, dopo una modifica, una regola firewall, un oggetto host o un’interfaccia appare diversa dal previsto.

La procedura più rapida consiste nel verificare lo stato nella Device Console, scaricare configuration-audit.log o cercare al suo interno dalla Advanced Shell, confrontare la modifica con il ticket e l’intervallo temporale e infine verificarne separatamente l’effetto tecnico.

⚠️ L’Audit Trail mostra una modifica registrata. Non dimostra automaticamente che sia stata approvata, tecnicamente corretta o testata con successo e non sostituisce né il backup né la documentazione delle modifiche.

Verificare Configuration Audit in quattro passaggi

1. Controllare lo stato nella Device Console

Configuration Audit è attivo per impostazione predefinita. I comandi devono essere eseguiti nella Device Console, non nella Advanced Shell.

system configuration-audit show

Se la funzione è disattivata:

system configuration-audit enable

La disattivazione è tecnicamente possibile, ma negli ambienti di produzione deve essere giustificata e limitata nel tempo:

system configuration-audit disable

⚠️ Non disattivare l’Audit Logging come prima misura solo perché il file è grande o difficile da leggere. Proprio dopo un malfunzionamento, queste voci possono costituire la prova decisiva della modifica.

2. Scaricare il file di log da WebAdmin

Il file si chiama configuration-audit.log. In WebAdmin si trova in:

Diagnostics > Tools > Troubleshooting logs

Per un’analisi mirata, selezionare e scaricare il singolo file. Un Consolidated troubleshooting report (CTR) è utile quando Sophos Support necessita anche dello stato del sistema e di altri log; alcuni log dei sottosistemi di servizio inclusi nel CTR possono tuttavia essere limitati dal numero di righe configurato.

3. Cercare nel file di log dalla Advanced Shell

Dopo l’accesso SSH, selezionare 5. Device Management e quindi 3. Advanced Shell. Ad esempio, per cercare il nome di un oggetto:

grep -i 'LAN_to_WAN' /log/configuration-audit.log

Sostituire LAN_to_WAN con il nome effettivo della regola, dell’host o dell’interfaccia. Le nuove voci possono essere visualizzate in tempo reale con:

tail -f /log/configuration-audit.log

Terminare l’output in tempo reale con Ctrl+C. Per una visualizzazione statica, pagina per pagina, utilizzare less /log/configuration-audit.log. L’output XML può essere lungo; per un caso di assistenza salvare solo l’estratto pertinente insieme al timestamp.

4. Verificare separatamente la modifica e il suo effetto

L’Audit Trail risponde innanzitutto alla domanda: Che cosa è stato modificato? Un test funzionale deve poi mostrare se la modifica produce l’effetto previsto. In caso di problemi di traffico, utilizzare quindi anche Log Viewer, Policy Test e Packet Capture. La procedura è descritta in Testare una regola firewall con Log Viewer, Policy Test e Packet Capture.

Che cosa registra configuration-audit

configuration-audit.log registra in formato XML le modifiche supportate effettuate tramite WebAdmin e CLI. Una voce può contenere:

• configurazione precedente e successiva alla modifica
• timestamp
• identità dell’amministratore e IP di origine
• console o metodo di accesso utilizzato

L’attuale ambito funzionale comprende in particolare regole firewall, IP Hosts o Hosts and services e interfacce di rete. Per le interfacce, Sophos indica quelle fisiche, virtuali, wireless e Cellular WAN. Non tutte le pagine di configurazione offrono lo stesso livello di dettaglio; per NAT, routing, VPN o altre funzioni non si deve presupporre una copertura completa dell’Audit Trail.

Una Description o un ticket spiega perché un oggetto dovrebbe esistere. L’Audit Trail mostra che cosa è stato effettivamente modificato in un oggetto supportato. Per una prova completa servono entrambe le informazioni.

Che cosa non sostituisce l’Audit Trail

• Analisi del traffico: Log Viewer e Packet Capture restano essenziali per le connessioni consentite o scartate.
• Backup e rollback: Prima di modifiche importanti sono comunque necessari un backup aggiornato e un piano di ripristino.
• Gestione completa delle modifiche: approvazione, responsabilità, test e convalida devono essere registrati nel ticket o nel verbale di manutenzione.
• Confronto delle configurazioni: Sophos Firewall Config Studio confronta esportazioni complete della configurazione, ma non legge configuration-audit.log.

Analizzare una modifica in modo attendibile

Individuare e documentare la modifica

Una procedura di verifica efficiente:

1. Stabilire l’ora del problema o della modifica, incluso il fuso orario.
2. Identificare l’oggetto interessato, ad esempio il nome della regola, l’host, l’interfaccia o la VLAN.
3. Cercare in configuration-audit.log il nome dell’oggetto, l’amministratore, l’indirizzo IP o l’intervallo temporale.
4. Confrontare il valore precedente con quello nuovo.
5. Confrontare la modifica con il ticket, la finestra di manutenzione e l’amministratore responsabile.
6. Salvare l’estratto XML pertinente insieme all’intervallo temporale e al nome dell’oggetto.

In una regola firewall potrebbero essere stati modificati, ad esempio, origine, destinazione, servizio, posizione della regola o funzioni di protezione attive. La modifica concreta deve essere ricavata dalla voce; l’elenco non garantisce che ogni sottocampo sia rappresentato allo stesso modo in tutte le build.

Per Sophos Support sono particolarmente utili le seguenti informazioni:

• ora esatta con fuso orario
• oggetto interessato e stato previsto
• sintomo effettivo
• amministratore o utente Central coinvolto
• valore precedente e successivo pertinente
• numero del ticket e test funzionale eseguito

Il file XML completo può contenere indirizzi IP interni, nomi di oggetti e dati degli amministratori. Conservare quindi le esportazioni con accesso protetto e, prima di inoltrarle, verificare che non contengano dati del cliente non necessari. Ulteriori indicazioni sono disponibili in Salvare i log di Sophos Firewall per l’assistenza e l’analisi.

Verificare l’effetto tecnico

Dopo una modifica a una regola, un host o un’interfaccia, non fermarsi al ritrovamento della voce di log:

1. Verificare la configurazione attuale in WebAdmin.
2. Generare traffico di test definito.
3. Controllare ID della regola, NAT, route e percorso di ritorno con lo strumento appropriato.
4. In HA, verificare anche lo stato dei ruoli e la sincronizzazione.
5. Documentare nella modifica il risultato e le eventuali discrepanze.

Per le modifiche a NAT, routing o VPN, configuration-audit.log può mostrare solo gli oggetti supportati coinvolti. La funzione stessa deve essere verificata tramite la configurazione corrente, i log degli eventi e dei servizi e, se necessario, Packet Capture.

Interpretare le modifiche tramite Sophos Central

A partire da SFOS 22.0 MR1, per le modifiche apportate a un singolo firewall tramite Sophos Central viene registrata l’identità dell’utente Central. Sophos conferma la presenza di questa informazione nel Firewall Log Viewer e in Sophos Central Logs and Reports. Ciò non implica automaticamente che l’identità Central sia sempre presente in configuration-audit.log.

I Central Audit Logs si trovano in:

Reports > General logs > Audit Logs

La vista mostra per impostazione predefinita 7 giorni e può visualizzare attività fino a 90 giorni. La ricerca utilizza i campi IP address e Modified by. Per l’esportazione valgono le seguenti regole:

• CSV/PDF of current view: applica i filtri attualmente impostati.
• CSV/PDF of past 90 days: esporta gli ultimi 90 giorni; viene applicato il filtro di ricerca, ma non l’intervallo di date selezionato.

Per conservare prove per periodi più lunghi, le esportazioni devono essere create regolarmente e archiviate in modo protetto. Central Firewall Reporting non estende il limite di 90 giorni dei Central Audit Logs generali.

Quando è utile la Task Queue

La Task Queue non è una prova generale per ogni modifica effettuata da Central. Il percorso di verifica corretto dipende dal tipo di operazione:

• Singolo firewall aperto direttamente: verificare Central Audit Logs e Firewall Log Viewer; per gli oggetti supportati controllare anche configuration-audit.log.
• Criterio di gruppo firewall: verificare lo stato nella Sophos Central Firewall Management Task Queue. Se il push del criterio di gruppo non arriva localmente, analizzare anche fwcm-updaterd.log.
• MDR Settings o MDR IOCs tramite Firewall Configuration API: utilizzare Firewall Task Queue e, se necessario, fwcm-api-executor.log.

Gli utenti Central nominativi consentono un’attribuzione attendibile. Ruoli adeguati e MFA proteggono gli accessi amministrativi. I ruoli sono descritti in Ruoli amministrativi di Sophos Central per Firewall Management.

Considerare HA e la conservazione dei log

Sophos documenta che gli Audit Logs vengono generati solo quando un dispositivo è Active. La valutazione varia a seconda della modalità HA:

• In Active-Passive è normalmente rilevante l’appliance attiva al momento della modifica.
• In Active-Active anche l’Auxiliary Appliance può essere attiva e contenere log locali del nodo pertinenti.
• Dopo un failover, gli intervalli temporali necessari possono trovarsi su dispositivi diversi.

Log e report non vengono sincronizzati tra i nodi HA. Per un’analisi completa, documentare quindi la modalità HA, il cambio di ruolo e l’intervallo temporale e scaricare separatamente i Troubleshooting Logs delle appliance interessate. La gestione della configurazione e la sincronizzazione del cluster sono descritte in Configurare Sophos Firewall High Availability.

Anche localmente non è documentato un periodo fisso di conservazione di 7, 30 o 90 giorni per configuration-audit.log. I Troubleshooting Logs ruotano in base al componente, al modello e allo spazio di archiviazione assegnato; le vecchie rotazioni possono essere compresse e successivamente eliminate. Per le prove di audit o compliance, esportare quindi per tempo i file necessari.

Lista di controllo operativa

• Verificare regolarmente system configuration-audit show e lasciare attivo l’Audit Logging.
• Utilizzare account amministratore nominativi, ruoli adeguati e MFA per gli accessi amministrativi.
• Documentare le modifiche indicando ticket, intervallo temporale, oggetto e test previsto.
• Preparare backup e piano di rollback prima di modifiche importanti.
• Cercare in configuration-audit.log per intervallo temporale, oggetto e amministratore.
• Confrontare i valori precedenti e successivi con la modifica approvata.
• Verificare l’effetto tecnico con Log Viewer e traffico di test reale.
• Per Central, utilizzare Audit Logs, Log Viewer o la coda appropriata in base all’operazione.
• In HA, considerare i nodi interessati e l’ora del failover.
• Esportare in modo protetto i dati di audit necessari prima della rotazione.

FAQ