DKIM – podepisujeme e-maily na serveru

15. 5. 2009 | František Kučera | Bezpečnost | 26052×

Elektronická pošta stojí na protokolu SMTP, který pochází z osmdesátých let, a její uživatelé dnes často trpí spamem. Jedním z největších problémů je praktická nemožnost dohledat, kdo daný e-mail odeslal. Proto vznikl standard DomainKeys Identified Mail (DKIM), díky kterému můžeme ověřit původce zprávy a další informace z hlaviček e-mailu.

Princip fungování

DKIM využívá elektronický podpis s dvojicí soukromý a veřejný klíč. K podpisu soukromým klíčem dochází na SMTP serveru (např. firemní server nebo server poskytovatele připojení) a není potřeba žádná součinnost ze strany uživatele. Předmětem podpisu je hash těla zprávy, některé hlavičky a hlavně doména, ze které e-mail pochází.

Pro distribuci veřejných klíčů se využívá DNS a předpokládá se, že DNS záznamy pro danou doménu může nastavovat jen její vlastník.

Server příjemce si tedy veřejný klíč pro danou doménu stáhne z DNS a ověří pomocí něj elektronický podpis zprávy.

Srovnání s S/MIME a GPG podepisováním

Jedná se o dvě různé úrovně podepisování e-mailů. V případě S/MIME nebo GPG podepisuje zprávu její autor (osoba) a tento podpis je vázán na danou e-mailovou adresu. Zatímco DKIM podpis pouze dokazuje, že e-mail pochází z dané domény.

Podepisování na serveru a podepisování odesílatelem se vzájemně nevylučují. Je možné obě metody kombinovat – každý podpis slouží k jinému účelu.

Nasazení v praxi

Na příkladu Postfixu si ukážeme, jak do svého poštovního serveru můžeme podporu DKIM přidat. K zapojení DKIM do procesu zpracování pošty použijeme technologii milter, takže postup v případě, že používáme místo Postfixu Sendmail, bude velice podobný.

Nainstalujeme si potřebný balíček – v Debianu/Ubuntu by to šlo takto:

# aptitude install dkim-filter

Vytvoříme si podpisový klíč:

# mkdir /etc/mail
# cd /etc/mail
# dkim-genkey -d naše-doména.cz

Program nám vygeneroval dva soubory: default.private (soukromý klíč) a default.txt (soubor obsahující veřejný klíč a informace pro nastavení DNS). Soubor se soukromým klíčem by měl patřit rootovi a neměl by být čitelný jinými uživateli.

Poznámka: při generování klíče můžeme zadat i tzv. selektor (parametr -s) – pro jednoduchost použijeme výchozí: default.

Teď potřebujeme nastavit správně DNS, aby ostatní servery mohly zjistit, jaký je náš veřejný klíč. Vytvoříme si DNS záznam podle vzoru uvedeného v souboru default.txt. Např.:

default._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQPmhgFl/Zj6f7ciMCyMYBk8oeSAJOOxBrgqarIyjkmeTNOr3oMeneP/uLOT9zP5VGYLUtepalxDsbs2WypjDa6MOm7mPHOrsW8WSSKTDTQsGyGekMgPu2QhV5I7BjTzIpYyOOJNoqMYKoqckQBno7CLaXuwI7lIvcc3Jdo7f+MwIDAQAB" ; ----- DKIM default for veverka.ch

Pokud zadáváme záznam do webového rozhraní našeho správce DNS, zadáme default._domainkey a v=DKIM1; g=*; k=rsa; p=MIGfMA0G … wIDAQAB (bez uvozovek) a zvolíme typ záznamu TXT.

Nastavíme si DKIM milter: v souboru /etc/dkim-filter.conf zadáme tyto hodnoty:

Domain                  naše-doména.cz
KeyFile                 /etc/mail/default.private
Selector                default

A do souboru /etc/default/dkim-filter přidáme řádek:

