Migliorare la sicurezza delle e-mail: Fermare la frode del mittente con SPF, DKIM e DMARC

Non si può filtrare la verità: è necessario proteggere la posta elettronica della vostra azienda.

Nel 2013, più di 100 miliardi di email aziendali sono state inviate e ricevute ogni giorno. Solo una su cinque di tutte le email inviate nel 2013 erano legittime, e il 92% di tutte le email illegittime includeva link a contenuti potenzialmente dannosi.

Ci sono comunque segni di miglioramento; questo mese è il primo degli ultimi 12 anni in cui meno della metà delle email dei clienti di Symantec erano spam.

Si possono ringraziare tre standard di sicurezza email (e altre iniziative) per la riduzione dello spam: SPF, DKIM e DMARC. Eppure, i rischi per la sicurezza sono prevalenti. Recentemente mi è stata raccontata la storia di un CFO che è stato oggetto di un tentativo di phishing. Il tentativo è fallito, ma se fosse riuscito, sarebbe costato all’organizzazione 50.000 dollari.

Per quanto riguarda questi standard di posta elettronica, c’è ancora molta confusione intorno ad essi. Spero di poter fare un po’ di chiarezza con questo post, oltre a guidarvi attraverso come implementare SPF, DKIM e DMARC.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, o SPF, è il vecchio della festa per l’autenticazione delle email. SPF è uno standard aperto che specifica un metodo per prevenire la falsificazione dell’indirizzo del mittente, secondo openspf.org. Non si tratta di fermare lo spam; si tratta di controllare e fermare i tentativi di falsificazione del mittente.

SPF ti permette di identificare le fonti di posta legittime del tuo dominio e impedisce alle fonti non autorizzate di inviare migliaia – o addirittura milioni – di email illecite dal tuo dominio.

Ci sono quattro tipi di abuso di email comunemente associati alla falsificazione del mittente:

• Spam (email di massa non richieste & email commerciali non richieste)
• Fraudatori (truffe 419)
• Malware (adware, zero days, virus, trojans, ecc.)
• Phishers (spear-phishing)

Non volete che il dominio della vostra organizzazione sia associato a nessuno di questi per ovvie ragioni. SPF vi aiuterà ad assicurarvi che le e-mail della vostra organizzazione provengano effettivamente da voi.

DomainKeys Identified Mail (RFC 6376, sostituisce RFC 4871 e RFC 5672 che sono ormai obsolete)

DKIM, o DomainKeys Identified Mail, è un record TXT pubblicato nel vostro Domain Name System (DNS). Implica qualcosa che tutti gli amministratori IT dovrebbero imparare ad amare: chiavi, chiavi pubbliche per essere specifici.

Prima di immergerci nel DKIM, è importante capire cosa sono le chiavi e come funzionano. Le chiavi, in questo caso la crittografia a chiave pubblica, consiste in una chiave pubblica (nota a tutti) e una privata (spesso chiamata segreta). Le chiavi pubbliche e private sono matematicamente legate l’una all’altra, rendendo possibile una comunicazione sicura su canali pubblici.

Queste chiavi sono come un sigillo antimanomissione su una busta trasparente. Non stai necessariamente nascondendo il messaggio; stai solo autenticando con il 100% di certezza sia il mittente che il messaggio.

Ora, torniamo a DKIM.

“Tecnicamente DKIM fornisce un metodo per convalidare l’identità di un nome di dominio che è associato a un messaggio attraverso l’autenticazione crittografica”, secondo dkim.org. In altre parole, DKIM usa le chiavi per assicurarsi che un mittente di e-mail sia chi dice di essere.

Con DKIM, vengono generate coppie di chiavi pubbliche e private per mantenere autenticati i server di posta e le comunicazioni. Ogni server SMTP (Simple Mail Transfer Protocol) in uscita ha bisogno della giusta chiave privata e del prefisso per corrispondere a un record DNS pubblico che il server di posta ricevente verifica.

Vi siete mai chiesti perché l’icona del lucchetto appare in Gmail quando ricevete messaggi da eBay, Paypal o dalla vostra banca? Questo è DKIM e un po’ di DMARC (di cui parleremo tra poco). Sotto, mailed-by mostra la corrispondenza SPF e signed-by mostra la corrispondenza DKIM. DKIM e DMARC non sono ancora essenziali, ma come IPv6, si stanno muovendo rapidamente dal laboratorio di prova al meglio.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, o Domain-based Message Authentication, Reporting, and Conformance, aiuta mittenti e destinatari a lavorare insieme per creare comunicazioni e-mail più sicure. DMARC è stato creato da un gruppo di organizzazioni per limitare l’abuso basato sulla posta elettronica “risolvendo un paio di problemi di lunga data operativi, di distribuzione e di segnalazione relativi ai protocolli di autenticazione delle e-mail”, secondo dmarc.org.

DMARC permette al mittente del messaggio di indicare che i suoi messaggi sono protetti con SPF e/o DKIM. Una politica DMARC applica istruzioni chiare per il destinatario del messaggio da seguire se un’e-mail non passa l’autenticazione SPF o DKIM – per esempio, rifiutarla o cestinarla.

Inoltre, DMARC invia un rapporto al mittente sui messaggi che PASSANO e/o NON passano la valutazione DMARC.

Come implementare SPF, DKIM e DMARC

Ora che abbiamo una migliore comprensione di ciascuno di questi tre standard (e perché sono importanti), diamo un’occhiata a come potete migliorare la vostra sicurezza e-mail implementandoli.

Nota: Per il bene di questa guida passo dopo passo, facciamo finta che tu sia il responsabile IT di 301 Moved, una piccola azienda di web design che usa Google Apps.

Di recente, hai avuto qualche problema con i bot di spam russi. I vostri utenti finali si sono lamentati di ricevere notifiche di rimbalzo delle e-mail da indirizzi che non hanno mai visto o a cui hanno inviato messaggi. Vi rendete conto che qualcuno sta chiaramente inviando email fraudolente dal vostro dominio.

Quindi come li fermate?

Nota: Sto includendo il formato standard BIND in testo semplice e uno screenshot di come appare il record in GoDaddy DNS. In GoDaddy, tutti i record per il dominio di primo livello 301Moved.com usano l’host “@,” il vostro host sarà probabilmente diverso. Per lo scopo di questo esercizio, discuterò solo la posta in uscita, non come trattiamo questi standard in relazione alla posta in entrata da mittenti esterni.

Implementare SPF

Passo Uno: la guida di Google per configurare i record SPF per lavorare con Google Apps è un buon punto di partenza. Seguendo queste istruzioni, aggiungiamo un nuovo record TXT al nostro Public DNS.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved usa anche Zendesk, un sistema di ticketing che invia email direttamente dal tuo dominio. È necessario assicurarsi che non venga inviato spam anche da lì.

Step Two: trovare e aggiungere il record SPF di Zendesk.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

È importante notare che non stiamo aggiungendo un secondo record SPF, che romperebbe le cose; invece, li stiamo combinando in un unico record, rendendolo più lungo quando vengono aggiunti più mittenti.

Nota: puoi aggiungere solo un record SPF per dominio o sottodominio.

Sai anche che 301 Moved ha un vecchio gateway email in sede che gestisce alcune cose legacy, quindi aggiungiamo anche il loro blocco IP. 301 Moved usa il meccanismo “IP4” per definire il blocco IP che possiede-198.51.100.0/24 (192.51.100.0-254).

Utilizza SPF Surveyor di Dmarcian per visualizzare i tuoi record SPF.

Fase tre: Aggiungere indirizzi IPv4 singoli per conto proprio, e netblock nella notazione Classless Inter-Domain Routing (CIDR). 198.51.100.0 per un singolo indirizzo IP (non c’è bisogno di un /32) e 198.51.100.0/24 per le sottoreti.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

L’aggiunta del vecchio gateway email assicurerà che le email in uscita dal gateway saranno autorizzate SPF.

I meccanismi sopra sono i più comunemente usati, ma ce ne sono otto in totale-inclusi quelli strani e deprecati. Questi meccanismi definiscono solo l’ambito della corrispondenza, non le azioni stesse.

I qualificatori nella prossima sezione sono dove PASS, SOFTFAIL e FAIL possono essere definiti: una corrispondenza risulterebbe in una delle tre azioni (PASS, SOFTFAIL e FAIL) innescata.

