Sophos Email: gestire in sicurezza le eccezioni Allow/Block in ingresso

Inbound Allow/Block controlla quali mittenti Sophos Email consente o blocca per i messaggi in ingresso. L’elenco amministratore si applica globalmente a tutte le caselle protette; gli elenchi personali si applicano al rispettivo utente. In caso di conflitto, Admin list ha la precedenza.

Procedura rapida e sicura: in Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block, esportare prima l’elenco esistente. Aggiungere quindi ad Admin list il valore mittente più specifico possibile, attivare Enforce Message Authentication per una voce Allow, documentare motivo e proprietario e verificare con messaggi corrispondenti e non corrispondenti. Domini, wildcard e reti estesi non sostituiscono l’analisi di un falso positivo.

Importante: una voce Allow non disattiva completamente la protezione. Per un mittente corrispondente e sufficientemente autenticato, Sophos ignora solo i controlli documentati di seguito; la scansione antimalware rimane attiva. Senza autenticazione obbligatoria, un messaggio contraffatto che usa un indirizzo consentito può ignorare i controlli documentati e raggiungere la posta in arrivo. La URL Allow List per Time of Click è una funzione separata e non viene gestita qui.

Comprendere ambito e corrispondenza

Gli elenchi valgono solo per i messaggi in ingresso. Per indirizzi e domini, Sophos confronta sia il mittente della busta SMTP sia l’indirizzo nell’intestazione From visibile. Se uno dei due corrisponde, viene eseguita l’azione Allow o Block configurata. Prima di creare un’eccezione, controllare entrambi nei dati del messaggio o nelle intestazioni non elaborate.

L’elenco amministratore supporta:

singoli indirizzi e-mail, come billing@example.com;
domini, come example.com;
indirizzi IP, come l’indirizzo di documentazione 192.0.2.25;
reti IPv4 con prefissi da /16 a /32, ad esempio 192.0.2.0/24;
wildcard all’inizio, al centro o alla fine di un indirizzo o dominio, ad esempio *.example.com, name*@example.com, name@example*.com o *.example;
wildcard per interi domini di primo livello; *.example è qui una forma di documentazione sicura anziché un TLD reale.

L’elenco utenti supporta invece solo indirizzi e-mail e domini, non indirizzi IP né wildcard. Il limite documentato per tutti gli elenchi è di 100.000 voci. Ogni utente può aggiungere al massimo 500 voci al proprio elenco Allow o Block; le voci aggiunte da Smart Banners possono superare questo limite per utente.

Un messaggio proveniente da un mittente o IP client bloccato viene eliminato senza ulteriori scansioni. I messaggi provenienti da indirizzi nell’elenco Block vengono normalmente rifiutati durante SMTP, prima che il server li accetti. Con più destinatari le cui impostazioni personali di blocco differiscono, invece, il messaggio viene prima accettato e poi bloccato solo per i destinatari che hanno bloccato il mittente. In questo caso l’accettazione SMTP non equivale alla consegna al destinatario che ha imposto il blocco. La verifica concreta è descritta più avanti.

Preparare e circoscrivere la modifica

Prima di ogni modifica, registrare:

ticket, motivo aziendale, proprietario e data di scadenza o revisione;
tipo esatto: Admin list o End user list;
azione Allow o Block e valore più specifico possibile;
utenti interessati da una regola utente;
esportazione corrente come backup e numero di voci;
mittente e destinatario di prova e risultati attesi con e senza corrispondenza.

Sophos non documenta una scadenza automatica per voce. La scadenza è quindi un processo operativo: pianificare le eccezioni nel sistema di change, riesaminarle regolarmente ed eliminarle quando il motivo viene meno. La descrizione deve indicare brevemente motivo e ticket, senza dati riservati.

Configurare l’elenco amministratore

