Tento článek navazuje na předchozí

• Protokol SMTP a adresy v elektronické poště
• Ověřování emailů pomocí SPF - Sender Policy Framework
• Ověřování emailů pomocí DKIM - DomainKeys Identified Mail

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Metoda Domain-based Message Authentication, Reporting, and Conformance (DMARC) je popsána jako informační RFC 7489.  Jedná se o mechanismus, pomocí kterého může organizace odesílající emaily (poštovní doména, Domain Owner), určit politiky a preference ověřování zpráv a reportingu na úrovni domény, které může organizace přijímající emaily (Mail Receiver) použít ke zlepšení zpracování pošty. Příjemce může poskytovat zpětnou vazbu (reporty) vlastníkovi domény o využívání jejich domény (ukazuje využití i zneužití domény). DMARC je mechanismus na distribuci politik, které umožní přísnější zpracování zpráv, kde selhalo ověření autentizace.

Princip DMARC

DMARC rozšiřuje a doplňuje existující techniky SPF a DKIM, které provádí ověření domény emailů, ale neobsahují možnost sdělit příjemci, jak se má chovat ke zprávám, kde ověření selže. Také nemají možnost informovat majitele domény, jak bylo naloženo s přijatými zprávami. Tyto možnosti nabízí DMARC. V emailu se nachází adresa odesílatele v SMTP příkazu MAIL FROM (obálce) dle RFC 5321 a ve From položce hlavičky zprávy dle RFC 5322. DMARC ověřuje doménu z adresy ve From.

Opět se využívá textový záznam v DNS pro definici DMARC politiky. Pro svoji odesílací doménu stačí publikovat odpovídající záznam (doporučuje se také vytvořit schránku pro příjem reportů) a tím aktivovat DMARC. Pro provádění kontrol a reakcí na příjmu, potřebujeme poštovní bránu, která DMARC podporuje, a aktivovat tuto funkci.

DMARC odděluje technologii autentizace od mechanismu politik. Díky tomu, že může využívat více autentizačních technologií (SPF a DKIM), tak je více odolný proti chybám. Pokud používáme obě technologie (což je doporučeno), tak stačí, když jedna kontrola projde (Pass) a druhá je chybná (Fail), aby prošel výsledek DMARC kontroly. Jako primární identifikátor se používá doména z položky From v hlavičce zprávy. A mimo kontroly SPF a DKIM se ještě porovnává, že tento identifikátor odpovídá doméně ověřené pomocí SPF a DKIM. Pokud odpovídá, tak se označuje jako Identifier Alignment (případně SPF Alignment a DKIM Alignment).

DMARC umožňuje, aby přijímající server generoval dva typy reportů. Jeden pro každou zprávu, kde selhalo SPF a/nebo DKIM (Failure Reports). Druhý je pravidelný agregovaný report vlastníkovi domény (Aggregate Reports).

Identifier Alignment

SPF ověřuje doménu, která je použita v SMTP příkazu MAIL FROM, případně EHLO/HELO či oboje. DKIM ověřuje doménu, která zprávu podepsala. V obou případech jde o domény, které běžný uživatel nevidí a mohou být jiné od zobrazené domény odesílatele.

DMARC požaduje, aby ověřený identifikátor (Authenticated Identifier) ze SPF nebo DKIM odpovídal (be aligned with) From adrese z hlavičky, která je standardně viditelná uživateli. To se označuje jako zarovnání identifikátoru (Identifier Alignment). Podle RFC 5322 je položka From v hlavičce povinná a standardně se používá pro reprezentaci původce zprávy. Tato položka je také nejčastějším cílem pro zneužití. DMARC počítá s tím, že příchozí zpráva je validní dle RFC 5322. Pokud například položka From chybí, je poškozená nebo se opakuje, tak takovou situaci DMARC neřeší.

Zarovnání (Alignment) domény může být definováno jako Strict, tehdy musí přesně odpovídat. Nebo Relaxed, kdy se kontroluje pouze hlavní doména organizace (Organizational Domain), takže se pak berou jako validní i subdomény.

