Võitlus spämmiga ja seda pärssiv “skriptide internet”

Rämpsposti teemal klienditoe poole pöördujatel on enamasti üks kahest küsimusest:

a) “kuidas saaksite teha nii, et mulle saadetud kirju efektiivsemalt rämpspostina tähistataks/kustutataks”;
b) “kuidas saaksite teha nii, et minu saadetud kirju rämpspostina ei tähistataks/kustutataks”?

Juhtub ka nii, et lühikese ajavahemiku jooksul pöördub nende küsimustega meie poole üks ja sama inimene.

Hulk probleeme, mis raskendavad nende kahe küsimuse vahel taskaalu leidmist pärineb allikast mida kutsume “skriptide internetiks”.

Aga enne selleni jõudmist, väike minikursus teemal …

“… kuidas kirju spämmiks märgitakse?”

Kiri liigub saatjalt adressaadini läbi mitme erineva serveri, tekitades sellega sammude ahela, mille iga lüli võib kirja ühel või teisel viisil “spämmisuse” suhtes kontrollida.

Saatja MUA ehk meiliklient võtab ühendust oma MSA-serveriga (Mail Submission Agent), autendib end ja annab kirja üle. MSA omakorda võtab ühendust väljuva MTA-serveriga (Mail Transfer Agent), mis on kirjade transportimise server. MTA salvestab kirja järjekorda ning üritab seda esimesel võimalusel edastada vastuvõtja MX-serverile (Mail Exchange), mis omakorda annab selle üle MDA-serverile (Mail Delivery Agent) ja lõpuks jõuab kiri saaja postkasti, kust saaja saab oma MUA-meilikliendi abil kirja lugeda.

Seda, kui “spämmine” kiri on, kontrollitakse enamasti järgmiste etappidena:

1. Sõnumitooja kontroll

Esimene tase on kontrollida mitte sõnumit, vaid sõnumitoojat. Näiteks kui kirja saatev server on mitmes mustas nimekirjas, võib kiri sattuda spämmiks juba ilma, et keegi selle sisu üldse vaataks. Kusjuures saatev server või õigemini serveri poolt kasutatud IP aadress ei pruugi ise olla kunagi midagi halba teinud, aga ikka peetakse seda kahtlaseks.

Tavaliselt on siis tegu kas mingi suurema IP vahemiku või veel hullemal juhul terve teenusepakkuja (ASN-numbri alusel) sattumine mõnda musta nimekirja. Mustad nimekirjad ei ole samas absoluutsed, neid võib pidada igaüks ning nimekirja haldaja võib koostada neid nagu ise heaks arvab. Oluline on, et kui paljud teised teenusepakkujad mõnd konkreetset listi usaldusväärseks peavad ning seda oma spämmikontrolli protsessis kasutavad. Sellist kontrolli tehakse samas pigem sisenevate kirjade puhul, kuna väljuvate jaoks peab kasutaja end reeglina autentima ja sellisel juhul ei ole saatja IP nii oluline.

Kui ühenduse avamine on lubatud, siis edasi vaadatakse sõnumitooja käitumist, et kas see ikka kasutab korrektset SMTP-protokolli. SMTP-klient peab ootama korrektselt oma rääkimiskorda, isegi kui server vastustega venitab. Klient peab kasutama enda tutvustamisel õiget domeeninime, ei tohi kasutada tundmatuid SMTP käsklusi, ei tohi saata kirja liiga paljudele tundmatutedele aadressidele jne. Mõned süsteemid kontrollivad ka TCP ühenduse sõrmejälge, et tuvastada kas saatjaks on meiliserver, või hoopis töölauaarvuti. Iga vea või mittevastavuse eest annab vastuvõttev server kas spämmipunkte või suuremate vigade korral katkestab üldse ühenduse ja keeldub kirja vastu võtmast.

Kui protokolli kontroll on läbitud, vaatab vastuvõtja juba SPF-kirjet ja selle vastavust. Juhul kui MAIL FROM käsus kasutatud saatja domeeninimel on seatud nimeserveri SPF-kirje, saab selle järgi kontrollida, kas saatja IP aadressilt ikka tohib sellist domeeninime kasutades kirju saata või mitte. Kui kliendi IP aadress on 217.146.66.121 ning e-posti aadressiks andris@zone.ee, siis kõik sobib, kuna zone.ee SPF-kirje lubeb muu hulgas ka 217.146.66.121 aadressi kasutamist. Kuna SPF on mitme vastavustasemega, siis siin jälle sõltub erinevatest asjaoludest, et kas server laseb kirja niisama läbi, keeldub seda üldse vastu võtmast või lisab mõned spämmipunktid.

