A DMARC, mint a hamisított levelek mérésének lehetséges eszköze

levelszemetMióta email létezik, létezik levélszemét is, a spam pedig nem meglepő módon egyidős a spamek ellen vívott küzdelemmel.

Már filozófiájukban rendkívül eltérőek a különböző levelezőrendszerek azzal kapcsolatban, hogy a spameket hogyan kezeljék, a paletta pedig egészen elképesztően széles. Van olyan levelezőrendszer, ami aztán tényleg mindent beenged, hacsak nem open relay-en keresztül érkezik, van, amelyik végigvizsgál több, hatalmas méretű rDNSBL  alapú adatbázist, mint amilyen a http://multirbl.valli.org/ többek közt az után kutatva, hogy a fejlécben szereplő hosztnevek és címek valamelyike összefüggésbe hozható-e esetleg valamilyen spamkampánnyal vagy botnethálózattal. A megoldás máig a Spamassassin egyik legfontosabb eleme.

Persze a jó spamfilter a levél tartalmát és fejlécét együttesen elemzi annak eldöntésére, hogy egy levél milyen valószínűséggel spam, gyakorlatilag minden rendszer lehetőséget ad a rendszer tanítására, azaz, hogy a felhasználó kézileg jelölhessen meg leveleket spamként vagy spambe került legitim leveleket legitim levélként. Az ilyen tanulórendszerek egyik legegyszerűbben megérthető típusa a Bayes-valószínűségen illetve a Bayes-féle valószínűségi hálókon alapul.

Az előbbi lényegét a következőképp lehetne szemléltetni nagyon egyszerűsítve: ha egy levelezőrendszerre érkezik 1000 olyan legitim levél, amiben nem szerepel a Viagra kifejezés, emellett másik 1000 levél, amikben szerepel a Viagra kifejezés, de ezek közül 950 spamként lett a felhasználók által megjelölve, a háló úgymond megtanulja ezt, így a későbbiekben érkező levelekben ha szerepel a Viagra kifejezés, az már eleve a spambe fog érkezni, mivel a spamszűrő annyira nagy valószínűséggel találja spamnek (spam score).

Vannak levelezőrendszerek, így a Google levelezőszolgáltatása és annak vállalati verziója, ami szinte teljes titokba tartja, hogy milyen logikák alapján szűrik a spamet. A transzparencia hiánya elsőre nem tűnik túl kedvesnek, de éppen emiatt a spammerek kevésbé tudják kijátszani a rendszert. Kevéssé ismert, de a Gmail nem a Google fejlesztése, eredetileg a Postini felvásárlásával került a Google-höz és lett Gmail, arra pedig mindenki emlékszik, hogy milyen hangzatos kritikákat kapott a Google amiatt, hogy az összes levél tartalmát „olvassa”. Szigorúan idézőjelbe olvassa. Mert annak kevésbé lett volna hírértéke a sajtóban, hogy a levelek tartalmi elemzése gépi úton történik, statisztikai célok érdekében. Többek közt ennek köszönhető, hogy a Gmail spamszűrője relatív ritkán téved. Olyannyira, hogy a SpamAssassin alighanem nem kegyelmezne egy olyan levélnek, aminek a törzsében többször is szerepel a Viagra kifejezés, míg a Gmail-nél vagy G Suite-nál alighanem nem akadna el olyan esetben, amikor a címzett vagy a feladó történetesen gyógyszerész vagy rendszeresen leveleznek olyan témában, ami alapján valószínűsíthető, hogy a levél nem spam.
Ami még izgalmasabb kérdés, hogy mennyien, kik, honnan küldenek spamet a mi nevünkben, a mi email címünkkel vagy csak a mi domainünkről? Ez a spamvédelem kevésbé ismert oldala. Egy egyszerű beállítással megoldható, ám a mai napig nem terjedt el kellően.

Jól ismert, hogy az email szabványai nem írják elő, hogy annak, ami megjelenik a címzett mezőben, egyeznie kell például a levelezőrendszer által azonosított felhasználó email-címével, de éppenséggel lehet üres is. Röviden: az email önmagában gyakorlatilag tetszőlegesen hamisítható, más kérdés, hogy a hosszú fejléc alapján ez tipikusan azonnal kiderül.

Ismerős lehet a levelezőrendszerek azon lehetősége, hogy másik címmel, normális esetben a sajátunkkal küldhetünk emailt anélkül, hogy az éppen használt levelezőrendszerből ki kellene lépni, sőt, ettől az email még mindig szabályos és bizonyíthatóan legitim marad normális beállítás esetén. Gondoljunk csak a Gmail, Outlook, Yahoo behalf of lehetőségére. A címzett oldalán vagy jelzi vagy sem, hogy a feladó kényelemből esetleg a céges postafiókból küldött levelet, de a privát címével, esetleg fordítva. Az ilyen leveleket tehát nem fogja meg a spamfilter.

