You are here: TUTWiki>Tietoturva/Tutkielmat>TyoLuettelo?>2006-2

Cristian Seres

Roskapostitorjuntaa: SenderID, DKIM ja SPF

Johdanto

Työssä käsitellään erilaisia mekanismeja, joilla pyritään estämään sähköpostin lähettäjäosoitteen väärentäminen. Suuressa osassa roskapostissa käytetään väärennettyjä lähettäjänimiä, kuten Sender Policy Framwork:in johdantosivullakin [1] kerrotaan. Meng Weng Wongin aloittama Sender Policy Framework (SPF), Microsoftin SenderID sekä Yahoon DomainKeysiin perustuva DKIM ovat osoiteväärennösten ehkäisyyn tarkoitettuja mekanismeja.

Lähettäjän osoitteen väärentäminen

Jokainen lienee joskus saanut postia, johon ei ole pystynyt vastaamaan, koska lähettäjän sähköpostiohjelmassa on ollut virheellinen lähettäjäosoite. Lähettäjä pystyy siis yleensä vapaasti valitsemaan lähettäjäosoitteen eikä viestin vastaanottaja voi luottaa lähettäjäosoitteen aitouteen.

Sähköpostiprotokolla SMTP määritellään dokumetissa RFC 2821 [2]. Myös vanhempaan RFC 821:een viitataan usein. Sähköpostiviestistä on erotettavissa kuori (envelope) ja viesti (message). Samassa viestissä voi olla kaksi lähettäjänosoitetta: kuoressa Mail From -kenttä ja viestissä From -kenttä. Lähettävä sähköpostipalvelin antaa vastaanottavalle palvelimelle viestin paluupolun (return path) Mail From - kentällä. Kuoren toiminta on lyhyesti ja yksinkertaisesti selitetty lähteessä [12].

Erityisen ikävä tilanne syntyy, jos roskapostilähettäjä väärentää kuoren Mail From -osoitteeseen haluamansa spam-vastaanottajan ja lähettää viestin siten, että vastaanottajan sähköpostipalvelin hyväksyy viestin käsiteltäväksi, mutta joutuu kuitenkin lähettämään ns. bounce-viestin, koska ei pysty toimittamaan viestiä perille. Tällöin vastaanottajan postipalvelin tuleekin lähettäneeksi virheilmoituksen (joka sisältää myös kopion spam-viestistä) roskapostin kohteelle eli vastaanottajan sähköpostipalvelin toimii roskapostin välittäjänä!

spam-kirjekuoret.png

Sender Policy Framework (SPF)

Sender Policy Framework on avoin standardi, joka määrittelee tekniset keinot sähköpostin lähettäjäosoitteen väärentämisen estämiseksi [1]. SPF on määritelty RFC 4408:ssa, mutta kyseessä ei ole virallinen standardi, vaan kokeellinen (experimental) protokolla [1]. SPF pyrkii estämään nimenomaan viestin kuoressa olevan Mail From -kentän väärentämisen ja siten estämään väärennettyihin osoitteihin lähetetyt bounce-viestit sekä muut automaattiset vastaukset. Sähköpostiohjelmat näyttävät käyttäjälle yleensä vain sähköpostiviestin viestiosassa olevan From-kentän sisällön, joihin SPF ei ota kantaa.

Toimintaperiaate

SPF:n täysi hyödyntäminen vaatii muutoksia sekä lähettäjän nimipalveluun että vastaanottajan sähköpostipalvelimeen. Domainin ylläpitäjä, joka haluaa estää domain-nimen väärinkäytön Mail From -kentässä, julkaisee nimipalvelussa SPF-tietueen, joka määrittää, mistä ip-osoitteista sähköpostia saa kyseisen domainin nimissä lähettää. Vastaanottajan sähköpostipalvelin noutaa nimipalvelukyselyn avulla SPF-tietueen ja tarkistaa, saapuuko viesti lähettäjäksi väitetyn domainin julkaiseman SPF-tietueen sallimalta palvelimelta. [1]

Nimipalveluun vaaditut muutokset lähettäjän domainissa

