Názory k článku
Identita občana se přesouvá na doménu gov.cz, chce tím bojovat proti falešným webům

Kdo se pohybuje v oblasti bezpecnosti, specificky bezpecnost emailu tak vi, ze k zabezpeceni emailu potrebuji SPF ve kterych definuji kdo muze odesilat emaily, pak potrebuji DKIM ve kterem resim kryptografii a podepisovani emailu a pak DMARC ve kterem muzu nastavit jak nalozit s emaily u kterych nesedi SPF/DKIM. Ze gov.cz nebo jeho subdomeny bezpecnost emailu ve spouste pripadu neresi je podle me problem.

Korektne nastaveny DKIM/DMARC/SPF na strane odesilajici domeny je prerekvizita pro to, aby se prijemce mohl branit podvrhum. To, ze se prijemce nebrani je uz problem prijemce - to uz odesilatel nikal ovlivnit nemuze. Ale v momente, kdy se na to odesilajici domena vykasle uz nemam na strane prijemce jak se branit...

Vyresene to je treba u notifikaci z ISDS nebo treba i system kolem dalnicnich znamek. Vyresene to ma treba i UOOU. NUKIB/GovCert take - ale tam by bylo uz primo epicke selhani, kdyby to nemeli...

ano, ano, ano, ale ne každý subdoména pod gov.cz odesílá emaily.

V rozpoctu NUKIB za rok 2023 ci 2024 najdete polozku prijmy - kde mate 400 tisic z pokut, podobna polozka je i v navrhu rozpoctu na rok 2025. Realne se v roce 2023 vybralo 300 tisic... no takze neco asi pokutuji :)

DKIM/DMARC souvisi s bezpecnosti emailu. Treba PCI DSS vyzaduje DMARC reject od pristiho roku. NUKIB pokutuje treba za nepatchovani systemu vystrcenych do internetu pricemz systemy pod gov.cz evidentne nejsou patchovane. 2 ruzne veci.

PCI DSS se asi nebude týkat webů státní správy :)

Ano, DMARC by měl být všude, ale DKIM může být pouze u domén, které něco posílají (resp. jsou v hlavičkách), což nemusí být doména, kde je web.

Btw, Núkib nepokutuje za to, že je vystrčen nepatchovaný systém, ale že nejsou dodrženy interní postupy, jak se zachovat při zranitelnostech a jak detekovat zranitelnosti. Mitigovat zranitelnost můžeš nejen patchováním.

Neni potreba mit celou zonu, ono DNS odpovi nejak, pokud podstrom s _domainkey existuje... a jinak, pokud tam vubec neni (aneb neni potreba dohledavat vsechny existujici selectory k tomu, abych zjistil, ze DKIM se nekde neresi vubec). Obdobne lze testovat existenci _dmarc, ktery by mel samozrejme existovat take (a tam uz to takova raketova veda neni uz vubec, dany TXT zaznam bud je a nebo neni). A samozrejme existuji nastroje, pomoci kterych si to muze overit i technicky neznalek... jestli dotycna domena DKIM/DMARC teda ma ci nikoliv.

a jak to souvisi s tim ze to neni v DNS zaznamech? Je uplne jedno jak si pojmenuji selector, pokud chci cokoliv overovat tak musi byt v DNS. Jak jiz Danny odkazal odtestovat DKIM/DMARC je docela snadne a opravdu nemusim znat jmeno selectoru.

Můžete ověřit DMARC. Můžete zjistit, že vůbec neexistuje DNS podstrom pro DKIM, jak psal Danny. Ale zda existuje konkrétní selektor neověříte, dokud ten selektor nemáte.

Konkretni DKIM selektor potrebuju znat az ve chvili, kdy overuji podpis v hlavickach daneho emailu. Selektoru muzou byt klidne stovky, kazdy system odesilajici emaily muze mit svuj vlastni selektor (naopak je rizikovejsi pouzivat jeden privatni podpisovy klic napric systemy) - a to ze je konkretni selektor zaneseny v DNS jeste neimplikuje, ze se skutecne pouziva k podpisum hlavicek - tedy informace o konkretnim selektoru je sama o sobe defacto k nicemu.

Zrovnatak plati, ze existence samotneho DKIM je k nicemu - dokud nemate DMARC politiku, tak sice muzete krasne podepisovat hlavicky (a verit jim, pokud tam ten podpis je), ale dokud nemate DMARC, tak email bez DKIM podpisu spokojene projde... (pokud ho nahodou nezastavi SPF). Samotny DKIM - pokud je pritomen - brani jen manipulaci s hlavickami za predpokladu, ze cast hlavicky s podpisem nezmizi, ale pokud z hlavicek DKIM podpis vyhodim, pak s temi hlavickami muzu manipulovat opet jak chci.

Proste resit konkretni selektor bez dalsiho nedava smysl. Vracime se zpet k tomu, ze staci overit, zda se DKIM vubec nekdo zabyval... ale hlavni teziste pruzkumu toho, jak moc to z bezpecnosti mysli vazne je u politiky popsane v DMARC (te casti, co specifikuje chovani ve vztahu k DKIM).

Danny: Pletete páté přes deváté.

DMARC politika pro doménu by měla být nastavená, o tom žádná. Zejména pro doménu, ze které se žádné e-maily odesílat nemají – pak je konfigurace jednoduchá.

Pro validaci správnosti DKIM potřebujete nějaký e-mail zaslaný z té domény – a pak stejně ověříte jenom ten jeden selektor. Bez toho můžete zjistit akorát to, že v DNS není žádný DKIM selektor nakonfigurován. Což je ovšem pro doménu, ze které se nemají žádné e-maily posílat, zcela legitimní stav.

Není pravda, že DKIM je bez DMARC k ničemu. Podle standardů má mít doména DMARC, ale DMARC je jen doporučená politika pro příjemce. Příjemce e-mailu se klidně může rozhodnout, že bude vyžadovat u příchozích e-mailů DKIM, a DMAR ho nemusí zajímat. Bylo by to drsné opatření (ale dávalo by mi větší smysl, než e-maily odmítat na základě pochybných nikde nepopsaných pravidel např. podle názvu odesílajícího stroje).

Tak si pozorneji prectete dnes aktualni RFC 6376, sekci 6.3 - to, ze pisete blbost s vynucovanim pritomnosti samotneho DKIMu (bez dalsiho) je jen dukazem, ze jste standard priliz pozorne nestudoval. Obecne odmitnout email jen proto, ze hlavicky postradaji DKIM podpis neni z pohledu internetovych standardu zcela konformni chovani - delat by se to proste nemelo. Ano, dve strany se teoreticky muzou dohodnout na takovem chovani - ale to mj. znamena nekde bokem udrzovat databazi, ve ktere si budu drzet prehled domen, ze kterych je DKIM striktne vyzadovan - proste jen predvadite zase "teoretizovani" zcela vytrzene z praktickeho zivota. Krom jineho prave proto vznikl (az nasledne) DMARC aka RFC 7489, ktery dany problem resi systemove - tak, ze nerozbije dorucovani z domen, kde DKIM zatim implementovany nemaji. A ano, nekteri hraci typu Microsoft ci Google si ty standardy obcas ponekud priohnou a vynucuji nekdy i veci nad ramec standardu - ale to porad neznamena, ze jejich pocinani je spravne, tam se pouze zneuziva sily/dominance. Rozhodne takovy pristup ale nejde doporucit jako obecne univerzalni reseni pro kazdeho provozovatele MTA...

Danny: Významy termínů SHOULD NOT, SHOULD a další najdete v RFC 2119.

Ja ty vyznamy znam, to vy si je vykladate ponekud extenzivne... nebo chcete-li po cesku, tak dost gumove, zvlast pokud je rec o tom, co by se delat nemelo...

Danny: Já jsem nenapsal nic, co by bylo v rozporu s vámi uvedenými RFC. To jenom vy máte potřebu všemu oponovat.

DMARC je jasný, ale pro DKIM prostě potřebuješ znát alespoň doménu, z které se to posílá, jinak je to cákání do vody.

Pokud primo gov.cz ma definovy MX zaznam smtp-cms.gov.cz tak je mozne posilat primo z gov.cz emaily tudiz by se mela resit jejich bezpecnost. Pokud neni zapotrebi posilat primo z gov.cz emaily tak nebudu mit MX zaznam. Ze to Ministerstvo vnitra systemove neresi je jejich problem. Snaha mit statni systemy pod .gov.cz se ceni ale je to furt k nicemu pokud ty systemy nebudou splnovat nejake minimalni bezpecnostni standardy. Ze si to musi resit vlastnici tech systemu je vec politicka stejne jako to ze nikdo za nic realne neodpovida... mame tady XX let pozadavek na to aby statni systemy meli IPv6 a staci se podivat jak na to spousta statnich organizaci prdi.

Pokud primo gov.cz ma definovy MX zaznam smtp-cms.gov.cz tak je mozne posilat primo z gov.cz emaily
Nikoli. MX záznam se týká příjmu e-mailů, ne odesílání.

Zbytecne slovickareni - nicmene lze predpokladat, ze pokud se na nejake domene emaily prijimaji, tak se ty emaily pouzivaji i pro odesilani. A muzou to byt emaily klidne "systemove", tedy emaily jejichz existenci predpoklada nejake RFC.

