SPF, DKIM e DMARC. Scopri Come Migliorare la Sicurezza delle Comunicazioni EMail

Manuel Roccon : 26 Settembre 2024 07:40

Nell’era digitale odierna, le email sono uno strumento essenziale per la comunicazione personale e professionale. 

Tuttavia, con l’aumento del volume di messaggi inviati e ricevuti ogni giorno, il fenomeno dello spam è diventato una minaccia sempre più pressante e un pericolo sempre maggiore per le aziende. Lo spam non solo intasa le caselle di posta, ma può anche rappresentare un rischio per la sicurezza, veicolando malware e phishing e coinvolge gli utenti, che solitamente rappresentano l’anello debole della sicurezza informatica.

In questo articolo parleremo di SPF, DKIM e DMARC, esploreremo le principali strategie per proteggere le email dallo spamming e far capire ai destinatari che le nostre mail siano affidabili.

Accenno fin da subito che nel semplificare il più possibile i processi legati alla mail, alcuni dettagli saranno semplificati ed ommessi.

Com’è composta una mail?

La mail è composta da 3 parti fondamentali: Envelope, Header e il Body.

Possiamo fin da subito dividere la busta(envelope) dalla lettera (che contiene header e body). Vediamo le differenze:

L’envelope (busta) è una parte invisibile sia al mittente (MAIL FROM) che al destinatario (RCPT TO). Viene utilizzata dai server di posta elettronica per gestire la consegna del messaggio.

Contiene informazioni tecniche come:

• Indirizzo del mittente e destinatario utilizzati dai server per instradare la mail
• Comandi SMTP che servono per le attività di consegna..

L’header (intestazione) di una mail contiene informazioni visibili e non visibili che sono cruciali per la consegna del messaggio.

Queste informazioni sono utili per tracciare l’origine e il percorso della mail, verificare l’autenticità del mittente e diagnosticare eventuali problemi di consegna.

I principali metadata del header sono:

• From: contiene informazioni sul mittente.
• To: mostra il nome e l’indirizzo e-mail del destinatario, inclusi tutti gli indirizzi e-mail nei campi CC (copia conoscenza) e CCN (copia conoscenza nascosta) .
• Subject: il titolo o l’argomento che il mittente imposta nella riga dell’oggetto.
• Return Path: campo obbligatorio che contiene l’indirizzo a cui il sistema invia un’email. Se non c’è reply-to, verrà utilizzato come indirizzo a cui i destinatari potranno rispondere.
• Reply-To: campo facoltativo che contiene l’indirizzo a cui i destinatari possono rispondere.
• Envelope-To: indica che un’e-mail è stata inviata all’indirizzo presente su questa riga.
• Data: timestamp di quando un client di posta elettronica ha inviato un’e-mail, solitamente segue il formato giorno, gg mese aaaa hh:mm:ss . Ad esempio, mer, 16 dic 2020 16:57:23.
• Received: vengono riportati tutti gli indirizzi che l’email ha attraversato durante l’invio da un MTA all’altro.
• Message-ID: un identificatore univoco di lettere e numeri creato quando si scrive per la prima volta un’e-mail.
• Versione MIME: la versione Multipurpose Internet Mail Extensions (MIME) è uno standard Internet che estende il formato e la funzionalità di un’email. Un’email può avere video, immagini e altri file allegati grazie a MIME.
• Content-type: dice se il mittente ha scritto l’email come testo normale o usando HTML.

Il body invece contiene il messaggio vero e proprio.

Cosa succede quando invii una e-mail?

Supponiamo che pippo [email protected] voglia inviare una mail a pluto [email protected].

Pippo comporrà la mail con il suo client di posta e la invierà a un server SMTP di invio, server configurato nel proprio client di posta per invio della posta in uscita confidato di solito assieme a quello di ricezione. 

Pensiamo a una persona che deve inviare una lettera a un destinatario, una volta compilata la consegnerà all’ufficio postale più vicino per farla arrivare a un destinatario, questo è il nostro SMTP configurato nel nostro client di posta!