2. Kirja vormistuse kontroll

Kirja enda puhul on kontrollitavaid parameetreid veelgi rohkem. Üheks olulisemaks asjaks on kirja vormistus, kas see kiri ikka näeb RFC822 formaadis kirja moodi välja või mitte. Kirjal peab olema From aadress saatja andmetega, Message-ID unikaalne identifikaator, kuupäeva Date väli, protokollist tulenevalt peavad reavahetused kasutama nn. Windowsi stiili ehk baite 0x0D+0x0A (carriage return + newline) jne. Iga puuduv või valesti vormistatud osa annab spämmipunkte. Tüüpiliseks vale vormingu näiteks on vigane kuupäevaväli (peab olema “Wed, 14 Dec 2016 10:58:26 +0200” aga on hoopis “2016-12-14 10:58:26”) või siis Message-ID puhul väiksem-kui ning suurem-kui märkide puudumine või kui väärtus ei kasuta e-kirja aadressi süntaksit (peab olema “<unikaalne-id@domeen>”, aga on “unikaalne-id”).

3. Krüptograafiliste allkirjade kontroll

Kui kirja vormistus vastab enamvähem nõuetele, siis vaadatakse ka selle sisu. Kas From real oleva aadressi (mitte segi ajada SMTP-ümbrikus kasutatud MAIL FROM aadressiga, mis moondub ühel hektel hoopis Return-Path väärtuseks) domeenile on seatud DMARC nimeserveri kirje või mitte? Kui on, siis kontrollitakse uuesti SPF-kirje vastavust, aga seekord juba From välja alusel. Lisaks vaadatakse kas kirjal on sobiva domeeni DKIM-alkiri.

Selle koha peal võib server kirja tagasi lükata ka siis, kui kirjal spämmipunkte üldse ei ole. Kui DMARC-kirje ütleb, et vigane kiri tuleb tagasi lükata, siis server seda suure tõenäosusega ka teeb. Vigaseks teeb kirja vale SPF (võib juhtuda näiteks, kui kiri saabub hoopis mõne meililisti kaudu) ja vale DKIM (reeglina juhtub siis, kui kirjal pole üldse vajalikku DKIM-allkirja, kuna kiri liikus selliseid kanaleid pidi, kus allkirjastamist ei toimu, näiteks läbi oma ISP väljuva SMTP-serveri kirju saates).

Edasi vaadatakse läbi ka kirja kõik muud DKIM (DomainKeys Identified Mail) krüptograafilised allkirjad. Selliseid allkirju võib olla kirjal palju, erinev allkiri iga seotud serveri kohta. Üks allkiri saatja aadressi domeeni jaoks, teine teenusepakkuja MTA-serveri jaoks, kolmas mingi statistika jaoks jne. Gmail Postmaster Tools veebiliides näitab teenusepakkujatele infot kirjades sisalduvate DKIM-domeenide alusel ja seega on mugav koondada kõikide oma süsteemi läbivate kirjade info kokku, kasutades kõikides väljuvates kirjades ühist DKIM-allkirjadomeeni.

DKIM-allkirja kontrollimiseks vaatab server kirja päises olevat allkirja päisekirjet, otsib sellest allkirja domeeni, läheb küsib domeeni nimeserverist allkirjale vastava avaliku võtme ja kontrollib saadud võtme abil allkirja kehtivust. Kui allkiri on vigane, siis saab kiri jälle spämmipunkte, aga mitte väga palju, kuna katkised allkirjad on suhteliselt tavaline nähtus, selle lõhkumiseks piisab vaid ühest muutunud bitist. Näiteks kui kiri läbib mõnd meililisti, mis lisab kirja lõppu meililisti info või läbib MS Exchange serverit, mis võib vahetada TAB sümbolid tühikute vastu, siis võibki allkiri katki minna, sõltub jälle erinevatest asjaoludest (osad DKIM formaadid taluvad selliseid tühikute-tab’ide vahetusi, osad mitte).

4. Sisuanalüüs

Kirja tekstilise osa analüüs jaotub suures plaanis kaheks. Esimene pool on algoritmilised kontrollid ja teine pool on kirja võrdlemine varasemalt teada oleva spämmiga. Algoritmiliseks kontrolliks võiks olla näiteks phishingu-linkide (ehk need lingid, mis suunavad “ganzapanga” lehele paroole sisestama) otsimine, kus võrreldakse HTML koodi lingis olevat URL’i selle kuvamise aadressiga ning kui need ei klapi, siis antakse spämmipunkte.

