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

Dizájnelem, amit a keresők is szeretni fognak: az email cím

A legkülönfélébb tematikájú blogokon találunk valamiféle kapcsolatfelvételi lehetőséget, nem egy esetben találkozhattunk már olyannal, hogy egy rendkívül nívós oldalon szinte esztétikátlan volt a szerzők email-címe, holott egy postafiók vagy éppen a leveleket csak adott irányba továbbító, saját domaines megoldás nem kerül többe néhány garasnál. A jelenséget ismét több oldalról járjuk körül.

Az összes hagyományos sajtóterméknél megszokhattuk, hogy fel van tüntetve valamilyen cím, ahova az olvasók írhatnak. Ami az online tartalmakat illeti, a kapcsolatfelvételi űrlap jó ötletnek tűnik, valójában viszont sokkal személytelenebb ahhoz képest, mint amikor a szerző email címe fel van tüntetve, így az olvasó közvetlenül tud írni neki.

Mi indokolja az egyébként a felhasználó számára kénylemetlen űrlapokat? Az ilyesmi jól használható az irkálók lelombozására, és a felesleges levéláradat csökkentésére, nem véletlenül használják ezt a módszert például az ügyfélszolgálatoknál, ahol fontos mérési szempont, hogy hány igény NEM érkezik be. Persze, tudjuk, a ticketing rendszer miatt van, de ez nem igaz, mert a hagyományos emaileket is el lehet látni ticketekkel.

A másik egy XX. századi félelem, hogy ha valahová kikerül az email címünk úgy, hogy a kukac karatert nem helyettesítjük a “kukac” szócskával, az egyenlő az adott email cím kinyírásával, mert fél órán belül teletömik a levelesládát a spamelők. Tizenöt évvel a spamfilterek megjelenése után ez ma már egyáltalán nem igaz. Pláne, ha valaki valamilyen felhős szolgáltatást használ, ahol a szolgáltató elemi érdeke, hogy ne hagyja floodolni az előfizetők levelesládáját, a spam-áradattól való félelemre nyugodtam mondhatjuk, hogy atavisztikus.

Az email ráadásul jobb a címzettnek is, mivel a feladó ugyan írhat olyan címről, amiből nem nagyon lehet következtetni a kilétére, aki viszont valamiféle normális visszajelzést szeretne kapni a szerzőtől, sanszosabb, hogy normális címről küld majd emailt. A netes műfajok folyamatosan folynak össze, amiről viszont hajlamosak vagyunk megfeledkezni, hogy ha egy portálnak, blognak, mikroblognak a fejléce, betűtípusa az arculat szerves részeit képzik, miért lenne ez alól kivétel éppen az email cím? Amivel kapcsolatban azért valljuk be, elvárható, hogy legyen valamilyen formája olyan esetben, amikor éppen egy ICT-vel foglalkozó blogról van szó.

Egy, a napokban publikálásra kerülő posztban részletesen kitérünk rá AI-megközelítésben, hogy mitől szeretnek valamit a keresőmotorok jobban vagy kevésbé.

Nem nehéz belátni, hogy a keresőmotor komolyabban fog venni egy olyan webhelyet, amihez normális emai lcímek tartoznak, aminek az oka minden részletében nyilván hétpecsétes titok, sejtéseink azért lehetnek. A kereső persze hogy komolyabban fog venni egy olyan oldalt, aminél nem fantázianévvel, ráadásul 2 perc alatt regisztrálható ingyenes cím van feltüntetve a szerzők elérhetőségénél, hanem azonos a domain, aminek nyilván van egy felelőse.

Vegyük észre, hogy mi is nyilván sokkal hitelesebbnek tartunk egy olyan oldalt, ahol a szerzők névvel vállalják az írásaikat (ami lehet ugyan fantázianév is), ha egy ahhoz passzoló email cím is van hozzá kapcsolva, éppen a szöges ellentéte annak, amit a hülye konteós oldalaknál láthatunk. Igen, igen. A keresőmotornak emberi értelemben érzései nincsenek ugyan, viszont bizonyos értelemben esztétikai érzéke, na meg mérlegelőképessége egy-egy oldal hitelességével kapcsolatban annál inkább, ahogy arról a következő posztban szó lesz.