Questo ufficio postale (smtp.pippo.acme) una volta accettata la mail, cercherà  di capire qual è l’indirizzo dell’ufficio postale del paese di destinazione (SMTP del destinatario) leggendo il envelope RCPT TO, ricavando il dominio del del destinatario (pluto.acme). Inoltre scriverà nel metadata Received il passaggio.

Per capire dove si trova l’ufficio postale del destinatario, l’ufficio postale mittente controllerà uno speciale record nel dominio pubblico di pluto.acme chiamato record MX (Mail Exchanger), un registro pubblico (pensiamo a una sorta di pagine gialle) in cui tutti possono consultare è presente l’indirizzo dell’ufficio postale del destinatario dovono essere inviate le mail per pluto.

In questo caso sarà una sorta di indirizzo come smtp.pluto.acme, quindi la mail verrà indirizzata qui.

Potrebbe inoltre accadere che la lettera passi da uffici postali intermedi (MTA), anche questi punti intermedi verranno scritti cronologicamente nel metadata Recived.

Una volta che la mail è arrivata all’ufficio postale di destinazione (smtp.pluto.acme), l’ufficio postale rimuoverà envelope e consegnerà la mail alla cassetta postale del destinatario. Anche questo aggiungerà un ultimo “Receiver” con le sue informazioni.

Capito questo meccanismo, sappiamo tutti che potrei sia consegnare la stessa lettera con lo stesso mittente a un ufficio postale diverso, magari a km di distanza, oppure Pippo potrebbe fare uno scherzo a Pluto cambiando il mittente in [email protected], in quanto l’ufficio postale non controllerà questo dato.

La lettera verrebbe comunque consegnata, il destinatario leggendo sempre i metadata potrebbe non accorgersi dell’errore e credere che sia stata effettivamente inviata da Minnie. 

Magari questo non è stato proprio un errore ma un tentativo di falsificazione, la nostra mail è diventata quindi una mail di spam o spoofing.

Infatti:

• È molto facile scrivere un indirizzo falso nel comando MAIL FROM nella comunicazione SMTP (nella busta dell’email)
• È molto facile scrivere un indirizzo falso nel metadata del header Da:
• Sia il mittente nel envelope che il mittente nel header possono essere falsificati
• L’indirizzo email del mittente nel header Da: può essere diverso da MAIL FROM della evelope

Come possiamo far capire al destinatario che la mail è falsa?

Autenticando la mail attraverso SPF e DKIM e ovviamente avere un antispam che possa fare queste verifiche.

Inoltre è necessario capire se qualcuno sta spedendo con il nostro dominio a ignari destinatari tramite il DMARC.

SPF

SPF (Sender Policy Framework) si occupa attraverso un record DNS pubblico, presente nel dominio del mittente, di identificare tutti gli IP pubblici autorizzati a spedire per conto del dominio mittente (tutti gli uffici postali autorizzati a ritirare e spedire la posta per pluto).

In poche parole SPF è una stringa, un record TXT, in cui sono inseriti la lista di host autorizzati a inviare che possono essere IP o FQDN.

Come funziona?

Quando l’ufficio postale di pluto riceverà la mail inviata da pippo, prima di accettarla e consegnala controllerà che l’ufficio postale di provenienza sia stato autorizzato del mittente, tramite questo record SPF che appunto contiene le informazioni dell’ufficio postale autorizzato, che il mittente ha dichiarato.

Se il mittente è pippo ma l’ufficio postale di provenienza è diverso da quello che ha dichiarato, pluto scarterà la mail. Questo vale per qualunque mail che pluto riceverà da qualsiasi mittente.

Questa attività di controllo in generale viene fatta da un antispam.

Spf nel dettaglio

Spf è un valore del tipo:

v=spf1 ip4: include: -all

Il record SPF è configurabile sia con indirizzi ip (esempio: v=spf1 ip4: -all) che con nomi di dominio (esempio: v=spf1 include: -all) che entrambi (esempio: v=spf1 include: ip4: -all), è possibile aggiungere anche piu host e IP assieme in quanto è ammesso sono un SPF per dominio.

L’ultimo parametro indicherà all’antispam di destinazione quale comportamento dovrà eseguire durante il controllo può variare in:

+all (Pass): se il controllo fallisce la mail verrà comunque recapitata

-all (Fail): se il controllo fallisce la mail non verrà consegnata