Ensin täytyy selvittää, miltä palvelimilta tai mistä ip-avaruudesta sähköpostia saa lähettää. Näitä voivat olla esimerkiksi

  • Sähköpostia vastaanottavat palvelimet, jotka on listattu domainin nimipalvelun MX-tietueissa
  • Palomuurin ulko-osoite, jos sähköpostia lähettävä palvelin on palomuurin sisäpuolella
  • Oman paikallisen SMTP-palvelun avulla lähettävät tietokoneet (yleensä Linux/UNIX)
  • Www-palvelimella oleva lomakkeenkäsittelijä tai automaattipostittaja, joka käyttää domainiin kuuluvaa sähköpostiosoitetta lähettäjätiedoissa.

Domainin nimipalveluun lisätään TXT-tietue SPF-syntaksin [3] mukaisesti. Esimerkki: firma.fi:n nimissä postia saa lähettää ainostaan MX-tietueista löytyvien posti1 ja posti2.firma.fi:n kautta, palomuurin ulko-ip:stä 84.20.128.99 sekä www-palvelimelta www.firma.fi:

firma.fi. IN TXT "v=spf1 mx ip4:84.20.128.99 a:www.firma.fi -all"

Jos ylläpitäjä on epävarma siitä, onko TXT-tietueessa varmasti mainittu kaikki postia luvallisesti lähettävät palvelimet, kannattaa hänen vaihtaa -all muotoon ~all, jolloin muista ip-osoitteista tuleva posti aiheuttaa ainoastaan "pehmeän virheen" (softfail) vastaanottajalla ja tällaista viestiä tuskin kokonaan hylätään.

Vastaanottajan sähköpostipalvelimelle vaaditut muutokset

Vastaanottavan sähköpostipalvelimen muutokset riippuvat täysin sähköpostiohjelmistosta. Tyypillisesti sähköpostiohjelmaan asennetaan patch tai lisäosa ja aktivoidaan asetuksista SPF-tarkistus sekä määrätään, miten toimitaan pehmeiden ja kovien virheiden kohdalla.

Esimerkki SPF:n toiminnasta

Palveluntarjoaja XyZZy:llä on asiakas Aardwark.fi, jolle on valitettu aardwark.fi -osoitteista lähetetystä roskapostista. Aardwarkin ja XyZZyn selvitysten perusteella roskaposti ei voi lähteä heidän virallisilta sähköpostipalvelimiltaan emmax1.xyzzy.fi ja emmax2.xyzzy.fi tai Aardwarkin nettikampanjaan liittyvältä sähköpostituslomakkeelta palvelimella www.aardwark.fi. Kyseessä täytyy olla osoiteväärennös Aardwark:in nimissä.

XyZZy päättää rajoittaa osoiteväärennöksiä julkaisemalla SPF-politiikan aardwarkille. XyZZy varmistaa asiakkaalta, ettei muilta kuin edellämainituilta palvelimilta lähde postia heidän nimissään. Muodostetaan SPF-politiikka: "v=spf1 mx a:www.aardwark.fi -all" ja lisätään tämä Aardwarkin nimipalvelun TXT-tietueeksi.

Spämmääjä H. Uijari Vinku-Intiassa lähettää roskapostia ip:stä 123.123.123.123 ja käyttää väärennettynä lähettäjäosoitteena mm. info@aardwark.fi. Jos roskapostin kohde Oy Virtanen Ab käyttää SPF-tarkistusta SMTP-palvelimellaan, toimitaan seuraavasti:

  • Kun 123.123.123.123 ottaa SMTP-yhteyden Virtasen SMTP-palvelimeen, ottaa se ylös smtp-yhteyden lähdeosoitteen 123.123.123.123
  • Viestin kuoresta poimitaan Mail From -kentän lähettäjäosoite info@aardwark.fi ja siitä domain-osa aardwark.fi
  • SPF-tarkistuksen tekevä osa suorittaa nimipalvelukyselyn domain-osan TXT-tietueesta (UNIX-komentorivillä "host -t txt aardwark.fi") ja saa vastaukseksi v=spf1 mx a:www.aardwark.fi -all
  • MX-kenttä täytyy purkaa auki, joten jatketaan nimikyselyitä selvittämällä aardwark.fi:n MX-palvelinten nimet ja niitä vastaavat IP:t (UNIX-komentorivillä luettavissa esimerkiksi "host -vt mx aardwark.fi")
  • 123.123.123.123 ei täsmää Aardwarkin MX-palvelimiin, joten tarkistusta jatketaan: selvitetään www.aardwark.fi:n ip. Tämäkään ei täsmää, joten päädytään sääntöön "-all", joka määrää SPF-tarkistuksen tulokseksi hardfail
  • Olettaen, että Virtasen SMTP-palvelin on säädetty hylkäämään viesti, jonka SPF-tarkistuksen tulos on hardfail, antaa palvelin H. Uijarin roskapostipalvelimelle SMTP-session aikana virheilmoituksen kuten "550 SPF Check Failed, Thank you and Goodbye! (#5.7.1)"

