(Ne)bezpečný e-mail, aneb DKIM, DMARC, DANE a další nejen od D

Ti cyničtější mezi čtenáři by mohli namítnout, že v tomto ohledu se mu někteří z poskytovatelů klasických poštovních služeb plně vyrovnají, a o určité „ekvivalenci“ e-mailu s reálnou poštou lze tak potenciálně skutečně hovořit, nicméně pro potřeby tohoto článku se omezíme na vyjádření, že s dopisem zaslaným poštou má e-mail jen máloco společného.

Posíláme zprávu historickým protokolem

Simple Mail Transfer Protocol (SMTP) , tedy protokol, na němž je přenos zpráv elektronické pošty principiálně založen, trpí snad všemi obvyklými neduhy historických komunikačních protokolů. V základu je nešifrovaný a sám o sobě neobsahuje žádné mechanismy pro ověření autenticity a integrity předávaných dat, ani identity jejich odesilatele. Vzhledem ke zmíněným faktorům se tak e-mail blíží spíše na stroji psanému korespondenčnímu lístku než podepsanému dopisu zalepenému v obálce.

Popsaná situace je ve světě, v němž je elektronická pošta jedním z dominantních kanálů pro mezilidskou komunikaci citelně nevyhovující, proto byla pro její dodatečné zabezpečení vytvořena řada doplňujících mechanismů a standardů, které dobrá odborná praxe velí aplikovat. Implementaci některých z nich, včetně těch bezpochyby nejvýznamnějších, pak požaduje po vybraných organizacích v ČR také ochranné opatření publikované NÚKIB 11. října 2021.

Vzhledem k tomu, že lhůta pro implementaci požadavků vyplývajících z tohoto opatření pro vybrané organizace uplynula 1. července tohoto roku, a lhůta pro většinu dalších povinných organizací uplyne 1. ledna 2023 (a také s ohledem na skutečnost, že obsah opatření lze převážně považovat za shrnutí požadavků dobré odborné praxe), je nyní bezpochyby vhodná doba krátce se pozastavit nad tím, jak jednotlivá opatření vlastně fungují, proč je jejich implementace žádoucí a jak vypadá stav jejich implementace (nejen) na úrovni vybraných významných státních institucí.

Mechanismy pro zabezpečení elektronické pošty

Principiálně je pro zabezpečení elektronické pošty nezbytné zejména zajistit důvěrnost a integritu předávaných zpráv a jednoznačně prokázat jejich původ.

Zajištění všech tří faktorů při komunikaci jejich původního autora, resp. jím užívaného klientu (MUA), s e-mailovým serverem (MSA/MTA) je relativně jednoduché – komunikace klientů se servery je dnes v podstatě bez ohledu na zvolený protokol (SMTP, IMAP, POP3, HTTP,…) standardně implicitně šifrovaná s pomocí TLS a při odesílání pošty se odesilatel zpravidla musí autentizovat. Konfigurace implicitního použití TLS při komunikaci serverů s klienty je v současnosti zpravidla relativně přímočará a nelze jí tak považovat za jakkoli problematickou. Situace je však o poznání složitější při předávání zpráv mezi dvěma e-mailovými servery.

Na rozdíl od světa webu, v němž webový prohlížeč komunikuje přímo s cílovým serverem, a kde je již nějakou dobu případná absence zabezpečeného spojení velmi dobře viditelná i pro běžného uživatele, je (ne)bezpečný přenos e-mailu pro koncového uživatele do jisté míry netransparentní.

Mimo jiné proto, že uživatelský klient nekomunikuje s e-mailovým serverem zamýšleného příjemce přímo, ale s využitím mezilehlých serverů, které přenos zprávy probíhá, a uživatel dostává zpravidla pouze informaci o tom, že „pošta byla úspěšně odeslána“, většina technicky méně vzdělané populace žije v bláhovém přesvědčení, že e-mail je „elektronický dopis“ a okolo zprávy tak určitě existuje jakási obálka, která zajistí zachování důvěrnosti jejího obsahu.