~all (Soft Fail): se il controllo SPF fallisce, l’email sarà consegnata al server di destinazione ma verrà contrassegnata come spam

?all (Neutral): Il controllo SPF sarà ignorato.

Per verificare la corretta configurazione del SPF possiamo usare il noto servizio web mxtoolbox.

https://mxtoolbox.com/SuperTool.aspx?action=spf

DKIM

Mentre l’obiettivo dell’SPF è verificare che la mail provenga da un server di invio affidabile, il DKIM (acronimo di DomainKeys Identified Mail) è un altro sistema di autenticazione che consente di impedire che il contenuto delle mail venga alterato durante la consegna.

Allo stesso tempo il destinatario potrà verificare che il messaggio ricevuto sia autentico e generato dal mittente senza alcun dubbio.

Torniamo ai nostri uffici postali. L’esempio più verosimile è che durante la spedizione, qualcuno apra la busta e scambi il messaggio originale con uno diverso.

Il mittente riceverà un messaggio diverso, controllando SPF il messaggio risulterà comunque  inviato da un ufficio postale autorizzato. Il mittente non riuscirà a riconoscere lo scambio effettuato e la considera valida.

Per questo è necessario il DKIM! Il DKIM può essere visto come il sigillo per verificare che la lettera non sia stata manomessa durante il viaggio.

Vediamo come funziona nel dettaglio.

Il DKIM si basa sulla crittografia a chiave pubblica/privata.

Il mittente prima di spedire con la propria chiave privata firma la mail e la inserisce nell’intestazione del messaggio in uno specifico metadata, come nel esempio.

dkim=pass [email protected] header.s=selector1 header.b=asdsdf4er;

Quando il destinatario riceve un’e-mail con DKIM, questo controlla la firma digitale per assicurarsi che sia valida tramite la chiave pubblica presente in un record TXT del mittente del suo DNS.

TXT selector1._domainkey

v=DKIM1; k=rsa; p=MIIBIjANBgkq…

Se la firma è valida, il messaggio è rimasto inalterato durante il trasferimento e quindi verrà accettato, in caso contrario sarà considerato spam.

La chiave pubblica è disponibile in un record TXT nel dominio pubblico, mentre quella privata la conosce solo il server del mittente che la userà per firmare la mail prima di inviarla. 

Qui una rappresentazione grafica del processo (fare attenzione ai colori di chiavi e lucchetti).

Anche in questo caso potremmo verificare la corretta presenza del dkim tramite il tool online

https://mxtoolbox.com/SuperTool.aspx?action=dkim

DMAC

Finché siamo i diretti destinatari, possiamo utilizzare i metodi visti prima  per dividere le mail buone da quelle cattive.

Ma se qualcuno sta spedendo utilizzando il nostro dominio ad altri destinatari ,non potremmo mai capire di essere vittime di questo attacco.

Esiste un sistema che potrebbe avvisarci di questa attività: il DMARC (Domain-based Message Authentication, Reporting and Conformance)

Il DMARC serve a contrastare le mail di spoofing, avvisando i destinatari di queste attività fraudolente.

Il DMARC aiuta i proprietari di domini ad avere un controllo migliore sulla loro attività di posta elettronica. Questo genera report sulle attività di posta elettronica di un’organizzazione che forniscono informazioni su dati che non possono essere trovati altrove. 

I rapporti includono le seguenti informazioni:

1. Origine della mail ricevuta
2. Numero di email autorizzate 
3. Numero di email non autorizzate
4. Destinatari dell’email

Nel DMARC sono inserite anche le azioni di default che l’antispam di chi ha ricevuto la mail deve eseguire una volta ricevuta la  mail non autentica (none, quarantine, rejected)

Esempio di un record DMARC:

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100; fo=1; rf=afrf; ri=86400; rua=mailto:dmarc_rua@examplecom; ruf=mailto:dmarc_ruf@examplecom

Vediamo i parametri:

• p: definisce le regole con le quali i server di posta di destinazione tratteranno le email (obbligatorio).
  • none: nessun avviso specifico sarà dato al server di posta di destinazione, 
  • quarantine: avvisa il server di posta di destinazione di trattare qualsiasi email che fallisce il test DKIM e/o SPF come sospetta ed esegue controlli aggiuntivi 
  • reject: avvisa il server di posta di destinazione di rifiutare qualsiasi email che fallisce il test DKIM e/o SPF