• ALL: Corrisponde a tutto ciò che non è già definito da un altro meccanismo.
• A: Se il nome di dominio ha un record di indirizzo (A o AAAA) che può essere risolto all’indirizzo del mittente, corrisponderà.
• IP4: Se il mittente è in un dato intervallo di indirizzi IPv4, corrisponderà.
• IP6: Se il mittente è in un dato intervallo di indirizzi IPv6, corrisponderà.
• MX: Se il nome di dominio ha un record MX che risolve all’indirizzo del mittente, corrisponderà (cioè la posta proviene da uno dei server di posta in entrata del dominio).
• PTR: Se il nome di dominio (record PTR) per l’indirizzo del cliente è nel dominio dato e quel nome di dominio risolve all’indirizzo del cliente (forward-confirmed reverse DNS), corrisponderà. Questo meccanismo è deprecato e non dovrebbe più essere usato.
• EXISTS: Se il nome di dominio dato si risolve a qualsiasi indirizzo, corrisponderà (non importa a quale indirizzo si risolve). Questo è usato raramente. Insieme al linguaggio macro SPF offre corrispondenze più complesse come DNSBL-queries.
• INCLUDE: Se la politica inclusa (un termine improprio) passa il test, questo meccanismo corrisponde. Questo è tipicamente usato per includere le politiche di più di un ISP.

Prossimo sono i qualificatori. Ci sono un milione di modi per combinarli con una lista nera e/o un modello di whitelist, ma per i nostri scopi qui, includeremo solo i tre meccanismi di ricerca di cui abbiamo parlato sopra con un singolo qualificatore alla fine per fare una whitelist. I nostri quattro qualificatori sono:

• + per un risultato PASS. Questo può essere omesso; ad esempio, +mx è lo stesso di mx.
• ? per un risultato NEUTRAL interpretato come NONE (nessuna politica).
• ~ (tilde) per SOFTFAIL, un aiuto di debug tra NEUTRAL e FAIL. Tipicamente, i messaggi che restituiscono un SOFTFAIL sono accettati ma etichettati.
• – (meno) per FAIL, la posta dovrebbe essere rifiutata (vedi sotto).

Step Four: Applicare la politica SOFTFAIL.

Per ora, 301 Moved usa la tilde per SOFTFAIL. Usando la tilde, tutta la posta che non corrisponde a Google, Zendesk o al blocco IP menzionato sarebbe SOFTFAIL. La posta sarà ancora consegnata, ma sarà probabilmente inviata alla cartella Spam o Junk. Tuttavia, questo dipende interamente dal server di posta del destinatario. Non è definito da nessuno standard.

Un “-” (meno) in questa situazione fallirebbe (e probabilmente respingerebbe) la posta che non corrisponde interamente. Puoi attivarlo una volta che inizierai ad avere più visibilità sulla tua posta in uscita (aspetta DMARC), e una volta che sarai più a tuo agio con la tua infrastruttura di posta.

SPF è ottimo perché non c’è nessuna modifica dei mailserver stessi. Le intestazioni rimangono le stesse. Solo un semplice record TXT (l’attuale tipo di record SPF dedicato non è mai stato molto popolare ed è ora deprecato) e puoi istruire la maggior parte dei mailserver del mondo su chi dovrebbe mostrare il tuo nome in giro.

Alla fine della giornata, il server SMTP ricevente controlla l’IP del mittente rispetto al tuo record SPF che ha interrogato, quindi applica la politica basata sulle tue istruzioni. In altre parole, stai autorizzando te stesso, e i tuoi provider, a inviare posta (per lo più) affidabile perché stai pubblicando una lista di controllo d’accesso (ACL) al pubblico.

Tuttavia, i messaggi possono ancora essere modificati in transito, e falsari e phisher furbi possono aggirare l’SPF in alcuni modi interessanti (forse un argomento per un altro giorno). È SMTP: TLS end-to-end non è garantito, quindi dobbiamo sempre assumere il testo in chiaro. I messaggi possono essere manomessi o falsificati.

Ma entra in scena a destra…

Implementazione delle DomainKeys Identified Mail

Quando la posta viene inviata, 301Moved.com firma (senza cifrare) la posta con la chiave privata. D’ora in poi, qualsiasi modifica al messaggio, compresi corpo, intestazioni o allegati, romperà la firma e renderà il messaggio non valido. Di nuovo, guardiamo a Google, usando il loro articolo Authenticate email with DKIM

Step Five: Aggiungi la chiave pubblica al tuo record DNS.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Ogni record DKIM ha un prefisso selettore unico, il che significa che possiamo pubblicarne più di uno. Invece di combinarli in un unico record, come abbiamo fatto con SPF, è possibile utilizzare selettori unici e pubblicare tutte le chiavi pubbliche di cui si ha bisogno. Questo ci permette di aggiungere un gran numero di server autorizzati DKIM senza alcun limite superiore.

Si noterà che il prefisso sopra è “google,” il default che Google Apps usa quando genera un record DKIM da pubblicare. Puoi cambiare questo in Google, e nella maggior parte delle altre configurazioni, quindi se vuoi il prefisso “dkimawesome,” non c’è niente che ti fermi.

Alcuni fornitori di cloud lo fanno in modo diverso. Invece di generare coppie di chiavi uniche per ogni inquilino del cloud, firmano tutta la posta in uscita per tutti i domini con la stessa chiave, facendovi invece pubblicare un nome canonico (CNAME) per la loro chiave.

Zendesk fa così, abbiamo CNAME due chiavi diverse sul nostro DNS al loro DNS. Zendesk ha un grande articolo di aiuto – Firma digitale delle tue email con DKIM o DMARC (Plus ed Enterprise)

Sesta fase (se applicabile): CNAME le chiavi sul tuo DNS al loro DNS. Qualsiasi query DNS che cerca zendesk1._domainkey.301Moved.com sarà reindirizzata dal tuo DNS a zendesk1._domainkey.zendesk.com. Zendesk quindi serve direttamente le chiavi DKIM.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Possiamo vedere come appare ad altri server usando lo strumento nslookup (per Unix o Windows) localmente.

Non tutti i mittenti in uscita supportano DKIM. Google Apps ovviamente lo fa, ma i vostri server di posta legacy potrebbero non farlo.

Implementare Domain-based Message Authentication, Reporting, and Conformance

DMARC, o Domain-based Message Authentication, Reporting, and Conformance, è lo strumento finale che abbiamo per combattere le email malevole. Per i server di posta che ascoltano, DMARC, rilancia come trattare SPF e DKIM, così come come come riferire a voi, dandovi la tanto necessaria visibilità sui vostri tassi di consegna e sulla conformità dei record.

E sì, DMARC è un altro record TXT.

Fase sette: Impostare una politica DMARC, identificare l’indirizzo mailto, impostare la modalità di allineamento e identificare la percentuale di messaggi a cui la politica dovrebbe essere applicata (non preoccupatevi, è più semplice di quanto sembri).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

La politica di cui sopra è designata come p=none. Non stiamo ancora modificando il flusso di posta, stiamo solo impostando la policy e la relativa segnalazione. L’indirizzo a cui saranno inviati i rapporti XML dello stato DMARC è designato con rua=.

I server di posta riceventi invieranno allegati XML che mostrano come i messaggi da – e quelli che dichiarano di provenire dal – vostro dominio si sono confrontati con il guanto di sfida SPF, DKIM e DMARC imposto dalla maggior parte dei moderni server di posta.

Questi rapporti mostrano, su una base per busta, se SPF è passato, fallito o softfailed. Mostrano se DKIM ha fallito, ha fallito l’allineamento o ha avuto successo, e come sono state applicate le politiche di cui sopra.

Infine, questi rapporti mostrano la disposizione finale di consegna del messaggio. Ci sono alcuni ottimi strumenti là fuori per aiutarvi ad analizzarli. Anche se non stai applicando politiche ai messaggi, è come i log di firewall, DNS e IDS/IPS – è sempre bene avere qualcosa che puoi tornare indietro e guardare.

L’adkim=r specifica la modalità di allineamento DKIM rilassato, “r” sta per rilassato e “s” sta per rigoroso. La modalità rilassata permette ai domini DKIM d= autenticati all’interno di un dominio organizzativo comune nell’intestazione della mail-From: di PASSARE il controllo DMARC. La modalità rigorosa richiede una perfetta corrispondenza tra il dominio DKIM d= e l’indirizzo header-From di una mail. Pensa ai sottodomini, se li usi.

aspf=r fa esattamente la stessa cosa, tranne che per i controlli SPF.

Il pct=100 è la percentuale di messaggi che sono effettivamente trattati secondo la politica DKIM. Scelta a caso, il server di posta ricevente applicherà la policy su questa percentuale di messaggi dal tuo dominio. Stiamo usando 100 per ora perché non stiamo applicando una policy, ancora.

Prima di applicare una policy, la limiteremo a cinque in modo che solo un messaggio su 20 abbia la policy applicata quando mettiamo il flag p= policy su quarantine o reject. In questo modo, se ci incasiniamo completamente, il 95% delle nostre email sarà comunque consegnato, invece dello 0% consegnato se iniziassimo con pct=100.

I messaggi che falliscono il controllo DMARC, o le vostre modalità di allineamento adkim= e aspf= che abbiamo impostato sopra sono quindi soft bounced, come sopra, per una policy di quarantena, o bounced interamente quando impostata su reject.