Ponechme prozatím stranou, že myšlenka zabezpečené obálky, kterou by otevřel až příjemce je samozřejmě zcela zcestná, pokud odesilatel sám zprávu nezašifruje s pomocí nějakého vhodného mechanismu, a zprávu si tak na jakémkoli serveru, který ji po cestě zpracovává, lze volně přečíst nebo modifikovat. Vrátíme se k tomu za okamžik, nejprve se však zaměříme na možnost zajištění důvěrnosti a integrity onoho „elektronického korespondenčního lístku“, jímž e-mail ve skutečnosti je, při jeho přenosu po nezabezpečené síti mezi dvěma servery (například po internetu).

Pro zabezpečení tohoto přenosu, který je standardně prováděn s pomocí SMTP,  je opět možné využít TLS. Z důvodu zachování zpětné kompatibility však nemůže být TLS spojení mezi servery navazováno automaticky/implicitně, ale až na základě vzájemné dohody obou komunikujících stran. Za tímto účelem byl navržen mechanismus STARTTLS.

Pokud tento mechanismus přijímající server (MTA) podporuje, informuje o tom po navázání běženého SMTP spojení odesílající server, který – pokud daný mechanismus rovněž podporuje – s pomocí klíčového slova „STARTTLS“ iniciuje přechod k šifrovanému spojení.

Nasazení a podpora tohoto mechanismu má bezpochyby citelný význam na bezpečnost přenášených zpráv, byť, jak je z výše uvedeného popisu patrné, s pomocí samostatně užitého STARTTLS není principiálně možné zabránit aktivním „man in the middle“ útokům, ale pouze pasivnímu odposlechu komunikace. Aktivní útočník schopný modifikovat probíhající komunikaci by mohl provést tzv. „STARTTLS downgrade útok“, tedy například „odfiltrovat“ informaci o podpoře STARTTLS z komunikace přijímajícího serveru, a zabránit tak odesílajícímu serveru dozvědět se o ní a následně navázat TLS spojení.

Pro korektní funkci výše uvedeného mechanismu je samozřejmě zapotřebí zajistit korektní konfiguraci TLS na straně obou komunikujících serverů. NÚKIB v rámci výše zmíněného opatření vyžaduje mimo opodstatněné případy využívat pouze protokoly TLS 1.2 a TLS 1.3, což odpovídá soudobé obecné dobré bezpečnostní praxi, spolu s certifikáty vydanými důvěryhodnou certifikační autoritou.

Poslední uvedený požadavek je zvlášť významný, a to vzhledem k tomu že kontrola certifikátů při navazování spojení mezi e-mailovými servery byla historicky považována spíše za formalitu a odesílající server zpravidla přijal jakýkoli certifikát, včetně těch, které byly podepsány nedůvěryhodnými certifikačními autoritami nebo byly „self-signed“.

Důvod je prostý – na rozdíl od webové komunikace, do níž může dynamicky uživatel zasahovat a do jisté míry rozhodovat o důvěřování/nedůvěřování určitém certifikátu, není takový zásah do e-mailové komunikace principiálně možný. Z pohledu odesílajícího e-mailového serveru tak bylo vždy vhodnější využít šifrované spojení (byť bez jednoznačného prokázání identity protějšku) než využít pro přenos nešifrovaný kanál nebo zprávu v případě použití nedůvěryhodného certifikátu odmítnout předat. V oblasti e-mailu byla totiž historicky v podstatě vždy (z pochopitelných důvodů) akcentována spíše spolehlivost doručení zpráv nad bezpečností jejich přenosu.

Aby se situace do budoucna měla možnost zlepšit, dává požadavek NÚKIB na využívání pouze „důvěryhodných“ certifikátů na e-mailových serverech jednoznačný smysl. Do doby než se však platné certifikáty vydané důvěryhodnými CA stanou na e-mailových serverech standardem (konec konců, i poté) je možné jejich nedostatečnou důvěryhodnost (a spolu s ní také výše zmíněný problém spočívající ve schopnosti aktivního „MitM“ útočníka zabránit využití STARTTLS) řešit s pomocí mechanismu nazvaného DNS-based Authentication of Named Entities (DANE).

Za vším hledej DNS