Aggregate Reports

DMARC aggregate feedback report odesílá příjemce periodicky (standardně denně) pro odesílající doménu, která má definovánu DMARC politiku s RUA adresou. Obsahem jsou agregované údaje o všech zprávách přijatých z dané domény. Vlastník domény tak získá statistický přehled, jaké legitimní zprávy posílá, jaký byl výsledek ověření těchto zpráv, a jaké podvržené emaily dostává příjemce. Obsahem reportu jsou údaje o organizaci, nalezená a uplatněná politika, záznamy pro zprávy, které obsahují výsledek kontrol SPF a DKIM, identifikátor a zda je zarovnaný.

XML formát reportů je definovaný v RFC 7489 příloze C. Soubor je doporučeno komprimovat pomocí GZIP. Přípona je pak buď xml nebo xml.gz. Název souboru i předmět emailu je specifikován v RFC.

Příklad předmětu zprávy:

Report Domain: odesilatel.cz Submitter: prijemce.cz Report-ID: <ID-1-1-0>

Příklad názvu souboru s reportem (čísla jsou časové razítko začátku a konce reportu v UNIX formátu):

prijemce.cz!odesilatel.cz!1580252403!1580338803.xml.gz

Obsahem agregovaných reportů jsou ovšem pouze statistické údaje na úrovni domén, rozhodně se tam nedozvíme, že zpráva z určité emailové adresy na jinou prošla/neprošla ověřením.

Zhruba se obsah reportu skládá z

• version - verze, která musí být 1.0
• report_metadata - metadata o tvůrci reportu (organizaci) a období, za které je report vystaven
• policy_published - aplikovaná DMARC politika, obsahuje doménu, kde byla politika nalezena a údaje z politiky - požadované zarovnání, politika pro doménu a subdomény, procenta a failure reporting
• record - jeden nebo více záznamů obsahující výsledek autentizace pro skupinu zpráv
  • row - obsahuje zdrojovou IP adresu, počet odpovídajících zpráv, vyhodnocení politiky (výsledek SPF a DKIM s DMARC zarovnáním domény, akce daná politikou, případně důvod)
  • identifiers - identifikátory header_from, envelope_from, envelope_to (v praxi je zde často pouze doména z From z hlavičky)
  • auth_results - výsledek autentizace SPF a DKIM bez vlivu DMARC, DKIM se může nacházet 0 nebo vícekrát, SPF minimálně jednou, každá část obsahuje ověřovanou doménu, výsledek kontroly, selektor pro DKIM a pro SPF určení, zda jde o mfrom nebo helo

Příklad agregovaného reportu

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <version>1.0</version>
    <report_metadata>
        <org_name>seznam.cz a.s.</org_name>
        <email>abuse@seznam.cz</email>
        <report_id>szn_firma.cz-2020-01-30</report_id>
        <date_range>
            <begin>1580342400</begin>
            <end>1580428800</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>firma.cz</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>none</p>
        <pct>100</pct>
        <fo>0</fo>
    </policy_published>
    <record>
        <row>
            <source_ip>1.2.3.4</source_ip>
            <count>61</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>pass</dkim>
                <spf>pass</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <envelope_from>firma.cz</envelope_from>
            <header_from>firma.cz</header_from>
        </identifiers>
        <auth_results>
             <dkim>
                <domain>firma.cz</domain>
                <result>pass</result>
                <selector>dkim2020</selector>
            </dkim>
             <spf>
                <domain>firma.cz</domain>
                <scope>mfrom</scope>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

Failure Reports

Pokud selže DMARC autentizace (výsledek Fail) a politika definuje adresu RUF, tak se okamžitě odesílá Failure Report pro danou zprávu. Vlastníkovi domény poskytuje rychlé upozornění, že došlo k selhání autentizace. Report obsahuje více informací, než se nachází v agregovaném reportu, takže poskytne podporu ke zkoumání, co způsobilo selhání.

