DKIM – zavádíme podpisovou politiku (ADSP)

5. 10. 2010 | František Kučera | Bezpečnost | 14683×

Dnes volně navážeme na článek o DKIMu, ve kterém jsme naučili náš poštovní server podepisovat e-maily, a povíme si něco o ADSP (Author Domain Signing Practices), pomocí kterého říkáme ostatním serverům, jaká je podpisová politika naší domény.

Co je ADSP a co nám přinese

Samotné podepisování odchozích e-mailů a jejich ověřování serverem příjemce (DKIM) je sice hezké, ale nemá skoro žádné praktické přínosy – snad jen to, že ve webovém rozhraní GMailu se příjemci zobrazí: podepsáno od naše-doména.cz nebo že si pokročilý uživatel může zobrazit zdrojový kód zprávy a v něm zkontrolovat hlavičku Authentication-Results.

Praktických přínosů se dočkáme až po nasazení technologie ADSP, která na DKIM navazuje. ADSP je způsob, kterým vlastník domény může sdělit světu, jak je to s podepisováním jeho e-mailů. Na výběr má tři možnosti:

• unknown – neznámá politika, některé e-maily z domény mohou být podepsané, jiné ne. Tomu, zda jsou dopisy podepsané nebo nepodepsané, nebudeme přikládat žádnou váhu.
• all – všechny dopisy z dané domény jsou podepsané. E-maily, kterým podpis chybí jsou podezřelé a příjemce je může podrobit přísnější kontrole – ale neměl by je zahodit/odmítnout jen na základě toho, že jim chybí podpis.
• discardable – všechny dopisy z dané domény jsou podepsané. A pokud ne, je doporučeno je zahodit – „the domain encourages the recipient(s) to discard it“

K čemu je tedy zavedení ADSP dobré?

Jako příjemce e-mailů se můžeme zbavit části spamu – nevyžádané pošty. Nepodepsané e-maily tvářící se být z domény, která má discardable politiku můžeme klidně zahodit/odmítnout a nemusíme jimi zatěžovat své uživatele. Bohužel se zbavíme jen části spamu, protože spameři často využívají zavirovaných klientských počítačů (typicky s Windows), ze kterých uživatelům ukradnou jejich jméno a heslo – a spam odesílají pomocí nich, takže může mít platný DKIM podpis. Přínos je ale každopádně v tom, že víme, z jakého serveru spam pochází a vlastník tohoto serveru ví, přes který uživatelský účet byl odeslán – je tak možné danému uživateli zablokovat SMTP, nastavit mu kvótu na odchozí e-maily nebo ho vyzvat k nápravě (odvšivení počítače).

Nastavením discardable politiky se jako vlastník domény budeme bránit rhybaření resp. podvodným dopisům. Nikdo pak nebude moci posílat e-maily, které se tváří, jako že jsou z naší domény. Alespoň ne na servery, které respektují ADSP politiku ostatních domén. Toho využívá např. platební systém PayPal.com. Nasazením ADSP na straně serveru příjemce ochráníte své uživatele před těmito podvodnými e-maily.

Nasazení v praxi

Podepisování e-mailů máme zprovozněné už od minule, teď se proto budeme soustředit jen na změny související s nasazením ADSP, nikoli samotného DKIMu.

DNS – na straně odesílatele

Jako vlastník internetové domény si definujeme ADSP politiku – to je velice jednoduché, stačí vytvořit příslušný DNS TXT záznam pro naši doménu:

_adsp._domainkey.example.com. IN TXT "dkim=discardable"

Místo discardable můžeme použít mírnější all (viz význam politik výše). Politiku unknown nemá moc smysl nastavovat, protože stejně se interpretuje, i když ADSP záznam úplně chybí.

DKIM Milter – na straně příjemce

Pro ověřování podpisů a souladu s ADSP politikou použijeme stejný software jako pro podepisování odchozích zpráv: DKIM Milter (viz předchozí článek). Jediné, co musíme udělat, je upravit konfigurační soubor /etc/dkim-filter.conf – přidáme do něj řádek:

