Sophos Firewall Configuration Viewer: verificare e confrontare le configurazioni

19 febbraio 2026 • 13 min read

Ciao a tutti,

se hai mai gestito una Sophos Firewall in un contesto aziendale reale, conosci bene il dilemma: la configurazione è la “single source of truth”. Ma nel momento in cui vuoi rileggerla fuori dalla web UI, documentarla in modo serio o confrontare un prima/dopo di una modifica, diventa rapidamente frustrante.

Sì, puoi fare screenshot. Sì, puoi esportare singole regole. Ma non appena entri nel territorio dei cambi più grandi (migrazione WAN, nuovi VLAN, pulizia degli oggetti, ristrutturazione della logica NAT, “giusto al volo” ritoccare qualche VPN), vuoi davvero due cose:

Una configurazione leggibile.
Un confronto che non sia “diffare l’XML e piangere”.

Ed è qui che entra in gioco il Sophos Firewall Configuration Viewer.

Questo strumento non ti toglie responsabilità. Devi comunque progettare una configurazione pulita e testare bene i cambiamenti. Però elimina una cosa che nella vita reale fa perdere un sacco di tempo: il problema del formato. Trasforma un export tecnicamente corretto ma praticamente illeggibile in una vista con cui puoi lavorare davvero.

E sì: su questo sono parecchio pignolo. Quando pianifico un change, non voglio solo sapere che qualcosa è cambiato. Voglio sapere cosa esattamente è cambiato e se ho toccato per sbaglio un oggetto, una regola NAT o un’impostazione VPN ai margini. Il viewer è un aiuto sorprendentemente pragmatico per questo.

Cos’è il Sophos Firewall Configuration Viewer?

Il Sophos Firewall Configuration Viewer è uno strumento basato su browser che converte le configurazioni Sophos Firewall in un formato leggibile per gli umani. Ti permette di:

filtrare, ordinare e cercare nella configurazione
cercare oggetti/host/FQDN specifici e vedere dove vengono referenziati
confrontare due configurazioni (Added/Modified/Removed)
esportare il risultato come report HTML

Importante: è uno strumento standalone che apri direttamente nel browser. Non devi installare nulla e puoi usarlo praticamente da qualsiasi laptop da admin. È uno dei motivi per cui mi piace: si integra nei workflow esistenti senza attriti.

Sotto il cofano lavora con ciò che Sophos ti dà già: l’export della configurazione in XML (tipicamente Entities.xml). La differenza è la presentazione. Invece di fissare strutture XML, ottieni una vista che sembra una documentazione ordinata.

E non è solo “view”. Nella pratica, tre funzioni tornano continuamente:

Leggere: una vista strutturata della config, filtrabile.
Ricerca/Riferimenti: trovare oggetti e vedere dove vengono usati.
Confrontare: prima/dopo o Firewall A vs Firewall B.

Il punto più importante per sicurezza e privacy: Sophos sottolinea che i dati vengono elaborati localmente nel browser e che nulla viene “caricato” altrove. Parsing, analisi e generazione dei report dovrebbero rimanere sul tuo dispositivo.

Trovi lo strumento qui: Sophos Firewall Configuration Viewer

Se preferisci prima un walkthrough veloce, qui c’è il TechVid di Sophos:

Un caso reale da PMI

Venerdì, 15:30. Un’azienda con circa 80 dipendenti: nuova connessione Internet, nuove IP pubbliche e, in parallelo, un piccolo progetto (nuovo CRM, nuove subnet). La richiesta di change è scritta bene: quali regole NAT, quali endpoint VPN e quali regole firewall vanno ritoccate.

Nella realtà, succede la solita storia:

Un oggetto come WAN_Public_IPs è referenziato da tre regole NAT, due regole “business application” e una regola WAF “storica” che nessuno guarda da anni.
Un oggetto FQDN per un SaaS è finito in un gruppo tempo fa e ora appare in dieci regole, ma solo due sono ancora rilevanti.
Vuoi fare pulizia, ma non vuoi la telefonata di lunedì mattina: “Dopo il change, X non funziona più.”

È qui che il Configuration Viewer fa risparmiare tempo sul serio.

Il mio workflow tipico in situazioni del genere:

Esportare prima (salvare una baseline)
Applicare la modifica
Esportare dopo
Fare un diff nel viewer e allegare l’HTML al ticket
Prima di cancellare oggetti: usare Usage Reference per verificare dove sono davvero usati

Non è solo comodità. Rende i cambiamenti tracciabili. Ed è esattamente ciò che vogliono audit, approvazioni interne e il tuo io del futuro.

