• Cloud, Guide, Microsoft 365, Sicurezza
• 17 Marzo 2020

L’e-mail è lo strumento più utilizzato dai criminali informatici per penetrare all’interno delle aziende.
I creatori dei ransomware e in generale dei malware fanno grande affidamento sulla curiosità dell’utente che prima o poi aprirà un documento malevolo, piuttosto che un sito web compromesso.
I danni però non sono sempre visibili immediatamente perché spesso i criminali infettano altri sistemi all’interno dell’azienda e, oltre a rubare i dati sensibili, sfruttando i mail server aziendali per le loro campagne di phishing. Questo comportamento porta ad un grosso danno d’immagine perché da visibilità pubblica a clienti e fornitori dell’avvenuta violazione di sicurezza, oltre all’inserimento dei server di posta in blacklist paralizzando anche l’invio delle e-mail regolari.
Una ulteriore possibilità è che se non adeguatamente protetto il dominio di posta aziendale venga falsificato anche senza che sia stata effettuata alcuna violazione dei sistemi aziendali; questo attacco di camuffamento prende il nome di spoofing.

Esistono diverse tecnologie per garantire la sicurezza e l’autenticità della posta aziendale e sono:

• Sender Policy Framework (SPF): È la tecnologia più semplice da implementare e permette di definire una lista di server autorizzati a spedire messaggi per conto di un determinato dominio di posta. Ha lo svantaggio di non prevenire il camuffamento dell’indirizzo del mittente all’interno del client di posta.
• DomainKeys Identified Mail (DKIM): È una tecnologia più complessa da implementare ma garantisce l’integrità, mittente incluso, del messaggio inviato. Consente all’infrastruttura di posta destinataria di un messaggio di verificare l’autenticità dell’infrastruttura mittente. Office 365 permette di implementare DKIM gratuitamente.
• Domain-based Message Authentication, Reporting and Conformance (DMARC): Sfrutta le potenzialità di SPF e DKIM per proteggere la posta elettronica, estendendole. Permette all’infrastruttura di posta mittente di definire delle policy per i mail server destinatari dei messaggi che non superano la validazione di SPF e DKIM, e di ricevere dei report contenenti la lista dei messaggi ricevuti ogni giorno.
  Aggregando questi report è possibile determinare se il dominio di posta è sottoposto a spoofing (il camuffamento degli indirizzi mittenti) o spam.
  È possibile implementare in maniera gratuita DMARC per i clienti di Office 365 grazie ad una partnership con Valimail.

In questo articolo esamineremo tutte e tre le tecnologie.

Sender Policy Framework

SPF permette al proprietario di un dominio di specificare una lista di server di posta autorizzati a spedire.
I server di posta vanno elencati all’interno di un record DNS di tipo TXT che consiste essenzialmente in una stringa di testo.
La sintassi di un record SPF deve rispettare alcune regole:

• v=spf1: determina la versione di SPF, attualmente la versione 1 è l’unica presente
• include: serve a referenziare la policy SPF di un altro dominio, includendola. Nel caso di Office 365 vengono inclusi tutti i server di Exchange Online Protection.
• ip4: indirizzi IP di ulteriori server autorizzati
• a: nome completo (FQDN) di ulteriori server autorizzati
• all: è il meccanismo di matching
  • ~all: SPF SoftFail -> se la posta arriva da un server non indicato in SPF
    può venire accettata lo stesso
  • -all: SFP Fail -> se la posta arriva da un server non indicato da SPF deve essere rifiutata

Quando un server di posta destinatario riceve un messaggio per prima cosa verificherà se il dominio mittente ha un record SPF presente.
Se un record SPF è presente ed il messaggio è stato inviato da un server autorizzato allora verosimilmente consegnerà il messaggio, se invece arriva da un server invalido verosimilmente lo rifiuterà oppure lo consegnerà nella posta indesiderata. Il tipo di azione intrapresa dal server destinatario dipende dalla sua configurazione.

Questo meccanismo ha però dei limiti che sono intrinseci al protocollo SMTP.
Di seguito è riportato un esempio di colloquio SMTP tra due server:

Figura 1 – Colloquio SMTP

Il protocollo SMTP permette che il mittente indicato nel campo MAIL FROM: sia differente da quello indicato nel corpo della mail nel campo From:.
I client di posta visualizzano il campo From:, il comando MAIL FROM: viene normalmente utilizzato dal server di posta per popolare il Return-Path del messaggio, ovvero chi riceverà le risposte.
Questo è un meccanismo legittimo e necessario al funzionamento di SMTP.
Purtroppo benché il messaggio arrivi da un server indicato nel record SPF come attendibile nulla può contro il contenuto del messaggio manipolato in questa maniera in quanto manca lo strato di protezione addizionale che DKIM può fornire.
Quindi se un server di posta -qualsiasi nel mondo- viene compromesso SPF può solo agire in maniera marginale nella protezione di un dominio.

Nonostante queste limitazioni SPF rimane la prima linea di difesa e l’implementazione è molto facile: Office 365 genera automaticamente un record SPF ogni volta che viene aggiunto un dominio all’interno del portale di amministrazione.

Per verificare la corretta configurazione è sufficiente andare su https://admin.microsoft.com e da Settings -> Domains cliccando sul dominio che si vuole verificare premere check health

Figura 2 – Verifica dominio Office 365

Se quando è stato aggiunto il dominio a Office 365 sono stati creati correttamente tutti i record necessari allora apparirà il messaggio in figura 3

Figura 3 – Dominio Office 365 correttamente aggiunto

Viceversa, sarà necessario correggere ogni errore nel proprio DNS pubblico, come evidenziato nella figura 4

Figura 4 – Errori nella configurazione del dominio di Office 365

La procedura per creare un nuovo record nel DNS pubblico differisce tra i diversi provider e sarà necessario fare riferimento alla documentazione del gestore. Nella figura 5 è riportato un esempio di record SPF correttamente pubblicato in Azure DNS.

Figura 5 – Esempio di record SPF in Azure DNS

Per verificare la corretta implementazione di SPF è sufficiente mandare una mail ad un indirizzo di posta esterno e visualizzare gli headers del messaggio.
Nella figura 6 è riportato un esempio con il servizio Outlook.com

Figura 6 – Visualizza headers messaggio

Cercare all’interno dell’header del messaggio la stringa “spf=pass”

Figura 7 – Headers con SPF=PASS

Così SPF è stato implementato correttamente.

DomainKeys Identified Mail

DKIM consente a un dominio di associare il proprio nome a un’email mediante l’apposizione di una firma digitale.
Il processo di firma avviene tramite crittografia asimmetrica dove la chiave privata risiede sul server di posta mentre la chiave pubblica viene pubblicata in un record TXT all’interno del DNS pubblico.
La diffusione della chiave pubblica è necessaria in quanto permette ai server di posta riceventi di verificare la firma digitale aggiunta al messaggio.

NOTA: Non confondete DKIM con le soluzioni di firma digitale certificata come ad esempio la PEC, in quanto la PEC identifica in maniera sicura un singolo utente mentre DKIM serve per identificare una infrastruttura di posta e a prevenire gli attacchi di spoofing.

Con Office 365 è possibile utilizzare gratuitamente
DKIM, l’implementazione è del tutto trasparente e non richiede particolare pianificazione.

Per implementare DKIM come prima cosa è necessario creare nel DNS pubblico due record alias il cui scopo è quello di rendere disponibili su internet le due chiavi pubbliche utilizzate dal tenant. Queste due chiavi saranno identificate come selector 1 e selector2.
È necessario installare il modulo di Exchange Online PowerShell V2 (abbreviato come modulo EXO V2), che consente agli amministratori di connettersi all’ambiente di Exchange Online in Office 365 per recuperare i dati, creare nuovi oggetti, aggiornare gli oggetti esistenti, rimuovere oggetti e configurare Exchange Online e le sue caratteristiche.

Aprire Windows PowerShell come amministratore e digitare i seguenti comandi:

Una volta installato il modulo EXO V2 è possibile collegarsi ad Exchange Online, come mostrato in Figura 8

Figura 8 – Connessione a Exchange Online

Recuperare gli indirizzi dei selector tramite il comando

Figura 9 – Recuperare indirizzi DKIM selector

Una volta recuperati i due selector è necessario aggiungerli alla zona DNS pubblica del dominio di posta.
Andranno pubblicati due record di tipo CNAME con le seguenti caratteristiche:

• TTL = 1 ora (3600 secondi)
• Nome = selector1._domainkey
• Valore = Valore riportato da Windows PowerShell per Selector1CNAME
• TTL = 1 ora (3600 secondi)
• Nome = selector2._domainkey
• Valore = Valore riportato da Windows PowerShell per Selector2CNAME

Di seguito un esempio dei record correttamente pubblicati.

Figura 10 – DKIM Selectors in DNS

Una volta pubblicati in DNS è possibile abilitare DKIM su Exchange Online tramite il comando

Exchange Online verificherà la correttezza dei record DNS e inizierà a firmare i messaggi.

Figura 11 – Abilitazione DKIM

Si può verificare la corretta implementazione di DKIM allo stesso modo in cui si è fatto per SPF, cercando nell’header del messaggio la stringa “dkim=pass”

Figura 12 – Header con DKIM=Pass

Ora, DKIM è stato implementato correttamente.

Domain-based Message Authentication, Reporting and Conformance

DMARC permette di combinare le potenzialità di SPF e DKIM e di estenderle.

Il termine Domain-based Message Authentication, Reporting and Conformance implica tre differenti azioni:

Message Authentication: quando viene implementato DMARC un messaggio è soggetto al controllo dell’allineamento dei mittenti.
L’allineamento dei mittenti è la verifica che i campi “From” di header SMTP, SPF e DMARC
siano corrispondenti.
Nella figura 13 è riportato un header di un messaggio con DMARC allineato.

Figura 13 – DMARC Allineato

Reporting: Implementando DMARC è possibile richiedere ai server destinatari la generazione di rapporti sui messaggi che gli sono stati consegnati.
Questi rapporti prendono il nome di Aggregate Reports e sono in formato XML.
L’indirizzo di ricezione degli Aggregate Reports viene definito tramite il parametro rua=

Conformance: è possibile definire una policy sulla base della quale i server remoti accetteranno, metteranno in quarantena o direttamente rifiuteranno i messaggi che non passano il controllo DMARC.
La policy viene definita dal parametro p= che può assumere 3 valori differenti

• p=none -> nessuna azione viene intrapresa sui messaggi
• p=quarantine -> i messaggi vengono consegnati nella posta indesiderata oppure messi in quarantena sul server di posta
• p= reject -> i messaggi vengono rifiutati.

Per implementare DMARC in maniera gratuita sfruttando la partnership di Microsoft con Valimail è necessario richiedere Free Valimail Monitor for Office 365.
Entrare nella console di gestione e portarsi su Domains -> Add a Domain

Figura 14 – Dashboard Valimail

Inserire il nome del dominio che si desidera aggiungere e premere Add

Figura 15 – Aggiunta di un dominio a Valimail

Premere quindi su Not Configured

Figura 16 – Dominio aggiunto a Valimail

Si aprirà una pagina contenente un record TXT da aggiungere al DNS pubblico del dominio che si ha appena configurato nella console.
Il record che Valimail proporre di aggiungere ha valorizzata la policy con p=none, di conseguenza non bloccherà nessuna e-mail ma permetterà l’invio degli Aggregate Reports al servizio, fornendo visibilità sullo stato del dominio.