ADSPDiscardyes

A restartujeme filtr:

/etc/init.d/dkim-filter restart

Po této úpravě bude náš server respektovat ADSP politiky ostatních domén a pokud se někdo pokusí odeslat nepodepsaný e-mail z domény, která o sobě tvrdí, že všechny její e-maily mají být podepsané, bude naším serverem odmítnut.

Poznámka: někdy můžeme narazit na výchozí konfigurační soubor dkim-filter.conf, který obsahuje chybný řádek #ASPDiscardno místo správného #ADSPDiscard no – dáváme tedy pozor na překlepy.

DKIM/ADSP vs. SPF

DKIM/ADSP a SPF (Sender Policy Framework) jsou svým způsobem konkurenční technologie – obě mají podobné cíle a obě používají DNS.

Pro DKIM a ADSP v DNS nastavíme:

default._domainkey.example.com. IN TXT "v=DKIM1; g=*; k=rsa; p=MIGf...wIDAQAB"
_adsp._domainkey.example.com. IN TXT "dkim=discardable"

A pro SPF:

example.com. IN TXT "v=spf1 mx ip4:146.102.….… ~all"

V obou případech definujeme v DNS záznamech jednak podmínky (u DKIM je to veřejný klíč, kterým mají být zprávy podepsané, u SPF jsou to IP adresy, ze kterých mohou e-maily odcházet) a jednak politiku, která říká, co se má dělat se zprávami, které podmínky nesplňují.

SPF je sice jednodušší (není potřeba pracovat s kryptografií – stačí zkontrolovat IP adresu), ale trpí docela zásadním problémem při přeposílání zpráv. Když si uživatel nechá přeposílat e-maily z jednoho účtu na druhý, zprávy z domény odesílatele najednou odcházejí z jiné IP adresy a cílový server nemůže poznat, zda se jedná o přeposílání nebo třeba o spam. DKIM/ADSP tímto problémem netrpí, protože elektronický podpis lze ověřit i u přeposlané zprávy – je jedno, odkud přišla, pokud je podpis platný. SPF navrhuje, aby se u přeposílaných zpráv měnila adresa odesílatele (použít tzv. remailing a ne forwarding), nebo aby si příjemci přidali přeposílající servery na bílou listinu. To ovšem vyžaduje provést změny na všech přeposílajících nebo cílových serverech, což činí ze SPF politiky -all (e-maily mohou odcházet jen z vyjmenovaných IP adres a žádných jiných) prakticky nepoužitelnou záležitost. Tuto politiku má nastavanou např. Česká národní banka (cnb.cz). Takže pokud vám bude psát někdo z ČNB a vy si necháváte e-maily přeposílat na server, který respektuje SPF politiku, zpráva k vám nedorazí. Když vám naopak bude psát PayPal (který má nastavenou DKIM politiku discardable), e-mail k vám dorazí, i když si ho přepošlete třeba desetkrát.

Modelová situace

Mějme tři poštovní servery resp. domény:

• a.tld – tato doména má nastavenou přísnou ADSP politiku, která říká, že všechny e-maily z této domény musí být podepsané, jinak se mají odmítat – tzn. má v DNS nastavený záznam: _adsp._domainkey.example.com. IN TXT "dkim=discardable"
• b.tld – poštovní server této domény má podporu DKIM a je nastaven tak, aby respektoval ADSP politiku domény odesílatele. V praxi to znamená, že je na serveru např. Postfix a dkim-filter s nastavenou volbou ADSPDiscard yes.
• c.tld – libovolný jiný server, který použijeme pro odeslání zprávy.

První případ – podvrh

Uživatel s adresou uzivatel@a.tld se pokusí odeslat e-mail ze své adresy pomocí nikoli svého domácího serveru (a.tld), ale pomocí jiného serveru (c.tld – např. server v práci nebo ve škole). Server c.tld nemá soukromý klíč domény a.tld a odchozí e-maily samozřejmě nepodepisuje.