Come usare lo strumento in pratica

1) Esportare la configurazione (Full o Selective)

Esporta direttamente dal firewall:

WebAdmin: Backup & Firmware > Import / Export
Esporta Export full configuration (tutto) oppure Export selective configuration (aree specifiche, opzionalmente con “Include dependent entity”)

Sophos genera un file .tar che scarichi.

Alcuni dettagli che contano davvero nella pratica:

Full export è il mio default per il change management (baseline/diff). Hai tutto e riduci il rischio di perdere dipendenze.
Selective export è ottimo quando vuoi rivedere solo un’area (ad esempio solo interfacce + routing) o quando devi condividere qualcosa con terzi (ISP/vendor) e vuoi minimizzare ciò che esponi.
Include dependent entity è spesso fondamentale negli export selettivi: se esporti regole firewall, di solito vuoi anche gli oggetti network/service referenziati. Altrimenti l’export risulta incompleto e perdi il contesto.

Pro tip per i confronti: per “Compare” esporta sempre due configurazioni con la stessa selezione (Full vs Full, oppure Selective vs Selective con le stesse spunte). Se confronti Full contro Selective, il diff sarà spettacolare, ma spesso poco utile.

2) Estrarre il TAR e trovare `Entities.xml`

Dal .tar, estrai il file Entities.xml (a seconda dell’export può chiamarsi anche entities.xml).

Su macOS/Linux:

tar -xvf backup.tar
ls -la

Su Windows puoi farlo con strumenti come 7-Zip.

Se (come me) vuoi evitare che questi backup marciscano nella cartella Downloads, crea una directory temporanea di lavoro. Esempio su macOS/Linux:

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

Alla fine puoi cancellare la directory. Sembra banale, ma è esattamente il tipo di igiene che impedisce alle config sensibili di restare in giro per settimane.

Per il tuo radar sicurezza: secondo la documentazione Sophos, un export senza contenuti sensibili (ad esempio solo interfacce) spesso contiene solo Entities.xml. Quando invece include informazioni sensibili (ad esempio utenti), il TAR può includere anche file come hashFile.json e propertyfile.

In pratica: tratta l’intero TAR come confidenziale.

3) Rendere una configurazione “leggibile”

Nel viewer, scegli “Single configuration” (o simile) e carica l’Entities.xml. Otterrai una vista renderizzata della configurazione.

A seconda della dimensione, il caricamento può richiedere qualche secondo. Dopo di che hai qualcosa che nella web UI spesso mi manca: una vista “documentazione” della config, senza cliccare attraverso decine di menu.

La cosa che apprezzo di più: puoi filtrare in modo aggressivo sulla sinistra. Se il tuo change riguarda routing/NAT, non vuoi scorrere report, logging e funzioni secondarie. Attivi solo le sezioni che ti servono adesso.

Combinazioni di filtri tipiche in pratica:

solo regole firewall + NAT
solo interfacce + routing
solo VPN

Quando audito o prendo in carico un ambiente per la prima volta, di solito seguo questo ordine:

Interfacce/zone (cosa è interno, cosa è esterno?)
Routing/SD-WAN (come esce il traffico, da dove arrivano le route di ritorno?)
NAT (cosa viene pubblicato, cosa viene riscritto?)
Regole firewall (quali flussi sono davvero permessi?)
VPN (site-to-site e remote access, a seconda del setup)

Non è l’unico ordine possibile, ma evita di giudicare regole senza capire la topologia.

E se ti serve qualcosa per documentazione o approvazione: puoi esportare un report HTML in qualsiasi momento.

Io lo uso spesso come “pacchetto di review”: esporti HTML, lo alleghi al ticket di change (o lo archivi internamente in una documentazione sicura), e qualcun altro può rivedere la configurazione senza accesso diretto al firewall. È comodissimo per il principio dei quattro occhi, approvazioni interne o audit esterni.

4) Usage Reference: “Dove viene usato davvero questo oggetto?”

Per me questa è la killer feature.

Le configurazioni Sophos si basano molto su oggetti: host, reti, servizi, FQDN, gruppi. È ottimo perché puoi riutilizzare tutto in modo pulito. Il rovescio della medaglia: dopo qualche anno, spesso non è più ovvio dove un oggetto è referenziato.

Ed è lì che nascono gli errori classici:

qualcuno elimina un oggetto “perché sembra vecchio” e scopre più tardi che veniva ancora usato in una regola NAT
qualcuno modifica un oggetto (ad esempio espande un range IP) e cambia involontariamente più policy insieme