SenderID

Teknistä tietoa Microsoftin SenderID:stä löytyy esimerkiksi lähteestä [6]. SenderID:n toimintaperiaate vaikuttaa nopeasti katsottuna SPF:n kopiolta - Microsoft jopa käyttää harhaanjohtavasti termiä SPF, joka tosin luetaan "Sender of Policy Framework" [6]. Jopa nimipalvelutietueiden syntaksi muistuttaa erehdyttävästi SPF:ää. Alla on tarkempi kuva SenderID:n toimintaperiaatteesta.

senderid.jpg

Nykyään SenderID:tä tai tarkemmin SenderID Frameworkiä (SIDF) käyttää noin 12 miljoonaa Domainin pitäjää. SIDF on IETF:n aloittama projekti sähköpostien väärinkäytön ehkäisemiseksi, jossa Microsoft on mukana.

SenderID verrattuna SPF:ään

Näennäisestä samankaltaisuudestaan huolimatta SPF ja SenderID eroavat toisistaan. SenderID:ssä tarkistus voidaan tehdä Mail From -kentän perusteella (SenderID:n syntaksissa mfrom) - mikä vastaa SPF:ää - tai monimutkaisemmalla päättelyllä Mail From, Sender, Resent-From ja Resent-Sender -kenttien perusteella, kuten Wikipedia asian yksinkertaistaa [13]. Jälkimmäistä mekanismia kutsutaan nimellä Purported Responsible Address (pra) ja se pyrkii estämään phishing:iä kun taas mfrom (ja SPF) torjuvat bounce-viestien ja automaattivastausten lähettämistä väärennettyihin osoitteisiin [13].

SenderID:tä kohtaan esitettyä kritiikkiä

Internetistä löytyy runsaasti kritiikkiä SenderID:tä vastaan. 2005 kesäkuussa julkaistussa artikkelissa [6] on tiivistetty SenderID:n ongelmat: Microsoft on yrittänyt suostutella palveluntarjoajat ottamaan SenderID:tä käyttöön huonolla menestyksellä. Microsoft oli uhannut luokitella roskapostiksi kaikki Hotmailiin and MSN:ään lähetetyt viestit, joiden lähettäjädomainit eivät ole ottaneet SenderID:tä käyttöön. Artikkelissa haastateltu Trend Micro -yhtiön teknologiapäällikkö Dave Randinternet totesi "Mielestämme Microsoft yrittää lujalla kädellä suostutella teollisuutta ottamaan käyttöön epätäydellisen ja ei-hyväksytyn standardin".

Erittäin kiihkeää keskustelua on synnyttänyt Microsoftin SenderID:hen liittyvät patentointiaikeet ja lisenssi, joka rikkoi GPL:ää. Tästä ja monesta muustakin SenderID:hen liittyvästä pimeämmästä puolesta kertoo Jakov Šafranovitš artikkelissaan Sender ID: A Tale of Open Standards and Corporate Greed? [8]. Šafranovitš muistuttaa aiheellisesti, että suurin osa SenderID:n tekniikoista on jo aiemmin keksittyjä ja julkaistuja.

Lopulta Microsoft julkaisi lokakuussa 2006 SenderID:n Open Specification Promise -nimisellä lisenssillä, jonka pitäisi olla yhteensopiva avointen lisenssien kanssa [13].

Teknisesti kaikkein ikävin piirre SenderID:n toiminnassa on ristiriitaisuus SPF:n kanssa. SenderID:n määritelmässä nimittäin suositellaan tulkitsemaan SPF-tietue vastaamaan SenderID:n spf2.0/mfrom,pra -syntaksia eli tarkistus tehdään muidenkin otsikkokenttien kuin Mail From:in perusteella vastoin SPF:n määritelmää. Tästä on lisätietoa lähteessä [9]. Pahimmassa tapauksessa SPF-tietueen julkaisseesta lähetetystä domainista lähetetty sähköposti voi joutua SenderID:tä käyttävän vastaanottajan väärän tulkinnan vuoksi hylätyksi.

