www.SAMURAJ-cz.com 

19.01.2020 Doubravka Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Ověřování emailů pomocí SPF - Sender Policy Framework

Upraveno 18.01.2020 18:44 | vytvořeno 09.01.2020 07:12 | Samuraj - Petr Bouška |
Metody, pro ověřování původu poštovních zpráv, kontrolují poštovní servery, které se účastní odeslání (a možné modifikace) emailu. Cílem je ověřit, že byla zpráva zaslána autorizovaným odesílatelem (serverem). Kontroluje se doména odesílatele, ne přímo emailová adresa. Jedna z nejrozšířenějších technik je SPF (Sender Policy Framework). Její využití je velmi jednoduché. Ověřuje, zda poštovní zpráva přišla z IP adresy, které je v DNS uvedena, jako povolený odesílatel pro danou doménu.

Email Authentication

V rámci SMTP protokolu je jednoduché podvrhnout většinu údajů v poštovní zprávě. Proto se vymýšlí metody, které by ověřili autentičnost. Jednou metodou je elektronický podpis, ale tam je složité získávání a práce s certifikáty (jsou kladeny velké nároky na koncového uživatele). Takže se řeší metody, které fungují na straně serverů.

Obecně se pro metody ověřování původu poštovních zpráv používá termín Email Authentication. Cílem je zamezit možnosti podvržení identity zprávy (Email Spoofing), tedy Phishingu a případně SPAMu. Ověřuje se, že email pochází od adresy, která je uvedena jako odesílatel, alespoň na úrovni domény. Částečně se dá říci, že se kontrolují poštovní servery (Message Transfer Agents - MTA), které se účastní odeslání a přenosu emailu.

Protože poštovní zpráva běžně obsahuje více adres odesílatele, tak je důležité, jaká adresa se ukazuje uživateli a jaká se kontroluje. Otázku adres v SMTP protokolu jsme si popsali v článku Protokol SMTP a adresy v elektronické poště.

Pro ověření původu zpráv se dnes převážně využívá technik SPF (Sender Policy Framework) a DKIM (DomainKeys Identified Mail), případně rozšíření DMARC (Domain-based Message Authentication, Reporting and Conformance).Tyto metody jsou definovány v internetových standardech RFC (a v nich nalezneme nejvíce detailních informací). Techniky SPF a DKIM se spíše doplňují, než by se nahrazovaly. Každá ověřuje trochu něco jiného.

Nutno poznamenat, že všechny tyto techniky fungují pouze mezi organizacemi, které je používají. Musí být provedeno nastavení pro odesílání zpráv. A při příjmu zpráv prováděna kontrola (pokud byla některá z technik použita).

SPF - Sender Policy Framework

Jednou z hodně rozšířených metod je Sender Policy Framework (SPF) popsané v RFC 7208 (navržený standard). Používají se termíny jako SPF Verification či SPF Authentication. Jeho využití je velmi jednoduché, ale funguje pouze pro strany, které jej používají. Pro své domény vytvoříme DNS záznamy a na příjmu zapneme SPF ochranu (naše poštovní brána musí SPF podporovat).

SPF ověřuje doménu použitou v adrese Envelope Sender (doporučeno je kontrolovat MAIL FROM i HELO), že poštovní zpráva byla odeslána korektním (povoleným) poštovním serverem pro tuto doménu. Dá se říci, že SPF svazuje doménu odesílatele s IP adresami serverů, které mohou email odeslat. Ověření může proběhnout již při přijetí prvních STMP příkazů (ve stejné chvíli, kdy se kontroluje existence adresy příjemce), nemusí se přijímat celá zpráva.

Princip SPF

SPF umožňuje vlastníkovi domény specifikovat, které poštovní servery jsou povoleny (autorizovány) k odesílání emailů za danou doménu. Nastavení se provádí pomocí textového (TXT) DNS záznamu se specifickým formátem.

  • Když poštovní server přijímá zprávu, tak se podívá na doménu v Envelope Sender, bere se doména z příkazu HELO a MAIL FROM (některé implementace používájí pouze MAIL FROM).
  • Pro tuto doménu se hledá SPF záznam (SPF Record) v DNS.
  • Pokud záznam existuje, tak se podle něj ověří (Checking Authorization) IP adresa poštovního serveru, odkud zpráva přišla.
  • Vyhodnocení (Evaluation) je definováno funkcí check_host() a jsou dány možné výsledky SPF testu (Results of Evaluation).
  • RFC také popisuje doporučené chování k různým výsledkům (Result Handling), ale reálné chování si standardně určujeme sami.