Pokud chce vlastník domény dostávat tyto reporty, tak v politice definuje značky RUF a případně FO. Pokud je příjemce ochoten přehledy poskytnout, tak je generuje a odesílá ve formátu AFRF (Authentication Failure Reporting Using the Abuse Reporting Format).

DMARC ověřování příjemcem (server)

Při příjmu zprávy se provádí následující kroky (2 až 4 probíhají paralelně):

1. získání domény z From položky hlavičky
2. hledání záznamu DMARC politiky v DNS, pokračování, pokud se nalezne validní záznam
3. kontrola DKIM podpisů (může jich být více), výsledek kontroly a doména se předává do DMARC
4. kontrola ověření SPF, výsledek kontroly a doména se předává do DMARC
5. provedení kontroly Identifier Alignment, pokud je jeden nebo více ověřených identifikátorů zarovnáno s From doménou, tak se zpráva považuje za vyhovující (Pass) DMARC kontrole, v ostatních případech kontrola selhala (Fail)
6. na zprávy, kde kontrola selhala, se aplikuje DMARC politika

Záznam DMARC politiky v DNS

DMARC Policy Record se publikuje v DNS jako TXT (type 16) Resource Record (RR) na subdoméně _dmarc. Například _dmarc.firma.cz. Formát záznamu je obdobný jako pro DKIM, skládá se ze značek (tag=value) oddělených středníkem.

Pro zadání adres příjemců dvou typů reportů (v DMARC záznamu) se používá formát DMARC URI. Jde o mailto URI schéma, kde jsou čárky a vykřičníky kódované a volitelně může obsahovat na konci vykřičník a maximální velikost reportu. Příklad mailto:reports@firma.cz!50m. Adres může být více oddělených čárkou.

Standardně musí být adresa pro příjemce reportů na stejné doméně. Pokud chceme použít externí doménu, tak se v cílové doméně musí nacházet DNS TXT záznam pro DMARC, který znamená souhlas s příjmem reportů. Jinak by někdo mohl zkusit útok, že by na externí doménu směroval velké množství reportů (tím, že by publikoval DNS záznam a pak rozeslal spoustu podvržených zpráv na různé domény).

Jméno (FQDN), kde se hledá TXT záznam s hodnotou v=DMARC1, se vytváří podle obou domén. Například máme doménu firma.cz (kde je DMARC politika), ale reporty chceme posílat na doménu prijemce.cz (tam směrují adresy rua/ruf). Pak se hledá záznam pro:

firma.cz._report._dmarc.prijemce.cz

Používané značky (tagy) v DMARC záznamu

(P) znamená, že daná značka se musí v záznamu nacházet (je povinná).

• v - version (P) - identifikace DMARC záznamu, musí být první s hodnotou DMARC1
• p - policy (P) -  politika určená vlastníkem domény, kterou má použít příjemce, none žádná akce,  quarantine pokud DMARC selže, má se brát zpráva jako podezřelá a vložit do karantény či označit, reject pokud DMARC selže, má se zpráva odmítnout (to může být během SMTP transakce)
• rua - address aggregate report - adresy, na které se má posílat agregovaný report, DMARC URI formát
• ruf - address message-specific report - adresy, na které se má posílat report při selhání zprávy, DMARC URI formát
• fo - failure reporting - jaké reporty chyb se mají generovat (musí být také definován ruf), 0 generuj DMARC report pokud všechny autentizační metody selžou (default), 1 generuj DMARC report pokud některá autentizační metoda selže, d generuj DKIM report pokud je nevalidní podpis (nezáleží na alignment), s generuj SPF report pokud selže SPF (nezáleží na alignment)
• adkim - DKIM Alignment mode - r relaxed mode (default), s strict mode
• aspf - SPF Alignment mode - r relaxed mode (default), s strict mode
• pct - percentage - DMARC politika se má aplikovat pouze na určité procento zpráv 0 až 100 (default)
• rf - message-specific reports format - jaký formát se má použít pro report, podporováno pouze afrf
• ri - report interval - jak často se posílají agregované reporty, default 86400
• sp - subdomains policy - politika (stejně jako p), která se aplikuje na subdomény (ne vlastní doménu)

