Portál AbcLinuxu, 18. říjen 2017 16:49

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

5. 10. 2010 | František Kučera
Články - DKIM – zavádíme podpisovou politiku (ADSP)  

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:

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:

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:

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

Další články z této rubriky

V sobotu se uskuteční konference CryptoFest
Pozor na androidové aplikace
Silent Circle představil bezpečný smartphone Blackphone 2
Android je bezpečnější, řada hrozeb však stále přetrvává
Avast varuje před nebezpečnými aplikacemi v Google Play

Diskuse k tomuto článku

5.10.2010 07:52 pet
Rozbalit Rozbalit vše První případ – podvrh
Odpovědět | Sbalit | Link | Blokovat | Admin

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" :-(

5.10.2010 08:40 flexo
Rozbalit Rozbalit vše Re: První případ – podvrh
č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.
5.10.2010 10:28 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: První případ – podvrh
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.
Quando omni flunkus moritati
xkucf03 avatar 5.10.2010 13:47 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: První případ – podvrh
  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.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
5.10.2010 23:13 Karel
Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
Odpovědět | Sbalit | Link | Blokovat | Admin
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!
6.10.2010 16:57 Hobil | skóre: 1 | blog: Hobilovo_doupe
Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
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.
Aktualni top neni 0.9, anobrz 3.2.8. Top 0.9 je beznadejne zastaraly.
Heron avatar 6.10.2010 17:31 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)

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).

11.10.2010 13:22 Ondar | skóre: 25 | blog: Linux_blog
Rozbalit Rozbalit vše SPF
Odpovědět | Sbalit | Link | Blokovat | Admin
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 avatar 11.10.2010 14:16 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: SPF
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.
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
29.12.2010 11:57 Luboš Kašpar - posmaster-at-cnb.cz
Rozbalit Rozbalit vše Re: SPF
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.
16.12.2010 13:47 Sapo | skóre: 8
Rozbalit Rozbalit vše Re: DKIM – zavádíme podpisovou politiku (ADSP)
Odpovědět | Sbalit | Link | Blokovat | Admin
V pripade ze server dela navic relay pro jinou domenu to funguje jak ? Predpokladam ze se email posle dale a nic se nepodepisuje ?

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.