In Sophos Fusion (in precedenza Sophos Central) fare clic su Global Settings.
Aprire Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Selezionare Admin list e fare clic su Add.
Selezionare Allow o Block e inserire esattamente un indirizzo, dominio, IP, rete CIDR supportata o valore wildcard necessario.
Aggiungere una breve Description con motivo e ticket, lunga al massimo 250 caratteri.
Per le voci Allow, attivare Enforce Message Authentication. Non disattivare l’opzione per aggirare un’autenticazione del mittente non riuscita.
Salvare e cercare la voce nell’elenco. Advanced Search filtra per Allow/Block, Message Authentication e indirizzo o dominio mittente.

Se il valore esiste già, usare Override duplicates solo dopo aver confrontato la voce esistente. Sophos utilizza quindi l’ultima impostazione scelta. È possibile modificare insieme la descrizione di più voci amministratore selezionate e attivare Message Authentication per le voci Allow. Una modifica collettiva non deve però unire silenziosamente motivi o proprietari diversi.

I controlli specifici di ogni voce in Enforce Message Authentication rispecchiano le opzioni di autenticazione in User Settings. Per ogni voce Allow è possibile mantenere o sostituire singole opzioni, compresi i controlli SPF e i domini della busta. Confrontare e documentare anche questi valori, non soltanto l’interruttore principale. La protezione globale dallo spoofing non sostituisce l’interruttore della voce: se Enforce Message Authentication è disattivato su una voce Allow amministratore, un mittente contraffatto può sfruttarla anche con l’opzione globale attiva.

Controlli ignorati da una corrispondenza Allow autenticata

Per una voce Allow amministratore con autenticazione obbligatoria deve riuscire almeno un controllo di DMARC, SPF o DKIM. L’opzione Prevention of spoofing of allowed address attiva e le impostazioni della voce determinano la valutazione dettagliata; in particolare, un fallimento DMARC con una policy diversa da p=none può far fallire l’autenticazione. Un qualsiasi SPF pass non è quindi una prova sufficiente in generale. Per una corrispondenza Allow autenticata correttamente, Sophos ignora:

Header anomalies;
Impersonation protection;
Anti-spam;
BATV (Bounce Address Tag Validation);
Country of origin;
Language;
Data control.

Una corrispondenza Allow utente autenticata correttamente ignora solo Impersonation protection, Anti-spam, Country of origin e Language. La sezione successiva chiarisce le descrizioni contrastanti dell’autenticazione utente. In entrambi i casi la scansione antimalware rimane attiva. La guida alla protezione da malware, allegati e URL spiega quali controlli di contenuti e URL si applicano indipendentemente.

Allow utente: descrizioni contrastanti dell’autenticazione

Le descrizioni attuali di Inbound Allow/Block e dell’elaborazione degli elenchi Allow affermano che le voci Allow utente impongono sempre Message Authentication. La descrizione di User Settings, invece, presenta Prevention of spoofing of allowed address come un’opzione da attivare per l’autenticazione Allow utente illustrata in quella pagina. Indica che per i clienti esistenti l’opzione è disattivata per impostazione predefinita e potrebbe non essere ancora disponibile in tutti i tenant. Queste descrizioni non sono inequivocabilmente coerenti. Non consentono di dedurre né un aggiramento affidabile dell’autenticazione con l’opzione disattivata né una protezione dimostrata in tutti i tenant indipendentemente dall’opzione. Il conflitto sull’autenticazione rimane irrisolto.

In esercizio, mantenere attivi i controlli di protezione esistenti e, se Prevention of spoofing of allowed address è disponibile, pianificarne l’attivazione con una convalida controllata dei percorsi di invio legittimi. Se l’opzione manca o il suo effetto non è chiaro, non basare una nuova eccezione Allow utente su una logica di autenticazione presunta; chiarire lo stato del tenant usando dettagli dei messaggi privati dei dati sensibili e le impostazioni attuali. Non disattivare Enforce Message Authentication, la protezione dallo spoofing o altri controlli come soluzione alternativa.

Per la verifica documentata con Prevention of spoofing of allowed address attivo, un indirizzo consentito può saltare i controlli solo se supera la valutazione di autenticazione seguente. In caso contrario, Sophos ignora lo stato Allow ed esegue tutte le scansioni:

Un risultato DMARC pass è sufficiente. Se DMARC fallisce con una policy del mittente diversa da p=none, l’autenticazione Allow fallisce in questa configurazione di prova con l’opzione attiva.
Con p=none, o quando DMARC non può essere eseguito, SPF e DKIM determinano il risultato.
SPF controlla il dominio della busta del messaggio.
DKIM deve riuscire per il dominio della voce Allow.
SPF check for non-aligned address può accettare un SPF pass anche se il dominio della busta dell’indirizzo mittente non è allineato con l’indirizzo consentito. Sophos sconsiglia di attivarla: un indirizzo header-from contraffatto potrebbe corrispondere a un indirizzo consentito dall’utente, aumentando il rischio di spoofing.
SPF check for envelope domain fa leggere a Sophos il dominio della busta per ogni indirizzo di intestazione consentito dall’utente, così che SPF venga applicato al dominio della busta del messaggio. Usarla solo quando è necessario questo flusso SPF eccezionale non allineato.

Questo percorso di eccezione non allineato amplia la fiducia e non è una soluzione standard. Correggere prima SPF, DKIM o DMARC nel servizio di invio legittimo. La guida all’autenticazione del mittente descrive relazioni e verifica dei risultati.

Amministrare gli elenchi utenti

User Settings non può essere configurato in modalità EMS. Fuori da tale modalità, gli utenti possono gestire il proprio elenco nel Sophos Central Self Service Portal se Release/Delete e Allow/Block List sono abilitati correttamente in Global Settings > Products and Services > Email > User Settings. Si applicano due dipendenze di sicurezza:

Se End-user message settings è attivo e i link Allow sender e Block sender sono configurati su Smart Banners, Allow/Block List deve rimanere attivo.
Se End-user message settings è disattivato e viene disattivato Release/Delete oppure Allow/Block List, Sophos ignora gli elenchi Allow/Block esistenti degli utenti.

L’amministratore può visualizzare e modificare centralmente gli stessi elenchi:

Aprire Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Selezionare End user list e fare clic su Add.
Assegnare la voce all’utente corretto, scegliere Allow o Block e usare solo un indirizzo e-mail o dominio.
Salvare e verificare con Advanced Search per azione, mittente o utente.

Anche qui Override duplicates sostituisce un valore identico con la scelta più recente. Controllare sempre prima l’elenco amministratore globale, che prevale su una voce utente in conflitto. La guida al self-service della quarantena tratta l’abilitazione delle azioni utente e dei permessi di quarantena.

Verificare correttamente più destinatari

In un messaggio con più destinatari, gli elenchi personali possono differire per lo stesso mittente. Se solo person1@example.com lo ha bloccato, person2@example.com riceve comunque il messaggio; il blocco riguarda solo person1@example.com. Nel caso normale il rifiuto avviene prima dell’accettazione SMTP. Nel caso misto con più destinatari, invece, il messaggio viene prima accettato e poi bloccato per singolo destinatario. Un’accettazione SMTP riuscita non dimostra quindi la consegna al destinatario che ha bloccato il mittente.

Per un pilota controllato, usare due caselle di prova e un mittente di prova propri; sostituire gli indirizzi di esempio con questi valori autorizzati. Prima controllare la Admin list globale per eventuali voci prevalenti e le autorizzazioni degli elenchi utenti descritte nella sezione precedente. Il pilota richiede elenchi utenti effettivamente applicati. In particolare, se End-user message settings è disattivato, disattivare Release/Delete o Allow/Block List può aggirare gli elenchi esistenti; non è una soluzione per un risultato di prova inatteso.