Příklad DNS záznamu

"v=DMARC1; p=none; rua=mailto:dmarcreports@firma.cz; ruf=mailto:dmarcreports@firma.cz"

Pro kontrolu DMARC záznamu v DNS můžeme využít online služby, třeba DMARC Check Tool - Check DMARC Records for Errors, DMARC record check.

Pro vytvoření záznamu můžeme také nalézt online generátor DMARC Record Generator.

Praktické nasazení DMARC

Ověřování DMARC

Potřebujeme poštovní bránu (server), která podporuje DMARC. Zapnutí ověřování je pak většinou jednoduché. Příkladem brány s podporou DMARC je Cisco Email Security. Velmi stručně jsem zapnutí DMARC kontroly popsal v článku Cisco Email Security - konfigurace AntiSpam řešení. Můžeme změnit chování, pokud kontrola neprojde a DMARC politika definuje určité chování. Také nastavujeme, zda se mají odesílat agregované reporty.

Hodně zjednodušeně DMARC provádí

• kontrolu SPF a porovnání domény z MAIL FROM (SPF) a From, pokud projde vrací Pass, pokud není SPF použito vrací Fail
• kontrolu DKIM a porovnání domény z DKIM-Signature (tag d) a From, pokud projde vrací Pass, pokud není SKIM použito vrací Fail
• pokud je alespoň jeden výsledek Pass, tak je celá DMARC kontrola Pass, v opačném případě je Fail a použije se politika
• odesílání reportů

Zapnutí DMARC

Když chceme nasadit DMARC, tak se doporučuje provést obecné kroky:

• nasadit DKIM a SPF
• ujistit se, že jsou při odesílání korektně zarovnané identifikátory (domény)
• publikovat DMARC záznam s politikou none a adresami pro reporty, abychom získali informace o zpracování pošty a neovlivnili doručení zpráv
• analyzovat reporty
• upravit DMARC politiku na quarantine či reject

Vlastní aktivace DMARC pro určitou doménu spočívá v publikování textového DNS záznamu. Pokud odesíláme emaily z domény firma.cz, například bouska@firma.cz, tak vytvoříme TXT záznam _dmarc na doméně firma.cz. (FQDN _dmarc.firma.cz). Hodnota záznamu může být (případně bez značky RUF, kdyby chodilo příliš zpráv)

v=DMARC1; p=none; rua=mailto:dmarcreports@firma.cz; ruf=mailto:dmarcreports@firma.cz

Kterou později změníme na

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@firma.cz; ruf=mailto:dmarcreports@firma.cz; adkim=s; aspf=s

Prohlédnout záznam můžeme jednoduše, třeba řádkovým příkazem na Windows.

nslookup

> set type=txt
> _dmarc.firma.cz
Server:  ns.firma.cz
Address:  192.168.0.10

Non-authoritative answer:
_dmarc.firma.cz   text =
	"v=DMARC1; p=none; rua=mailto:dmarcreports@firma.cz; ruf=mailto:dmarcreports@firma.cz"

Problémy v praxi

Technologie DMARC je zajímavá a docela rozšířená. Tedy řekl bych, že mnoho organizací publikovalo DMARC záznam, ale řada z nich má politiku nastavenu na NONE. A je vidět, že to je dobře, protože mají v odesílání pošty zásadní chyby a DMARC kontrola selže. To se týká i tak velkých organizací, jako je Ministerstvo financí ČR, kteří odesílají oficiální emaily i ze subdomény, kde nepoužívají ani SPF či DKIM (ani DMARC), ale na hlavní doméně mají definovaný DMARC záznam (který se použije i pro všechny subdomény). Některé firmy mají DMARC záznam, ale nepoužívají SPF ani DKIM.

