Documentare le regole di Sophos Firewall

Le regole firewall diventano rapidamente poco chiare. All’inizio ogni regola è logica: un server deve accedere a Internet, un servizio viene pubblicato, una VPN richiede accesso oppure un’applicazione necessita di porte specifiche. Dopo alcuni mesi, spesso non si sa più perché la regola esiste, chi l’ha richiesta e se sia ancora necessaria.

La contromisura più semplice non è una grande CMDB, ma una descrizione pulita direttamente nella regola Sophos Firewall. Anche poche informazioni coerenti aiutano nel troubleshooting, negli audit, nelle attività di pulizia e nei passaggi di consegne.

Per la struttura di una regola, Comprendere e configurare correttamente le regole Sophos Firewall è l’articolo di base. Dopo il salvataggio di una regola, è utile Testare una regola Sophos Firewall con Log Viewer e Packet Capture.

Perché La Documentazione Delle Regole È Importante

Una regola firewall non è solo un’autorizzazione tecnica. È una decisione operativa: chi può accedere a cosa, tramite quale servizio, con quale rischio e per quale motivo?

Senza documentazione compaiono problemi tipici:

• Vecchie regole restano attive perché nessuno ne conosce più lo scopo.
• Le regole di test non vengono mai rimosse.
• Gli audit richiedono molto più tempo del necessario.
• Gli incidenti durano più a lungo perché l’owner dell’applicazione non è chiaro.
• Le modifiche vengono fatte direttamente sulla firewall ma non documentate.
• Le regole non vengono ripulite per paura di effetti collaterali.

Una buona descrizione non elimina tutti questi problemi, ma riduce sensibilmente l’attrito nelle operazioni quotidiane.

Dove Inserire La Descrizione

Il campo Description si trova direttamente nella regola firewall. Aprire la regola in:

Rules and policies > Firewall rules

Poi modificare la regola interessata e compilare il campo Description.

Il campo è limitato. Non deve quindi sostituire la documentazione tecnica completa, ma rendere visibili direttamente sulla firewall le informazioni operative più importanti. I dettagli possono rimanere in un ticket, wiki, change request o cartella di progetto.

Cosa Inserire Nella Descrizione Della Regola

Source, Destination, Services, NAT e Security Features sono già visibili nella regola. La descrizione non deve quindi ripetere tutto, ma spiegare ciò che in futuro non sarà più evidente.

Informazioni utili:

• Scopo: Perché esiste la regola?
• Applicazione / servizio: Quale applicazione o processo richiede la regola?
• Owner: Chi è responsabile dal punto di vista operativo?
• Ticket / change: Dove è documentata la modifica?
• Creatore / modificatore: Chi ha creato o modificato la regola?
• Data: Quando è stata creata o rivista l’ultima volta?
• Review: Quando deve essere rivista o rimossa?
• Particolarità: Eccezione, deviazione o rischio consapevole.

Non tutte le regole richiedono tutti i campi. Per una regola client standard spesso basta meno. DNAT, VPN, management, accessi di partner o eccezioni temporanee dovrebbero essere descritte in modo più preciso.

Combinare Nome E Description

Il nome della regola deve essere breve e strutturato. La Description spiega il contesto. Non esiste uno schema perfetto valido per ogni azienda. L’importante è che un amministratore, scorrendo la rule base, capisca approssimativamente cosa fa la regola senza doverla aprire.

Nella pratica funzionano bene tre approcci:

• Sorgente, destinazione, servizio: VLAN12_WAN_HTTPS. Buona variante standard per regole client, server e VPN.
• Applicazione, sorgente, destinazione: ERP_VPNUSERS_SRVERP_HTTPS. Utile quando l’applicazione è più importante del segmento di rete.
• Tipo di regola come prefisso: DNAT_WAN_SRVWEB01_HTTPS. Utile per DNAT, regole Drop, regole temporanee o casi speciali.

Usiamo spesso il modello SOURCE_DESTINATION_PORT, perché resta tecnico e leggibile anche dopo mesi. L’azione non deve per forza essere nel nome, dato che Sophos Firewall mostra già Accept, Drop o Reject nella regola.

Esempi tipici:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

A seconda dell’ambiente, lo schema può essere esteso leggermente:

• ZONE_SOURCE_DESTINATION_PORT, ad esempio LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, ad esempio ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, ad esempio CHG1842_VPNUSERS_SRVERP_HTTPS

Per ambienti piccoli spesso basta uno schema semplice. In ambienti più grandi con molti VLAN, VPN, reti server e regole DNAT, uno standard coerente diventa molto più utile. Prefissi come DNAT, DROP o TEMP sono sensati quando aiutano a leggere rapidamente la rule base o indicano un tipo di regola particolare.

Meglio evitare nomi molto generici, perché in seguito non permettono più di dedurre nulla:

• Rule1
• Test
• Allow
• Internet
• Temp

Esempio Compatto

Esempio di regola produttiva:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

Se lo spazio è limitato, si può lavorare in modo più breve. Scopo, owner e ticket dovrebbero comunque restare riconoscibili:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Per una regola temporanea, la data di scadenza deve essere particolarmente chiara:

Temp vendor access per migrazione, Owner IT, CHG-1910, remove after 2026-07-31

Cosa Non Inserire Nella Description

Nel campo Description non devono essere inseriti:

• password,
• chiavi API,
• dati personali senza motivo,
• dati cliente riservati,
• istruzioni complete di accesso per terzi,
• URL esterni lunghi senza contesto interno.

Se sono coinvolti fornitori esterni, spesso bastano un referente interno, un ticket o un riferimento alla documentazione. I dettagli sensibili devono stare in un sistema adatto per ticket, documentazione o password, non in una regola firewall.

Review E Pulizia

La descrizione delle regole è solo il primo passo. La cosa decisiva è verificare regolarmente le regole.

Procedura pratica:

1. Segnare le regole senza Description.
2. Verificare le regole con Test, Temp, Allow any o nomi poco chiari.
3. Analizzare Usage Counter e Log Viewer.
4. Cercare owner o ticket.
5. Disattivare le regole non più necessarie, monitorarle e rimuoverle in seguito.
6. Documentare la modifica.

Durante ogni pulizia, Log firewall traffic dovrebbe essere attivo per le regole rilevanti, così Log Viewer mostra se una regola è ancora usata. Per i test dopo modifiche, usare Testare una regola Sophos Firewall con Log Viewer e Packet Capture.

Standard Minimo Per Nuove Regole

Le nuove regole Sophos Firewall dovrebbero avere almeno:

• un nome significativo,
• Source e Destination chiari invece di Any non necessario,
• logging attivo per le regole importanti,
• una Description con scopo, owner e ticket,
• una data di review per regole temporanee o rischiose,
• nessun segreto nel campo Description,
• un test dopo il salvataggio.

Per server pubblicati è utile anche Pubblicare un server con DNAT su Sophos Firewall. Per le basi del NAT, vedere Comprendere NAT su Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