Documentare le voci personali originali. Bloccare il mittente di prova solo per il primo destinatario; il secondo non deve avere un blocco corrispondente.
Inviare un messaggio nuovo e innocuo a entrambi con un’unica operazione di invio. Verificare ogni azione separatamente in Message History e controllare le caselle: per il primo si attende un blocco senza consegna, per il secondo la consegna, purché un altro controllo non fermi il messaggio.
Se l’accesso SMTP è esplicitamente autorizzato, conservare anche il log dell’invio e distinguere accettazione e rifiuto. Verificare che entrambi i destinatari appartengano alla stessa transazione SMTP: transazioni separate non dimostrano il caso misto. Confrontare il risultato con una prova separata a un solo destinatario, diretta alla casella che blocca, per cui si attende il normale rifiuto prima dell’accettazione. Non dedurre un codice SMTP o una fase di elaborazione dal solo stato di consegna.
Dopo il pilota, ripristinare le voci personali documentate e ricontrollarle. In caso di risultato inatteso, fermare la modifica e verificare priorità amministratore, assegnazione utenti, corrispondenza e autorizzazioni, anziché creare una regola Allow più ampia.

Una prova SMTP con un solo destinatario non riproduce il caso misto. Senza accesso SMTP autorizzato è possibile verificare i risultati dei destinatari, ma non dichiarare la fase SMTP dimostrata in modo indipendente.

Esportare e importare CSV in sicurezza

Prima di un’importazione di massa, esportare le voci selezionate o l’intero elenco interessato come CSV. È il backup e la base di confronto. Contiene colonne aggiuntive, quindi non può essere usato invariato per l’importazione. Scaricare il modello corrente da Sophos Fusion, rispettarne esattamente formato e colonne e rimuovere le colonne aggiuntive dell’esportazione. Non inventare nomi di colonna.

Aprire la scheda corretta Admin list o End user list.
Esportare l’elenco e conservare il file invariato come backup.
Selezionare Add > Import allow/block list e scaricare i modelli.
Creare il CSV nel formato del modello. Controllare riga per riga azione, valore, Description e, per gli elenchi utenti, assegnazione.
Nell’anteprima controllare campioni Allow e Block, caratteri speciali, domini e assegnazioni utente.
Importare prima un piccolo file pilota. Cercare e provare le nuove voci prima di procedere.

Avvertenza: selezionando Replace existing list with this import e aggiungendo il CSV, tutte le voci correnti dell’elenco interessato vengono eliminate definitivamente. Usare l’opzione solo per una sostituzione completa approvata, con backup verificato e pilota riuscito. Non selezionarla per aggiungere voci.

Proteggere e annullare una sostituzione completa

Prima di una sostituzione completa, un responsabile designato deve approvare la scheda esatta, il backup completo e invariato con il numero di righe registrato, il file di ripristino preparato, l’esito del pilota e la finestra di manutenzione. Il pilota deve usare lo stesso modello Sophos corrente in un tenant non di produzione o in un elenco di prova separato e controllato. Non eseguire mai un file pilota parziale sull’elenco di produzione con Replace existing list with this import.

Se dopo la sostituzione mancano voci o alcune sono errate, interrompere ogni ulteriore importazione e non correggere l’elenco riga per riga. Dopo l’approvazione dell’incidente o della modifica, convertire l’elenco completo, precedentemente esportato e noto come valido, in un nuovo file conforme al modello Sophos corrente; conservare invariata l’esportazione originale. Prima dell’importazione, confrontare il numero di righe e voci Allow e Block rappresentative, oltre alle assegnazioni utente negli elenchi utenti e a campioni all’inizio e alla fine. Nella scheda corretta e durante una finestra controllata, importare quindi il file di ripristino completo con Replace existing list with this import. Infine, verificare che il numero di voci corrisponda a quello precedente alla modifica, confermare gli stessi campioni e ripetere i test di corrispondenza, mancata corrispondenza e autenticazione per dimostrare il ripristino dello stato valido noto. In caso di differenze, mantenere la modifica sospesa ed eseguire l’escalation; la scansione antimalware e tutti gli altri controlli di protezione rimangono attivi.

Rispettare separatamente questi limiti documentati:

massimo 500.000 voci nell’elenco di importazione creato;
massimo 500 voci per utente;
massimo 1 MB per file CSV;
massimo 250 caratteri per Description; i testi più lunghi vengono troncati durante l’importazione.

Dividere i file più grandi e caricarli in fasi. Un foglio di calcolo può modificare delimitatori, caratteri iniziali o codifica. Se i caratteri accentati sono danneggiati o le colonne slittano, annullare, ricreare il file dal modello Sophos invariato e controllare l’anteprima. Non indovinare la codifica né modificare direttamente il backup.

Convalidare il risultato

Dopo una modifica individuale o ogni importazione, eseguire un piccolo test documentato:

Corrispondenza: Un nuovo messaggio con mittente della busta o intestazione From esattamente corrispondente deve mostrare l’effetto Allow o Block previsto.
Nessuna corrispondenza: Un indirizzo simile o un dominio vicino ma non coperto dalla voce deve subire i controlli normali. Soprattutto con wildcard e CIDR, ciò rivela un ambito troppo ampio.
Autenticazione riuscita: Verificare un mittente legittimo con un risultato di autenticazione documentato rispetto alle opzioni globali e della voce effettivamente attive. Per Allow amministratore, mantenere Enforce Message Authentication attivo; per una prova controllata di Allow utente, usare l’opzione Prevention of spoofing of allowed address disponibile e attiva. Possono essere saltati solo i controlli documentati per ciascun caso; la scansione antimalware rimane attiva. Un singolo SPF pass non dimostra una corrispondenza Allow riuscita con una valutazione DMARC più rigorosa.
Autenticazione non riuscita: In questa configurazione di prova protetta, un messaggio controllato per cui falliscono tutti e tre i controlli non deve beneficiare dello stato Allow e deve subire tutte le scansioni. Verificare anche il fallimento DMARC con una policy diversa da p=none se previsto dalla prova autorizzata. Senza una configurazione di prova Allow utente verificabile, la convalida resta aperta; non disattivare alcun controllo di protezione per forzare la consegna.
Block e più destinatari: Per gli elenchi Block personali, provare nello stesso messaggio un destinatario interessato e uno non interessato e documentare separatamente entrambe le azioni. Verificare anche accettazione o rifiuto SMTP solo con accesso autorizzato, non dalla sola consegna.
CSV: Confrontare quantità, azione, valore, Description e assegnazione utente con il file sorgente e il backup. Controllare anche campioni all’inizio e alla fine dell’elenco.

In Message History registrare ora, mittente della busta, From visibile, IP client, destinatario, risultati di autenticazione e azione. La sola consegna non dimostra che la voce Allow sia stata applicata: il messaggio potrebbe aver superato le scansioni normali.

Risolvere i problemi e mantenere le eccezioni

Allow non funziona: confrontare mittente della busta e From con la voce, poi verificare priorità amministratore, opzioni della voce e DMARC/SPF/DKIM. La scansione normale è intenzionale quando l’autenticazione obbligatoria fallisce. Se l’effetto di Allow utente non è chiaro, documentare anche lo stato effettivo della protezione dallo spoofing; non aggirare il conflitto documentale descritto disattivando le protezioni.
Block interessa solo alcuni destinatari: controllare assegnazioni e caso con più destinatari. Una regola amministratore in conflitto ha la precedenza.
Wildcard o CIDR funziona male: controllare sintassi e prefisso. Sono documentati solo /16–/32; gli elenchi utenti non supportano IP/CIDR o wildcard. Rimuovere la voce ampia fino al chiarimento.
Importazione assente o errata: controllare scheda, dimensione file, limite utente, modello, colonne di esportazione aggiuntive, descrizioni troncate e codifica visibile. Non riprovare con Replace existing list with this import prima di conoscere la causa e verificare il backup.
Un messaggio legittimo resta bloccato: confrontare elenco amministratore, elenco personale, indirizzo busta/intestazione e IP client; poi esaminare autenticazione e Message History. Non creare come scorciatoia una seconda voce Allow più ampia.

Almeno ogni trimestre e a ogni cambio di proprietario, confrontare elenco, ticket ed esigenza aziendale. Dopo l’approvazione eliminare eccezioni scadute, senza proprietario, duplicate o troppo ampie e ripetere test con e senza corrispondenza. Se la causa resta incerta, annullare la nuova voce ed eseguire l’escalation con ID messaggio, data e ora, esportazione, riga interessata e risultati di autenticazione, senza divulgare contenuti riservati o elenchi di produzione completi.