Výsledky SPF kontroly (Results of Evaluation)

Níže jsou možné výsledky vyhodnocení SPF ověření. Stručný popis i doporučené chování (manipulace) se zprávou podle výsledku.

  • None - neexistuje SPF záznam, přijmout zprávu
  • Neutral ? - záznam určuje, že o platnosti nelze rozhodnout, přijmout zprávu
  • Pass + - server je autorizován k odeslání zprávy, přijmout zprávu
  • Fail - - server není autorizován k odeslání zprávy, odmítnout zprávu
  • Softfail ~ - server pravděpodobně není autorizován k odeslání zprávy (ale nechceme odmítat), přijmout a označit zprávu
  • Temperror - při ověření SPF došlo k přechodné chybě (obvykle DNS)
  • Permerror - došlo k trvalé chybě (chybný SPF záznam)

SPF záznam v DNS

Formát SPF záznamu, a další požadavky na DNS záznamy, jsou specifikovány v RFC 7208. Čitelnější popis najdeme v článku SPF Record Syntax. Na internetu jsou také různé nástroje pro kontroly SPF záznamů SPF Record Check - Lookup SPF Records, či jejich generování SPF Record Generator.

SPF záznam musí být publikován jako DNS TXT (type 16) Resource Record (RR) přímo na dané doméně. Jeho formát začíná určením, že jde o SPF záznam v=spf1. Následuje seznam direktiv oddělených mezerou, ty jsou vyhodnocovány v zadaném pořadí. Případně obsahuje modifikátory.

Direktiva se skládá z kvalifikátoru a mechanismu. Kvalifikátor určuje chování (vyhodnocení) k danému mechanismu, což je zjednodušeně odesílající adresa. Pokud se adresa shoduje, tak se dle kvalifikátoru určí vyhodnocení. Kvalifikátor se nemusí zapisovat, pak je výchozí Pass. Možnosti jsou

  • + Pass
  • - Fail
  • ~ Softfail
  • ? Neutral

Mechanismy jsou například ip4:<ip4-address>, kde se určuje porovnávaná IP adresa, a:<domain>, kde se zadává A záznam v DNS pro porovnání. Speciální mechanismus je include:<domain>, kdy použije SPF záznam zadané domény. A all, který vždy odpovídá (určuje všechny adresy), standardně se používá na konci záznamu.

Jednoduchý SPF záznam, pro FQDN firma.cz (na této doméně se TXT záznam vytváří), může vypadat následně:

"v=spf1 ip4:1.2.3.4 mx -all"

Pokud přijde mail z IP adresy 1.2.3.4 nebo IP adresy, která je přiřazena k MX záznamu, tak je výsledek Pass. Pro všechny ostatní případy je Fail.

SPF HELO

Standardně se při SPF kontrole ověřuje doména v MAIL FROM (tedy doménová část adresy odesílatele - Envelope Sender). Například pro adresu bouska@firma.cz vychází doména firma.cz. RFC 7208 doporučuje, aby se ověřovala také doména v HELO/EHLO příkazu. V HELO/EHLO je doporučeno uvádět jméno serveru (hostname - FQDN), což je například mail.firma.cz (viděl jsem použitu i emailovou adresu).

Myslel jsem, že ze jména se vezme pouze doména (ač to není nikde popsané), ale patrně ne. Různé testovací služby pro kontrolu SPF, ověřují nejen MAIL FROM (mfrom), ale také HELO (helo), a vrací, že SPF záznam pro doménu mail.firma.cz nebyl nalezen. Zkusil jsem tedy přidat TXT DNS záznam i pro subdoménu a testy najednou vychází jako Pass. Také brána Cisco Email Security umožňuje při kontrole SPF/SIDF volitelně zapnout HELO Test. Pak přidává do hlaviček zpráv druhou (třetí, pokud máme i PRA) položku Received-SPF, kde je výsledek testu HELO domény.

Zkusil jsem hledat pro mnoho známých domén, ale u nikoho jsem nenalezl, že by měl SPF záznam pro HELO doménu. Takže se to v praxi asi nepoužívá.

Problém SPF

S technologií SPF je jeden problém, a to při přeposílání emailů (Forward) na jinou emailovou adresu. Pokud se použije standardní přeposlání, jaké nabízí běžný poštovní klient pod funkcí Forward, tak problém není. Tehdy se vytvoří nová zpráva, kde je odesílatelem daný uživatel (je vidět, že jsem zprávu přeposlal já). Chování je stejné, jako při odpovědi (Reply), jen se nevyplní adresa příjemce a do předmětu se vloží (něco jako) FW:.

Problém způsobuje operace, která se označuje jako přesměrování emailu (Redirect). Přesměrování se v běžných poštovních klientech (například MS Outlook) nedá provést ručně, ale můžeme vytvořit automatizované pravidlo (Rule), které tuto funkci podporuje. Při přesměrování se zpráva nemění a vypadá, jako kdyby přišla od originálního odesílatele. Pokud na ni příjemce odpoví, tak odpovídá originálnímu odesílateli a ne tomu, kdo přesměrování provedl. Problém je, že zprávu odesílá poštovní server toho, kdo přesměrování provádí, a používá adresu originálního odesílatele. Čili prakticky jde o podvržení odesílatele. A pokud je originální odesílatel a přeposílatel na jiné doméně, tak příjemcův server, při použití SPF, zprávu detekuje jako podvrženou.

Praktický dopad (s kterým jsem se dříve setkával velmi často, ale možná se situace zlepšuje) popisuje následující příklad. Odešlu email (ja@firma.cz) příjemci v jiné firmě (prijemce@nekde.cz). Tato osoba má nastavené pravidlo, aby se všechny zprávy přeposlaly na její adresu prijemce@seznam.cz (a v horším případě, aby se neuložila jejich kopie). Seznam přijímá email, kde je odesílatel z domény firma.cz, ale odeslal jej poštovní server domény nekde.cz. Pro naši doménu firma.cz máme SPF záznam, kde je autorizovaný pouze náš poštovní server. Seznam kontroluje SPF a toto považuje za podvržený email, takže jej odmítne. Zajímavé je, že chyba se nedostane k osobě, která má nastaveno přesměrování. Ale NDR se odešle nám (je to jediná adresa v hlavičce).

Níže je příklad chyby, která je uvedene v NDR při odmítnutí zprávy. Je vidět, že jsem sice psal adrese na doméně nekde.cz, ale odpověď je od serveru seznam.cz pro jinou adresu.

prijemce@seznam.cz
mx1.seznam.cz #<mx1.seznam.cz #5.7.1 smtp; 550 5.7.1 Sender Policy Framework of `firma.cz' domain denied your IP address.> #SMTP#

Ve většině případů, kdy vytváříme automatické pravidlo na přeposílání příchozích zpráv, můžeme volit jednu ze tří možností. Buď klasické přeposlání (to bychom měli preferovat) nebo přeposlání jako přílohu, poslední možnost je právě přesměrování (nechat zprávu nezměněnou).

Pozn.: DKIM, který si popíšeme dále, s přesměrováním problém nemá, protože funguje na úplně jiném principu.

Sender ID, Sender ID Framework (SIDF)

Sender ID, popsané v RFC 4406, je založené na SPF a je mu značně podobné, i když má určité rozšíření. Patrně se dnes příliš nepoužívá. Microsoft implementoval Sender ID jako Sender ID Framework (SIDF). Umožňuje kontrolovat doménu z Envelope Sender, klíčové slovo mfrom. Ale také Purported Responsible Address (PRA), což je adresa určená různými pravidly, uvažuje se také Header Sender.

Textový DNS záznam pro SPF začíná v=spf1. Pro Sender ID je to nějaká varianta typu spf2.0/mfrom, spf2.0/pra,mfrom, apod.

zobrazeno: 491krát | Komentáře [4]

Autor:

Související články:

Elektronická pošta - email

Protokol SMTP a jeho vlastnosti. Ochrana elektronické pošty proti SPAMu a Phishingu. Šifrování pošty...

Microsoft Exchange

Jednou částí mé práce je administrace poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Články začínají u verze 2003 a jak jde čas, tak pokračují dále.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] Martin

    Přeposílání u SPF se dá vyřešit nasazením SRS, viz socl.cz/postfix-spf-a-preposilani-posty-postsrsd ;)

    Čtvrtek, 09.01.2020 10:01 | odpovědět
  2. [2] Samuraj

    odpověď na [1]Martin: Já myslím, že poštovní server by neměl povolil přesměrování zprávy. Je to jednoznačně podvržení adresy ;-). Na to vkládání odkazů někdy kouknu :)

    Čtvrtek, 09.01.2020 10:08 | odpovědět
  3. [3] Petr

    Výborné jako vždy ...

    Pátek, 10.01.2020 10:41 | odpovědět
  4. [4] Karel

    Díky moc! Už se těším na DKIM ;-)

    Čtvrtek, 16.01.2020 17:00 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách