Cum un e-mail falsificat a trecut de verificarea SPF și a ajuns în căsuța mea de e-mail

Acum douazeci de ani, Paul Vixie a publicat o Cerere de comentarii pe Se respinge MAIL FROM care a ajutat la stimularea comunității internetului să dezvolte un nou mod de a lupta împotriva spam-ului cu Cadru de politici ale expeditorului (SPF). Problema atunci, ca și acum, era că Protocol de transfer simplu prin poștă (SMTP), care este folosit pentru a trimite e-mailuri pe internet, nu oferă nicio modalitate de a detecta domeniile de expeditori falsificate.  

Cu toate acestea, atunci când folosesc SPF, proprietarii de domenii pot publica înregistrări ale sistemului de nume de domeniu (DNS) care definesc adresele IP autorizate să folosească numele lor de domeniu pentru trimiterea de e-mail. La capătul de primire, un server de e-mail poate interoga înregistrările SPF ale aparent domeniul expeditorului pentru a verifica dacă adresa IP a expeditorului este autorizată să trimită e-mail în numele acelui domeniu. 

E-mail SMTP și prezentare generală SPF 

Cititorii familiarizați cu mecanismele de trimitere a mesajelor SMTP și cu modul în care SPF interacționează cu acestea ar putea prefera să omite această secțiune, deși este scurtă din fericire. 

Imaginează-ți că Alice la example.com dorește să trimită un e-mail lui Bob la exemplu.org. Fără SPF, serverele de e-mail ale lui Alice și Bob s-ar angaja într-o conversație SMTP, ceva de genul următor, care este simplificată folosind HELO mai degrabă decât EHLO, dar nu în moduri care modifică semnificativ constructele de bază: 

Acesta este modul în care a avut loc trimiterea și primirea de e-mail pe internet (SMTP). de la începutul anilor 1980, dar are – cel puțin după standardele internetului de astăzi – o problemă majoră. În diagrama de mai sus, Ciad la exemplu.net s-ar putea conecta la fel de ușor la exemplu.org Server SMTP, angajați-vă în exact aceeași conversație SMTP și primiți un mesaj de e-mail aparent de la Alice la example.com livrat lui Bob la exemplu.org. Mai rău, nu ar exista nimic care să indice înșelăciunea lui Bob, cu excepția poate adreselor IP înregistrate alături de numele gazdelor în antetele mesajelor de diagnosticare (nu sunt afișate aici), dar acestea nu sunt ușor de verificat de către neexperti și, în funcție de aplicația clientului dvs. de e-mail , sunt adesea greu de accesat. 

Deși nu au fost abuzate în primele zile ale spam-ului prin e-mail, pe măsură ce spam-ul în masă a devenit un model de afaceri consacrat, deși meritat disprețuit, astfel de tehnici de falsificare de e-mail au fost adoptate pe scară largă pentru a îmbunătăți șansele ca mesajele spam să fie citite și chiar luate în considerare. 

Înapoi la ipoteticul Ciad la exemplu.net trimiterea acelui mesaj „de la” Alice... Asta ar implica două niveluri de uzurpare a identității (sau falsificare) în care mulți oameni consideră acum că pot sau ar trebui făcute verificări tehnice automate pentru a detecta și bloca astfel de mesaje de e-mail falsificate. Primul este la nivelul plicului SMTP, iar al doilea la nivelul antetului mesajului. SPF oferă verificări la nivel de plic SMTP și, ulterior, protocoale anti-falsificare și autentificare a mesajelor extensia dkim și DMARC oferă verificări la nivelul antetului mesajului. 

Funcționează SPF? 

Conform unuia studiu publicat în 2022, aproximativ 32% din cele 1.5 miliarde de domenii investigate aveau înregistrări SPF. Dintre acestea, 7.7% aveau sintaxă invalidă și 1% foloseau înregistrarea PTR depreciată, care indică adresele IP către nume de domenii. Adoptarea SPF a fost într-adevăr lentă și greșită, ceea ce ar putea duce la o altă întrebare: câte domenii au înregistrări SPF prea permisive?  

Cercetări recente au fost găsite că numai 264 de organizații din Australia aveau adrese IP exploatabile în înregistrările lor SPF și, astfel, ar putea, fără să vrea, să creeze terenul pentru campanii de spam și phishing la scară largă. Deși nu are legătură cu ceea ce a descoperit cercetările, recent am avut propria mea perie cu e-mailuri potențial periculoase care au profitat de înregistrările SPF configurate greșit. 

E-mail falsificat în căsuța mea de e-mail 

Recent, am primit un e-mail care pretindea a fi de la compania franceză de asigurări Prudence Créole, dar avea toate semne distinctive ale spamului și falsificarea: 

 

Deși știu că falsificarea antetului mesajului De la: adresă al unui e-mail este trivială, curiozitatea mi-a fost trezită când am inspectat anteturile complete de e-mail și am constatat că domeniul din plicul SMTP MAIL FROM: adresa reply@prudencecreole.com a trecut de verificarea SPF: 

Așa că am căutat înregistrarea SPF a domeniului prudencecreole.com: 

Acesta este un bloc imens de adrese IPv4! 178.33.104.0/2 conține 25% din spațiul de adrese IPv4, variind de la 128.0.0.0 la 191.255.255.255. Peste un miliard de adrese IP sunt expeditori aprobați pentru numele de domeniu Prudence Creole – paradisul spammer-ului. 

Doar pentru a mă asigura că nu glumesc, am configurat un server de e-mail acasă, mi-am atribuit o adresă IP aleatorie, dar eligibilă, de către furnizorul meu de servicii de internet și mi-am trimis o falsificare de e-mail. prudencecreole.com:  

Succes! 

În plus, am verificat înregistrarea SPF a unui domeniu dintr-un alt e-mail de spam din căsuța de e-mail care a fost falsificat wildvoyager.com: 

Iată și iată că 0.0.0.0/0 bloc permite întregului spațiu de adrese IPv4, constând din peste patru miliarde de adrese, să treacă de verificarea SPF în timp ce se prezintă drept Wild Voyager. 

După acest experiment, l-am anunțat pe Prudence Créole și Wild Voyager despre înregistrările lor SPF configurate greșit. Prudență Créole și-a actualizat înregistrările SPF înainte de publicarea acestui articol. 

Reflecții și lecții învățate 

Crearea unei înregistrări SPF pentru domeniul dvs. nu este o lovitură de moarte împotriva eforturilor de falsificare ale spammerilor. Cu toate acestea, dacă este configurată în siguranță, utilizarea SPF poate zădărnici multe încercări precum cele care ajung în căsuța mea de e-mail. Poate cel mai important obstacol care împiedică utilizarea imediată, mai largă și aplicarea mai strictă a SPF este livrarea prin e-mail. Este nevoie de doi pentru a juca jocul SPF, deoarece atât expeditorii, cât și destinatarii trebuie să-și armonizeze politicile de securitate a e-mailurilor în cazul în care e-mailurile nu reușesc să fie livrate din cauza regulilor prea riguroase folosite de ambele părți. 

Cu toate acestea, având în vedere potențialele riscuri și daune cauzate de spammeri care vă falsifică domeniul, următoarele sfaturi pot fi aplicate după caz: 

• Creați o înregistrare SPF pentru toate identitățile dvs. HELO/EHLO în cazul în care verificatorii SPF urmăresc recomandare în RFC 7208 pentru a le verifica 
• Este mai bine să utilizați toate mecanism cu -Matei 22:21 or ~Matei 22:21 calificative mai degrabă decât cele ?Matei 22:21 calificativ, ca și acesta din urmă permite efectiv oricui să vă falsifice domeniul 
• Configurați o regulă „renunțați totul” (v=spf1 -all) pentru fiecare domeniu și subdomeniu pe care îl dețineți, care nu ar trebui să genereze niciodată e-mail (direcționat pe internet) sau să apară în partea de nume de domeniu a comenzilor HELO/EHLO sau MAIL FROM: 

• Ca orientare, asigurați-vă că înregistrările dvs. SPF sunt mici, de preferință până la 512 octeți, pentru a preveni ignorarea lor în tăcere de către unii verificatori SPF 
• Asigurați-vă că autorizați doar un set limitat și de încredere de adrese IP în înregistrările dvs. SPF 

Utilizarea pe scară largă a SMTP pentru a trimite e-mailuri a creat o cultură IT concentrată pe transferul de e-mailuri în mod fiabil și eficient, mai degrabă decât în ​​siguranță și cu confidențialitate. Reajustarea la o cultură axată pe securitate poate fi un proces lent, dar care ar trebui întreprins pentru a câștiga dividende clare împotriva uneia dintre necazurile internetului – spam-ul.