Další časté problémy jsou s odesíláním reportů. Mnoho organizací má definovanou adresu pro agregované reporty, ale ta buď neexistuje nebo je schránka plná. Opět se to týká velkých firem, například Fortinet, Aliexpress, Teamviewer, Čedok. Ještě hůře to působí u služby, která zpracování DMARC reportů poskytuje, a report se nedá doručit, jako easydmarc.com, dmarcanalyzer.com (možná se to děje v případě, kdy firma přestane za službu platit, ale DMARC záznam má stále směrovaný na tuto službu).

Vtipná je také další situace na doméně isaca.org (na to by si měl dát pozor každý, kdo chce nasadit DMARC). Doručení agregovaného reportu se nepovede, protože adresa dmarc_rua@isaca.org neexistuje. Server odpovídá NDR o nedoručení (Bounce Message), ale zpráva není podepsaná a chybí adresa odesílatele (Envelope Sender). Doména má nastavenu DMARC politiku na karanténu, kontrola DMARC neprojde, takže se zpráva nedoručí.

Kdy DMARC selže

Pro SPF je problém přeposílání emailů (Redirect) na jinou adresu, pokud se zpráva nemění (údaje o odesílateli). Tehdy je doména odesílatele původní, ale zprávu odešle jiný poštovní server. Tento problém by neměl mít DKIM, protože zpráva zůstává původní, takže i podpis by měl být validní. DMARC byl navržen tak, aby kontroloval SPF i DKIM, ale stačila jedna úspěšná kontrola. Měl by tedy být funkční při přeposílání zpráv, protože se ověří DKIM, ale zároveň se kontroluje doména odesílatele.

Při přesměrování se často využívá nějaká forma přepisu adresy odesílatele v obálce (MAIL FROM), například SRS. Cílem je, aby prošla kontrola SPF. Zůstává ale původní adresa v hlavičce (From), takže nejsou domény zarovnané a kontrola DMARC SPF neprojde.

V praxi ovšem nastávají situace (které se považují za legitimní), kdy DMARC kontrola neprojde. Například členství v nějakém Mailing List. Taková služba přijímá emaily, které rozesílá na všechny členy skupiny. Zároveň ovšem lehce modifikuje obsah zprávy, například doplněním patičky, ale nemění údaje o odesílateli. Takže neprojde ani SPF, ani DKIM podpis. Stejně jako některé metody automatického přeposílání.

Analyzoval jsem nějaké situace, kdy přesměrované (Redirect) emaily neprošly DMARC kontrolou. Nesedělo zarovnání SPF, což je logické, ale nebyl v pořádku ani DKIM podpis. Kolega přišel na důvod. Některé společnosti (například Facebook) podepisují zprávy s kanonikalizací simple. A určité poštovní servery, třeba od Microsoftu, provedou při přesměrování zprávy určité úpravy netisknutelných znaků. Pak kontrolní součet neodpovídá. Z tohoto důvodu se doporučuje používat volnější kanonikalizaci relaxed.

Authenticated Received Chain (ARC)

V agregovaných reportech od google.com, jsem občas narazil na informaci, že byla uplatněna lokální politika pro rozhodnutí s poznámkou arc=pass. K tomu jsem našel, že jde o Authenticated Received Chain (ARC) RFC 8617, který by měl předchozí problém řešit. Jde o protokol, který předává výsledek autentizace do dalšího kroku při přeposílání. Pokud nějaká přeposílací služba přijme zprávu, kde je validní DMARC a podporuje ARC. Tak při přeposílání doplní další položky hlavičky (ARC-Authentication-Results, ARC-Seal, ARC-Message-Signature). Díky tomu zpráva zachovává původní výsledek ověření. Přijímací server ověří řetězec ARC-Seal hlaviček a poslední ARC-Message-Signature. Pokud je v pořádku, tak by měl použít původní výsledek autentizace.

