Tutti i sistemi di posta elettronica sui public cloud più famosi gestiscono l’attendibilità delle email tramite i protocolli SPF, DKIM e DMARC. E’ importante configurare questi protocolli per rendere le nostre email attendibili ma anche eseguire controlli stringenti sui domini dei nostri interlocutori. Quando si implementano sistemi esterni di antivirus ed antispam capita che si rompano le verifiche SPF e DKIM, quindi anche DMARC; il protocollo ARC, standardizzato nel 2019, ci aiuta a gestire efficacemente questo effetto indesiderato.
Le architetture postali
Quando un interlocutore ci vuole consegnare una mail utilizzerà i record MX sulla zona DNS per scoprire l’indirizzo ip pubblico dei nosti server di posta. Alla ricezione effettueremo i controlli SPF e DKIM per verificare se le email sono attendibili. Questi controlli possiamo effettuarli una sola volta nell’unico server di ricezione oppure possiamo demandare ad un servizio esterno il filtraggio della posta in ingresso. Nel secondo caso l’antispam esterno, dopo aver controllato la posta, dovrà inoltrarla alle caselle postali che si trovano su un altro sistema, nel nostro caso Microsoft365. La situazione è resa molto più complessa quando alcuni domini di posta del tenant vengono intermediati dall’antispam ed altri no, magari perchè siamo in fase di migrazione, oppure se anche la posta in uscita deve passare dall’antispam; con o senza il dominio nativo mittente degli NDR: azienda.onmicrosoft.com. Per sintetizzare, avere un intermediario di posta tra il mondo e Microsoft365 necessità di molta attenzione e precise configurazioni.
Quando falliscono i protocolli SPF, DKIM e DMARC
Il protocollo SPF pubblica gli indirizzi ip che sono legittimati a spedire posta per un certo dominio. Quando riceviamo la posta in un antispam esterno e la inoltriamo alle caselle postali in Exchange OnLine (EOL) su Microsoft365 quest’ultimo vede arrivare tutte le email con gli indirizzi mittente tramite un IP che non è presente negli SPF dei nostri interlocutori. In pratica tutte le email in ricezione saranno considerate spoofing con SPF=fail. Il protocollo DKIM, solo se implementato dai nostri interlocutori, ci aiuta a sopperire a questo problema perchè ogni email viene firmata ed EOL può verificarla quando SPF fallisce. Molti antispam però modificano il corpo delle email e dell’header per aggiungere footer o informazioni “spezzando”, di fatto, la firma DKIM. Quando entrambi i protocolli SPF e DKIM saltano anche il DMARC fallisce e tutte le mail in arrivo vengono rigettate, finiscono i quarantena o, nella migliore delle ipotesi, le troviamo nella posta indesiderata. Per correre ai ripari si creavano regole massive di accettazione su EOL, eccezioni sconsiderate che aprivano la strada agli attaccanti. L’ideale sarebbe riuscire a “congelare” il controllo DMARC sull’antispam e riportarlo ad EOL facendo in modo che questo venga incorporato nei controlli come se lo facesse esso stesso. A questo serve il protocollo ARC.
Cos’è il protocollo ARC
Letteralmente significa “Authenticated Received Chain” e permette di trasferire al server destinatario le verifiche dei protocolli SPF, DKIM e DMARC operate dal server intermedio. E’ un protocollo pensato espressamente quando ci fidiamo di un interlocutore che filtra le email in ingresso sui nostri sistemi e NON va pensato ed usato per garantire le nostre email nei confronti degli interlocutori esterni.
Dal punto di vista pratico il server intermedio (l’antispam nel nostro esempio) aggiunge all’header della mail 3 campi:
– ARC-Authentication-Results (AAR): contiene i risultati dell’autenticazione SPF, DKIM e DMARC per il messaggio originale (positiva quando c’è il valore oda=1).
– ARC-Seal (AS): contiene la firma ARC del server intermedio includendo l’identificativo del server (è un nome di dominio che andrà poi configurato come fidato in M365).
– ARC-Message-Signature (AMS): contiene la firma, molto simile al DKIM, per garantire che il messaggio è immutato dopo il passaggio dal server intermedio.
Come si configura ARC in Microsoft365
La prima cosa da fare è configurare e controllare l’identificativo del server intermedio (AS) usato per la firma (AMS) sul nostro antispam. In genere è un nome di dominio di secondo o terzo livello. Questo nome di dominio va poi inserito in questo pannello di configurazione della sicurezza di Microsoft365. A questo punto il selettore usato per la verifica della firma ARC (AMS) presente nel dominio specificato renderà la mail attendibile in Exchange Online (compauth=pass reason=130).
Funzionamento di ARC in sintesi
- Il mittente del messaggio originale applica le firme di autenticazione (SPF, DKIM, DMARC) come di consueto.
- Il server che riceve il messaggio e lo inoltra, aggiunge una firma ARC al messaggio.
- Questa firma ARC include informazioni come l’identificatore del server che ha aggiunto la firma e il suo indirizzo IP.
- Il messaggio viene inoltrato attraverso altri server intermedi, che possono aggiungere ulteriori firme ARC.
- Alla fine, il server di consegna finale verifica tutte le firme ARC nel messaggio, risalendo lungo la catena, per confermare l’autenticità delle firme di autenticazione originali.
Conclusioni
Il protocollo ARC consente ai destinatari di verificare le firme di autenticazione originali, anche se il messaggio è stato inoltrato attraverso più server intermedi. I grandi provider di posta (Microsoft e Google tra tutti) hanno una fiducia reciproca negli inoltri effettuati col protocollo ARC tramite i loro server cloud di frontiera; ecco perchè si possono creare redirezioni facilmente con consegne garantite. I siti di reportistica DMARC evidenziano i report che usano ARC nella sottocategoria Forwarders.
E’ fondamentale quindi usare ARC in ricezione solo se ci si fida della controparte (il proprio antispam, azienda partner, mailing-list) e MAI per fidarsi genericamente di fonti di spedizione altrui o, ancora peggio, pensare di rendere le proprie email attendibili verso gli altri.
Configurare ARC in M365
Approfondire i Trusted ARC Sealers in M365