1. Uživatel se pokusí poslat e-mail z adresy uzivatel@a.tld pomocí serveru c.tld na adresu uzivatel@b.tld. SMTP server c.tld jeho požadavek přijme – zařadí zprávu do fronty a ukončí SMTP spojení.
2. Server c.tld se pokusí předat zprávu serveru b.tld, ten si ale pomocí DNS dotazu zjistí ADSP politiku domény odesílatele (a.tld), která říká, že nepodepsané e-maily z této domény se mají odmítat. Server b.tld tedy odmítne přijetí zprávy ještě v rámci dané SMTP relace – zprávu vůbec nepřijme a v logu serveru c.tld najdeme záznam podobný tomuto:

   Sep 24 13:31:13 vse postfix/smtp[22720]: [ID 197553 mail.info] 8DC611802: to=<uzivatel@b.tld>, relay=b.tld[2a01:430:...::...]:25, delay=1.3, delays=0.01/0/0.63/0.65, dsn=5.7.1, status=bounced (host b.tld[2a01:430:...::...] said: 550 5.7.1 rejected due to DKIM ADSP evaluation (in reply to end of DATA command))

3. Server c.tld odesílání zprávy vzdá, zabalí ji do obálky a pošle jako nedoručitelnou na adresu odesílatele – uzivatel@a.tld dostane typický e-mail s předmětem Undelivered Mail Returned to Sender. Zpráva se tedy neztratí, nezahodí – odesílatel okamžitě zjistí, že nebyla doručena a proč – může ji tedy odeslat znovu, tentokrát pomocí správného SMTP serveru. Pokud by se jednalo o podvrh – útočník by se snažil odeslat zprávu z adresy uzivatel@a.tld – uživatel by na to díky této chybové zprávě přišel (v ní by byl přiložen i přímo ten e-mail, který se útočník jeho jménem pokoušel odeslat).

Druhý případ – přeposílání

Uživatel má dvě adresy: uzivatel@c.tld a uzivatel@b.tld. Poštu z c.tld si nečte na tomto serveru, ale nechá si ji přeposílat na server b.tld.

1. Odesílatel uzivatel@a.tld pošle zprávu pomocí serveru a.tld na adresu uzivatel@c.tld. Server a.tld podepíše zprávu.
2. Server c.tld zprávu přijme a včetně podpisu ji předá serveru b.tld
3. Server b.tld ověří podpis a ADSP politiku a zprávu přijme – nezajímá ho, z jakého serveru k němu zpráva fyzicky dorazila (c.tld místo a.tld), důležité je, že zpráva má správný DKIM podpis.

Při použití technologie DKIM/ADSP tedy nemáme problémy s přeposíláním, jako je tomu u SPF.

Na co nezapomenout

Možná se teď chystáte nadšeně nastavit ADSP politiku pro svoji doménu, před tím je ale dobré se ještě zamyslet nad následujícími případy:

• Odchozí e-maily z našich www serverů – řada webových serverů posílá např. registrační e-maily nebo zapomenutá hesla uživatelům. Pokud nepoužíváme centrální poštovní server, ale běží nám na tom webovém samostatný SMTP server, který komunikuje s okolním světem přímo, nesmíme ani tento server zapomenout vybavit DKIM klíči a podepisovat na něm e-maily. Totéž platí pro všechny ostatní systémy, které posílají zprávy – různé helpdeskové aplikace, systémy na správu požadavků, měřáky dostupnosti atd.
• Hromadné e-maily posílané třetí stranou – zajišťuje pro vás marketing nebo rozesílání e-mailového zpravodaje nějaká externí firma? Pak jí musíte říct, aby zprávy podepisovala a její klíč přidat do DNS vedle těch svých, nebo jí dát přístup na svůj SMTP server (to už si to můžete posílat sami), případně takové hromadné e-maily posílat z jiné domény – např. marketing.example.com, která bude mít benevolentní podpisovou politiku.
• E-maily z cizích webových formulářů – mnoho webů umožňuje pomocí vlastního formuláře poslat kamarádovi např. odkaz na článek nebo pozvánku. Uživatel jednoduše vyplní svoji a příjemcovu adresu a odešle formulář. Takový e-mail se pak tváří, jako že je z naší domény, ale samozřejmě nemá potřebný podpis. Své uživatele (zaměstnance, studenty atd.) musíte v případě přísné ADSP politiky upozornit, že takto e-maily odesílat nemohou (stejně jako je upozorníte, že nemohou použít např. SMTP server domácího poskytovatele). Pokud naopak sami takové formuláře vytváříte, zkuste je navrhnout lépe – tak, aby se zprávy odesílaly z vaší domény a měly nastavenou hlavičku Reply-To na adresu, kterou zadal uživatel – zpráva bude bezproblémů doručena (protože bude z vaší domény a vašeho sevreru) a pokud na ni bude chtít příjemce odpovědět, odpoví na adresu odesílatele.