Prastará (na IT poměry) administrátorská poučka praví, že v podstatě jakýkoli problém spojený s informačními technologiemi ve finále můžeme vytrasovat k chybě na úrovni protokolu DNS. Přes toto nepříliš dobré renomé je vedle TLS právě DNS tím protokolem, na němž jsou založeny téměř všechny bezpečnostní mechanismy pro elektronickou poštu, a to – jak již jeho jméno napovídá – včetně DANE.

Pokud situaci drobně zjednodušíme, lze říci, že tento doplňkový bezpečnostní mechanismus je založen na publikaci speciálního DNS záznamu (TLSA) obsahujícího kryptografický otisk certifikátu užívaného ze strany určitého serveru pro specifickou službu, což umožňuje klientům přes tento DNS záznam ověřit legitimitu daného certifikátu. Tento postup samozřejmě vyžaduje, aby DNS záznamy získané klientem byly samy o sobě „zabezpečené“ a nemohlo dojít k jejich podvržení, což je důvod, proč nezbytným předpokladem pro implementaci DANE je využívání DNSSEC na úrovni relevantní domény.

V oblasti elektronické pošty je využití DANE následující. Pokud odesílající server DANE podporuje, zjistí nejprve zda pro doménu příjemce není publikovaný záznam TLSA obsahující otisk relevantního certifikátu. Pokud takový záznam publikován je, naváže server odesilatele spojení s přijímajícím serverem pouze s pomocí TLS spojení, v rámci něhož je využit certifikát, který odpovídá publikovanému TLSA záznamu (a specifikovanému způsobu použití). Pokud TLSA záznam existuje, nesmí dle relevantního RFC odesílající server spojení navázat a e-mailovou zprávu předat bez využití STARTTLS a návazného TLS spojení s využitím odpovídajícího důvěryhodného certifikátu. V případě, že TLSA záznam neexistuje, dochází standardně k využití „fallback“ mechanismu v podobě klasického SMTP (a případně „běžného“ STARTTLS). 

S pomocí výše popsaných mechanismů je možné zajistit, že „po cestě“ nedojde k modifikaci ani porušení důvěrnosti předávaného obsahu. Nepomohou však se zajištěním autenticity zpráv jako takových.

Jak jsme již nastínili, protokol SMTP neobsahuje žádný mechanismus, který by umožňoval jednoznačně ověřit identitu odesilatele, čehož historicky rádi využívali (a v některých případech stále využívají) útočníci a autoři cílených phishingových zpráv.

Pokud situaci opět drobně zjednodušíme, při zasílání elektronické zprávy s pomocí protokolu SMTP jsou přijímajícímu serveru předávány dvě informace o odesilateli – jedna v SMTP „obálce“/hlavičce a jedna v hlavičce samotného e-mailu. Druhá uvedená je po doručení zobrazena uživateli. Nic principiálně nebrání tomu, aby se tyto dvě adresy lišily, nebo aby tu na úrovni SMTP „obálky“ poštovní servery za určitých okolností modifikovaly – naopak je takové chování někdy žádoucí a nezbytné, nicméně problematiku oprávněné modifikace zpráv ponechme stranou. Problém spočívá v tom, že ani u jedné z těchto adres se u protokolu SMTP nekontroluje, zda jsou užity „oprávněně“, tedy zda nebyly podvrženy a zda adresa odesilatele, kterou vidí uživatel (případně ta, s níž pracuje přijímající server) opravdu patří reálnému odesilateli zprávy.

Aby bylo možné identitu odesilatele (alespoň do jisté míry) potvrdit, vznikly, vedle možnosti elektronicky podepsat zprávu přímo samotným jejím autorem (PGP, S/MIME, …), tři vzájemně se doplňující standardy – Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) a Domain-based Message Authentication, Reporting and Conformance (DMARC).

SPF

První zmíněný mechanismus, tedy SPF, je v principu extrémně jednoduchý, ale přesto relativně mocný. Umožňuje držiteli domény publikovat s pomocí specificky formátovaného TXT DNS záznamu seznam serverů, které mají „oprávnění“ za tuto doménu odesílat elektronickou poštu. Pokud přijímající e-mailový server SPF podporuje (což je v současnosti standardem), provede po přijetí zprávy kontrolu existence zmíněného TXT záznamu pro doménu uvedenou v adrese odesilatele v SMTP „obálce“ zprávy. Pokud relevantní SPF záznam existuje, zkontroluje přijímající server, zda je s jeho pomocí odesílající server označen jako oprávněný zasílat poštu za danou doménu. Pokud na tomto seznamu daný server není, může přijímající server zprávu přesto přijmout, nebo označit jako potenciální spam, případně „zahodit“, a to na základě specifik obsahu SPF záznamu a své vlastní konfigurace.

SPF záznam má obecně následující formát:

V=spf1 [seznam IP adres/doménových jmen odkazujících na určitý systém či systémy, které jsou oprávněny za doménu odesílat elektronickou poštu] [politika pro všechny ostatní systémy]

Záznam může být i citelně komplexnější a položky v seznamu mohou mít různou podobu, nicméně do těchto detailů nebudeme zabíhat. Co si však zaslouží krátké pozastavení, je onen (obvykle) konečný prvek, stanovující politiku pro „neoprávněné“ odesílající servery (tedy ty neuvedené v SPF záznamu). Ten může mít tři podoby:

• ?all  – politika není definovaná. V tomto případě držitel domény říká, že pro jakýkoli explicitně neuvedený server nestanoví, zda má či nemá oprávnění za danou doménu zasílat elektronickou poštu, a výsledek je tak v podstatě stejný, jako kdyby pro doménu žádný SPF záznam neexistoval. Přes uvedené lze nalézt (nejen) v českém prostředí mnoho domén, které mají takový SPF záznam nastaven (viz níže).
• ~all  – tzv. „soft fail“ politika – držitel domény stanoví, že zprávy ze serverů neuvedených mezi „povolenými“ by měly být příjemcem označeny jako potenciálně podvodné nebo umístěny do karantény.
• -all  – tzv. „hard fail“ politika – držitel domény stanoví, že zprávy ze serverů neuvedených mezi „povolenými“ by měly být příjemcem „zahozeny“.

Příkladem reálného SPF záznamu může být ten následující, který je v době psaní předloženého textu aktuální pro doménu Root.cz.

v=spf1 include:spf.smartemailing.cz include:_spf.iinfo.cz ~all

Kontrola SPF tedy umožňuje ověřit, zda byla určitá zpráva odeslána z IP adresy, která je skutečně držitelem odpovídající domény využívána pro zasílání elektronické pošty. Vzhledem k tomu, že ne každý poštovní server je využíván pouze jednou organizací, resp. držitelem jedné domény (například e-mailové servery cloudových poskytovatelů e-mailových nebo marketingových služeb využívají pro odesílání pošty mnohdy doslova sta tisíce různých institucí), pouhá identifikace „oprávněného“ serveru nemusí nezbytně znamenat, že určitá zpráva skutečně byla odeslána držitelem související domény. Pouhé otestování SPF tak není nezbytně průkazné, a ani u zpráv, které testem korektně projdou není zajištěna nepopiratelnost jejich původu. To je jeden z důvodů, proč byl definován standard DKIM.

DKIM

Zmíněný mechanismus umožňuje držiteli domény podepisovat na úrovni vlastních e-mailových serverů všechny odchozí zprávy a publikovat (opět s pomocí speciálního TXT DNS záznamu) veřejný klíč, který následně může server příjemce využít k ověření podpisu určité zprávy. Je na místě zdůraznit, že při využití DKIM jsou zprávy podepisovány odesílajícím serverem, ne konkrétním uživatelem, a kontrola podpisu probíhá na straně přijímajícího serveru. Proces je tedy zcela transparentní jak pro odesilatele, tak adresáta dané zprávy a nejedná se o podpis ve smyslu využití PGP, S/MIME nebo obdobného mechanismu.

Na straně odesílajícího serveru je možné nakonfigurovat, které části zprávy mají být podepisovány, resp. povinně je vždy podepsána informace o odesilateli v hlavičce e-mailu, nicméně volitelně je možné podepisovat i obsah zpráv.

Při současném využívání SPF a DKIM na straně odesilatele i příjemce je tedy do jisté míry zajištěna integrita, autenticita i nepopiratelnost předávaných zpráv. Ale neznamená to, že by tím byly vyřešeny všechny potenciální problémy s podvrženými zprávami. SPF sice slouží k verifikaci domény uvedené v má adrese odesilatele v SMTP „obálce“ e-mailu, a DKIM k verifikaci domény v adrese uvedené v jeho hlavičce, tedy té, kterou příjemce reálně vidí, když zprávu otevře. DKIM, jako podpisový mechanismus, však umožňuje ověřovat platnost pouze těch zpráv, které jsou podepsané. U zpráv bez DKIM podpisu je tak i při podpoře tohoto mechanismu na straně odesílajícího serveru stále nemožné jednoznačně ověřit, zda je nepodepsaná zpráva podvržená či nikoli.

Popsaná skutečnost je jedním z důvodů, proč byl definován poslední z výše zmíněných standardů, tedy DMARC.

DMARC

DMARC je v podstatě nadstavbou nad SPF a DKIM, resp. teoreticky může být reálně nasazen pouze nad SPF nebo pouze nad DKIM, avšak efektivita takového řešení je ve většině případů (v podstatě s výjimkou nastavení „blokačních“ SPF a DMARC záznamů – viz níže) citelně nižší než při použití obou mechanismů současně.

DMARC umožňuje – do třetice, resp. do čtvrtice, počítáme-li DANE – s pomocí speciálního TXT DNS záznamu (tentokrát publikovaného pod jménem _dmarc.doména.tld) držiteli domény publikovat politiku, která mj. specifikuje jak má příjemce nakládat se zprávou, která neprojde kontrolou s pomocí SPF a/nebo DKIM – zda má výsledek kontroly ignorovat, zprávu umístit do karantény, nebo ji „zahodit“.

Vedle toho umožňuje (kromě řady jiných parametrů) DKIM politika určit, zda má být informace o zprávě, která (ne)prošla kontrolou, zaslána zpět držiteli domény a na jaký e-mail. Tento mechanismus lze jednak využít při úvodním nastavování SPF/DKIM/DMARC pro identifikaci chyb v konfiguraci (například pokud by držitel domény zapomněl v SPF záznamu uvést některý ze serverů, který za danou doménu pravidelně legitimně odesílá poštu, velmi rychle by se o chybě v konfiguraci dozvěděl díky informacím od příjemců, že takto odeslané zprávy nesplňují požadavky kontroly SPF), ale také jej lze využít pro detekci phishingu a spamu, u něhož by se jeho autor pokoušel podvrhovat zprávy z relevantní domény.

Základní struktura DMARC záznamu je následující:

v=DMARC1; p=[politika]; [další parametry]

přičemž politika může nabývat následujících hodnot:

• none  – politika není definována – toto nastavení se tradičně využívá pro úvodní konfiguraci DMARC spolu s parametrem stanovujícím kontakt pro zasílání informací o vyhodnocení zpráv od přijímajících e-mailových serverů. To umožňuje držitelům domén ověřit před nastavením rigidnější „blokační“ DMARC politiky, že nedojde k nežádoucí blokaci legitimních e-mailů z jejich domény na straně příjemců. Zmínku zaslouží, že nastavení politiky „none“ bez dodatečných parametrů specifikujících požadavek na zasílání informací o výsledcích kontroly zpráv (RUA a/nebo RUF) má principiálně stejný výsledek, jako kdyby nebyl žádný DMARC záznam publikován, a uvedené nastavení je tak do jisté míry analogické k využívání SPF záznamu končícímu „?all“. Přesto se však lze i s takovými DMARC záznamy v praxi potkat (viz níže).
• quarantine  – politika stanoví, že zprávy nesplňující parametry stanovené SPF a/nebo DKIM by měly být příjemcem umístěny do karantény.
• reject  – politika stanoví, že zprávy nesplňující parametry stanovené SPF a/nebo DKIM by měly být příjemcem „zahozeny“.

Zmínku zaslouží, že stejně jako v případě SPF, i u DMARC nemusí příjemce vždy nezbytně striktně dodržet požadavky stanovené odesilatelem. Jako příklad reálného DMARC záznamu lze opět využít ten nastavený pro doménu Root.cz.

v=DMARC1; p=none; rua=mailto:dmarc+10109@smartemailing.cz; ruf=mailto:dmarc-report@adminit.cz; fo=1

DMARC je významný nejen proto, že umožňuje držiteli domény získávat informace o případných phishingových kampaních cílených na jeho zákazníky, zaměstnance či obchodní partnery, ale také proto, že při ověřování DMARC politiky na straně příjemce se verifikuje tzv. SPF a/nebo DKIM „alignment“, což je kontrola ověřující, zda doména obsažená v adrese odesílatele v hlavičce e-mailu (tedy ne v SMTP „obálce“, jako je tomu u samotného SPF) odpovídá parametrům specifikovaným v SPF a/nebo DKIM. Zatímco tedy první výše zmíněný mechanismus samostatně brání pouze podvržení adresy odesilatele uvedené v obálce, avšak nikoli podvržení adresy, kterou reálně příjemce uvidí, a druhý umožňuje tuto adresu ověřovat pouze u podepsaných zpráv, spolu s DMARC již tyto mechanismy umožňují zajistit určitou míru ochrany i proti podvržení této adresy u nepodepsaných zpráv.

Dobrá odborná praxe, požadavky NÚKIB a významné domény v ČR

Z výše uvedeného by mělo být patrné, proč je nastavení a využívání SPF, DKIM a DMARC pro jakoukoli doménu, z níž je jejím držitelem legitimně zasílaná pošta, považováno za dobrou odbornou praxi. Mělo by být rovněž zjevné, proč je vhodné pro jakoukoli doménu, kterou její držitel pro odesílání pošty nepoužívá, nastavit tak zvaný „blokační“ SPF záznam ( v=spf1 -all) a případně i DMARC záznam ( v=DMARC1; p=reject;), v důsledku čehož by libovolný přijímající server, který provádí SPF a/nebo DMARC kontrolu měl jakoukoli zprávu zdánlivě pocházející z dané domény „zahodit“.

Nastavení a kontrolování SPF, DKIM a DMARC konec konců u „povinných“ organizací také požaduje NÚKIB (pro domény využívané pro odesílání pošty a všechny e-mailové servery), resp. jejich použití doporučuje (pro domény nevyužívané pro odesílání pošty – pro zjednodušení lze říci, že ty nemůže NÚKIB přímočarou cestou regulovat a proto u nich zůstal pouze u doporučení). Na tomto místě je tak vhodné se u požadavků a doporučení NÚKIB krátce zastavit.

Výše zmíněná povinnost nastavit vybrané typy záznamů a mechanismů pro domény užívané pro odesílání elektronické pošty je vcelku srozumitelná a přímočará. Vzhledem k tomu, že relevantní opatření NÚKIB bylo navíc publikováno již v říjnu loňského roku, dalo by se předpokládat, že většina „povinných“ organizací (minimálně z oné první skupiny, které lhůta pro jejich zavedení skončila 1. července) již bude mít vše korektně implementované. Přesto se však stále najde řada takových, které dosud nebyly schopné svým povinnostem dostát.

V rámci přípravy podkladů pro tento článek jsem koncem letošního srpna mj. prošel nastavení SPF a DMARC, i publikaci DANE záznamů pro domény všech českých ministerstev s vidinou toho, že právě tyto instituce by mohly tvořit vhodný vzorek a poskytnout tak alespoň nějakou představu o stavu implementace relevantních mechanismů na straně povinných organizací.

Jak se ukázalo, všechna ministerstva měla implementované validní SPF záznamy korektně zakončené požadavkem na „soft“ nebo „hard fail“ (viz výše) u e-mailů nezaslaných legitimními servery.

Kde již situace nebyla tak růžová, byl DMARC. Pro domény všech ministerstev byly publikovány validní DMARC záznamy, a většina z nich byla nastavena smysluplně, avšak u Ministerstva vnitra a Ministerstva práce a sociálních věcí byly publikované záznamy v podstatě k ničemu. Byly totiž nastaveny na hodnotu „ v=DMARC1; p=none; “.

Jak jsme uvedli výše – publikace politiky „none“, která instruuje server příjemce, aby existenci DMARC záznamu při vyhodnocování e-mailové zprávy ignoroval, je z principu zbytečná, pokud současně není nastavena i e-mailová adresa, na kterou mají být zasílány reporty o vyhodnocování zpráv (RUA a/nebo RUF). I pokud bychom tak ponechali stranou, že NÚKIB explicitně požaduje nastavení DMARC politiky na „quarantine“ nebo „reject“, nastavení DMARC záznamů ze strany jmenovaných ministerstev je sice fakticky provedeno, ale praktický dopad těchto záznamů je nulový (a v některých případech může být dokonce kontraproduktivní).

To lze, téměř rok po publikaci výše zmíněného opatření a zhruba dva měsíce (resp. tři, neb v době publikace článku je situace stále stejná) po uplynutí implementační lhůty, považovat za přinejmenším nešťastné.

Ještě méně optimistická však byla situace na úrovni DANE. Nejenže pro domény některých ministerstev stále ještě nebyl v době sběru dat využíván DNSSEC, ale ani všechna ministerstva, která jej využívají neměla publikované relevantní TLSA záznamy – ty chyběly u celkem šesti ze čtrnácti ministerstev. Vedle dvou výše uvedených institucí, které měly problémy již s nastavením DMARC záznamů, nebyl DANE korektně implementován ani pro e-mailové servery Ministerstva spravedlnosti, Ministerstva dopravy, Ministerstva zemědělství a Ministerstva kultury.

Je pravdou, že povinnost implementovat DANE pro e-mailové servery byl v době publikace opatření NÚKIB relativně živě diskutován a mnozí se vůči němu vyjadřovali kriticky, nicméně přestože globální využití tohoto standardu je prozatím omezené, nelze nepřiznat, že vybraným útokům na e-mailovou komunikaci (nejen) ze strany sofistikovaných, cizími státy sponzorovaných skupin se nelze bez jeho použití efektivně bránit.

Shrnuto a podtrženo, pokud bychom ministerstva skutečně považovali za dobrý vzorek „povinných“ organizací, zdá se, že plné implementaci požadavků NÚKIB stran zabezpečení e-mailových služeb jsme i u oné první implementační skupiny ještě citelně vzdáleni.

Zmínku však zaslouží nejen požadavky NÚKIB, ale také jeho již zmíněná doporučení, která reflektují dobrou odbornou praxi – mimo jiné ta spojená s nastavením „blokačních“ záznamů pro SPF a DMARC u domén nevyužívaných povinnými organizacemi pro odesílání elektronické pošty.

Daná doporučení zmiňuje i NÚKIB, jsou však uvedena ne v samotném opatření, ale v souvisejícím metodickém dokumentu, jehož obsah není jakkoli závazný. Není tedy zřejmě nijak překvapivé, že některé „povinné“ organizace se tak v něm uvedenými doporučeními neřídily. Co však působí poměrně kuriózním dojmem je, že mezi organizace nedodržující daná doporučení patřil ještě na začátku září i samotný NÚKIB.

Kromě výše uvedených domén jednotlivých ministerstev jsem na konci srpna prošel také existenci SPF a DMARC záznamů pro domény NÚKIB (nukib.cz, govcert.cz a nckb.cz), a také několik dalších domén významných z hlediska bezpečnosti. Zatímco pro první dvě uvedené domény byl ze strany NÚKIB nastaven relevantní SPF záznam (a pro první zmíněnou doménu byl nastaven i relevantní DMARC záznam), pro doménu nckb.cz, která není využívána pro odesílání pošty, nebyl nastaven ani jeden z nich. Kolegy z NÚKIB jsem na situaci upozornil a zmíněná doména již v současnosti má nastavený blokační SPF záznam, ale i tak je skutečnost, že samotný NÚKIB se svých doporučení nedržel, lehce humorná.

Pro úplnost je vhodné uvést, že stejná situace vyvstala i v souvislosti s doménou Národního Centra Kybernetických Operací (ncko.cz), a kolegové z Vojenského zpravodajství rovněž na informaci o ní zareagovali promptním nastavením blokačního SPF záznamu.

O poznání složitější je však situace u některých jiných, z pohledu bezpečnosti významných domén – například policie.cz nebo gov.cz. I přes snahu o informování relevantních míst v rámci ministerstva vnitra prostřednictvím řady různých kanálů (včetně několika přímých zpráv i kontaktu skrz NÚKIB a CSIRT.CZ) a opakované urgence z mé strany se zjevně doporučení na nastavení alespoň blokačních (či jakýchkoli jiných) záznamů pro ně prozatím buď ještě nedostalo k relevantním IT specialistům, nebo se nastavení SPF záznamů nezdá být ze strany MVČR z nějakého důvodu žádoucí.

Ať už je důvod zdrženlivosti na straně relevantního ministerstva jakýkoli, v době publikace tohoto článku tak stále může v podstatě kdokoli na internetu za obě jmenované domény volně zasílat e-mailové zprávy, což je přinejmenším nešťastné…

Situace u dalších domén v TLD .CZ

Efektivní fungování bezpečnostních mechanismů v oblasti elektronické pošty je podmíněno jejich podporou na obou komunikujících stranách. Krátkou zmínku proto zaslouží také stav adopce alespoň některých z těchto mechanismů i na úrovni domén, které nepatří „povinným“ organizacím.

Vzhledem k tomu, že kolegové z CZ.NIC, resp. CSIRT.CZ, mi laskavě poskytli agregovaná data ze svých systémů, za což jim tímto ještě jednou děkuji, nemusíme se v této oblasti spoléhat pouze na analýzu vzorku, ale můžeme se podívat na přesná čísla za celou doménu .CZ.

Jak je patrné z následujících grafů, počty domén, pro něž jsou nastaveny SPF záznamy se dlouhodobě zvyšují (včetně počtu domén s nastavením neutrální politiky „ ?all “, byť ta je v porovnání se smysluplnějšími variantami v menšině) a zvyšuje se rovněž procento domén, pro něž je nějaký SPF záznam nastaven.

V době publikace článku má dle dat CZ.NIC validní (alespoň na první pohled) SPF záznam nastaveno téměř 22 % českých domén, přičemž téměř 19 % (lehce přes 270 000 domén) má nastaven záznam stanovující soft nebo hard fail politiku pro zprávy zaslané z neoprávněných serverů.

V oblasti DMARC je situace drobně odlišná. Jak je vidět z následujících grafů, přestože počty domén, které mají publikovanou DMARC politiku rostou, citelně mezi nimi převažují ty, u nichž není zmíněný mechanismus využívaný pro vlastní blokaci nežádoucích zpráv, ale jen (resp. maximálně) sběr informací.

Z dat poskytnutých CZ.NIC se zdá, že validní (opět alespoň na první pohled) DMARC politiku má nastaveno necelých 4,5 % českých domén, a pouze necelých 1,2 % (tedy ani ne 17 000 domén) má nastavenou politiku quarantine nebo reject.

Výše uvedený výsledek nevypadá nijak přehnaně pesimisticky, neboť, i když stávající situace není zcela vyhovující, úroveň adopce SPF iDMARC kontinuálně zvyšuje.

Na druhou stranu je však na místě poznamenat, že ne všechny české domény generují stejné množství e-mailů, a ani některé z těch, které jsou v tomto ohledu v doméně CZ nejvýznamnější, nemají SPF a DMARC nastavené v souladu s dobrou odbornou praxí. Dobrou ukázkou v tomto směru může být například skutečnost, že mezi domény, které mají nastavený SPF záznam s neutrální politikou patří vedle jiných i ty spojené se zřejmě největšími poskytovateli freemailových služeb v ČR, konkrétně domény seznam.cz a centrum.cz (a další domény provozované se stejnými poskytovateli), což lze opět považovat za přinejmenším neoptimální.

Zlepšujeme se pomalu

Jak ukazují dostupná data, úroveň adopce bezpečnostních mechanismů v oblasti e-mailové komunikace se v ČR postupně zvyšuje, byť ani u významných domén ještě není používání těchto mechanismů běžným standardem.

Ačkoli je tak přinejmenším smutné vidět, že ani něco tak relativně přímočarého jako je implementace smysluplných SPF a DMARC záznamů (nemluvě o DKIM nebo DANE) v rozumném čase není pro některé organizace zcela dosažitelný cíl, existuje důvod doufat, že situace se v nadcházejících letech bude pomalu zlepšovat.

Pomoci tomu můžeme konec konců do jisté míry i sami, používáním alespoň základních bezpečnostních mechanismů pro jakoukoli vlastní doménu.