Creare e testare in sicurezza le eccezioni email di Sophos Firewall

Un’eccezione email su Sophos Firewall non si limita ad autorizzare un mittente. Ignora controlli di sicurezza selezionati per un percorso SMTP definito. Proprio per questo può risolvere in modo preciso un falso positivo confermato, ma può anche disattivare silenziosamente SPF, la scansione antimalware, Zero-Day Protection o i controlli DKIM.

⚠️ Un’eccezione viene creata solo dopo aver riprodotto un falso positivo. Si ignora esclusivamente il controllo interessato. Scegliere la condizione affidabile più ristretta, perché host sorgente, mittente e destinatario sono alternative e non una condizione AND comune. All checks e wildcard estese non sono una soluzione rapida standard.

Creare l’eccezione in sette passaggi

1. Registrare l’ora del test, l’IP sorgente SMTP, il mittente della busta, il destinatario, l’oggetto, il Message-ID e il motivo esatto del rifiuto.
2. Verificare se il problema è causato da DNS, routing, relay, TLS o dalla policy email vera e propria anziché da un controllo di sicurezza.
3. In Email > Policies and exceptions > Add an exception, selezionare solo il controllo dimostrato come interessato.
4. Attivare solo la condizione più ristretta adatta in Sources or hosts, Sender addresses o Recipient addresses.
5. Testare positivamente un messaggio equivalente e negativamente almeno una variante fuori dall’ambito.
6. In Email > Mail logs, confrontare risultato e Reason prima e dopo; verificare separatamente le altre protezioni con casi innocui.
7. Documentare il responsabile, la motivazione e la data di revisione; rimuovere l’eccezione dopo aver corretto la causa.

Cosa ignora realmente un’eccezione

SFOS raggruppa i controlli ignorabili in base al loro effetto. Spam protection contiene RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF e BATV. Malware protection contiene Malware e Zero-day protection. Other contiene Data protection, File protection, Encryption, Banner addition, DKIM signing e DKIM verification.

Questa selezione non è un elenco di comodità. Un’eccezione per SPF, ad esempio, lascia in funzione il resto del percorso antispam e antimalware. Un’eccezione per Malware o Zero-day protection, invece, rimuove un controllo centrale dei contenuti per tutti i messaggi che corrispondono all’ambito. Encryption, DKIM signing o DKIM verification modificano inoltre la riservatezza e la convalida dell’integrità del flusso email in uscita o in entrata.

Questa eccezione appartiene alla modalità MTA. Una policy SMTP route and scan riunisce routing e azioni antispam, antimalware, file e dati. In modalità legacy, SFOS opera come proxy trasparente e usa policy SMTP malware scan e SMTP spam scan separate; l’oggetto eccezione MTA non è il controllo adatto. Vedere Configurare Mail Protection di Sophos Firewall in modalità MTA e Configurare Mail Protection in modalità legacy.

Encryption indica qui la crittografia email della policy MTA, ad esempio SPX Email Encryption, non la crittografia di trasporto SMTP. Require TLS negotiation, convalida del certificato e Skip TLS negotiation si gestiscono separatamente in Email > General settings > SMTP TLS configuration. Un’eccezione email non corregge quindi handshake TLS, routing, relay o regole firewall.

Comprendere la corrispondenza prima di salvare

I tre gruppi non formano una condizione AND. L’API ufficiale SFOS 22.0 li denomina ForTheseSourceHost, ORTheseSenderAddresses e ORTheseRecipientAddresses. Con più gruppi attivi basta la corrispondenza dell’host sorgente o del mittente o del destinatario. IP, dominio partner e casella pilota creano quindi tre percorsi di corrispondenza, non una combinazione più ristretta.

Questo oggetto non offre un AND tra i gruppi; anche due eccezioni allargherebbero l’ambito. Se servono due criteri simultanei, correggere la causa o separare il flusso con una policy o un percorso gateway appropriato.

Sources or hosts

SFOS accetta come sorgenti indirizzi IP, intervalli IP, liste IP, reti o FQDN. I FQDN con wildcard non sono supportati per le eccezioni host email. *.example.net non è quindi un sostituto valido dell’indirizzo sorgente SMTP osservato. Per localhost non serve un’eccezione, poiché SFOS non esegue la scansione delle email locali per impostazione predefinita.

Per i servizi email cloud o i gateway distribuiti, un singolo IP può essere troppo restrittivo, mentre un’intera rete del provider può essere eccessivamente ampia. Si utilizza solo un oggetto sorgente pubblicato e realmente osservato nel proprio flusso email. Se altri tenant condividono gli IP del provider, anche tale oggetto può essere troppo ampio. Non escludere un controllo di sicurezza basandosi soltanto su quella rete.

Mittente e destinatario

Per Sender addresses e Recipient addresses è consentito un indirizzo come sender@example.net o una wildcard come *@example.net. Un secondo gruppo non è un ancoraggio più restrittivo perché è collegato con OR. Un mittente non è una prova di fiducia indipendente quando si esclude SPF o DKIM; un’eccezione destinatario vale per i messaggi corrispondenti di tutti i mittenti.

BATV presenta una regola speciale insolita: per ignorare il controllo BATV delle email di un mittente, il suo indirizzo deve essere inserito sia in Sender addresses sia in Recipient addresses. Se manca uno dei due campi, l’eccezione è incompleta per questo caso BATV.

Creare un’eccezione ristretta

L’esempio riguarda un falso positivo SPF confermato da un gateway dedicato del partner. 203.0.113.25 è un indirizzo di documentazione da sostituire con l’IP pubblico osservato in Mail logs. È adatto solo se l’IP appartiene esclusivamente al gateway fidato; per un relay cloud condiviso il bypass sarebbe troppo ampio.

1. Aprire Email > Policies and exceptions > Add an exception.
2. Inserire un nome tracciabile come FP-SPF-partner-example-review-2026-09-30.
3. Tra i controlli da ignorare, selezionare esclusivamente SPF.
4. In Sources or hosts, inserire l’host 203.0.113.25.
5. Lasciare Sender addresses e Recipient addresses disattivati o vuoti: aggiungerebbero corrispondenze OR.
6. Salvare senza aggiungere altri host o controlli.

Il nome contiene intenzionalmente la causa e la data di revisione. Non sostituisce però la documentazione nella modifica o nel ticket. Il nome non impone tecnicamente una data di scadenza; il responsabile deve effettuare realmente la revisione.

Eseguire test positivi e negativi

Il partner reinvia lo stesso messaggio controllato, che non deve più fallire per il Reason SPF confermato. In Email > Mail logs filtrare per intervallo, mittente, destinatario o oggetto e per Result e Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification e BATV hanno filtri Reason dedicati. Per approfondire usare smtpd_main.log e, per i rifiuti, smtpd_reject.log; Servizi e log di Sophos Firewall ne spiega il ruolo.

Eseguire poi un test negativo su un percorso SMTP controllato non escluso. Non deve bypassare il controllo documentato a causa di questa eccezione. Con un’eccezione solo per host sorgente, altri mittenti o destinatari sullo stesso IP non sono test negativi: corrispondono allo stesso ramo OR. Un file innocuo può verificare separatamente Malware e File Protection; non usare malware reale.

La sola consegna non dimostra l’ambito. La documentazione ufficiale di Mail logs descrive Reason e stato di consegna, ma non un campo “matched exception” né l’elenco dei controlli ignorati. Valutare insieme Reason prima/dopo, configurazione e casi positivi e negativi separati. Non presentare la consegna come prova che tutte le altre protezioni siano state eseguite.

Riconoscere le eccezioni rischiose

Anche una sola wildcard di dominio ampia o una grande rete sorgente può rimuovere la protezione per una parte considerevole del flusso email. Inserirle entrambe non restringe l’ambito, ma aggiunge corrispondenze OR. In particolare, le eccezioni per Malware, Zero-Day Protection, Data protection e File protection richiedono una decisione di rischio documentata e un ambito molto ridotto e affidabile di per sé. In presenza di un errore di scansione ancora sconosciuto, non si disattiva preventivamente l’intero gruppo.

Anche le opzioni apparentemente funzionali sono rilevanti per la sicurezza. Ignorare Encryption può inviare contenuti riservati senza protezione. Senza DKIM signing manca la firma in uscita pianificata; senza DKIM verification non viene valutata una prova d’identità in entrata. Un’eccezione Banner può rimuovere testi o contrassegni obbligatori. Tali modifiche vengono concordate con i responsabili della posta e della conformità.

Circoscrivere gli errori in base al sintomo

Il messaggio viene ancora rifiutato

Valutare prima la nuova voce di log anziché il vecchio messaggio di test. L’IP sorgente effettivo, il mittente della busta, il destinatario e il Reason devono corrispondere all’ambito e al controllo selezionato. Un FQDN con wildcard in Sources or hosts non funziona. Se il messaggio viene rifiutato a causa di RBL, IP reputation, RDNS/HELO o un altro controllo, un’eccezione esclusivamente SPF non risolve questo motivo separato.

L’eccezione corrisponde a troppi messaggi

Confrontare separatamente i tre gruppi con il flusso reale. Ogni gruppo OR attivo aumenta le corrispondenze. Ridurre l’eccezione a un gruppo affidabile con il minor numero di valori e ripetere il test negativo.

L’email supera il controllo, ma non viene consegnata

Un’eccezione controlla le verifiche di sicurezza, non MX, il percorso interno, il relay, TLS SMTP o il server email di destinazione. Mail logs e lo spool mostrano se il messaggio fallisce dopo la scansione per DNS, routing, policy o consegna. Per un errore TLS, controllare il certificato, Require TLS negotiation e il peer; Encryption nell’eccezione e un ambito più ampio non lo risolvono.

L’eccezione BATV non viene applicata

Verificare che lo stesso indirizzo del mittente sia presente in Sender addresses e Recipient addresses. Quindi confrontare nuovamente il Reason BATV specifico e gli altri campi dell’ambito. Una seconda eccezione più ampia non sostituisce il campo BATV mancante.

Gestione e rollback

Ogni eccezione ha un responsabile, un motivo dimostrato di falso positivo e una data di revisione. Le modifiche vengono confrontate con l’audit trail; Tracciare le modifiche di configurazione su Sophos Firewall descrive la prova appropriata. Il flusso email effettivo rimane inoltre visibile separatamente in Mail logs e nei file MTA.

Prima della modifica registrare nome, controlli, valori dell’ambito e Reason precedente. Per preservare lo stato, eliminare soltanto la nuova eccezione lasciando intatte policy e altre eccezioni. Ritestare l’errore originale e un messaggio di controllo; se la causa non è risolta, pianificare prima una finestra di manutenzione o una correzione più ristretta.

Checklist

• Sono disponibili un falso positivo riproducibile e il Reason esatto.
• IP sorgente, mittente della busta, destinatario e Message-ID sono documentati.
• Viene ignorato solo il controllo interessato.
• Preferire un solo gruppo di ambito adatto; gruppi aggiuntivi ampliano la corrispondenza tramite OR.
• I FQDN con wildcard non vengono usati come eccezioni host.
• Un’eccezione BATV contiene l’indirizzo del mittente in entrambi i campi degli indirizzi.
• I test positivi e negativi, insieme ai Reason precedenti e successivi, confermano l’effetto previsto.
• Gli altri controlli di spam, malware, file, dati e DKIM restano attivi.
• Responsabile, motivazione, data di revisione e rollback sono documentati.

FAQ