<a href="www.aaa.com">www.bbb.com</a>

Kõiki linke kontrollitakse lisaks veel phishingu andmebaaside pihta ning kui link tõesti mõnes phishingu baasis eksisteerib, siis antakse kirjale jälle tublisti spämmipunkte juurde. Siin on küll mõningane valepositiivsete tulemuste tekkimise võimalus, seega sellise lingi olemasolu üksi kirja tagasi lükata ei tohiks.

Teksti võrdlemine teadaoleva spämmi vastu on üks parimaid, aga samas ka segasemaid meetodeid. Levinuimaks klassifitseerimismeetodiks on Bayesi filter, mille puhul võrreldakse kirjas sisalduvaid sõnu teadaolevate spämmikirjades sisalduvate sõnade ja fraaside vastu ning mida erinevam on kirja sisu tavalisest spämmist, seda suurema tõenäosusega polegi tegu spämmiga. Segaseks teeb selle kontrolli asjaolu, et inimesena on raske öelda, miks spämmikontroll mingit kirja spämmiks peab või mitte, sest oma silmaga vaadates võib see paista üsna tavaline kiri. Kuna algoritm ja andmed ei ole ülearu keerukad, siis on võimalik see hea tahtmise korral siiski tuvastada. Hoopis teine asi on juba neuraalvõrkude põhise kontrolliga, mis on väga efektiivne, aga kus ei saa enam keegi ilmselt aru, et miks spämmikontroll mingit kirja spämmiks peab või mitte.

5. Viirusekontroll

Kõige viimasena saadetakse kiri ka veel viirusekontrolli, kus vaadatakse üle kirjas olevad manused ning kohati ka kirja tekstiosa, kui viirusekontroll oskab sellest näiteks phishingut vmt. tuvastada. See on võibolla ka kõige jäigem kontroll üldse, sest kui kirjast leitakse teada olev viirus, siis siin nagu polegi enam midagi mõelda, sellise kirja koht ei ole postkastis. Samas ka viiruste puhul on suhteliselt tavalised erinevad valepositiivsed tulemused, näiteks kui leitakse pakitud ZIP-faili seest kahtlase nimega fail, aga selle sisu täpsemaks uurimiseks pole enam mahti. Sellisel juhul antakse kirjale pigem spämmipunkte, et see satuks spämmikausta, aga tagasi lükkama ka ei hakata.

6. Lõppotsus

Erinevaid reegleid, mida spämmi tuvastusel kontrollida, on sadu ja kõiki siin välja tuua ei jõuakski. Üldpõhimõte on see, et iga reegel annab kas negatiivseid või positiivseid spämmipunkte ning peale kõiki kontrolle lüüakse need punktid kokku ja saadud tulemus ütlebki, et mida kirjaga edasi teha.

Kui kiri pole üldse spämmipunkte saanud, siis võib selle lihtsalt niisama vastu võtta. Kui mingeid punkte on siiski tulnud, aga mitte piisavalt, et kirja spämmiks lugeda, saab kasutada nn. greylistingut, kus saatjale vastatakse ajutise veateatega ja lastakse seega sama kiri mõne aja pärast uuesti saata (spämmerite süsteemid tihti uuesti saatmist teha ei suuda).

Kui punkte on juba rohkem, siis võetakse kiri küll vastu, aga paigutatakse see spämmikausta, jättes sellega lõpliku otsustamise adressadi enda kanda. Kui punkte on juba väga palju, näiteks leiti kirjast viirus, see on kehvasti vormistatud ja tekstisisu sarnaneb spämmiga, siis ei võeta seda kirja võibolla üldse vastu, vaid keeldutatakse teatega, et kiri paistab olevat spämm.

Spämmikontroll väljuvatel ühendustel

Spämmitõrje igal tasandil on muidugi mõistlik tegevus ja seega hakkasime hiljuti rakendama seda lisaks sisenevatele kirjadele osaliselt ka väljuvate kirjade puhul. Teenusepakkujana on meie probleemiks häkitud kontod, kus kasutaja veebileht võetakse pahalaste poolt ära või lähevad meilikonto paroolid jalutama vmt. tegevused ning mille tõttu hakatakse ühtäkki meie võrgust spämmi laiali saatma. Tagajärjeks on meie väljuvate IP aadresside sattumine mustadesse nimekirjadesse ja seega tekivad probleemid ka teiste klientide kirjade edastamisel, mis liiguvad samade IP aadresside kaudu.