Usage Reference nel viewer rende visibili queste dipendenze. Invece di cercare nella UI “a intuito”, usi search/Usage Reference per capire dove un oggetto o un hostname è referenziato.

Esempio dal TechVid: cerchi box e vedi subito quali policy/regole NAT referenziano l’oggetto FQDN.

La parte bella è il click-through: passi dalla ricerca all’oggetto e poi vedi i riferimenti (ad esempio quale policy firewall o regola NAT lo usa). Quando faccio una cleanup, spesso esporto questa vista in HTML e la allego al ticket. Più tardi è chiaro perché ho eliminato o modificato un oggetto.

Perfetto per:

cleanup (rimuovere oggetti vecchi)
change planning (quali regole vanno davvero modificate)
troubleshooting (perché una regola matcha ancora da qualche parte)

5) Confrontare due configurazioni (Before/After)

Nella landing page puoi scegliere “Compare” invece di “View” e caricare due file Entities.xml.

Sembra semplice, ma è un pattern potentissimo. Io lo uso, ad esempio, per:

before/after di cambiamenti (il mio classico)
confronto tra test/staging e produzione per trovare drift
validazione dopo migrazioni (nuova WAN, nuova logica NAT, nuova VPN)

Quello che mi piace della modalità compare: non è un semplice diff testuale. Prova a raggruppare le modifiche in modo sensato. Non vedi solo “qualche XML è diverso”, ma: questo oggetto è stato aggiunto, questa regola è stata modificata, questa voce è stata rimossa.

È esattamente ciò che serve per il change management:

summary: cosa è stato rimosso, modificato, aggiunto?
dettagli per oggetto/regola
XML raw affiancato (opzionale)
export HTML per ticket/audit

Il mio workflow personale è piuttosto semplice (ma efficace):

Leggo il summary: le quantità hanno senso? (ad esempio “ho cambiato 3 regole” vs “in qualche modo 200 oggetti modified”)
Vado sulle aree critiche: interfacce/WAN, routing, NAT, VPN, regole firewall
Salvo l’export HTML finché tutto è fresco

Soprattutto il punto 1 riduce lo stress. Se vedo che solo gli oggetti previsti sono stati toccati, dormo molto meglio nel weekend.

Se prendi l’abitudine di salvare un diff before/after per i change importanti, ti semplifichi la vita nel lungo periodo.

Funzioni e feature nel dettaglio

Fin qui lo strumento è già utile. Ma dopo averlo usato un paio di volte, ti accorgi che: il viewer è meno “nice to have” e più una piccola cassetta degli attrezzi per domande tipiche da admin. Ecco le feature che uso davvero spesso, con un po’ più di dettaglio.

Human-Readable View: finalmente senza maratona di clic

Nella web UI Sophos le impostazioni sono spesso raggruppate in modo logico, ma sparse su molte pagine. Per lavori rapidi va bene. Per audit o change planning è stancante, perché perdi continuamente il contesto.

Il viewer trasforma tutto in una rappresentazione compatta. Io lo uso per un reality check veloce:

quali interfacce/zone esistono davvero?
quali regole NAT pubblicano quali servizi?
quali regole sono troppo ampie perché in passato “doveva funzionare”?

Non sostituisce un design pulito, ma rende visibile come il firewall è descritto alla fine.

Filtri: focus su ciò che conta ora

I filtri a sinistra sembrano banali, ma nella pratica sono oro. La maggior parte dei change non riguarda l’intera configurazione, ma una sezione (WAN, NAT, VPN, routing).

Se sto portando online una nuova connessione Internet, nascondo tutto e mi concentro su:

interfacce/WAN
routing/SD-WAN
NAT
regole firewall (per i flussi coinvolti)

Sembra banale, ma evita di perdersi in side quest durante una review.

Ricerca: da “box” a “10.20.30.0/24”

La ricerca è un ottimo punto di ingresso se vieni dall’operatività e hai solo un sintomo:

“Il nostro servizio verso box.com non funziona più”
“La nuova rete della filiale 10.20.30.0/24 non ha accesso”
“Perché SMTP è ancora aperto?”

Cerchi per nome, IP, FQDN o oggetto e arrivi velocemente al punto giusto.

Usage Reference: vedere l’impatto (prima che faccia male)

Usage Reference è la funzione che più spesso decide se una cleanup è “coraggiosa” o “responsabile”. La uso principalmente per tre casi:

Eliminare oggetti: prima verifico se è referenziato da qualche parte.
Modificare oggetti: prima verifico quante regole/policy verrebbero impattate indirettamente.
Pianificare change: prima verifico quali regole sono realmente legate allo stesso oggetto.