Figura 17 – Record TXT per DMARC

Procedere quindi alla creazione del record all’interno della zona DNS pubblica del dominio.

Figura 18 – Record TXT per DMARC aggiunto alla zona

Una volta creato il record in DNS è necessario attendere che i sistemi di Valimail inizino a ricevere gli Aggregate Reports, possono essere necessarie fino a 48 ore per visualizzare i primi risultati.

Nel rapporto mostrato in figura 19 è possibile osservare un dominio per il quale Valimail ha ricevuto dati negli ultimi 30 giorni.
Questo è un esempio di dominio non soggetto a spoofing, spam, utilizzato per phishing o attacchi di altro tipo, nessun Aggregate Report è stato ricevuto con e-mail scartate per mancato allineamento dei mittenti o firma non valida.

Figura 19 – Authentication Report Valimail

Se nella dashboard dovesse apparire traffico che Valimail segnala come spoofing (colonna Mostly Failing) ma si riconosce provenire da infrastrutture legittime allora si tratta di servizi configurati in maniera errata.
Questo è uno dei motivi per cui è importante non aver troppa fretta nel voler impostare immediatamente la policy DMARC su p=reject perché esiste la possibilità di bloccare traffico e-mail legittimo, come ad esempio quello di un fornitore terzo che fa campagne marketing per l’azienda oppure un CRM esterno.
In questi casi esistono differenti alternative:

• Mailing massivo: spostare il server od il fornitore che fa mailing massivo su un altro dominio, come ad esempio contoso-marketing.com.
  Questa è una buona pratica a prescindere dall’implementazione di DMARC in quanto si potrebbe venir catalogati come bulk mailer (chi manda e-mail in maniera massiva) da un provider di posta e avere impatti sulla consegna della posta ordinaria, se condividono lo stesso dominio.
• CRM/Sistema esterno: se il sistema è compatibile con DKIM allora implementare sia DKIM che SPF.
  DKIM offre la possibilità di pubblicare differenti selector nel DNS pubblico e ogni server di posta indica quello correntemente utilizzato quando firma una mail.
  Non ci sono controindicazioni nella convivenza di differenti infrastrutture di posta su un solo dominio.
  Se il sistema non è compatibile con DKIM allora è possibile utilizzare Office365 come e-mail relay a patto che invii una quantità ragionevole di posta.
  Microsoft non permette l’uso di Office 365 per campagne pubblicitarie.

Conclusioni

Proteggere il dominio di posta elettronica è critico e un dominio non adeguatamente protetto può essere fonte di danni considerevoli, sia in termini di continuità di servizio che di reputazione essendo la mail il mezzo di comunicazione più diffuso e su cui le persone fanno molto affidamento.
Un attaccante che decidesse di utilizzare il dominio aziendale per una campagna di phishing porterebbe ad un danneggiamento dell’immagine pubblica dell’azienda.

Circa il 90% delle frodi via email avvengono tramite un dominio falsificato, questo per sfruttare la naturale tendenza dell’essere umano e fidarsi di ciò che già gli è familiare o di una azienda con una buona reputazione (fonte: Spear Phishing:Top Threats and Trends)

L’implementazione congiunta di Sender Policy Framework, DomainKeys Identified Mail e Domain-based Message Authentication, Reporting and Conformance permette di proteggerlo.

In questo articolo sono state fatte volutamente delle semplificazioni per via della vastità dell’argomento, alle pagine Set up SPF in Office 365 to help prevent spoofing, Use DKIM to validate outbound email sent from your custom domain in Office 365, Use DMARC to validate email in Office 365 potete trovare ulteriori informazioni.

Raccomando anche la voce di Wikipedia relativa a Simple Mail Transfer Protocol che offre delle buone basi per comprendere il funzionamento del protocollo.