Ami a technikai megvalósítást illeti, nagyon labilis megvalósítás, amikor az adott címre küldött leveleket csak forwardolja egy szolgáltatás a szerző postafiókja felé, egy-egy freemium vagy filléres levelezőrendszer beállítása viszont már teljesen elegendő lehet, ahogy arról a tervek szerint kurzus is lesz. A komolyabb szerkesztőségekben pedig a legpraktikusabb megoldás lehet, ha hosztolt vagy éppen cloudban futó Microsoft Exchange van beállítva, aminek az üzemeltetésével kapcsolatban éppen a Netacademia egyik tanfolyama minden részletet lefed.

Korábban az egyszerűsége és a letisztultsága miatt rendkívül népszerű volt a Google Apps, mai nevén G Suite, ami ingyenesen biztosított – pongyola megfogalmazásban – saját domaines Google Mail levelezést. 2011. április 26-adika alighanem eléggé kellemetlenül érintette azokat a Google Apps adminokat, akik 10-nél több felhasználóval használták a szolgáltatás. A Google először az 50 felhasználót leszorította 10-re, majd teljesen előfizetésessé tette a Google Apps-t.

all-in-one-saas
All in one Software as a Service

Néhány dolgot viszont nagyon fontos tudni a G Suite-ról. Egyrészt a korábbi regisztrációkat visszamenőlegesen nem tették fizetőssé, ezek az ún. legacy csomagok. Viszont abban az esetben, ha az admin volt olyan elővigyázatlan, hogy rákattintott a dashboardon vöröslő UPGRADE-re 30 napos kipróbálási lehetőséggel, supporttal, utána már nem volt semmilyen módon lehetősége visszatérni az ingyenes változathoz! Az pedig azért nagyon nem mindegy, hogy ingyenesen vagy 10 felhasználóval számolva évenkénti 600 dollárért használható ugyanaz, mivel egy-egy fiók havi díja 5 USD körül van, csak az entry level esetén.

Természetesen nemcsak a levelezés, hanem közel 100 Google-szolgáltatás használható saját domaines végződéssel.

g-suite-google-apps
Hivatalosan nincs legszigorúbb DLP, viszont audit igen

További, amit nagyon fontos tudni a legacy G Suite-ról, hogy nem csak egyetlen domain lehet alá bekötve, hanem szinte akármennyi, aztán vagy a governance szerint beállítható vagy a felhasználóra bízható, hogy melyik végződéssel használja a szolgáltatáscsomagot.

Ugyancsak fontos, hogy az elsődleges domain nem cserélhető ki úgymond, viszont egy-egy nevet évenként 10 USD-ért megújítani annyira nem fájdalmas. Márpedig ha az elsődleges domaint, amivel eredetileg regisztrálta az admin a Google Apps-t, nem újítják meg, igencsak izgalmas pillanatokat okozhat működés közben, másrészt nyilván regisztrálhatóvá válik más számára is, aki ráadásul ha tudja, hogy G Suite volt bekötve a domain alá, korlátozás nélkül viheti az egész házat, mivel a G Suite admin elfelejtett jelszava az elsődleges domainhez tartozó zóna módosításával is kérhető!

Kísérleti jelleggel mostantól ehhez a bloghoz is tartozik szabályos formátumú email cím, igaz, még csak egy, a bardoczi.akos@elemzes.netacademia.hu.

A freemiumok közül a Google Apps-t emeltük ki, mert a legelterjedtebb volt. Különös érdekessége még az immár közel 10 éves történetnek, hogy a Microsoft ugyancsak nyújtott ilyen szolgáltatást, azaz olyan volt, mintha teljesen ingyen adtak volna Office 365-öt – ami persze akkor még nem volt – tokkal-vonóval, mindennel. Mégsem tudta felvenni a versenyt a Google Apps-szel és persze ugyanúgy kivezették az ingyenes csomagokat.

Hogy most elérhető-e hasonló komplett freemium szolgáltatáscsomag? Természetesen, több is, amik közül nem lehet egyikre sem mondani, hogy jobb lenne a másiknál, egy-egy szolgáltatás vagy szempont alapján erősebb. De ez már egy másik elemzés története lesz.