Ikävästi ajateltuna tulee mieleen, että Microsoft pyrkii tarkoituksellisesti SPF:n ja SenderID:n ristiriitaisuuden avulla pakottamaan sähköpostin ylläpitäjät siirtymään SPF:stä SenderID:n käyttöön.

DomainKeys

DomainKeys eroaa edellämainituista mekanismeista siinä, että sen avulla viestin vastaanottaja voi lisäksi varmistua sähköpostiviestin eheydestä eli siitä, ettei viestiä ole matkan varrella muutettu. [4]. DomainKeys Identified Mail, lyhenne DKIM, perustuu DomainKeys:iin ja seuraavassa esitellään DomainKeys:in toimintaa, sillä perusperiaate on sama.

Toimintaperiaate

Tämä kohta perustuu kokonaan lähteeseen [4].

Sähköpostia lähettävän domainin ylläpitäjä luo avainparin (julkinen ja yksityinen avain) ja julkaisee julkisen avaimen nimipalvelun kautta. Yksityinen avain toimitetaan domainin lähettävien sähköpostipalvelinten käyttöön. Lähtevän postin palvelimelle asennetaan tarvittavat työkalut, joiden avulla lähtevistä sähköpostiviesteistä muodostetaan digitaalinen allekirjoitus, joka liitetään sähköpostiviestin otsikkokenttien alkuun. Vastaanottajan sähköpostipalvelin puolestaan noutaa otsikkokentän tietojen perusteella lähettäjän nimipalvelusta julkisen avaimen ja varmistaa sen avulla allekirjoituksen aitouden. Oletuksena DKIM käyttää viestin autentikoinnissa SHA-256:sta, salauksessa Base64:sta ja julkisen avaimen salaukseen RSA:ta.

spam-dkim2.jpg

spam-dkim1.jpg

Nimipalveluun vaaditut muutokset

Perustuu lähteeseen [11]

DomainKey:tä tukeva sähköpostipalvelin tekee nimipalvelukyselyn sähköpostiviestin DomainKey-Signature -otsikkokentän tietojen perusteella. Kenttä voisi olla esimerkiksi "a=rsa-sha1; s=mailer; d=esimerkki.fi; q=dns; c=simple; b=base64-koodattu allekirjoitusdata". Nimipalvelukysely muodostetaan kenttien s ja d perusteella, tässä tapauksessa tehtäisiin TXT-tietueen kysely mailer._domainkey.esimerkki.fi. Esimerkki.fi:n nimipalvelusta pitäisi siis löytyä vastaava julkisen avaimen sisältävä TXT-tietue. Julkinen avain tallennetaan TXT-tietueeseen PEM-koodattuna. Lisäksi mukana voi olla muita tietoja kuten avaimen tyyppi (RSA/DSA). BIND-ohjelman syntaksilla TXT-tietue olisi:

mailer._domainkey IN TXT "g=; k=rsa; p=PEM-koodattu julkinen avain"

Julkisen avaimen lisäksi lähettäjädomain voi julkaista "lähetyspolitiikan", jonka vastaanottaja tarkistaa vain, jos DomainKey-tarkastus epäonnistuu. Politiikalla voi esimerkiksi kertoa, että kaikkia sähköposteja ei allekirjoiteta (o=~) ja että DomainKeys on vasta testausvaiheessa (t=y):

_domainkey IN TXT "t=y; o=~; n=We are still testing DK; r=dk-yllapitaja@esimerkki.fi"

Lähettäjän sähköpostipalvelimelle vaaditut muutokset

