it-swarm-eu.dev

Perché è anche possibile creare l'intestazione del mittente nell'e-mail?

Con così tanti famosi provider di posta elettronica che costringono gli utenti ad accedere utilizzando i loro server SMTP, perché è ancora possibile creare l'intestazione "Da:" nelle e-mail? Cosa impedisce agli utenti di scartare semplicemente le e-mail in cui il dominio di origine del mittente non corrisponde al dominio del server SMTP?

23
d33tah

tl; dr

  • È molto facile falsificare un dominio anche con i controlli SPF abilitati.

  • La soluzione è utilizzare DKIM + DMARC, oppure SPF + DMARC

  • Il client di posta elettronica è responsabile di comunicarti se il messaggio supera la verifica DMARC Visualizza da

  • Il protocollo e-mail consente lo spoofing legittimo utilizzando le intestazioni Resent- * e Sender. Il client di posta elettronica (MUA) dovrebbe visualizzare questa eccezione ogni volta che esiste.

Ci sono alcune idee sbagliate su SPF, vale a dire:

  1. SPF non impedisce lo spoofing delle e-mail.
  2. Il solo SPF non influenza, influenza o controlla l'RFC 2822 Display From.
  3. Per impostazione predefinita, l'utilità di SPF è prevenire problemi di backscatter e scenari di spoofing molto semplici.

Microsoft ha tentato di risolvere questo problema con SenderID (rendendo SPF applicabile all'indirizzo Visualizza da) ma era troppo complicato e non ha risolto l'intero problema.


Alcuni retroscena

Per prima cosa sappi che ci sono due indirizzi "da" e due "a" in ogni messaggio SMTP. Uno è noto come busta RFC2821, l'altro è il messaggio RFC2822. Servono a scopi diversi

La busta: (RFC2821)

  • La busta sono metadati che non compaiono nell'intestazione SMTP. Scompare quando il messaggio passa al MTA successivo.

  • Il RCPT From: è dove andranno i rapporti di mancato recapito. Se un messaggio proviene da Postmaster o da un servizio di remailer, di solito è <> o [email protected]. È interessante vedere che salesforce usa questo simile a constantContact come chiave in un database come [email protected] per vedere se il messaggio è stato rimbalzato.

  • Il RCPT TO: è a chi viene effettivamente inviato il messaggio. È usato per gli utenti "to" e "bcc". Questo di solito non influisce sulla "visualizzazione degli indirizzi" nel client di posta, ma ci sono occasioni in cui gli MTA visualizzeranno questo campo (se le intestazioni RFC2822 sono corrotte).

Il messaggio (RFC2822)

  • La parte del messaggio inizia quando viene emesso il comando data.

  • Queste informazioni includono le intestazioni SMTP che conosci, il messaggio e i relativi allegati. Immagina che tutti questi dati vengano copiati e incollati da ciascun MTA al successivo, in successione fino a quando il messaggio non raggiunge la posta in arrivo.

  • È consuetudine che ciascun MTA preceda la copia e incolla sopra menzionata con informazioni sull'MTA (IP di origine, IP di destinazione, ecc.). Incolla anche i dettagli del controllo SPF.

  • Questo è il Display From è posto. Questo è importante. Gli spoofer possono modificarlo.

  • Il Mail From: nella busta viene scartato e solitamente inserito qui come return-path: indirizzo per i rapporti di mancato recapito

Quindi, come possiamo impedire alle persone di modificare Display From? Bene DMARC ridefinisce un secondo significato per il record SPF. Riconosce che esiste una differenza tra Envelope From e Display From e che esistono motivi legittimi per cui non corrispondono. Poiché SPF era originariamente definito per occuparsi solo di Envelope From, se Display From è diverso, DMARC richiederà un secondo controllo DNS per vedere se il messaggio è autorizzato da quell'indirizzo IP.

Per consentire scenari di inoltro, DMARC consente anche a Display From di essere crittografato in modo crittografico da DKIM, e se qualsiasi spammer o phisher non autorizzato dovesse tentare di assumere tale identità, la crittografia fallirebbe.

Che cos'è DKIM? DKIM è una tecnologia crittografica leggera che firma i dati che risiedono nel messaggio. Se hai mai ricevuto un messaggio da Gmail, Yahoo o AOL, i tuoi messaggi erano firmati DKIM. Il punto è che nessuno saprà mai che stai usando la crittografia DKIM e la firma a meno che non guardi nelle intestazioni. È trasparente.

DKIM di solito può sopravvivere a essere inoltrato e trasferito a diversi MTA. Qualcosa che SPF non può fare. Gli amministratori di posta elettronica possono utilizzarlo a nostro vantaggio per prevenire lo spoofing.


Il problema risiede nel fatto che SPF controlla solo la busta RFC2821 e non Display From. Poiché la maggior parte delle persone si preoccupa del Visualizza da mostrato in un messaggio e-mail, e non del rapporto di mancato recapito NDR, abbiamo bisogno di una soluzione per proteggere e proteggere questo pezzo.

È qui che entra in gioco DMARC. DMARC consente di utilizzare una combinazione di un controllo SPF modificato o DKIM per verificare Visualizza da. DKIM consente di firmare in modo crittografico il display da RFC2822 ogni volta che SPF non corrisponde a Display From (che si verifica frequentemente).


Le tue domande

Perché è ancora possibile creare l'intestazione "Da:" nelle e-mail?

Alcuni amministratori di server non hanno implementato le ultime tecnologie per impedire che questo genere di cose accada. Una delle principali cose che impediscono l'adozione di queste tecnologie è "servizi di inoltro di posta elettronica" come un software di mailing list, auto-spedizionieri o remailer di ex studenti (.forwarder). Vale a dire:

  1. SPF o DKIM non sono configurati.

  2. Non è stata impostata una politica DMARC.

  3. Il client di posta elettronica non sta visualizzando i risultati della verifica del campo Visualizza da e Risentito * * o Mittente.

Cosa impedisce agli utenti di scartare semplicemente le e-mail in cui il dominio di origine del mittente non corrisponde al dominio del server SMTP?

Cosa non corrisponde: la busta o il corpo? Bene, secondo gli standard di posta elettronica, la busta non dovrebbe corrispondere se passa attraverso un remailer. In tal caso, è necessario DKIM firmare Display From e assicurarsi che MUA lo verifichi.

Infine, il MUA (client di posta elettronica) deve mostrare se il mittente è verificato DMARC e se qualcuno sta cercando di sovrascriverlo con un'intestazione Sender o Resent-From.

27

Cosa impedisce agli utenti di scartare semplicemente le e-mail in cui il dominio di origine del mittente non corrisponde al dominio del server SMTP?

Niente. Sono autorizzati a farlo e molti lo usano per filtrare lo spam.

Come molte tecnologie con carenze di sicurezza, l'e-mail non è stata progettata pensando alla sicurezza e all'autenticazione. Lo scopo del campo "da" era più o meno lo stesso di una busta tradizionale con posta ordinaria. Per rendere l'e-mail utilizzabile alla luce delle necessità e degli abusi del 21 ° secolo, abbiamo dovuto aggiungere ulteriori elementi. In particolare, SPF risolve la prima parte della tua domanda:

Con così tanti famosi provider di posta elettronica che costringono gli utenti ad accedere utilizzando i loro server SMTP, perché è ancora possibile creare l'intestazione "Da:" nelle e-mail?

La soluzione è verificare l'intestazione/IP al momento della ricezione. Sebbene ciò non impedisca tecnicamente l'effettiva forgiatura dell'intestazione, rende meno utili le intestazioni forgiate.

6
B-Con

Esiste già una protezione parziale contro questo: https://en.wikipedia.org/wiki/Sender_Policy_Framework

Tutti i principali provider di posta elettronica lo utilizzano. Ma gestiscono gli errori SPF in modo diverso, alcuni provider di posta elimineranno totalmente i messaggi in base a tale controllo e alcuni provider li inseriranno semplicemente nella cartella spam.

Chiunque può creare il proprio server di posta elettronica e provare a inviare come chiunque.

Puoi controllare il tuo indirizzo Gmail (se ne hai uno) e aprire l'intestazione di qualsiasi e-mail e vedrai il risultato del controllo SPF in alto:

spf=pass (google.com: domain of *****@*****.com designates 174.**.**.** as permitted sender) smtp.mail=*****@*****.com;

4
sharp12345

[...] perché è ancora possibile creare l'intestazione "Da:" nelle e-mail?

SMTP è un protocollo progettato quando probabilmente si potrebbe nominare ogni macchina su Internet, e far funzionare una macchina che forniva posta era un affare relativamente grande, intrapreso da grandi organizzazioni e hobbiest molto dedicati. Non ha alcuna protezione integrata o sicurezza contro i cattivi attori e si fida praticamente di qualunque cosa tu gli dica.

Esistono anche numerosi motivi legittimi per cui potresti voler che l'intestazione "Da:" sia diversa dal tuo dominio - forse il tuo server di posta è condiviso con molti altri domini (come una società di hosting web/posta), nel qual caso il tuo la registrazione inversa (PTR) e la registrazione in avanti (A/MX) differiranno necessariamente.

Tuttavia, dato che la maggior parte degli utenti, nella maggior parte dei casi utilizzerà un servizio di posta che corrisponde al proprio dominio di posta; possiamo applicare un po 'di logica around SMTP. Questo porta alla tua prossima domanda:

Cosa impedisce agli utenti di scartare semplicemente le e-mail in cui il dominio di origine del mittente non corrisponde al dominio del server SMTP?

La risposta qui è niente , e la gente lo fa.

Esistono molti metodi per identificare lo spam come:

Problemi di classificazione come l'identificazione di spam/non spam sono principali aree di studio . Sfortunatamente, non è solo semplice come eliminare la posta che non proviene da dove ti aspetteresti (assisti all'enorme numero di messaggi spam provenienti dagli account Gmail agli account Gmail) e l'applicazione di tale regola probabilmente colpirà un enorme numero di ostacoli (nel caso in cui il server di posta sia in qualche modo condiviso); tu puoi tuttavia includi questo nella tua analisi del messaggio e fidati di esso meno, e una volta superato un certo livello di certezza, lascialo cadere.

Le e-mail avranno probabilmente sempre questo tipo di problemi di abuso in quanto sono intrinsecamente un sistema che consente alle persone di inviare e ricevere messaggi a chiunque abbia il minor attrito possibile. Per sua natura, consente alle persone che non conosci di inviarti messaggi che non ti aspettavi e, proprio come con il normale sistema di posta, questa è sia una cosa buona che una cattiva.

4
Bob Watson