server (endpoint, doménu), která by emaily posílala a příjímala zároveň jsem nedělal už pěknou řádku let, i z ohledem na potřeby škálování a rozdílných potřeb pro řešení bezpečnosti se to rozděluje.

To jde vidět i na těch odesílacících doménách @identitaobcana.cz @notifikace.gov.cz nemají MX záznamy, používají se pouze pro posílání. Něco jiného může být třeba pcr.cz, odkud emaily a přijímají zároveň, to může být dáno i historicky, mají to tak prostě 30 let či jak dlouho. Dnes se ale snažíme co nejvíce ty služby oddělovat, nemít web na stejné doméně jako odesílání nebo přijímání emailů hlavně z důvodu snížení vektoru útoku v případě nějakého průniku, zlepšení flexibility na použití různých čistístích brán a přesměrování provozu v případě útoku atd.

To muze byt taky zradne - uz jsem se setkal s MTA, kde odmitaji prijem emailu z dane domeny, pokud pro danou domenu neexistuje MX zaznam - pripadne v "lepsim" pripade to jenom zvysi skore v ramci anti-spamu. Setkal jsem se i s problemy v pripade existujiciho null-MX zaznam v duchu RFC 7505...

Ano, obcas jsou takova reseni jakoze dost na hrane - na druhou stranu, pokud chcete nahlasit problem k takove domene, co "jen odesila", taky to dost komplikuje zivot. Protoze pak nemate sanci ani pouzit genericke kontakty typu abuse@, postmaster@ na reportovani problemu vztazenych k dane domene... a krome bohulibych ucelu typu ty notifikace je tu samozrejme velka skupina tech, co to delaji zamerne - a jde jim jen o to sve sdeleni dorucit... a odpoved je nezajima. Ano, bavime se o spammerech ;-) Ten led, po kterem se brusli.... je proste moc tenky.

Danny: Hlavně že výše rozporujete věci, které RFC explicitně nezakazuje (jen je nedoporučuje ale říká, co by měl dělat, pokud to tak chce dělat). A pak tady obhajujete věci, které nemají v RFC vůbec žádnou oporu.

Ja je neobhajuju, ja pouze popisuju jejich existenci. Narozdil od vas se nepohybuju v teoretickem prostredi a naopak casto resim ty problemy v praktickem realnem zivote. To ze to vy nedokazete odlisit je ciste vas problem... to se internetovym teoretikum stava, ze realitu sveta venku nevnimaji ;-)

Hlavně že si to vždycky dokážete zdůvodnit, že když něco děláte vy, je to vždycky správně, a když to samé udělá někdo jiný, je to špatně.

Ja svuj nazor narozdil od vas dokazu korigovat, pokud se ukaze ze pohled protistrany je relevantni. Ale to vy neumite... :-)

Tak určitě.

ty MTA ale pravděpodobně kontrolují nejen odesílací doménu, ale třeba i reply-to či jiné hlavičky. Prázdný MX atribut (nikoliv neexistující) ale může být problém, to nemusí mít dobře ošetřené, to už jsem také řešil.

Vyzkoušeno, abuse@identita­obcana.cz či postmaster@iden­titaobcana.cz nefunguje, což je samozřejmě v rozporu třeba s RFC 2142. Naopak pro subdoménu identita.gov.cz to není povinné a postmaster@gov.cz funguje, již zkoušeno.

Hlášení je každopádně vždy věda, koukáš na hlavičky, koukáš na domény v cestě, koukáš na reply-path a na konci dojdeš buď na samotnou doménu, registrátora, hosting nebo ASN, tak to hlásíš tam. Pokud ani jedno nefunguje a škodlivost je značná, blokuješ co nejdále od teba a nejblíže ke zdroji.

Myslím, že neexistence abuse@identita­obcana.cz mě reálně netrápí a je dobře, že přechází na identita.gov.cz, protože tam to za ně jednotně řeší gov.cz a o tom to je.

No z pohledu "mistnaka" to muze byt uchopitelne, my strukturu nasich uradu plus minus zname... ale je to ignoranstvi, protoze lide z okolniho sveta se uz te lokalni strukture zas tak orientovat nemusi, no spis nebudou vubec.... stejne jako pro nas asi bude tezko uchopitelna uradu nekde (treba) v Brazilii. Ty standardy vznikly s nejakym globalnim mind-setem, coz se odrazi mj. v tom, ze tam je spousta nedokonalosti - coz je vysledek nejakeho kompromisu. Ale pokud se i na tohle kasle, je to proste smutne.... ale ano, je to fakt, ze na nejktere "zakladni" teze se proste s oblibou kasle ledacske.

MX a DMARC/DKIM/SPF jsou ale opačné strany jedné trubky. Že ty šachuješ s termíny aniž bys tušil?