Ugyanakkor előfordulhat, hogy a küldő rendszer, ami behalf of módon küldene emailt, egyszerűen nincs erre normálisan felkészítve, a fogadó rendszer nincs illedelmesen konfigurálva, aminek eredményeként a levél a levélszemétbe került. Ahogyan az sem zárható ki, hogy valaki ténylegesen létező email címet hamisít spamek küldéséhez, ekkor a spamfilter jó esetben észlel. Mégis, kik a küldők, honnan küldhetik a leveleket, esetleg mennyi olyan levelet küldtünk, amit tévesen azonosított spamként a címzett rendszere? Erre kínál megoldást a DMARC.

A technológia lényege, hogy a levelezőrendszer, tipikusan egy napos időközönként szolgáltat információt arról XML-ben egy külső szolgáltatónak, hogy a beérkező levelek közül mennyi volt hamisított levél az SPF-szabály vagy a DKIM-szignatúra alapján. Valamint az adott levelezőrendszerekről más levelezőrendszerek küldenek hasonló jelentést.

Nagyon fontos megjegyezni, hogy a DMARC reportot értelmezni kell, miután alaposan megértettük a működését. Azaz például hiába látszik a reportban, hogy a levél az SPF vagy a DKIM ellenőrzésen, esetleg mindkettőn elbukott, a címzett nem biztos, hogy ettől spambe tette, ugyan nagy a valószínűsége, hogy igen. Másrészt a többihez hasonlóan itt is egy (E)DNS alapú ellenőrzésről van szó, annak minden hátrányával együtt. Azaz például ha a címzett az SPF-et és a DKIM-et nem tudja eléggé gyorsan kiértékelni a DNS lassúsága miatt, tipikusan akkor, ha ha az SPF kiértékelése túl sok túl sok névfeloldást igényelne, akkor a címzett úgy tekinti, hogy az email nem valid, aztán vagy spambe teszi vagy sem.

dmarc-rekord-email-hitelesites.png

Mi kell mindehhez? A netacademia.net domain példáján keresztül érthetőbb lesz:

A _dmarc.netacademia.net ben rögzített érték a következő:

v=DMARC1; p=none; rua=mailto:ad6221eb84ab177@rep.dmarcanalyzer.com; ruf=mailto:ad6221eb84ab177@for.dmarcanalyzer.com; sp=none; fo=1;”

a v utáni érték jelzi, hogy a DMARC hanyas verziójáról van szó, a p, mint policy azt közli a címzettel, hogy ha a levelet nem találja legitimnek, jegyezze fel (none), de ne tegyen vele mást, esetleg tegye karanténba (quarantaine) vagy dobja el (reject), a rua utáni érték azt az email címet tartalmazza, amire XML formátumban továbbítódnak a címzettek visszajelzései összegezve, az sp azt, hogy a domain alá tartozó domainekre is ez a szabály vonatkozzon-e, a fo-nál pedig jelölhetjük, hogy csak az SPF-problémát, csak a DKIM-problémát vagy mindkettőt tegye a reportba, mint fals levél. Ezen kívül beállíthatók további paraméterek, amik hiányában a hozzájuk tartozó alapértelmezett érték adott. Ilyen például a ri, azaz reporting interval, ami alapértelmezés szerint egy nap.

dmarc-beallitas-1

dmarc-beallitas-2

Nem mélyedünk el a DMARC beállításával kapcsolatos best practice-be, például abba, hogy hiába tűnik jó ötletnek policyként a none helyett szigorúbbat megadni, ha valahol hiba csúszik az email authentikációba, falspozitívként nyelődhet el egy egyébként teljesen legitim levél, viszont a none is igen erős jelzés a spamszűrők felé.

Ezen kívül megtekinthetjük, hogy más levelezőrendszerek mennyi spamet jelentettek valamint a mi nevükben mennyi hamisított levelet próbáltak küldeni.

A mailhosting fortélyairól, az EDNS működéséről hamarosan közérthető, mégis szakszerű sorozatokat találhattok a Netacademia Tudástárban a slusszkulcs meghívókód megadása után.

Kép: Securelist, Moonmail

Szerző: bardóczi ákos

ORCID, Google Scholar ID, ResearcherID, ResearchGate, MTMT.hu? Find me!