Falsificazione delle email è una delle tecniche usate dai malintenzionati per convincerti che la loro email di spam/phishing sia legittima. In breve, la falsificazione delle email viene utilizzata da questi agenti malevoli per far sembrare che le loro email provengano da fonti fidate come la tua banca, il tuo prodotto preferito o il tuo capo.

I protocolli email sono con noi da molto tempo. Simple Mail Transport Protocol (SMTP), il principale protocollo su cui si basano le comunicazioni email, risale al 1981. Internet è cambiato molto, purtroppo le email non tanto. Quando è stata creata l'email, c'era solo una frazione degli utenti di oggi. All'epoca non c'era molto danno nell'inviare un'email falsa. Ora, le email vengono utilizzate per quasi tutti i servizi digitali che puoi immaginare e la tecnologia ha lentamente recuperato terreno.

Iniziamo a parlare di come funzionano le email, così siamo tutti sulla stessa lunghezza d'onda. Sii paziente, questa è una semplificazione estrema di come funziona l'email, ma mi aiuterà a spiegare i meccanismi per rendere questo processo sicuro. In linea generale, quando qualcuno invia un'email, funziona così:

1. Alice (hi@alice.com) scrive un'email a Bob (hi@bob.com).
2. Alice invia l'email al suo server di posta per la consegna.
3. Il server di posta di Alice localizza il server di posta di Bob e trasmette l'email.
4. Ogni volta che Bob si connette al suo server di posta, chiede nuovi messaggi e una nuova email appare nella sua casella di posta.

Facile! Tuttavia, molte cose possono andare storte nel processo di invio di un'email. Approfondiamo!

Sender Policy Framework (SPF)

Oh, ma Internet è pieno di orrori. Immaginiamo che ci sia un attore malvagio, chiamiamolo Chuck, che vuole ingannare Bob per fargli inviare la sua password di Harvest.

Esatto, il semplice SMTP non ci dice se chi invia un'email è chi dice di essere.

Per proteggere le nostre email da questo tipo di attacco, possiamo utilizzare Sender Policy Framework (SPF). Quando un server di posta riceve una nuova email, chiede al dominio di origine se il mittente è autorizzato a inviare email a nome loro. Questo è ciò che fa SPF; quando il server di posta di Bob riceve un'email che sembra provenire da alice.com, prima chiederà a alice.com se il vero mittente, chuck.com, può inviare qualcosa a nome loro.

Nell'immagine sopra, puoi vedere che il server di Bob esegue una richiesta DNS. Questa tecnica e tutte le altre in questo post si basano su questo protocollo. Quando parlo del server di posta di Bob che chiede a alice.com alcune informazioni, significa semplicemente inviare una richiesta DNS a alice.com cercando record specifici.

Se alice.com non ha elencato chuck.com come uno dei suoi mittenti autorizzati, allora il server di posta di Bob potrebbe contrassegnare l'email come spam. Hai sentito bene, potrebbe farlo o potrebbe non farlo. Il server di Bob ha sempre l'ultima parola e ci sono altri controlli da eseguire prima di prendere una decisione finale.

DomainKeys Identified Mail (DKIM)

Le email dovrebbero essere sicure ora, giusto? Beh... non del tutto. Abbiamo impedito a Chuck di inviare email false dai suoi server, ma cosa succederebbe se trovasse un modo per intercettare le email in transito? E se fosse in grado di cambiare il contenuto dei messaggi di Alice? Ricorda, SPF verifica solo che il mittente sia autorizzato a inviare email a nome suo, ma non dice nulla su cosa succede lungo il percorso verso il destinatario.

Questo è lo scenario perfetto per utilizzare le firme. Nel mondo digitale, una firma è un meccanismo per garantire e verificare che il contenuto di ciò che viene consegnato non sia cambiato. Quando Alice invia un'email a Bob, ora il server di posta di Alice aggiungerà una firma al contenuto dell'email. Se qualcuno cambia anche solo un bit di quel messaggio, Bob lo saprà. Inoltre, solo il server di posta di Alice sa come creare queste firme. Nessun altro può farlo senza che il destinatario se ne accorga.

Questo è esattamente ciò che fa DomainKeys Identified Mail (DKIM). In pratica, la configurazione di DKIM inizia nel server di posta di Alice:

• Di solito c'è un modo per "iniziare ad autenticare" le email inviate. Di solito significa semplicemente abilitare DKIM.
• Il server di posta ti chiederà di pubblicare alcune parole criptiche nel tuo DNS; quella è la chiave pubblica della tua firma. In parole semplici, la chiave pubblica consente ad altri di verificare che una firma ricevuta sia valida e che il messaggio non sia stato modificato in transito. Il server conserva la chiave privata in modo che sia l'unico in grado di creare firme.
• Una volta pubblicata la chiave pubblica, il server di posta inizierà a inviare una firma con ogni nuova email.

Come è utile la firma? Quando il server di posta di Bob riceve un'email con una firma allegata, può convalidare che la firma sia corretta. Per farlo, il server deve recuperare la chiave pubblica e il contenuto dell'email. Con solo queste due cose, il server può rilevare se ci sono state modifiche indesiderate.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Ora Bob può essere abbastanza sicuro che le email provengano da una fonte fidata e che non siano state manomesse, giusto? GIUSTO?... Se solo fosse così facile... Chuck, il nostro personaggio malvagio, può ancora modificare il contenuto dell'email e semplicemente eliminare la firma DKIM. Chi ha bisogno di quella comunque? È meglio avere un controllo neutro piuttosto che uno negativo.

Tuttavia, non è tutto perduto. Abbiamo solo bisogno di un modo per dire al server di posta di Bob quali misure di sicurezza sono state configurate e una politica che definisca cosa fare se qualcuna di esse fallisce. Andiamo con il nostro ultimo acronimo: Domain-based Message Authentication, Reporting and Conformance (DMARC).

Con DMARC, il server di posta di Bob ha un punto pubblico di informazione che definisce cosa fare con le email che riceve. Più specificamente, un record DMARC descrive:

• Se SPF o DKIM sono applicati nell'email ricevuta
• Un indirizzo email per la segnalazione a scopo di monitoraggio
• Una politica per decidere cosa fare quando c'è un controllo fallito. Ci sono 3 politiche diverse:
• Nessuna politica - I risultati del controllo DMARC verranno ignorati. Tuttavia, i server di posta invieranno report per ulteriori analisi. Questo viene spesso utilizzato durante la configurazione di DMARC per vedere se funziona come previsto.
• Quarantena - Le email che falliscono qualsiasi controllo DMARC verranno inviate alla cartella spam del destinatario.
• Rifiuta - Le email che falliscono qualsiasi controllo DMARC non raggiungeranno il destinatario.

DMARC è l'ultimo pezzo del nostro toolbox, ed è l'unico che dice specificamente ai server di posta di scartare le email non conformi, e in quali circostanze ciò avviene.

Conclusioni

Siamo felici di dire che Harvest utilizza queste tecniche per proteggere le nostre email. Ci sono voluti mesi di apprendimento e raccolta dati fino a quando finalmente siamo arrivati dove siamo ora. Abbiamo reso davvero difficile per gli altri impersonarci e minare la reputazione di Harvest. Questo è stato un risultato incredibile che avrà un impatto positivo sui nostri clienti.