La protezione della posta elettronica in Microsoft 365 è gestita da Defender for Office365. Nei vari livelli di protezione, in base alle licenze, agisce in maniera diversa nella gestione dell’evento malevolo ma ha sempre una grave lacuna: in alcuni contesti ignora le logiche del protocollo DMARC. Vedremo come governare questi eventi con un’opportuna regola di trasporto al fine di avere maggiore consapevolezza e controllo del nostro ambiente di posta.
Il DMARC
Il protocollo DMARC, già approfondito in articoli precedenti, è uno standard di autenticazione delle email che aiuta a proteggere i domini da email fraudolente. DMARC si basa su due protocolli esistenti: SPF e DKIM. Questi protocolli verificano che le email provengano effettivamente dai domini dichiarati.
Una delle principali funzionalità di DMARC è la possibilità per i proprietari dei domini di definire politiche su come gestire le email che non superano i controlli di autenticazione. Le opzioni includono la consegna (p=none), la quarantena (p=quarantine) o il rifiuto delle email (p=reject). Questo aiuta a prevenire che email di phishing raggiungano i destinatari. Google, Yahoo ed altri provider applicano seriamente questo protocollo e non accettano email rigettate dal protocollo DMARC. Microsoft 365 le accetta, anche se dice il contrario nei report DMARC, le tratta analizzandole per bene e non le consegna SOLO se la destinazione è una mailbox interna al tenant.
La vulnerabilità
Questo comportamento anomalo, per certi versi senza senso, ha diverse implicazioni:
Positive
- Permette ai filtri antispam di analizzare tutte le email in transito per migliorare la qualità di identificazione delle minacce.
- Permette, tramite opportuni connettori, di gestire i flussi di posta ibridi con ambienti di posta OnPrem anche se non configurati a dovere dal punto di vista dei protocolli SPF e DKIM.
- Permette di gestire le redirezioni di email con partner e caselle di posta esterne.
Negative
- Le redirezioni verso caselle di posta esterne NON sono protette in nessun modo. In altre parole, una mail dannosa che non andrebbe in consegna in una casella del tenant viene comune inoltrata ad un indirizzo esterno membro di una lista di distribuzione o frutto di una redirezione da mailbox interna.
- L’email dannosa rediretta viene sempre firmata col protocollo DKIM dal tenant e, ancora più grave, se il dominio fraudolento mittente è interno al tenant come “Accepted Domain”, la firma DKIM trasforma la mail falsa in mail autenticata. La spiegazione dettagliata del caso è già stata affrontata in un precedente articolo.
Se ho faticato per configurare il DMARC del mio dominio con p=reject, posso godere delle implicazioni positive controllando però le vulnerabilità?
Il controllo della vulnerabilità
Per evitare il caso peggiore indicato in precedenza, dove un’email fraudolenta col mio dominio mittente entra in Microsoft 365 e viene rediretta esternamente con firma DKIM valida, è necessario configurare una regola di trasporto (Transport Rule) solo se avete configurato il record DMARC nei vostri domini di posta interessati dalla regola.
Dall’Exchange Admin Center andare nel Mail Flow e poi Rules (Flussi di posta e Regole).
Creare una regola col nome preferito (es: Email spoofing da domini interni).
Da eseguire solo se il record MX dei vostri domini di posta punta al cloud Microsoft, non configurate nulla del genere se avete un antispam davanti a Microsoft 365.
Applicare la regola se:
‘Authentication-Results’ message header includes ‘dmarc=fail action=oreject’
Indica che tratterà le email in ingresso che hanno il protocollo DMARC del dominio di posta mittente in fail con p=reject. In Google e Yahoo verrebbero scartate. Indicate “action=oreject” solo se avete la p=reject del record DMARC altrimenti basta non inserire l’azione lasciando solo “dmarc=fail”.
Altra condizione da aggiungere:
The sender address includes any of these words ‘azienda.it’ or ‘miodominio.com’
Inserendo solo i domini interni abbiamo il pieno controllo del nostro ambiente di posta anche se sarebbe opportuno non avere alcun filtro ed applicare alla lettera il protocollo DMARC per tutti.
Azione da eseguire:
Send incident report to: ‘caselladimonitoraggio@miodominio.com’ with content: ‘AttachOriginalMail’
All’inizio è bene solo applicare la regola in monitoraggio tramite questa condizione e vedere cosa arriva nella casella di monitoraggio.
In seguito, dopo aver monitorato per bene, sostituire o aggiungere l’azione di blocco:
Delete the message without notifying anyone
In alcuni contesti è bene tenere entrambe le azioni per avere una copia del messaggio dannoso rigettato.
Per concludere, talvolta serve creare delle eccezioni:
The sender address includes any of these words ‘fax’ or ‘applicazione’
Da usare con parsimonia anche se le esigenze applicative potrebbero imporlo.
Con la configurazione di questa regola, in ambienti complessi, avrete la visibilità chiara ed inequivocabile degli attacchi subiti e delle errate configurazioni.
Conclusioni
Defender for Office 365 non è così sicuro come ce lo dipingono ma abbiamo tutti gli strumenti per monitorare e proteggere il nostro ambiente di posta dagli attacchi di impersonificazione. Implementare il protocollo DMARC è fondamentale per garantire al mondo la qualità delle nostre email e, con la regola descritta qui sopra, potremo monitorare e poi bloccare le email dannose che cercano di entrare nel nostro ambiente di posta evitando le redirezioni esterne dannose.