Zpracování reportů

Mimo to, že nám má DMARC chránit doménu, aby se za ni někdo nevydával, tak nám nabízí možnost reportů, které zajistí přehled o posílání pošty. Odesílání reportů je ovšem volitelná možnost dle RFC a Mail Receiver je nemusí provádět. Z praxe mi přijde, že Failure Reports se posílají minimálně (zatím jsem je dostal pouze od seznamu), třeba Cisco Email Security to patrně také nepodporuje. Aggregate Reports se nějakým způsobem posílají, ale také asi v omezené míře (dostávám je pouze od pár velkých organizací jako je Google, Seznam, Amazon, Yahoo, IOL).

V každém případě, pokud na doméně aktivujeme DMARC, tak mohou být reporty zajímavé, ale je třeba je zpracovávat. To se moc nedá manuálně, když nám každý den přijde desítky až stovky XML souborů. Minimálně to chce vytvořit nějaký skript (například v PowerShellu), který bude automaticky stahovat XML soubory, parsovat a ukládat buď do databáze či třeba Excelu. Lepší je samozřejmě nástroj, který provede i nějakou analýzu. Existuje řada placených online služeb, které zpracovávají DMARC reporty.

Reporty by nám měly ukázat, jestli někde nejsou odesílány zprávy za naši doménu z veřejných služeb, například pro marketing. Nebo jestli dochází k přeposílání zpráv, kde selže DMARC ověření. Není ovšem jednoduché z údajů v reportu analyzovat situaci, o kterou jde.

Online nástroje

Seznam nástrojů a služeb, které jsem nalezl na internetu.

Kontrola domény

• Mail Tester
• Domain Health Checker

Vytvoření DMARC záznamu

• DMARC Record Generator
• DMARC Record Generator

Kontrola DMARC záznamu

• DMARC Check Tool - Check DMARC Records for Errors
• DMARC record check
• DMARC Record Checker
• DMARC Check

Zobrazení XML DMARC Aggregate Report

• Dmarc Report Analyzer
• DMARC XML to Human Converter

Skripty (aplikace)

• DMARC - Harvest DMARC Report files from mailbox and generate HTML Reports v2.3
• Open source DMARC report analyzer and visualizer
• DMARC viewer

Řešení (služba) na zpracování (analýzu) DMARC reportů

Další odkazy jsou uvedeny na webu dmarc.org Analytics and Implementation Support.

Test DMARC služeb

Krátce jsem vyzkoušel některá řešení, která zpracovávají DMARC reporty. Vždy je třeba přidat (nebo vyměnit) RUA adresu v DMARC záznamu, případně i RUF. Adresa bývá generovaná pro klienta.

• Postmark DMARC report - jednou týdně (v pondělí) odesílá souhrnný report, obsahuje základní statistiky rozdělené na vlastní zdroje a přeposílané zdroje
• EasyDMARC - rozhraní nevypadá špatně, základní věci jsou zdarma, ale ani v úvodní Trial periodě jim služba nefunguje dobře, patrně mají přetížené servery, tak 2/3 reportů jsou odmítnuty (zpráva překročena velikost schránky), takže výsledek není dobrý
• URIports - opět na první pohled nevypadá špatně, mimo DMARC podporuje sledování TLS-RPT a pak nějaké funkce pro weby, ale v DMARC reportech se vůbec nevyznám, proti EasyDMARC mi to přijde naprosto nepřehledné, často když rozkliknu nějaký detail reportu, tak vrátí prázdnou stránku - sami mne oslovili a zjistili, že toto byla chyba, kterou opravili, když jsem to nyní proklikával, tak to již vypadá lépe (člověk musí také přijít na to, že detaily dosten kliknutím na Inspect)
• OnDMARC - další služba s hezkým rozhraním, více službami, ale pro mne nepřehledné reporty, dostat se k detailům, jaká doména je v SPF a DKIM, lze asi pouze někde a opět pro mne nepřehledně