SOCKET="inet:8891@localhost"

DKIM teď bude naslouchat na místním portu 8891. Místo síťového portu můžeme použít i UNIXový socket.

Zbývá už jen nastavit Postfix – do souboru /etc/postfix/main.cf přidáme tyto řádky:

# DKIM podpis SMTP serveru
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

A výsledek…

E-maily odeslané z naší domény teď budou obsahovat elektronický podpis. Jedná se o podpis serveru, nikoli odesílatele (osoby). Podpis je realizován formou hlavičky ve zprávě – např.:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=veverka.ch;
	s=default; t=1241265143; bh=opC+T+DvWgIbxfSLcsOLnAcFxNGJTZfSK4iWmZj
	Vwic=; h=Message-Id:Date:From:To; b=DOhq7UkgV0xHaVrrOEP17cv/iwDo9Dw
	tqgxOeI2q5ei4ab/Io5TWCDFS9M9RxbHnBNGHXbAUYjz83R+bFbPVIwRwQAzuanNNjS
	SVd4cEw6ClLnPLi3AMeDdaYXm2GhY96sFBKzoXCtVolv04nF+O0811T8NRIbz0+F6zz
	317QSM=

DKIM-filter podpisy zpráv nejen vytváří, ale i ověřuje. Pokud máme dva servery s podporou DKIM, můžeme si to snadno vyzkoušet. Výsledek pak vypadá takto:

Authentication-Results: veverka.ch; dkim=pass (1024-bit key)
	header.i=@frantovo.cz; dkim-asp=none

Cílový server ověřil elektronický podpis (veřejný klíč zjistil z DNS záznamu) a vložil hlavičku o úspěšném ověření. Pokud zkusíme podpis podvrhnout, např. tak, že na odesílacím serveru nastavíme jiný klíč a neaktualizujeme DNS záznam, výsledek bude tento:

Authentication-Results: veverka.ch; dkim=hardfail (verification failed)
	header.i=@frantovo.cz; dkim-asp=none

Jestliže nemáme dva e-mailové servery s DKIM, můžeme si jeho funkčnost ověřit např. tak, že pošleme e-mail na adresu firmy Eland Systems: autorespond+dkim@dk.elands ys.com. Za chvíli nám přijde odpověď s výsledkem, zda se náš podpis podařilo ověřit. Nebo si můžete poslat zprávu do schránky na GMailu a ve webovém rozhraní se vám u přijaté zprávy ukáže: podepsáno od naše-doména.cz.

Závěr

DKIM je jedna z technologií, která může pomoci v boji proti tolik nenáviděnému spamu. Nepodepsané (nebo špatně podepsané) e-maily sice nebudeme zahazovat jako spam, ale ty správně podepsané za spam považovat nemusíme. Pokud by se přesto o spam jednalo, víme alespoň, kdo je za něj zodpovědný.

Zároveň může DKIM podpořit důvěryhodnost e-mailů pocházejících z vaší organizace u jejich adresátů. Tedy alespoň u těch, kteří tyto podpisy dokáží interpretovat a ověřovat (např. uživatelé GMailu). I přes absenci elektronického podpisu, jako je S/MIME či GPG, je příjemce schopný ověřit původ zprávy – alespoň na úrovni domény, např. firma.cz. Což může teoreticky fungovat jako opatření proti podvodným e-mailům – rhybaření (phishing) – a to především při nasazení Author Domain Signing Practices.

       

Komentáře

[Shadow]

Skvělý článek, díky.

[Kenji]

Děkuji, jdu si to nahodit na server

[peter]

Dobré a jednoduché.

Ja by som však všetky maily z domén, ktoré majú v DNS publikovaný tento kľúč a sú ním nepodpísané zahadzoval. Takisto zahadzovať maily, ktoré majú chybný podpis. Dá sa to takto nastaviť?