Jakou politiku zvolit?

V případě firem lze doporučit discardable politiku. Zřejmě nestojíte o to, aby zaměstnanci posílali firemní (důvěrnou) poštu přes nějaké pochybné cizí SMTP sevrery – když už mají mít přístup k e-mailu i mimo firmu, tak jim poskytnete přístup na svůj SMTP server, webové rozhraní k poště nebo třeba VPN. Díky ADSP snížíte pravděpodobnost, že bude někdo vaším jménem (z vaší domény) posílat např. falešné faktury nebo nějaké poplašné zprávy.

Pokud naopak spravujete školní nebo nějaký komunitní server nebo jste poskytovatelem e-mailových služeb, není discardable politika moc dobrou volbou. Těžko donutíte uživatele, aby posílali e-maily výhradně přes váš SMTP server – a ani to není žádoucí – uživatelé by pak asi danou e-mailovou adresu přestali používat. Přesto je dobré nasadit DKIM a podepisovat e-maily – v případě nějakých incidentů půjde např. dohledat, zda daný e-mail odešel z vašeho serveru. Také tím zvýšíte důvěryhodnost odchozích e-mailů – zde záleží na podpoře klientského softwaru – ten může uživateli signalizovat, že e-mail obsahuje platný DKIM podpis (jako to dělá např. GMail).

Je SPF na nic?

SPF není na nic, jen jeho politika -all je takřka nepoužitelná. Klidně ale můžete nastavit ~all politiku, která říká, že e-maily odeslané z jiných IP adres mají být přijaty, jen mohou být podrobeny důkladnější kontrole. Naopak zprávy přijaté z vyjmenovaných IP adres budou důvěryhodnější.

Ještě jedno dobré využití má SPF: existuje poměrně dost domén, které se používají jen pro web nebo jiné služby, ale nikdy z nich žádné e-maily neodcházejí. U takových domén nastavíme -all SPF politiku a tím zabráníme spamerům, aby naši doménu zneužívali jako odchozí. Totéž můžeme udělat s ADSP – nastavíme discardable politiku (pro případ, že server příjemce podporuje ADSP, ale nepodporuje SPF).

Jak se chovat na straně příjemce

Jako správci serveru přijímajícího poštu bychom měli respektovat politiky (jak ADSP, tak SPF), které si nastavili vlastníci jiných domén. Pokud někdo tvrdí: „všechny naše e-maily jsou podepsané tím a tím klíčem“, tak to berme jako fakt – a to i v případě, že by se nám jeho politika mohla zdát příliš přísná nebo špatná – jsou to jeho e-maily a jeho případná odpovědnost a chyba – ne naše. Navíc pokud si poštovní systém nastavíme tak, jak je uvedeno v návodu výše, nevyhovující e-maily budou odmítnuty ještě v rámci SMTP spojení (ne až následně), takže se žádné zprávy neztratí – e-mail se jednoduše vrátí ke svému odesílateli jako nedoručitelný.

Závěr