Se lo fai con costanza, il numero di “ah, era collegato anche lì” cala drasticamente.

Compare + export HTML: il mio default per il change management

La modalità compare è la mia “prova” che un change è andato come previsto.

Quasi sempre faccio così:

Export prima
Export dopo
Compare
Salvo l’HTML diff e lo allego al ticket

Sembra pedante, ma sono pochi minuti e possono risparmiarti ore di discussione più tardi quando qualcuno chiede cosa è cambiato esattamente. In team è anche un ottimo formato di review: puoi chiedere a qualcuno di leggere l’HTML diff e verificare solo i punti critici.

Sicurezza: cosa va bene e quali sono i limiti

1) Privacy-first è ottimo, ma non è una scusa per essere superficiali

Che Sophos dica che nulla esce dal browser è un grande vantaggio, soprattutto per dati di configurazione.

Detto questo: una configurazione firewall è quasi sempre sensibile. Anche senza password in chiaro, di solito contiene:

reti interne, VLAN, schemi IP
definizioni NAT ed endpoint pubblici
topologie VPN
gruppi di oggetti (spesso più rivelatori di quanto sembri)

2) L’export è il vero rischio

Il viewer ti aiuta a leggere. Ma il rischio di solito è prima e dopo:

durante il download del TAR
durante l’estrazione
quando salvi/condividi report HTML

Sophos documenta esplicitamente che export con informazioni sensibili possono includere file aggiuntivi e che il tema della secure storage master key conta per gli import.

Il mio consiglio pratico:

tenere gli export localmente per poco tempo (e poi ripulire)
non mettere report in sistemi di ticket “aperti”
se lavori con terzi: preferire export selettivi e condividere solo il necessario

3) SSH/Advanced Shell: il viewer mostra solo ciò che è nell’export

Una cosa che succede più spesso nella realtà di quanto si ammetta: durante un incidente, qualcuno entra via SSH e “sistema qualcosa al volo” nell’Advanced Shell.

Il punto importante non è se la modifica sopravvive al prossimo reboot o no. Il punto importante è: se qualcosa non finisce nell’export (Entities.xml), nel viewer non lo vedi. E questo può succedere con regolazioni via Advanced Shell/SSH, perché non sempre compaiono come configurazione “normale” nell’export.

Se tocchi cose via SSH/Advanced Shell, documentale a parte e pianifica di rappresentarle correttamente tramite la configurazione WebAdmin. Altrimenti il prossimo restore, HA failover o firmware update è quando ti morde, o semplicemente te lo perdi nel diff.

4) Regole pratiche che aiutano in produzione

Usa un profilo browser senza un “zoo” di estensioni per attività come questa.
Conserva TAR/HTML solo dove conserveresti altre config confidenziali.
Se devi condividere: esporta il minimo (selective) e pensa alle dipendenze.

Conclusione

Il Sophos Firewall Configuration Viewer non è una feature da titoli di giornale. Ma onestamente: strumenti così sono quelli che ti tolgono il peso di dosso nel lavoro quotidiano.

Negli anni ho visto abbastanza configurazioni in cui lo stress vero non era “la tecnologia”, ma la tracciabilità: cosa è cambiato e quando? Questo oggetto è davvero inutilizzato? Abbiamo toccato qualcosa senza volerlo? Nella web UI puoi trovare tante cose, ma raramente in modo rapido. E leggere export XML a mano è qualcosa che nessuno fa volontariamente per più di cinque minuti.

Il viewer colma bene questo gap. Posso leggere una configurazione con calma, trattarla come documentazione, filtrare ciò che mi serve, controllare i riferimenti e infine salvare un HTML diff. Sembra “nice”, ma in team è una leva reale: le review diventano più facili, gli audit meno stressanti e hai meno sorprese il lunedì mattina.

Se ti porti via solo una cosa: crea un piccolo riflesso.

Prima di change importanti: esporta una volta, dopo il change esporta di nuovo, lancia Compare e archivia l’HTML diff. Sono pochi minuti, ma è uno dei modi più affidabili per combattere il “credo che abbiamo cambiato solo X”.

E come sempre: il viewer rende le config più leggibili, ma non automaticamente più sicure. Il ragionamento resta tuo. Ti dà solo finalmente uno strumento che non lavora contro di te.

Se hai mai fatto tweak “quick and dirty” via SSH nell’Advanced Shell: tieni presente che non sempre finiscono nei backup, e quindi non saranno visibili nel viewer.

Fonti e approfondimenti

Alla prossima, Joe