Dobré by bolo, keby sa to dalo integrovať aj s greylistingom, t.j. podpísaný mail prijať okamžite ostatné predať na greylist (teda dočasne odmientnuť s chybou 4xx, čo normálny server doručí do 20 minút).

Inak podobný výsledok dostaneme aj so SPF. Tam v DNS publikujeme servre, ktoré môžu odosielať poštu z našej domény. V tomto prípade netreba rátať hash a kryptograficky ho overovať, ale stačí pozrieť IP adresu servra, ktorý mail posiela. BTW cca pred 2 rokmi som si prebehol celú sk. doménu a SPF používalo cca 2,5 % domén.

[Chulda]

No, zahazovat muzete, ale ne vsichni posilaj firemni emajl pres firemni mailserver, protoze jim to zrovna podminky jinak neumoznuji.

[St4nd3l]

A to je prave spatne tohle by si mel kazdy admin ohlidat nikdo nebude posilat firemni postu pres nejakeho ISP horni-dolni. Pokud uz nekdo chce odesilat postu a port 25 je blokovany ma to udelat bud pres VPN a nebo pres web rozhrani.

[linuxnew]

souhlasim s vami, prakticky stejny problem vznika s nasazenim SPF

[Michall]

paráááda

[oron]

ak mam se servery viacej domen a chcem pre kazdu zvlast podpis ?

vygenerujem kluc, ale kde zadam postfixu ktorym klucom ma podpisovat maili pre danu domenu ?

 

[iwk]

no to je cely problem DKIM - nefungovanie s viacerymi domenami, ktore ho cini dost nepouzitelnym v praxi.

[xkucf03]

To naštěstí ne – jsou dvě řešení:

• používat pro více domén stejný klíč – pokud běží na jednom fyzickém serveru, tak je to nejjednodušší a přitom bezpečné řešení
• nebo použít KeyList viz komentář pode mnou.

DKIM milter potom pro svoje domény klíč přidává a pro cizí ho ověřuje.

[R]

V konfiguraku dkim-milter.conf namiesto KeyFile pouzijes KeyList. (Nezadavas to Postfixu, on o tom nic nevie).

[Bigbunny]

Pro Debian Edge balicek tento balicek neexistuje? Jak tento balicek/program zprovoznit na debianu etch?  Dekuji Jakub

[Shadow]

V backportech není? Jinak zkusit najít repository pro etch, kde bude, přinejhorším najít homepage a zkompilovat ručně.

[Bigbunny]

Uz jsem to nasel....

http://debian.incertum.net/

[CEST]

No ja nevim, jestli mi to v necem pomuze. Bude mi celkem asi jedno, kdyz mi prijde 10 spamu, ktery budou mit podpis od odesilajiciho serveru. At uz to bude poslany primo od nejakyho spamera pres server podepisujici zpravy, nebo od nejaky obeti-zombie z outlooku nebo primo nejakym spam-softem.

Osobne si myslim, ze proti spamum by byla ucina zbran prave podepisovani certifikatem podepsany nejakou kvalifikovanou certifikacni autoritou, nebo minimalne GPG (pokud by si nekdo nechtel platit kvalifikovany certifikat a domluvil se s prijemcem na duvere).

Pak bych mohl automaticky zahazovat (nebo oznacovat) emaily bez podpisu. A pokud by mi prisel spam s podpisem, tak by se presne vedelo, kdo za tim stoji. Certifikaty dneska podporuji uz snad vsechny klienty, pripadne si uzivatele muzou importovat vlastni CA (treba levnejsi nez ty nejznamnejsi). Pokud by klient podporoval i cache hesla k certifikatu nebo klici, tak by to ani pro uzivatele nebyl problem jednou denne zadat heslo. Stejne dneska uz clovek pouziva na dost mistech certifikaty, takze by to nemusel byt takovy problem s nasazenim. A overovani by mohl zajistovat server, nebo dorucovaci agent nebo primo klient.