DKIM a ADSP je přínosná technologie, která pomáhá v boji se spamem a podvodnými e-maily – i když samozřejmě nedokáže tyto problémy vyřešit zcela. Ideální by bylo, kdyby e-maily podepisovali sami uživatelé (ať už pomocí OpenPGP/GPG nebo S/MIME) a také je šifrovali, ovšem vzhledem k neschopnosti běžných uživatelů tyto technologie používat je fajn podepisovat zprávy alespoň na úrovni domény. Ruku na srdce: kolik už jste zaplatili faktur, které k vám dorazily nešifrovaným a nepodepsaným e-mailem nebo dokonce papírovou poštou?

Odkazy

• RFC 5617: DKIM Author Domain Signing Practices (ADSP)
• RFC 4871: DomainKeys Identified Mail (DKIM) Signatures
• DKIM v roce 2010 – chcete zkusit ADSP?
• Does SPF break forwarding?
• Yahoo! emailové účty zneužívané pre spam

       

Komentáře

[pet]

Pokud by se jednalo o podvrh – útočník by se snažil odeslat zprávu z adresy uzivatel@a.tld – uživatel by na to díky této chybové zprávě přišel (v ní by byl přiložen i přímo ten e-mail, který se útočník jeho jménem pokoušel odeslat).

Jinými slovy: nespamujete příjemce, ale "odesílatele"

[flexo]

článek mi přistál v rss čtečce, chtěl sem si ho přečíst, ale odkaz vede na http://www.abclinuxu.cznull/. Prosím jestli je to chyba u Vás, tak to opravte. Díky. Teď si to du přečíst.

[trekker.dk]

Jinými slovy: nespamujete příjemce, ale "odesílatele"

To většinou nebude pravda: pokud je mail odmítnut už v SMTP relaci - v uvedeném příkladu to tak podle všeho je - pak není pravděpodobné, že by se rozesílající spamovací vir obtěžoval s tím zasílat zprávu o nedoručitelnosti.

[xkucf03]

1. K odmítnutí dojde ještě v rámci SMTP spojení (záleží na nastavení, ale podle toho uvedeného v článku ano), takže je zpráva vrácena přímo útočníkovi – nedostane se ani do poštovní fronty. Pokud se útočníkovi/spamerovi podaří zprávu procpat do poštovní fronty nějakého jiného serveru, který se ji staží předat na ten cílový, k odeslání chybové zprávy falešnému příjemci dojde – ale problém vznikl už ve chvíli, kdy se mu podařilo ten mail procpat už na ten první server (ne až ve chvíli, kdy nastoupil DKIM a ADSP).
2. Je to podobná situace jako když je příjemcem neexistující adresa – lepší řešení to moc nemá – máme totiž jen dvě možnosti: odeslat chybovou zprávu a otravovat nevinné lidi nebo ji neodeslat s tím, že nějaký důležitý e-mail prostě ztratí. V případě DKIM/ADSP by ten systém šlo nastavit i tak, aby se žádné chybové zprávy neposílaly a nepodepsané e-maily se prostě zahazovaly – ale to vyžaduje poměrně vysokou disciplínu na straně odesílatele – musí podepisovat vše a když omylem pošle nepodepsaný e-mail (třeba použije jiný SMTP server nebo na tom jeho bude chyba), nedozví se o tom a může se ztratit nějaká důležitá zpráva.

[Karel]

Stejne je tohle podepisovani mailu na serveru na nic - maily maji podepisovat uzivatele a maji mit nejaky certifikat podepsany CA - tim se teprve zbavime spamu!

[Hobil]

Nezbavis. Pokud se pocitac stane soucasti botnetu (napr. "diky" nejakemu rootkitu), posila zpravy i s (legalnim) podpisem.

Vidim to spis jako riziko pro uzivatele - pri nabourani pocitace ziska utocnik nejen jeho pocitacovy vykon, ale take jeho e-identitu. H.

[Heron]

Nezbavíme