• rua: definisce l’elenco delle email alle quali viene inviato il report aggregato (obbligatorio).
• ruf: definisce l’elenco delle email alle quali viene inviato il report forense (obbligatorio).
• sp: indica le regole da applicare a tutti i sottodomini del dominio principale. (opzionale: se omesso il tag “p” coprirà il dominio principale e anche tutti i suoi sottodomini)
• adkim: specifica la “modalità di allineamento” per la firma DKIM. (opzionale il valore di default sarà adkim=r.)
• aspf: specifica la “modalità di allineamento” per il controllo SPF. (opzionale: se omesso il valore di default sarà aspf=r)
• pct: definisce la percentuale di email alle quali le regole del DMARC sono applicate. (opzionale: se omesso il valore di default sarà pct=100)
• fo: definisce le regole per quando deve essere generato il report DMARC. (opzionale: se omesso il valore di default sarà fo=0)
• rf: definisce il formato del report DMARC. (opzionale: se omesso il valore di default sarà rf=afrf)
• ri: definisce l’intervallo di tempo in secondi tra l’invio di un report DMARC e l’altro. (opzionale: se omesso il valore di default sarà ri=86400)

Per verificare la presenza del DMARC utilizzeremo invece questo link

https://mxtoolbox.com/SuperTool.aspx?action=dmarc

Facciamo un Test Finale

Una volta compreso questi metodi di autenticazione, potremmo fare un test di delivery utilizzando questo servizio

https://www.mail-tester.com

Otterremo un punteggio da 1 a 10 che ci indicherà quanto completa è la configurazione.

Non meno importante il check del header. Qualora avessimo una mail sospetta potremmo prelevare e verificare se i parametri siano configurati correttamente e la mail sia correttamente autenticata è possibile usare questo strumento:

https://mxtoolbox.com/EmailHeaders.aspx

GESTORI DMARC

Come abbiamo visto è possibile gestire le segnalazioni mail a un indirizzo interno, ma potrebbe essere difficoltoso da comprendere e difficile avere una visione d’insieme delle campagne e mail segnalate..

Esistono dei tool che ci semplificano la vita, i report DMARC verranno inviati a questi servizi online. 

Questi raccolgono questi dati, e li classificano, mostrandoli in modo semplice con dashboard grafiche.

Per citarne 2:

VALIMAIL: Valimail aiuta i professionisti IT e gli addetti al marketing non solo a implementare l’applicazione DMARC 4 volte più velocemente, ma anche a mantenerla, con una sicurezza maggiore rispetto a qualsiasi altra piattaforma di autenticazione e-mail.

https://www.valimail.com

CLOUDFLARE: Cloudflare DMARC Management aiuta a monitorare ogni origine che invia email dal dominio e a esaminare i report Domain-based Message Authentication Reporting and Conformance (DMARC) per ogni origine. I report DMARC aiutano a capire se i messaggi inviati dal tuo dominio superano l’autenticazione DMARC, l’autenticazione DKIM e i criteri SFP.

https://developers.cloudflare.com/dmarc-management

Conclusioni

Abbiamo visto come funziona l’invio di una mail e le tecniche per difendere noi e gli altri da quelle fraudolente che potrebbero arrivare e il motivo per cui dovremmo difenderci attraverso gli antispam, che effettuano questi controlli per noi.

Essendo le mail uno dei principali vettori di attacco, consiglio vivamente di fare un piccolo check su tutti i domini in possesso, che solitamente impiega qualche decina di minuti per ridurre questi rischi.

Una volta configurati correttamente, non è più necessario intervenire su questi parametri, a meno che non aggiungete nuovi server smtp di inoltro. In questo caso sarà necessario aggiungere il nuovo server di inoltro nel SFP e il nuovo selettore nel DKIM.

Se sono presenti domini che non inviano mail (ma magari hanno siti web o landing page), è bene configurare anche questi domini privi di autenticazione che potrebbero essere usati per campagne di phishing o spoofing.