[Zdenek]

A co zabrani malware na zombie hostech rozesilat takto podepsane maily? Zvlaste kdyz, bude klient podporovat vami navrhovane chachovani hesla k certifikatu. Ale i tak neni problem si to heslo odchytnout a pak ho pouzit.

[User682]

zdravim,

pouzit certifikaty by v necem pomohlo. A byl bych jednoznacne pro.

I kdyz spammer Vam casem bude klidne podepisovat dokumenty certifikatem z Verisign.

Jenomze to ma par hacku, minimalne u nas v "Bananistanu" = CR.

0) dokud nebude certifikat pro uzivatele za pivo (invex, interval.cz, hlaska), tak to nema smysl. O cene serverovych certifikatu radeji nemluve.

1) hodne velky problem je jednoduse nainstalova a vubec nainstalovat certifikat pro usery. Idealne vyridit a predinstalovat do postovniho klienta.

2) zakony. Spam se bude rozesilat a nikomu se moc nestane. Anebo musite podepsat neco o ochrane udaju a opet v tom litate.

3) Misto obcanky chipovou kartu a na ni mit certifikaty. Idealne mit nejakou klicenku se statnimi a duveryhodnymi certifikaty.

4) Dokud bude bezpecnost v rukou Microsoftu, tak bych to ani nedelal. To proste nema smysl. At uz aplikace nebo hlasky typu nebezpecny obsah s certifikatem....

5) ono bylo vcelku chyba, ze se v hodne protokolech nepouziva defaultne nejake SSL/TLS a podobne.

Certifikaty jsou kouzelna technologie. Jen IT svet ji nejak nezvladl.

gf

 

[xkucf03]

I kdyz spammer Vam casem bude klidne podepisovat dokumenty certifikatem z Verisign.

Pak ale půjde dohledat, kdo spamovat.

hodne velky problem je jednoduse nainstalova a vubec nainstalovat certifikat pro usery. Idealne vyridit a predinstalovat do postovniho klienta.

V první řadě musí uživatelé používat poštovního klienta. Pro mě je to samozřejmost, ale lamy si chodí číst poštu přes web. Nechápu.

Misto obcanky chipovou kartu a na ni mit certifikaty. Idealne mit nejakou klicenku se statnimi a duveryhodnymi certifikaty.

Moje řeč Tohle by s elektronickým podpisem hodně pohnulo – každý by měl svůj certifikát na kontaktní čipové kartě a zároveň by to byla občanka.

ono bylo vcelku chyba, ze se v hodne protokolech nepouziva defaultne nejake SSL/TLS a podobne.

Dnes hlavně FTP a SMTP – FTP by se mělo zahodit úplně (resp. používat jen pro anonymní veřejné stahování) a používat místo něj SFTP. SMTP by šifrování prospělo, taky se někdy mezi servery používá*, ale v principu to nikoho nespasí – člověk dopředu neví, jestli se všechny servery po cestě domluví na TLS, tudíž by měl stejně šifrovat na úrovni zprávy (S/MIME nebo GPG).

Certifikaty jsou kouzelna technologie. Jen IT svet ji nejak nezvladl.

Nemyslím si – vždyť na certifikátech a PKI stojí dneska všechny banky a elektronické obchody, bez SSL by tenhle byznys byl nepředstavitelný. Jenže to jsou serverové certifikáty, s klientskými je to horší – ty občanky s tokenem by hodně pomohly…

*) mezi klientem a serverem to považuji za samozřejmost, když se klient prokazuje jménem a heslem.

[imro]

No, a prave vsetko toto by mohlo vyriesit SPF. Ono, dnes spamy rozosielaju hlavne vselijake zombie pocitace. Tych je povedzme 10 000(este dost male cislo). A ak by mal spammer udrzovat pre kazdu domenu tych 10 000 ip adries ktore mozu pre danu domenu rozosielat maily, tak by sa asi zblaznil. Naviac, je to skoro nerealne. DKIM je super vec-spolu s SPF sa doplnaju. Myslim si,ze keby vsetky mailove servre zacali SPF pouzivat, tak by sa spam minimalne obmedzil a spammarom by to pridalo omnoho viac prace.

......................................

Za DKIM zase hovori to, ze ak by mal spammer pre kazdu priblblu domenu generovat certifikat ktory je za prachy, tak by ho to stalo dost vela prachov-naviac mal by viac papierovaciek a zmenit odosielaciu domenu by nebolo az tak jednoduche.

[petr_p]

Tedy se vracíme k tomu, že kdo nemaže, ten nejede – kdo si nezaplatí doménu, delegaci reverzní domény, certifikát a nenechá si server posvětit jedinou správnou církví, tak e-mail neodešle. Ne, pěkně děkuji, takové protokoly nepotřebuji.

[xkucf03]

Tohle vůbec není nutné*, SPF a DKIM ADSP jsou více méně alternativy – jedna pracuje s oprávněnými IP adresami a druhá s oprávněnými podpisovými klíči – v obou případech si ale ty oprávněné klíče nebo IP adresy propaguješ sám skrze DNS → nemusíš tedy platit nic navíc, stačí mít vlastní doménu. Nemusíš se ani nikoho ptát nebo žádat o posvěcení certifikátu nějakou autoritou – prostě si jen vytvoříš soukromý a veřejný klíč a ten veřejný vystavíš do DNS záznamu (TXT). Vedle toho do DNS můžeš vystavit i pravidlo, že všechny e-maily z tvé domény musí pocházet od vybraných IP adres, nebo být podepsané vybraným klíčem.

Ať jedno či druhé, přijde mi to jako velice rozumné řešení, protože jako vlastník doménového jména můžeš omezit, odkud se pošta z tvé domény smí posílat, ale nic to nestojí. Kdo nemá vlastní doménu, ten používá např. SMTP server svého poskytovatele nebo firmy, školy atd. → takže není problém, aby tenhle SMTP server byl mezi těmi, které z dané domény smějí posílat.

*) pravda, Microsoft by si přál, aby se platilo za kde co a on si z těch peněz mohl část užírat, ale to mu neprojde.

[Filip Jirsák]

A pokud by mi prisel spam s podpisem, tak by se presne vedelo, kdo za tim stoji.

Ale to je přesně to, co DKIM dělá. Vás totiž nezajímá, kdo SPAM vytvořil, vás zajímá, kdo vám ho poslal. A to právě podle DKIM zjistíte. Pokud ho ten dotyčný poslal kvůli špatné konfiguraci serveru nebo zavirovanému počítači, je to stejně jeho problém a on ho musí vyřešit. Pokud se má bojovat se spamem tak, že se budeme snažit zabránit posílání spamu, nejde řešit původního odesílatele (ten se klidně bude připojovat pokaždé odjinud pod jinou identitou), ale právě toho, kdo e-mail (byť třeba nechtěně) rozesílá.

[xkucf03]

BTW: spam chodí i ze „seriózních“ domén (Hotmail…), přímo z jejich serverů – psal jsem jim stížnost, ale neobtěžovali se s odpovědí – kéž by aspoň tomu chudákovi, který to posílal, zablokovali SMTP a upozornili ho – pravděpodobně má postižené Windows a z jeho počítače se spamuje.

Tyhle případy DKIM nevyřeší, ale spoustu spamu, který je odesílaný z pochybných serverů ano – hlavně když se nasadí DKIM ADSP, což je alternativa k SPF

[Filip Jirsák]

Tyhle případy to vyřeší – pokud bude běžné blokovat servery, které rozesílání spamu neřeší, budou to muset řešit i servery jako Hotmail či GMail. A ty už to můžou řešit velice snadno, můžou spamujícímu uživateli zakázat přístup. problém (ale jejich), je, co s novými účty – ale ty mohou být třeba v jakési karanténě a server nebude e-maily poslané z nového účtu třeba nějakou dobu podepisovat nebo je bude podepisovat jiným klíčem.

[xkucf03]

Noví uživatelé by mohli mít nějakou kvótu – třeba postal nanejvýš deset zpráv¹ za den… a kvóta by jim postupně rostla, až by časem omezení neměli vůbec. Uživatelé by si svých účtů aspoň víc vážili. Kdyby někdo zaspamoval, tak by o účet přišel, nebo by přinejmenším dostal omezení (mohl by jen přijímat a posílat jen málo zpráv). Časem by se vyprofilovaly důvěryhodné servery, které nepodporují spamery a mají takto přísná pravidla, a ostatní by od nich mohli bez obav přijímat poštu – a vůči ostatním by se praktikovaly přísnější metody (např. greylisting, který zdržuje poštu).

1. nepočítaly by se na kusy odeslané, ale na počet příjemců (kopie, bcc). BTW²
2. Jsou lepší čísla*

*) nebo hvězdičky?

[Bigbunny]

Predpokladam, ze DNS se mysli NS pro danou domenu....overitelny napr pres dig domena.cz NS  ....?

Diky

[R]

Do DNS sa mysli vlozit ten TXT zaznam do domeny, z ktorej sa budu maily podpisovat. Overit sa to da napr. "dig TXT default._domainkey.domena.cz".

[R]

Skusam to s Postfixom, ale mam problem. Pouzivam aj spamassassin (cez spamc ako content_filter). A problem je v tom, ze sa do odchadzajucej spravy dostane dvakrat.

Mam sice v master.cf nastaveny content_filter len pre smtpd z vonkajsej IP, ale toto sa pouzije aj v pripade, ked sa pripajam znutra na vonkajsiu IP (v konfiguracii mail klienta to tak musi byt, lebo hostname sa porovnava s TLS certifikatom).

Takze mail sa podpise, potom to prejde cez spamassassin a podpise sa znovu. Cez test http://www.mailradar.com/domainkeys/ to nepreslo.

[R]

Aha, takze problem vyrieseny:

1) Nepouzivat "smtpd -o content_filter" v master.cf ani rozdelenie podla IP. Namiesto toho pouzit check_sender_access v smtpd_recipient_restrictions - napr.:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_sender_access regexp:/etc/postfix/filter.regexp
        reject_unauth_destination,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        permit

Subor filter.regexp obsahuje len jeden riadok:

/^/     FILTER filter:

("filter" je definovany v master.cf)

To sposobi, ze vsetci z lokalnej siete a prihlaseni budu pusteni bez kontroly, inym sa nastavi content_filter na "filter".

2) Ten test nie je pre DKIM, ten elandsys funguje.

[R]

Este som prehodil check_sender_access az na predposledne miesto (pred permit), aby to zbytocne nic nerobilo, ked sa sprava odmietne.

[jd]

asi jsem tupy, ale "("filter" je definovany v master.cf)"

jak? kde?

[R]

V mojom pripade je "filter" existujuci filter, ktory sa pouzival doteraz (spamassassin a anomy-sanitizer spustane z jedneho skriptu):

filter    unix  -   n   n   -   -   pipe
    flags=Rq user=filter null_sender= argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient}

[jd]

jde to i jinak do casti preposlani do scanneru

127.0.0.1:10025 inet    n       -       -       -       -       smtpd

pridate

        -o smtpd_milters
        -o non_smtpd_milters
 

[R]

Take nic som tam nemal a ani nemam. Islo to cez filter naspat na port 25. A hlavne to neriesi povodny problem, ktorym je prechod odchazdajucej posty cez spamassassin - ten je neziaduci.

[Petr]

Výborný příspěvek. Díky za něj!