È molto importante notare che DMARC farà passare il messaggio se SPF o DKIM passano, e solo FAIL il messaggio se sia SPF che DKIM FAIL. In questo modo i messaggi solo SPF e DKIM possono PASSARE DMARC, ma i messaggi senza SPF/DKIM saranno sempre FAIL. Questa è una grande notizia se hai sistemi di posta che supportano solo SPF, o solo DKIM.

Usa DMARC Inspector di Dmarcian per controllare i tuoi record DMARC.

Dmarcian è uno strumento a pagamento che ti permette di gestire facilmente i tuoi rapporti DMARC, ce ne sono molti altri, ma Dmarcian è il mio preferito.

Aggiornamento: Abbiamo ricevuto alcune e-mail (conformi a DMARC!) che chiedono informazioni sulla politica del sottodominio sp=none. Con una policy che include sp=none non stai specificando una policy DMARC per nessun sottodominio. Questo viene fatto manualmente impostando un appropriato record DMARC per ogni specifico sottodominio o incluso nel record DMARC principale con un sp=quarantine o sp=reject.

Configurazione minima

Se vuoi provare, ti consiglio di iniziare in modo molto aperto e di rimanere semplice fino a quando non avrai abbastanza rapporti DMARC per iniziare a far rispettare qualcosa.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Definisci i grandi provider con un “include:” e qualsiasi blocco IP da cui puoi inviare posta con un “IP4” o “IP6”. Usate “MX” per autorizzare i vostri server di posta in entrata. E a meno che non inviate la posta direttamente dalla stessa casella/server che ospita il vostro sito web (cattiva, cattiva pratica a proposito) potete saltare il meccanismo “A” che è stato menzionato sopra. Il “?” non applica alcuna politica ai tuoi messaggi, ma fa sì che il tuo record SPF sia presente in modo che DMARC possa riconoscerlo.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Prendi il selettore corretto, “google” in questo caso, e la chiave giusta. Ricorda, puoi pubblicarne più di una.

Nota: Per favore non pubblicare questa chiave attuale o sarò in grado di firmare DKIM la tua posta.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Per DMARC, non abbiamo nessuna politica applicata, siamo in modalità rilassata, ma stiamo chiedendo che i rapporti XML siano inviati a una casella di posta elettronica a cui possiamo accedere. Da lì, DMARC ci dà un feedback abbastanza rapido (non in tempo reale) su come possiamo restringere le diverse politiche in tutti e tre i record.

Ma aspetta, e TLS?

Transport Layer Security, o TLS, non fa parte dello standard DMARC, e non è un record DNS.

Invece, TLS è solo un Secure Socket Layer (SSL) cresciuto che i server di posta possono usare per inviare messaggi tra loro su connessioni pubbliche. È SMTP avvolto in TLS, come si possono fare molte altre cose dentro/su TLS-SNMP su TLS e FTP su TLS sono esempi comuni. TLS cripta solo i messaggi in transito, non a riposo.

Se mandiamo un messaggio firmato DKIM su TLS, è firmato per tutta la sua vita, ma solo criptato mentre passa dalle vostre Google Apps al loro Cisco Ironport, o dovunque la vostra posta transiti. TLS certamente non protegge i messaggi a riposo, anche se è anche usato per la tua sessione HTTPS:// alla webmail mentre stai leggendo lo stesso messaggio, ma di nuovo, quello è in transito.

TLS è qualcosa che dovresti usare ovunque possibile, ma anche essere pronto a parlare in chiaro ad altri sistemi di posta pubblici. Anche nel 2015 alcuni server di posta non supportano STARTTLS (linguaggio dei server per iniziare l’handshake TLS).

È possibile imporre l’uso di TLS con alcuni domini esterni in Google Apps con un semplice cambiamento di configurazione. È una buona cosa da attivare per le aziende esterne associate, i partner e altre organizzazioni, ma applica TLS solo quando sei sicuro che sia affidabile e supportato da tutti i server di posta su quel dominio specifico.

L’importanza della sicurezza delle e-mail e di evitare le frodi dei mittenti

Che tu sia un amministratore IT veterano o un principiante, questi tre standard hanno la stessa importanza. Certamente, ciò che ciascuno di essi fa e come lavorano insieme può diventare un po’ disordinato, ma la loro implementazione è relativamente semplice e i benefici valgono bene il vostro tempo.