1) Nikdy nepřinutíš všechny něco dělat.
2) Spamerovi nic nebrání to posílat podepsané (jak už bylo řečeno).

[Ondar]

A jeho politika -all není vůbec na nic. Spíš bych řekl, že klasickému forwardování už odzvonilo a ten kdo to dělá by se měl nad sebou zamyslet. Stačí to ponechat na uživatelích - ti pokud si u sebe třeba v TB nastaví forwarding, tak to projde v pohodě. Ne, SPF má díky své jednoduchosti pro mnoho adminů (včetně mě) pořád co říci.

[xkucf03]

Takže mi má pořád běžet desktop a na něm Thunderbird, který bude přes pomalou domácí linku ty maily posílat zase zpátky do Internetu na jiný server? Ne, děkuji nechci.

[Luboš Kašpar - posmaster-at-cnb.cz]

Souhlas s "Ondarem" (úvodní větě rozumím tak, že SPF "-all" k něčemu je).

Ohledně SPF článek nepracuje příliš korektně s pojmy. Pokud je zachována SMTP-obálková adresa odesilatele (z "MAIL FROM:"), jde o tzv. "bouncing", resp. "relaying" a pak mohou být "problémy"; jestliže však je odesilatel v obálce změněn, jde o "forwarding" (pojem "remailing" je poněkud svérázný a je poplatný spíš oblasti MUA než MTA). V obou případech bez ohledu na to, jak se pracuje s adresami v hlavičkách typu "From:", "Sender:" ap. V dnešní době by samozřejmě k žádnému podloudnému relayingu již docházet nemělo (na úrovni MSA je korektní forwarding), takže by neměly být ani problémy se SPF (původní obálkovou adresu odesilatele lze uložit např. do standardní hlavičky "Return-Path:").

Zároveň si dovoluji se ohradit proti způsobu, jakým je citována SPF-politika ČNB (cnb.cz), kdy je nastavení "-all" v ní uvedeno hned za větou zcela znevažující takovou SPF-politiku. Pisatel článku také nebere ve svém stanovisku v potaz velmi důležitý fakt, že RFC 4408 (definice SPF) má status EXPERIMENTAL, tj. zatím nejde o žádný faktický standard (např. typu RFC 5321 pro SMTP), takže jeho aplikace má být podmíněna konkrétní dohodou odesilatele a příjemce. Pokud tedy příjemce odmítá maily, které odporují SPF bez dohody s odesilatelem (např. s ČNB zatím nikdo takovou dohodu ohledně cnb.cz neuzavřel), nečiní tak korektně a uživatel SPF na straně správy domény na tom nemůže mít žádnou vinu.

[Jiřík 1435]

V pripade ze server dela navic relay pro jinou domenu to funguje jak ? Predpokladam ze se email posle dale a nic se nepodepisuje ?

[Jack Wood]

werving en selectie bureau interim recruiter interim recruitment best online gambler vip casino tips casino gambling ideas real money casino guides casino expert advice komo poker seminariostop trellising vakantiehuishuren ShopAbsoluteWill DAfnasha https://www.steunsar.nl https://www.slimmerincasino.nl https://www.betere-energie.com https://www.crypto-investeren.com https://www.beterwedden.com https://www.huisjehuren.nl/ Water bottles Yoga mats robot vacuums air-purifiers corless stick pro sangyoui Christopher Horne nhacai888b soicau888 kaiyokukan typhu88 twin688 photoslate Healing scriptures at Alive Christians TrueTech footballexpress sixsports fitveform thegamblinggurus nodepositpokeronline onlinecasinoku espresso kahvipavut slickcashloanca https://www.aaz-credit-immobilier.com/ https://www.sport-trader.com/ https://www.lespersiennes.com/

[spam]

I personally like your post; you have shared good insights and experiences. Keep it up Click here

[spam]

Great site thanks admin. More power. fencecompanypensacolafl.com

[spam]

I really loved it here but are there any recent updates? Thanks dental implants san jose ca

[spam]

Awesome! Learned alot thanks so much keep posting more. quality painting