Sähköpostipalvelimen pitää tukea DomainKey:tä. Useisiin sähköpostipalvelimiin löytyy patch tai laajennos, jolla DomainKey voidaan ottaa käyttöön. Esimerkiksi qmailiin [http://domainkeys.sourceforge.net/] ja tarkemmat ohjeet lähteessä [14]. Ylläpitäjän tulee luoda julkinen ja yksityinen avainpari (openssl:llä tai vastaavalla työkalulla) ja säätää sähköpostipalvelimen DomainKey-laajennos käyttämään yksityistä avainta lähtevien postien allekirjoittamiseen. Yksityiskohdat riippuvat täysin käytetystä sähköpostipalvelimesta.

Vastaanottajan sähköpostipalvelimelle vaaditut muutokset

Vastaanottajan sähköpostipalvelimelle pitää lisätä DomainKeys-tuki kuten lähettäjäpäässäkin. Vaiheet saapuvaa sähköpostia tarkistettaessa ovat lyhyesti:
  1. Poimi otsikkokentistä allekirjoituksen tiedot
  2. Nouda nimipalvelukyselyllä allekirjoituksen tietoja vastaava julkinen avain
  3. Tarkista allekirjoitus; tarkistuksen epäonnistuessa nouda nimipalvelukyselyllä lähettäjän DomainKeys-politiikka ja tarvittaessa hylkää viesti.

Järjestelmien rajoituksia ja ongelmia

DKIM ja SPF varmistavat ainoastaan osoitteen domain-osan. Lähettäjä saattaa käyttää toista käyttäjänimeä samasta sähköpostidomainista. Kuitenkin jo pelkän lähettäjän domainin varmistaminen helpottaa syyllisen löytämistä.

Kuten esimerkiksi lähteessä [4] mainitaan, postituslistat ja muut sähköposteja uudelleenohjaavat järjestelmät voivat muokata viestiä ja mitätöidä DKIM-mekanismin digitaalisen allekirjoituksen. Samassa lähteessä mainitaan myös DKIM:n alttius replay-hyökkäyksille. Sähköpostin uudelleenohjaus voi rikkoa myös SPF:n ja SenderID:n toiminnan. SPF:n tapauksessa ongelman ratkaisemiseksi on kehitetty Sender Rewriting Scheme (SRS) [http://www.openspf.org/SRS], joka vaikuttaa varsin monimutkaiselta rakennelmalta.

Päätelmät

SPF ja DKIM täydentävät toisiaan, sillä ensimmäinen keskittyy smtp-viestin kirjekuoren (envelope) lähettäjäosan varmentamiseen ja jälkimmäinen smtp-viestin viestiosan eheyden varmentamiseen.

Järjestelmät eivät edes yhdessä käytettynä estä roskapostin lähettämistä useammastakaan syystä:

  1. Jotta toiminta olisi aukotonta, tulisi kaikkien vastaanottavien sähköpostipalvelinten hylätä viestit domaineista, jotka eivät käytä väärennöksenestomekanismeja. Tämä puolestaan vaatisi, että kaikki asiallista postia lähettävät domainit ottaisivat väärennöksenestomekanismit käyttöön.
  2. Roskapostittaja voi julkaista omassa domainissaan SPF-tietueen, joka sallii postin lähettämisen kaikista maailman ip-osoitteista tai vastaavasti allekirjoittaa roskapostin DomainKeys-mekanismilla.
  3. Sähköpostiohjelmat näyttävät yleensä lähettäjänä sähköpostiviestin viestiosassa olevan From-kentän tiedot eivätkä SPF tai SenderID:n mfrom-mekanismi ota kantaa tämän oikeellisuuteen.

Toivottavasti jokin aukoton osoiteväärennökset estävät mekanismi keksitään. Todennäköisesti tämä onnistuisi ainoastaan päivittämällä SMTP-protokollaa ja pakottamalla kaikki maailman sähköpostipalvelimet ottamaan se käyttöön tietyllä aikavälillä.

Osoiteväärennösten estämisen lisäksi roskapostin karsimiseksi tarvitaan siis edelleen muita keinoja kuten roskapostittajien ip-osoitteiden laittaminen mustalle listalle ja sähköpostin analysointi SpamAssassin-ohjelmistolla.

Microsoftin SenderID:n tulevaisuus on epävarma. Microsoft käytti kyseenalaisia keinoja sen standardoinnissa ja mainostamisessa, mikä tahrasi SenderID:n maineen ja suututti monet yhteisöt.

Kehitysideat

SMTP:n korvaajiksi tarkoitettuja protokollia ei tässä harjoitustyössä käsitelty. Sähköpostijärjestelmän täydellisellä uudistamisella voitaisiin roskapostiongelmaan puuttua tehokkaasti. Sähköpostijärjestelmän tulevaisuudennäkymistä kiinnostuneet voivat etsiä lisätietoa Internet Mail 2000 -nimisestä protokollaehdotuksesta.

Lähteet

Topic attachments
I Attachment Action Size Date Who Comment
senderid.jpgjpg senderid.jpg manage 60.0 K 16 Nov 2009 - 19:21 UnknownUser  
Print version |  PDF  | History: r5 < r4 < r3 < r2 | 
Topic revision: r5 - 16 Nov 2009 - 22:57:42 - TuomasSaarelainen?
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback