Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
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.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Accenno fin da subito che nel semplificare il più possibile i processi legati alla mail, alcuni dettagli saranno semplificati ed ommessi.
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:
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:
Il body invece contiene il messaggio vero e proprio.
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:
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 (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.
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 è un valore del tipo:
v=spf1 ip4:
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
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.
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
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:
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:
Per verificare la presenza del DMARC utilizzeremo invece questo link
https://mxtoolbox.com/SuperTool.aspx?action=dmarc
Una volta compreso questi metodi di autenticazione, potremmo fare un test di delivery utilizzando questo servizio
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
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.
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
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.
Manuel Roccon