Esimene kaitse musta nimekirja sattumise vastu on hajutada saatmisel kirju erinevate IP aadresside vahel, mis võimaldaks võtta musta nimekirja sattunud IP kuni asjaolude selgitamiseni rivist maha (ZoneMTA oskab teha seda automaatselt, nii et ühe IP sattumine musta nimekirja ei tähenda suures plaanis veel suurt midagi). Kuid võibolla olulisemgi oleks üldse vältida spämmi saatmist (kuigi päris täielikult välistada seda muidugi kunagi ei saa), eelkõige kasutades spämmikontrolli.

Paraku ei ole miski liiga lihtne. Maailm on muutunud, e-posti ei kasutata enam ammu ainult personaalseks suhtluseks, üha rohkem ja rohkem on see uudiskirjade, automaatsete teadete, parooli meeldetuletuste jms. maailm. Väljuva liikluse puhul spämmikontrolli teostamine on sisenevast keerukam, kuna eksimisruumi on vähem. Juhul kui kiri paistab kahtlane, siis ei saa seda panna spämmikausta. On vaid üks valik – saata kiri edasi või mitte.

Ja nii jõuamegi müstilise “skriptide internetini”

Meie kasutajad saadavad välja igasugust e-posti. Loomulikult on jätkuvalt olulisimal kohal tavasuhtlus ehk käsitsi kirjutatud kirjad. Viimasel ajal on suur osa kirjadest siiski masinate koostatud, osaliselt on need lausa masin-transaktsioonid, kus ühe masina skripti poolt saadetud kiri tekitab vastuvõtmisel mingi tegevuse teise masina skriptis.

Lisaks võidakse selliste kirjade transpordiks kasutatada neidsamu kontosid, mida kasutatakse ka Webmaili, Outlooki ja muude meiliklientide poolt ehk kus peaks eelkõige liikuma niiöelda “tavakirjad”.

Näiteks kasutab mõni inimene WordPressi (fiktiivset, kuid reaalsele elule lähedast) pluginat NutisaunPro™®, kus veebilehe tarkvara saadab vajalikul hetkel nutisauna kerisele e-kirja, milles sisaldub käsklus keris kuumaks ajada ning nutikeris saadab omakorda vastuskirja, kui soovitud temperatuur on käes. Paraku on need kirjad saadetud PHP mail() käsu abil ning kirja vormistamise skript on kopeeritud HotScripts lehelt PHP kirjade saatmise kategooriast.

Masinate vahelises suhtluses ei tähenda see suurt midagi, kõik toimib, aga kui hakkame sellisele kirjale siseneval või väljuval suunal rakendama spämmivastast kontrolli sarnaselt tavalistele kirjadele, ajab see kõik mõõdikud punaseks järgmistel põhjustel:

• tõenäoliselt asub nutisaun IoT-seadmena mingis kummalises võrgus, kus pole seatud korrektseid tagurpidi reverse DNS-kirjeid;
• kirja vormistus on kopipasta tõttu ebakorrektne, puudu on vajalikud päised;
• teksti kodeering pole korrektselt määratud;
• kirja sisu on lühike ja segane, tekitades Bayesi kontrollis selle vastu liigset huvi;
• DKIM allkirja pole lisatud;
• SPF kirjet ei eksisteeri;
• DMARC kirjet pole
• jne.

Spämmifiltreid karmistada ei saa, sest nutisaunade omanikud on kurjad, koju jõudes ootab ees külm saun – keris ei ole vajalikku e-kirja kätte saanud.

Nii tekib olukord, kus selliste “nutisaunade” poolt kasutatavate skriptide kvaliteet saab ühiseks nimetajaks, mille järgi rämsposti on võimalik filtreerida. Loomulikult pääsevad siis liig-kõrge lävendi tõttu efektiivsemalt läbi hästi vormistatud päris spämmikirjad.

Siinkohal kasutatud fiktiivne “nutisauna” näide võib tunduda jabur, aga uskuge meid, reaalsus on jaburam. E-posti on (äri)protsessidesse sisse kirjutatud imelistesse kohtadesse.

Oleks siis veel tegu mõne üksiku juhtumiga, aga kui aus olla, siis oleme avastanud, et meil pole tegelikult õrna aimugi, kui palju ja milleks kõigeks e-posti infrastruktuuri üldse kasutatakse.

Kasutan siinkohal võimalust pöörduda arendajate poole. Kui soovite oma postkastis näha vähem spämmi, palun ärge toitke “skriptide internetti” koodiga, mis kasutab e-posti selleks, milleks ta algselt mõeldud ei ole.