Kuuldused e-posti surmast on jätkuvalt liialdatud

E-post võis küll hiljuti tähistada oma 47. sünnipäeva, kuid pakub jätkuvalt uusi rakendusi ning väljakutseid.

Sõltumata regulaarsetest uutest e-posti killeritest on e-post, nagu me seda tunneme, püsinud enam-vähem samasugusena juba aastakümneid. Loomulikult on juurde tulnud uusi võimalusi nagu näiteks manuste kasutamine või täpitähtede tugi, mida e-posti esimesed versioonid sugugi ei tunnistanud, kuid see on reeglina alati olnud olemasoleva lahenduse raamides toimetamine, mitte millegi päriselt uue lisamine (manusega kiri oleks täiesti loetav ka manuse-eelse ajastu e-posti kliendiga, see lihtsalt näeks kummaline välja). Samal ajal on Google Wave, Slack, Facebook, WhatsApp ja teised e-posti alternatiivid lisanud loetamatul hulgal täiendusi, nii kasutajakogemuse kui turvalisuse vallas, mida e-postis kas senini ei ole või ei saagi kunagi olema.

E-posti areng on väljastpoolt vaadates kohutavalt aeglane, viimaste aastate suurim täiendus e-posti standardites on olnud täpitähtede tugi e-posti aadressi kasutajanime osas (domeeni osas olid täpitähed juba varem lubatud), näiteks андрис@уайлддак.орг on nende uuenduste alusel täiesti korrektne ja toimiv aadress. Samas suurem osa e-posti servereid selliseid aadresse endiselt ei toeta, kuna vastav standard on “alles” 6 aastat vana.

E-post elab ikka veel

Miskipärast ei ole e-posti kasutamine, hoolimata selle piiratud võimalustest ja üliaeglasest muutumisest kuhugi kadunud – vastupidi, selle tähtsus on ajas aina kasvanud. Tõsi, korrespondentsi laad ei ole võibolla püsinud päris sama. Täna me ei leia oma e-postkastist mitte niivõrd otsesuhtlust oma sõprade või lähedastega (selle jaoks on välksuhtlusrakendused tõesti paremad), vaid uudiskirju, paroolimeeldetuletusi, elektrooniliste teenuste kviitungeid, kõikvõimalikke teavitusi, tuttavate tehtud fotosid ühistest üritustest jmt.

Lisaks muutunud sisule on e-postkast sarnaselt päris postkastiga muutunud rohkem globaalse identiteedi osaks, selmet olla vaid suhtluskanal – Jaan Tammesid võib olla maailmas palju, aga konkreetsel aadressil elab siiski neist vaid üks. Facebookis on samanimelisi inimesi palju, aga igaühel neist on unikaalne e-posti aadress. E-posti aadress on seega sarnane läänemaailma kurikuulsate gaasiarvetega, mida tahetakse pangakonto avamisel näha. Kuigi e-post pole selleks üldse mõeldud ja riiklikult täiesti sanktsioneerimata, on praktikas tegu identiteedi tunnusega.

Failisüsteemi rõõmud ja mured

Muutunud sisu on jätnud oma jälje ka kasutaja e-postkasti majutavale ressursile. Uudiskirja peen HTML kood ja kujundus on mahult hoopis erinev välkteatest sõbrale. Kirjade kustutamise asemel kuhjatakse need erinevatesse kaustadesse, nii et mõnes kaustas on varasema 200 asemel 200 000 kirja. Moodsa telefoniga saadetud foto on suurem, kui kunagi ammu olid mitme aasta kirjad kokku. Mis siis veel sellest rääkida, kui see foto saadetakse mitte ühele inimesele, vaid kõikidele samal üritusel viibinutele. Mäletan isegi kuidas kunagises töökohas saatis postiserveri administraator kõigile kurja kirja, kui inimesed töökaaslastele ühte ja sedasama koerapilti edastasid ning sellega serveri töövõime ohtu seadsid.

Samas, kui nüüd vaadata, et kuidas on e-posti serveri tarkvara (eelkõige pean silmas kõigile kättesaadavat avatud lähtekoodil põhinevat tarkvara) nende muutustega kaasas käinud, siis selgub, et väga nagu ei olegi. Riistvara on odavam ja kiirem kui varem, seega piisab reeglina lihtsalt tarkvara seadistuses määrata endise 10MB postkasti suuruse asemel 10GB ning ongi nagu kõik korras. Enamikel juhtudel ongi korras, kümne inimese 10GB postkastide jaoks läheb serveris vaja kuni 100GB kõvaketast, mis ei ole tänapäeval mingi suurus. Probleemid tekivad siis, kui tegu on juba suurema hulga kui toatäie inimeste postkastide majutamisega. 1000 inimese postkastide majutamiseks läheb vaja 10TB kõvakettaruumi, 10 000 inimese jaoks juba 100TB jne.

Reeglina ei ole inimestel postkast kogu aeg servani täis, mis annab mõningase võimaluse paigutada serverisse rohkem postkaste, kui sinna tegelikult mahuks. Samas aga tähendab see pidevat monitoorimist, et kui täis või tühi mingi server tegelikult on ja vajadusel migreerida kasutajaid, tuleb liigutada suuri postkaste tühjematesse serverisse ja teha muid sarnaseid tegevusi. Klassikaliselt asuvad kasutaja kõik kirjad kas ühesainsas failis (mbox formaat) või ühes kaustas (maildir formaat), igal juhul tähendab kasutaja migreerimine, et ümber ei tule kolida mitte neid kirju, mis serverisse ära ei mahu, vaid terve postkast koos saba ja sarvedega.

Mõningase leevenduse annavad teinekord skaleeruvad võrgupõhised failisüsteemid nagu GlusterFS, kuid sõltuvalt kasutatud tarkvarast võib tekkida ootamatuid ja seletamatuid probleeme – tarkvara eeldab failisüsteemilt reeglina sellist käitumist, milleks võrgupõhine kuidagi võimeline pole, st. et süsteem peaks olema korraga kiire ja usaldusväärne. Failisüsteemi toimingud (näiteks faili ümbernimetamine, mis on maildir puhul väga tüüpiline tegevus) teostatakse koheselt ja enam-vähem konstantse kiirusega ning üldiselt need toimingud ka õnnestuvad, võrk aga on tunduvalt ebakindlam. Tavaliselt kõik toimib, aga siis, ühel hetkel, võtab faili ümbernimetamine aega 10 sekundit. Iseenesest mis siis sellest, aga kui tavaliselt võib lugeda sellise tegevuse kestust pigem milli- või isegi mikrosekundites, siis 10 sekundit on sellest 10 000 korda aeglasem. Lisame patta veel samal ajal kuhjuvad muud ootel tegevused (ka kõik ülejäänud kasutajad tahavad samal ajal oma postkastis muudatusi teha) ja saamegi tulemuseks väikese kaose.

Üks häda ja viletsus

IMAP protokoll, mille abil kasutajad oma e-kirju serverist alla laevad, on algselt disainitud olema skaleeruv, kus eeldatakse, et kasutaja võib ühenduda korraga erinevate serverite pihta kuna e-posti server ei pea otseselt olema seotud kirjade hoiustamisega. Selline disain tuli reaktsioonina ülimalt piiratud POP3 protokollile, kus, vähe sellest, et ei saa sama kasutaja paralleelselt pöörduda erinevate serverite poole, ei saa kasutaja paralleelselt üldse midagi teha ning peab piirduma üheainsa ühendusega. Samas praegused IMAP implementatsioonid on tavaliselt jäigalt failisüsteemiga seotud ja nendes implementatsioonides ei saa kasutaja päringuid hajutada, kuigi protokoll seda isegi võimaldaks. Ka Dovecot Director puhul, mis on kättesaadavatest lahendustest senini parim, satuvad sama kasutaja paralleelsed ühendused alati samasse serverisse (kuigi tõsi, see server võib aja jooksul vahelduda).

Veel üks keeruline küsimus e-posti puhul on autentimine. Esiteks on autenditavaid kohti palju – veebimeil, IMAP, POP3, SMTP ning kõiki neid tuleks kuidagi eraldi kohelda. Kui me tahame pakkuda veel kahefaktorilist autentimist, rakendusepõhiseid paroole, autentimislogi, ajas uuenevat parooliräsi algoritmi jmt. siis, kuigi võimalik, tähendab see olemasolevate rakenduste korralikku häkkimist.

Meilirakenduste monitoorimine on samuti olnud üldiselt paras peavalu. Loomulikult on olemas kõiksugu tööriistad e-posti järjekordade haldamiseks, kuid suures osas tähendab see failisüsteemis perioodilist failide ülelugemist või paremal juhul meiliserveri logifailide analüüsimist. Tõenäoliselt jääb meile meiliserveri kõhus toimuv siiski parajaks mustaks auguks. Siin tuleb jälle mängu sama kana ja muna probleem, et meilisüsteem asub reeglina ainult ühes masinas. Sellises seadistuses on ühes masinas loomulikult ka logifailid ja seega, kuigi võib-olla ebamugav, on neid logifaile võimalik töödelda standardsete utiliitidega nagu grep, awk ja sõbrad. Jaotame aga meilinduse mitmesse serverisse laiali ja kohe ongi pilt eest läinud, et mis täpselt toimub.

Üks tüüpiline puudujääk e-posti serverite tarkvaras on muutuste jälgimine kasutaja kontol. Näiteks kui kasutaja loob ühes meilirakenduses IMAP protokolli kaudu uue kausta, või veel hullem – nimetab mõne olemasoleva kausta ümber, siis sama kasutaja teine seade ei saa sellest mitte kuidagi teada. Muutused kaustadega ilmnevad üsna pea, sest reeglina teevad meilikliendid peale uue ühenduse avamist kaustade listingu, kuid esiteks võtab see aega ning teiseks, ümbernimetamiste puhul see ei aita, meilikliendi jaoks paistab selline kaust olevat uus kaust uute kirjadega, mis tuleb jälle alla tõmmata, samas kui ümbernimetatud kaust koos selles olnud kirjadega kustutatakse ära. Hea küll, IMAP klient on piiratud kasutatava protokolliga, aga sama kandub üle ka veebimeili rakendustele, mis reeglina on samuti taustal IMAP kliendid.

Ning kui veebimeil juba jutuks tuli, siis veebimeil üle IMAP protokolli on paras kaos. Heal juhul istub veebimeili rakenduse ja IMAP serveri vahel mingisugune kolmas rakendus, mis hoiab ühendusi IMAP serveri suunas lahti, aga reeglina tähendab siiski iga uus päring kliendi poolelt kogu IMAP tsirkuse taasmängimist – ühenduse avamine (sh. TLS “käepigistus”), serveri võimaluste küsimine, kasutaja autentimine, kausta avamist ning alles seejärel toimingut kirjaga (näiteks selle loetuks märkimist). IMAP protokolli kasutamine ning RFC822 vormingus e-kirjade haldamine teeb veebimeili arenduse ülimalt keerukaks ja aeganõudvaks. Populaarse veebimeili tarkvara Roundcube uue versiooni arenduseks mõeldud rahakogumise kampaania lõppes edukalt juba 3 aastat tagasi, aga siiani peame leppima vana versiooni kasutamisega.

Mida siis teha?

Väikestel pakkujatel taolisi skaleeruvusprobleeme, kus kasutajad enam ühte või paari serverisse ära ei mahu, üldiselt ei ole ning nemad saavad vabavara peal hakkama. Suured e-posti teenuse pakkujad on lahendanud skaleeruvusprobleemid ennekõike omaenda vajadustele vastava tarkvara arendusega, kus failisüsteemi asemel on kohe kasutuses skaleeruvad võrgusüsteemid ning tarkvara ei oota failisüsteemi tavapäraseid garantiisid, kuid need ei ole siis enam vabavaralised lahendused. Zone, kus postkastide arvu loetakse kuuekohalise numbriga, on selles suhtes olnud veidi õnnetus positsioonis, et tegu ei ole ammu enam väikese pakkujaga, aga maailma mastaabis ka mitte suurega. Olemasolevad vabavaralised lahendused jäävad kitsaks, kuid suurte poolt kasutatavad e-posti lahendused jäävad käeulatusest välja. Ainus mõeldav variant kuni senimaani oleks olnud Dovecoti kommertslahendus koos Dovecoti Directori ning object storagega.

Zones läksime siiski teist teed ning ka meil on nüüd kasutusel maja sees ehitatud (kuid siiski vabavaraline) e-posti süsteem, mis vastab paremini reaalsetele nõudmistele.

Featuuridest, seekord positiivse noodiga

Kirju ei hoita enam failisüsteemis, vaid need on laiali suures MongoDB sharditud klastris. See tähendab, et kui kasutaja rakendus teeb kirjade listingut, siis osad kirjad sellest listingust võivad asuda ühes, aga osad hoopis teises shardis. Samuti on kirjad ise osadeks jaotatud, kus manused on serveri pool kirjadest eraldatud ning võivad asuda hoopis mujal. Alles kliendi päringu peale otsitakse need erinevad jupid klastris pealt kokku ja esitatakse kasutajale tavalise e-kirjana. Selle kohta võiks öelda, et tegu on üsna tüüpilise pilve-mudelil töötava lahendusega.

Veebimeili puhul võib IMAP protokolliga seonduva osa täiesti vahele jätta ning saame meiliserverist küsida andmeid üle standardse REST API. Kusjuures kogu töö e-posti vormindusega jääb serveri kanda, nii et veebimeil ei pea midagi teadma MIME-kodeeringutest ega sellest, et kuidas manuseid kirjadest kätte saada. Sama API annab koheselt teada ka kõikidest kontol toimunud muutustest, sealhulgas siis kaustade ümbernimetamisest ning kirjade lisandumistest/kustutamisest.

Keskne autentimissüsteem võimaldab granulaarset haldust, kus kasutajal võib olla mitu erinevat parooli ning igal paroolil saavad olla erinevad õigused mingite toimingute teostamiseks. Samuti võimaldab see paremini paroolide kasutamist logida ning seda logi kasutajale vajadusel ka näidata.

Küberrünnak Zone.ee e-posti süsteemide pihta? Ei, täiesti tavapärane pilt 60 sekundi jooksul mõõdetud automaatsete skännerite katsetest kasutajate postkaste üle võtta. Niiviisi need Minunimi123 tüüpi paroolidega kaitstud kontod langevadki

Iga tegevuse kohta on võimalik saata struktureeritud infot kas Greylogi või muusse sarnasesse logiserverisse, väljuvate kirjade queue seis on loetav Prometheuse formaadis, nii et sisepilt e-posti serveri töösse on tunduvalt parem ning anomaaliad kergemini tuvastatavad.

Lõpetuseks

Kõiki lisandunud võimalusi ei hakkagi üles lugema, muidu ei jää uuteks blogipostitusteks enam materjali. Kokkuvõtvalt võib küll tõdeda, et sellise e-posti süsteemi arendus ei ole olnud lihtne, see on võtnud kaua aega, aga loodetavasti on tulemus seda väärt. Siiani ei ole keskmise suurusega e-posti teenuse pakkujatele sobivat platvormi leidunud, eelkõige mõeldes siis muutunud kasutajaharjumuste ning postkastide suuruse peale, nüüdsest võibolla siis on.

Tööd alustas uus e-posti platvorm

Zone on tasa ja targu asunud klientide ette tooma ühe viimaste aastate suurema väljakutse vilja, milleks on kaasaegsem e-posti platvorm.

Uue platvormiga välja tuleku juures on meil üks olulisi eesmärke võimalikult vähe häirida oma klientide igapäevatööd, mistõttu saavad alguses vaikimisi selle kasutajateks meie uued kunded.

Neil, kes Zone infosüsteemi juba tarbivad, on peagi võimalik ise valida hetk, mil soovitakse oma postkastid uuele platvormile üle tõsta. Kuna paljude lõppkasutajatega klientide jaoks ei ole see triviaalne ülesanne, siis esialgu me kedagi tagant kiirustada ei kavatse.

Järgnevalt proovin kirjeldada meie uue e-posti platvormi võtmeomadusi, mis võiksid ahvataleda kõiki seda kasutama.

Uuel platvormil on kolmekordne töökindlus

Interneti olelusteenuste (veebimajutuse jms) kontekstis on e-post paljude teenusepakkujate ja kasutajate silmis teenimatult teisejärguline teenus, mille töökindlusele erilist tähelepanu ei pöörata ning millelt oodatakse ainult vaikselt taustal tiksumist. Pahatihti hoitakse kasutajate postkaste lausa veebiserveris, mis meie nägemuses on lubamatu.

Meil on alati e-posti teenindamise jaoks olnud eraldi füüsiline serveripark, milles igale infosüsteemi rollile on omad serverid (e-posti vastuvõtjad, välja saatjad, rämpspostifiltrid, antiviirused, proksid, postkastide säilitamine jne) ning enamus neist dubleeritud.

Nüüd astume sammukese veel edasi. Kasutaja postkasti säilitab tulevikus korraga mitte üks või kaks, vaid lausa kolm serverit, mis saavad talitluspidevuse säilitamise eesmärgil olema hajutatud mitme andmekeskuse vahel.

See tähendab, et isegi ühe või kahe serveri täieliku häivimise korral ei pea me kliendi teenuse taastamiseks veel kasutama varukoopiaid, vaid lihtsalt suunama päringud ümber kolmandale serverile.

Varukoopiatest ei pääse loomulikult üle ega ümber, neid jääme jätkuvalt tegema. Mitmeid teenuse üldise jätkusuutlikkusega seotud riske on võimalik maandada vaid varukoopiate abil.

Uus platvorm on vaikimisi turvalisem

Nende aastakümnete jooksul, mil oleme e-posti teenuse pakkumisega tegelenud, on ühiskonna ootused andmete privaatsusele muutunud palju nõudlikumaks ning e-posti puudutav seadusandlus samuti karmistunud.

Seetõttu on meie uues platvormis läbivalt kasutusel krüpteeritud ühendused TLS (Transport Layer Security) tehnoloogial, maandamaks salasõnade või kasutaja andmete lekkega seotud riske.

NB! Pane nüüd hästi tähele! See tähendab järgmist:

  • POP3 ja IMAP protokollid on ligipääsetavad ainult nende krüpteeritud vormides POP3S (TCP port 995) ja IMAPS (TCP port 993);
  • SMTP ühendus on samuti ligipääsetav ainult selle krüpteeritud vormis, kasutusel on SMTPS (TCP port 465) ja SMTP STARTTLS (TCP port 587).

Kuna sisuliselt käsitletakse pea igas postkastis isikuandmeid, siis on selline lähenemine nende kaitse kontekstis igati õigustatud. Nii aitame oma klientidel vältida mitmete elementaarsete riskide realiseerumist ja vähendada nendega seotud võimalikke kahjusid.

Rämpsposti ja pahavara eemaldamine on efektiivsem

Rämpspostifilter tegutseb nüüd efektiivsemalt, konkreetsemalt ja lausa 10x kiiremini.

Rämpspost pannakse edaspidi vaikimisi serveri pool hoitavasse eraldi kausta. Kui seni võisid rämpsuks klassifitseeritud kirjad märgistatuna jõuda ka kasutaja sisenevasse postkasti (inbox), siis uues platvormis hoitakse seda puhtamana.

Tähelepanu! Oluline on teada, et 30 päeva peale rämpskirja saabumist kustutakse see serveri poolt automaatselt ära.

Rämpsposti märgistamine kirja pealkirjas või sisus lõpeb aga ära. Erinevalt praegusest ei muudeta tulevikus enam rämpspostiks loetava kirja sisu ega pealkirja, need jäävad samaks. Kogu kirja rämpsuks klassifitseerimist puudutav täiendav info lisatakse kirja päistesse. Kiri pannakse rämpsposti kausta oma algse välimusega.

Rämpsposti tõkestamine muutub personaalsemaks.

Rämpsposti tuvastamise tundlikkuse seadistamisel võetakse senise domeenipõhise punktisüsteemi asemel kasutusele uus süsteem, mille “rangust” iseloomustab neli taset, mida saab määrata igale postkastile eraldi.

Need tasemed on:

  • deaktiveeritud
  • madal
  • keskmine
  • kõrge.

Vaikimisi seadistatakse rämpsposti tuvastustundlikkus keskmisel tasemel.

Arvestades globaalseid trende, ei ole pahavara tõkestamisega tegelevat antiviirust võimalik uues e-posti infosüsteemis ka enam välja lülitada.

Rakendustele või seadmetele spetsiifilised salasõnad pakuvad täiendavaid riskide maandamise võimalusi

Lisaks postkasti peasalasõnale on uues infosüsteemis võimalik luua täiendavaid salasõnu, mida saab kasutada erinevates rakendustes või seadmetes.

See võimaldab näiteks kasutada üht salasõna oma lauaarvutis, teist sülearvutis, kolmandat mobiilseadmes ja neljandat mõnes pilveteenuses. Salasõna lekkimisel on nii võimalik lihtsalt tuvastada kust see “jalutama läks”.

Samuti ei ole ühe salasõna kustutamisel või muutmisel kõik ligipääsud e-postile kadunud.

Täiendavaid salasõnu saab hetkel lisada veebipõhise e-posti vahendusel.

Kirju saab uues platvormis filtreerida ka serveri poolel

Lõpuks on saanud teoks paljude meie kasutajate poolt pikisilmi oodatud võimalus. Nüüd on võimalik lasta sisenevaid kirju filtreerida meie serveritel, mitte e-posti klienttarkvaral.

Kui kasutaja on seadistanud endale filtreid, siis serverid tähistavad, liigutavad, edastavad ja kustutavad kirjad vastavalt nendes kirjeldatud instruktsioonidele juba enne, kui need kliendi seadmesse jõuavad.

See tähendab, et enam pole vaja luua eraldi filtreid igas seadmes, kust neid loetakse. Samuti töötavad filtrid ühtmoodi sõltumata sellest, kuidas kasutaja oma kirjade poole pöördub – olgu selleks siis POP3, IMAP või veebipõhine e-posti klient.

Serveripoolseid filtreid saab täna seadistada veebipõhise e-posti kliendi seadetes.

(Kasutajaliides filtrite loomiseks pole tõesti hetkel just kõige mugavam, aga see paraneb peagi.)

E-posti seadistamine on kiirem ja dünaamilisem

Postkastide lisamine ja e-posti sätete muutmine muutub palju kiiremaks ja platvorm reageerib muudatustele dünaamilisemalt. Lisatud e-posti aadressid hakkavad edaspidi normaalolukorras tööle kohe peale haldusliideses nupu vajutamist ja muud e-posti sätete muudatused jõustuvad samuti hetkega.

Postkasti kustutamine samas ei toimu enam hetkega – kustutamisele järgneb nüüd 14 päevane karantiiniperiood, mille möödudes postkast hävitatakse. Selle perioodi jooksul on serveri haldajal võimalik otsustada postkasti taastada või see kohe hävitada.  See viimane tähendab kogu postkasti sisu kadumist –  kadunud andmeid pole enam võimalik taastada isegi varukoopiast, sest ka need hävitatakse.

Teenused saavad uued aadressid

Selleks, et mitte sundida olemasolevaid kasutajaid kohe oma seadistusi muutma, oleme otsustanud, et uue e-posti platvormi poole pöördumisel tuleb kasutada uusi teenuste aadresse.

Iga e-posti protokolli jaoks on see nüüd unikaalne:

  • SMTP teenuse leiab aadressilt smtp.zone.eu;
  • IMAP teenuse leiab aadressilt imap.zone.eu;
  • POP3 teenuse leiab aadressilt pop3.zone.eu.

Iseenesest lihtne, kuid nõuab kindlasti harjumist, sest praegused aadressid on kasutusel olnud juba väga pikka aega ja paljudel nö “käe sees”.

Senised aadressid jäävad seotuks praegu tarbitava platvormiga.

Selleks, et e-posti seadistamine oleks lihtsam, oleme klientprogrammide seadistamise juhistele lisanud võimaluse tuvastada konkreetsele domeenile kehtivad sätted.

Postkastile nime valimine läheb lihtsamaks

E-posti aadresside loomisel ettevõttes moodustatakse see reeglina kasutaja ees- ja perenimest, seejuures eksisteerib kaks koolkonda – ühed kirjutavad need kokku (jaantamm@domeen.tld) ja teised eraldavad punktiga (jaan.tamm@domeen.tld).

Toome need leerid omavahel kokku ja muudame punkti postkasti nimes valikuliseks. Uuel platvormil viivad ühte postkasti nii aadressidele jaantamm@domeen.tld, jaan.tamm@domeen.tld kui ka j.a.a.n.t.a.m.m@domeen.tld saadetud kirjad.

IMAP kataloogipuu on lihtsam ja ühildub paremini rakendustega

Senine, mõnedele IMAP protokolli kasutajatele veidi segadust tekitanud, INBOX prefix kaob uute postkastide nimeruumist ära. Kõik alam-postkastid tehakse tulevikus vaikimisi postkasti juurkataloogi. See lahendus ühildub paremini kaasagsete kolmandate osapoolte rakenduste ning pilveteenustega.

 

Kas saaksid kiiresti ühe maksekorralduse teha?

Umbes sellise küsimusega hakkab pihta enamus CEO-kelmuse kirjavahetustest – ja viimastel päevadel on nende hulk järsult kasvanud. Suvi, firmades on osa inimesi puhkamas ning suhtlevad teistega äärmise vajaduse korral lühikeste, mobla-ekraanilt tipitud sõnumitega.

Kontorisse jäänutel on aga puhkajate asendamistega käed-jalad tööd täis ning olukord natuke uus ja ilma sisse harjunud käitumisreegliteta.

Näiteks võiks reedel, napilt enne lõunapausi, assistent Anne postkasti saabuda selline kiri tegevjuht Tiiult:

Ääremärkus: see ja järgmised kirjad on pärit ühe meie turvateadliku kliendi suhtlusest päris kelmidega. Nimed ja aadressid muudetud, fiktiivse firma nimi pärit ühest sotsmeedia-eksperimendist. Igaks juhuks ka tavakohane hoiatus “don’t try that at home work” – vaevalt, et neil sind maksma petta õnnestub… aga äkki võtab keegi trollimist südamesse ja leiab mõne turvaprobleemi mille ärakasutamise-katseks sa veel valmis pole.

Raamatupidaja on puhkusel, aga lõunalt naasnud Anne ülesandeks on kontor iga ilmaga toimivana hoida ja Tiiu saab peagi täpsustava küsimuse:

Viis minutit hiljem tuleb talt vastus:

Samuel on ilmselt rahamuul, kes on “töökuulutuse” peale olnud nõus oma kontole saabuvast rahast 90% sulas välja võtma ja Western Union’i kaudu edasi saatma.

Anne jääb hetkeks kirja uurima – aga peagi on postkastis järgmine kiri Tiiult, kellel ilmselt on maksega kiire:

Mistahes kelmuse puhul on oluline sundida ohver enne tegutsema ja alles siis mõtlema. “Ja-jaa, juba jooksen,” ohkab Anne – aga ta ei saa ju niisama maksta, sest raamatupidaja peaks selle kuidagi algdokumendiga kokku viima:

Ja saab vastuseks:

Nagu näha, sai Google Translate jälle natuke tööd teha ning kellegi nobedad näpud kopeerisid vastused Outlook’i.

Järgmine kord ei pruugi aga pettus nii kergesti märgatav olla, sest suhtluse kulg on üsnagi etteaimatav ja pole keeruline paarkümmend tüüpvastust inimtõlgilt tellida. Tegemist on ikkagi levinud kelmuseliigiga ja küllap leiab selle läbiviimiseks asjakohastest veebidest nii õpetusi kui ka tekstinäiteid. Brian Krebs’il on hea lugu veidi erinevast pettuseliigi ehk “vene kohtinguteenusest” toimimisest.

Jätame aga Tiiu ja Anne omavahel suhtlema ning vaatame…

Kuidas selline kelmus töötab?

Keerulisemate CEO-kelmuste puhul on tegemist ühe osapoole e-postikonto ülevõtmise ning päris arve võltsimisega. Sellist näidet kirjeldab Andris postituses Tõestisündinud lugu e-posti võltsimise tõttu kaotatud rahast ja ühte banaalselt lihtsat postikontosse sissemurdmist lahkas Ardi loos “Paha Panda” varastab postkaste.

Sedapuhku pole aga tegemist konkreetse firma vastu suunatud kuluka harpuunimisega ning Tiiu ja Anne kontaktid leiti pigem firma kodulehelt:

Veebifragment kelmidega kirjavahetust arendanud firma kodulehelt, pildid “Anna Malvara” loo juurest. Olgu lisatud, et mõlemad on 100% sünteetilised ehk 3D-renderdatud – Tiiu on pärit Renderpeople galeriist ja Anne leidsin üles ühest 3ds Max’i õpetusest.

Robotid skannivad tuhandete firmade veebe, korjates kokku e-posti-aadressid ning nendega seotud nimed ja rollid. Keegi hoolas inimene puhastab andmed ja müüb need kena Exceli-tabelina ahela järgmisele lülile maha – hinnajärk ilmselt sent per firma.

Ja see järgmine lüli saadab laiali spämmi, kus saatja real on kenasti From: Tiiu Kask <tiiu@malvara.ee>, kiri on saadetud mõne pahaaimamatu firma serverist (Return-Path: <vd@somehackedwebsite.com>) ja Outlook’i vms e-postikliendi puhul vastamisel kasutatav Reply-To aadress viitab kolmandale, samuti kelmi kontrolli all olevale serverile, kus kasutajanimest sõltumatult jõuavad kõik kirjad “operaatori” postkasti (Reply-To: "Tiiu Kask" <tiiu@vd-scammersdomain.org>):

Anne saab kogu suhtluse käigus kirju, kus saatjaks oleks justnagu õige Tiiu – aga tehes Reply läheb vastus vale-Tiiule.

Kuidas ennast selliste pettuste eest kaitsta?

Ma heameelega räägiks siinkohal vajadusest lisada oma domeenile SPF-kirje, mis võimaldab postiserveritel kontrollida, et malvara.ee kirju tohib saata ainult see üks ja õige server (loe: 3 tehnoloogiat, mis aitavad kirjad kindlalt kohale toimetada ja Kuidas kontrollida väljuva e-posti SPF+DKIM+DMARC toimimist?)… aga kuigi see on 100% mõistlik liigutus, peitub tegelik võti ikka meie endi peas – valmisolekus kelmust ära tunda ja kokkulepitud käitumisreeglites:

  • tea, et kiirusele rõhumine on sageli märk soovist sind tavapärasest erinevalt käituma panna ja e-posti on lihtne võltsida
  • vähimagi kahtluse korral kontrolli saatja tegelik soov üle, kasutades selleks alternatiivset sideviisi (loe: helista sulle teadaolevale, mitte kirjas toodud numbrile) või kasuta vastamise (Reply-To) asemel edastamist (Forward) sisestades teise osapoole aadress ise To-lahtrisse
  • sellise kelmuse ohvriks sattujad ei ole rumalad või hooletud – teine pool on suhtluse üles ehitanud lähtudes väga heast inimpsühholoogia tundmisest ning iga sammu läbi mõelnud, praktiseerides sellist tegevust “üheksast viieni” ehk põhitööna

Tänud kõigile, kes on võtnud vaevaks meile kirjanäidiseid saata ning eriti uudishimulikule “Annele”, kes tahtis teada mis toimub peeglitaguses maailmas 🙂

“Paha Panda” varastab postkaste

Suurbritannia parlamenti tabanud küberrünnak, mis suunatud parlamendiliikmete e-poskastide vastu, ajendab jagama infot e-posti rünnakukampaania kohta, mis täna aktuaalne ka Eestis.

Ühel pealelõunal hakkasid Zone IT operatsioonide meeskonna ekraanil vilkuma alarmid. Infoturbeintsidente tuvastav monitooringusüsteem hakkas järjest välja sülitama teateid, et mõned e-posti kasutajad rikuvad teleportides teada olevaid füüsikaseadusi.

Teleportimine on fenomen, mille puhul internetikasutaja ühendub ühel hetkel meie serveriga Eestist, järgmisel Hiinast, siis omakorda Venemaalt, Malaisiast, Indoneesiast, Brasiiliast või mujalt. Kuigi eksisteerivad mõned erandid (Tor), viitab selline kontinentide vahel hüplemine enamasti siiski kasutajaandmete lekkimisele.

Lühikese aja jooksul tuvastas monitooringusüsteem seda anomaaliat ligi saja e-posti kasutaja juures, võimaliku kuriteo takistamiseks ning kahju minimaliseerimiseks hakkas algoritm blokeerima teleportivate kasutajate ligipääsu serveritele.

Kasutajaandmete lekkimise intsidendid ei ole harukordsed, selliseid intsidente leiab aset regulaarselt – enamasti on põhjuseks kasutajaandmete jalutama minek kahtlasest WiFi võrgust, tööjaama nakatumine pahavaraga või sama kasutajanime/salasõna tarvitamine mõnel hiljuti kompromiteeritud veebisaidil.

Mõjutatud kasutajate arv pani siiski meie infoturbe töörühmal vere vemmeldama. Kui korraga rikutakse niivõrd suure hulga kasutajate privaatsust, tuleb igaks juhuks välistada võimalus, et salasõnad on lekkinud meie süsteemist.

Analüüs

Seetõttu alustati koheselt tööd logide analüüsimise kallal ja võeti ühendust ka mõnede mõjutatud kasutajate või neid toetavate IT spetsialistidega, et selgitada välja võimaliku lekke asjaolud.

Hüpotees andmelekkest meie poolel õnneks kinnitust ei leidnud. Küll aga avastasime oma logisid analüüsides ühe üllatava fenomeni, mille eest teid nüüd hoiatada tahan.

Nimelt on aset on leidmas unikaalne kampaania üliaeglase jõuründe (slow rate brute force attack) näol, mille abil loodetakse rikkuda internetikasutajate e-posti privaatsust.

Jõurünnet teostatakse tavaliselt juhuslike stringide läbiproovimise teel või sõnastikuründe abil ning võimalikult suure efektiivsuse nimelt proovitakse lühikese aja jooksul läbi suur hulk erinevaid salasõna kandidaate. Jõuründe muudab ebaefektiivseks see, et seda on suhteliselt lihtne tuvastada.

See tegevus, mis meile logist vastu vaatas, oli teistsugune.

“Paha Panda”

Vältimaks tuvastamist, tegutseb konkreetset rünnakut teostav kurjategija meelega aeglaselt, metoodiliselt ja väga kannatlikult.

Protseduur, mida kasutaja andmete arvamiseks kasutati, oli iga sihtmärgi puhul sarnane.

Ühel heal päeval ilmub logisse 5-6 kurjategija võrgustikku kuuluvat IP aadressi, millest igaüks katsetab sihtmärgi peal mõnd salasõna kandidaati. Sellele katsele järgneb 2-3 tundi vaikust. Siis ilmub ründaja taas välja ja proovib järgmise 5-6 erineva IP pealt. Jälle 2-3 tundi vaikust ja uus katse. Selline õngitsemine võib kesta nädalaid.

Iga sihtmärgi kallal töötab kurjategija tilkuva vee järjepidevusega, mis kivisse auku uuristab.

Ja see järjepidevus viib mõnel juhul ka sihile. Mõnel juhul õnnestus see kurjategijal juba 6 katse pealt, teisel juhul kulus eduks poolteist kuni kaks tuhat katset. Ühe konkreetse sihtmärgi puhul kulutas kurjategija eesmärgini jõudmiseks 553 päringut, nendega alustati 3. mail ja eduka tulemuseni jõuti 14. mail. Seejuures sooritati need päringud 445 erineva IP pealt.

Selles ründe iseloomus peegeldub omal moel mingi aasialik stoiline rahu, mis kombinatsioonis paljude kurjategija botneti Hiina päritolu IP aadressidega on pannud mind teda “Pahaks Pandaks” kutsuma 🙂

“Panda” üheks relvaks on aeglus, millega petetakse ära monitooringusüsteemid. Kui üks IP aadress teeb iga 2-3 tunni tagant mõnele kontole ühe ebaõnnestunud sisselogimiskatse, ei jää see ühtegi monitooringusse kinni, sest selline paranoia tase muudaks valepositiivsete tuvastuste hulga liiga suureks. Isegi kuu lõikes uurides jäävad “Panda” kasutatavad IP aadressid kaugelt välja ebaõnnestunud autentimiskatseid sooritavate süsteemide esiviiekümnest.

Kindlasti on nii mõnelgi kogenud IT-spetsialistil siinkohal kulm juba kipras ja küsimus keelel – kuidas on võimalik salasõnu nii väheste arvamistega salasõna ära arvata? Vastus on lihtne – “Panda” teab, et energiat tuleb kokku hoida, seetõttu ei käi ta läbi juhuslikke salasõna kombinatsioone, vaid kasutab teise relvana kasutajate endi halbu käitumismustreid.

Inimesed on halvad juhuarvugeneraatorid. Kui paluda inimestel valida juhuslik arv 1-10 vahel, valib väidetavalt ebaproportsionaalne hulk neist numbri 7 (trollidega, nagu ülal näha, on sarnane lugu). Sama kordub salasõnade määramisel. Mõte juhuslikust tähtede, numbrite ja sümbolite jadast tuleb pähe vaid vähestele.

Paljud hakkavad otsima abi sellest, mis ekraanil, klaviatuuril või parajasti meelel. Nii muutub väga tõenäoliseks, et e-posti aadressi siim@domeen.tld looja määrab sellele salasõnaks kombinatsiooni nimest Siim ja mingist numbrite jadast. Salasõnade variatsioonid nagu “Siim123”, “Siim1234”, “Siim666”, “Siim2017” on levinumad, kui julgeme endale tunnistada. Sama levinud on ilmselt klaviatuurilt tuletatud salasõnade kombinatsioonid nagu “Qwe123”, “Asdasd123”, “Qwerty666” jne või aadressiribalt tuletatud “Zone123”, “Zone.ee123” jne.

Nii ei raiska meie antikangelasest kurjategija “Panda” ennast juhuslike stringide äraarvamisega või täiemahulise sõnastikuründega. Ta on valinud välja suure hulga väga levinud halbu salasõnade mustreid ja tiksutab tema sihtmärkide hulgas läbi proovida.

“Panda” sihtmärgid on esmapilgul täiesti suvalised, ilmselt on need saadud veebilehtede kaapimise teel ja muudest allmaailmale tuntud allikatest. Silma jääb siiski kontakt@, contact@ ja info@ aadresside suur osakaal.

Aadresside internetist kogumisele viitab seegi, et mitmed aadressid, mida sihtmärgina kaaluti, sisaldasid kirjavigu – näiteks otsiti ühe telekanali töötaja e-posti kontot domeenist, mis erines tema tööandja tegelikust domeenist vaid ühe märgi võrra.

Võimalik kahju

Mida kurja “Panda” nende lahti murtud postkastidega korda saata võib? Väga paljut.

Kui mäletate, siis eelmisel aastal kirjutas Andris populaarsest skeemist, milles e-posti abil ettevõtetele sokutatakse valearveid (“Tõestisündinud lugu e-posti võltsimise tõttu kaotatud rahast”). Eelnevalt kirjeldatud viisil lahti murtud raamatupidaja postkast on sellisele valearvetega skeemitajale kulla hinnaga.

Loomulikult on sellised postkastid ka võrratuteks relvadeks spämmeritele. Domeenid ja postkastid, mis pole kunagi rämpsposti saatnud ja mille väljuvad kirjad kannavad usaldusväärsuse nimel DKIM-i antud autentsustõendi ja SPF-i ning DMARC-i allikakinnitusega? Just sellise spämmiga kurjategija meie radarile sattuski.

Kui kurjategija sooviks, siis võiks ta loomulikult ka postkastis tuulata ja sealt väärtuslikumat sisu endale sebida. Näiteks võib ta panna kokku aadressiraamatu inimestest, kellega tihedalt suheldakse ja korraldada klassikalise “Olen välismaal lennujaamas, rahakott varastati ära, ole hea kanna mulle kiirelt paar sotti” kampaania. Samasuguse õngitsusrünnaku saaks korraldada ka postkastiomaniku enda vastu.

Halvemal juhul on sama salasõna inimesel kasutusel mõnes olulises infosüsteemis, mille olemasolu suudab kurjategija näiteks poskasti sisu järgi kindlaks teha. Siis võidakse kompromiteerida juba mitte ainult postkasti sisu, vaid palju olulisemaid andmeid.

Kui “Panda” tahaks, saaks ta ka WannaCry või Petya pahavara niimoodi otse postkasti ujutada ja käivitada väljapressimisega lõppeva rünnaku. Viimasest sellisest ründest kirjutab RIA https://www.ria.ee/ee/uus-lunavaralaine.html

Ja hoidke alt, kui postkast kuulub riigiasutusele. “Panda” võib oma riigi struktuuridega sujuvate suhete omamise nimel head ja paremat ka neile sokutada.

Parem karta kui kahetseda. Kui tundsid ülalpool ära mõne oma salasõna mustri, siis muuda seda kohe.

Kokkuvõtteks

Miks ma sellest intsidendist kirjutan?

Esiteks tahame kõigile meelde tuletada kui halvad on ülalkirjeldatud mustrid salasõnades.

Teiseks pole me kindlad, kas teised e-posti serverite haldajad on “Paha Panda” tegutsemist tähele pannud – loodetavasti annab käesolev postitus neile ajendi seda kontrollida.

Kolmandaks annab see lugu loodetavasti selgust motiivi osas, miks Zone e-posti salasõnadele esitatavaid nõudeid muudab.

Me toome nõudmised salasõnale kaasaega. Rohkem kui salasõna keerukust, hindame me selle pikkust ning üritame takistada halbade mustrite kasutamist. Halbadeks loeme üldlevinud salasõnu; salasõnu, mille sisu saab tuletada kaitstava ressurssi kontekstist ja muud äraarvatavat. Uue e-posti salasõna miinimumpikkus on Zones nüüd 10 märki.

Rohkem salasõnu stiilis “Minu Lemmikpuu On Remmelgas” ja vähem stiilis “Siim123” 😀

Tõestisündinud lugu e-posti võltsimise tõttu kaotatud rahast

Lahkame keerukat ent elulist e-posti võltsimise juhtumit, mis lõppes kannataja jaoks märkimisväärse rahalise kahjuga. Soovitan seda analüüsi lugeda kõigil, kes e-posti teel arveid saadavad või vastu võtavad. Loetu võib säästa teid peavalust ja raskelt teenitud raha kaotamisest.

Esmalt kirjeldan meie tragöödia osapooled. Algses kirjavahetuses oli neid kolm: Eesti ettevõtja (Müüja), tema partner Hiinas (Tootja) ning klient Aasias (Ostja).

Osapoolte vaheline suhtlus käib kogu aeg e-posti teel ‘Reply To All’ meetodil ehk et iga järgmine kiri adresseeritakse kõigile kirja päises mainitud aadressidele. Algab kirjavahetus tavalisest ärisuhtlusest, lepitakse kokku mida ja kuhu saata, täpne transpordiviis ja muud taolist. Osalisi on lõpuks kirjavahetuse To (adressaat) ja Cc (koopia) ridadel palju.

Ühel hetkel jõutakse nii kaugele, et Eesti ettevõtjast Müüja koostab Ostjale ettemaksuarve, kus on loetletud kauba hind ning transpordikulu. Ostja saab arve kätte, maksab selle ära ja jääb kaupa ootama. Mida ei tule, on kaup. Kui Ostja pöördub lõpuks Müüja poole selgitusnõudega, saab ta vastuseks, et viimane pole raha näinud ja seetõttu kaupa väljastanud.

Mis Ostja rahaga juhtus?

Juhtus see, et meie kurbmängu neljandal osapoolel – Kurjategijal – oli õnnestunud üle võtta kas Müüja, Tootja või Ostja juures mõne kirjavahetuses osalenud inimese postkast. Kelle oma täpselt, ei ole teada ega antud kontekstis ka oluline. Mis järgnes, on aga šokeerivalt lihtne.

Kurjategija sättis ennast osapoolte kirjavahetuses vahemeheks, napsas Müüja poolt Ostjale teele pandud arve, muutis selle rekvisiidid ja saatis selle ise Ostjale edasi. Kuna muus osas oli arvega kõik korras ning see saabus eksisteeriva kirjalõime käigus, koos varasema kirjavahetuse koopiaga, mitte kahtlaselt eraldi, kandis klient tellimuse summa Kurjategija kontole.

Täpsemalt on arve väljastajaks märgitud küll ettevõte ise, kuid saaja pangakonto asub ühes Inglismaa ühistupangas ja kontoomaniku nimeks on märgitud keegi “Mr X”. Arve muu osa – arve read, maksmisele kuuluv summa, ettevõtte logo jne, olid muutmata ja ehtsad.

Kirjavahetuse analüüs

Vaatame nüüd täpsemalt, et kuidas sündmuste käik välja nägi.

Esimeste kirjade päised näevad välja nii (aadressid on siin ja edaspidi muudetud, ostja.tld tähistab kliendi domeeni, müüja.tld Eesti ettevõtte domeeni ja tootja.tld Hiina tehase domeeni, numbrid #1,#2,#3 jne. tähistavad erinevaid isikuid):

From: Ostja #1 <mailto:ostja_1@ostja.tld>
Date: 2016-10-07 12:26
To: Müüja <mailto:müüja_1@müüja.tld> ;
 Tootja #1 <mailto:tootja_1@tootja.tld>
CC: Ostja #2 <mailto:ostja_2@ostja.tld> ;
 Müüja #2 <mailto:müüja_2@müüja.tld> ;
 Müüja #3 <mailto:müüja_3@müüja.tld> ;
 Ostja #3 <mailto:ostja_3@ostja.tld> ;
 Ostja #4 <mailto:ostja_4@ostja.tld> ;
 Ostja #5 <mailto:ostja_5@ostja.tld>

Selliseid üsna paljude osapooltega kirju liigub kõikide osapoolte vahel palju. Muutuvad vaid aadresside asukohad kirja päises – kord on mõni aadress To, kord From real, vastavalt siis konkreetse kirja saatmisele.

Kirjade liikumise logides on kõik samuti korras ja seda senimaani, kuni saabub üks kummaline kliendipoolne kiri. Täpsemalt näeb logirida välja nii:

03:15:35 (2016-10-10) ... client=mout.gmx.com[74.208.4.200]
03:15:35 (2016-10-10) ... message-id=
 <trinity-...@3capp-mailcom-lxa16>
03:15:35 (2016-10-10) ... from mout.gmx.com[74.208.4.200];
 from=<ostja_1.ostja@mail.com>
 to=<müüja_1@müüja.tld>
 proto=ESMTP helo=<mout.gmx.com>
03:15:35 (2016-10-10) ... to=<müüja_2@müüja.tld>
03:15:35 (2016-10-10) ... to=<müüja_3@müüja.tld>

Nagu näha, on meiliteenusepakkuja GMX avanud ühenduse meie MX serverisse ning saadab Eesti ettevõttest Müüja kolmele esindajale kirja. Saajate näol on tegu siis nende aadressidega, mis asuvad kirja To ja Cc ridadel. Mis aga võiks kohe tähelepanu äratada on saatja aadress, mis varasemates kirjades on alati olnud kujul “ostja_1@ostja.tld”, aga nüüd on hoopis “ostja_1.ostja@mail.com”. Lisaks on teenusepakkujaks GMX, mitte kliendi senine tavapärane ISP.

See kiri sisaldab aga kogu eelnevat samas lõimes toimunud vestlust ja aadressiridadel on olemas kõik seotud osapooled, seega Müüjale midagi kahtlast selles ei tundu.

Samuti Cc real olnud Tootja esindaja vastab kirjale (ka tema ei märka midagi kahtlast) ja kogu vestlus käib edasi nagu tavaliselt. Samas kui vaadata edaspidise vestluse osapooli, siis on pilt drastiliselt muutunud.

Nimelt on selles kirjas Eesti e-posti aadressid ja Hiinas asuva Tootja aadress korrektsed, aga kõigi Kliendi esindajate aadressid, nii From kui Cc väljadel on muutunud kujule “ostja_N.ostja@mail.com”. Kuna kirjavahetus käib edasi ‘Reply To All’ meetodil, siis edaspidi jäävad kirjavahetuses kõikide kliendi esindajate aadresside asemel juba võltsitud @mail.com aadressid. Mitte keegi toimunud viga ei märka ja suhtlus käib endiselt edasi.

From: Ostja #1 <mailto:ostja_1.ostja@mail.com>
Date: 2016-10-11 14:56
To: Müüja #1 <mailto:müüja_1@müüja.tld>;
 Tootja #1 <mailto:tootja_1@tootja.tld>
CC: Ostja #2 <mailto:ostja_1.ostja@mail.com>;
 Müüja #2 <mailto:müüja_2@müüja.tld>;
 Müüja #3 <mailto:müüja_3@müüja.tld>;
 Ostja #3 <mailto:ostja_3.ostja@mail.com>;
 Ostja #4 <mailto:ostja_4.ostja@mail.com>;
 Ostja #5 <mailto:ostja_5.ostja@mail.com>

Kurjategija ei hoia mail.com aadressidele saadud kirju vaka all ja saadab laekunud kirjad ilusti Ostja aadressidele edasi, kuid ka seal on toimunud omad muudatused. Nendes kirjades, mis Ostjani jõuavad, on Ostja aadressid õiged, kuid muudetud on Müüja ja Tootja aadressid.

Kusjuures, löödud on üsna laia lauaga, sest Eesti inimeste domeeniks määrab Kurjategija @europe.com ja Hiina Tootja aadressis saab @asia.com.

From: Tootja #1 <mailto:tootja_1.tootja@asia.com>
Sent: ‎11-‎10-‎2016 12:38
To: Ostja #1 <mailto:ostja_1@ettevõte_1>;
 Müüja #1 <mailto:müüja_1.müüja@europe.com>
Cc: Ostja #2 <mailto:ostja_2@ostja.tld>;
 Müüja #2 <mailto:müüja_2.müüja@europe.com>;
 Müüja #3 <mailto:müüja_3.müüja@europe.com>;
 Ostja #3 <mailto:ostja_3@ostja.tld>;
 Ostja #5 <mailto:ostja_4@ostja.tld>;
 Ostja #5 <mailto:ostja_5@ostja.tld>

Vastuskirjades vahetatakse aadressid jälle teistpidi tagasi.
Sisuliselt võib öelda, et ründav pool hakkab proksiks Ostja, Müüja ja Tootja vahele teostades nö Man In the Middle rünnaku. Kirjad jõudsid kõik kohale, kuid seda läbi GMX serveri, kus ründaja omas kõiki vastavaid @mail.com, @europe.com ja @asia.com aadresse ja täielikku kontrolli kirjade sisu üle.

Ründaja eesmärk oli jõuda nii kaugele, et Eesti ettevõtja Müüja väljastaks Ostjale arve. Siis napsas ta selle vahelt, muutis ära ja edastas muudetud kujul Ostjale. Edasi polnudki muud teha, kui oodata rahalaeva laekumist.

Kes on tekkinud olukorras süüdi?

Kuna esimene võltskiri tuli Ostja poolelt, siis kahtlustaks, et Ostja postkast oli häkitud. Samas seda sajaprotsendilise kindlusega väita ei saa, sama hästi võis see ka ükskõik milline teine osapool olla, aadressaate käis tänu vestluse ‘Reply To All’ iseloomule kirjavahetusest läbi ju palju.

Samuti ei ole teada, et kuidas esimese võltskirja lõime istutamine täpselt käis. Kas see oli 100% võltsitud, st selle koostas ründaja ise või oli see kuidagi vahelt võetud, ehk selle kirjutas klient, kuid ründaja muutis seda enne kohale toimetamist endale sobivaks. On ka võimalik, et häkitud oli hoopis Hiina Tootja postkast ja IMAP’i kaudu vahetati seal Ostja poolt saadetud legitiimne kiri ära võltsingu vastu.

Igatahes on fakt, et ründajal oli ligipääs mõne osalise kirjakastile, sest ainult nii sai ta tekitada selle esimese võltsitud Reply kirja, mis sisaldas ka sama lõime eelnevate kirjade sisu. Konkreetset häkitud postkasti aga vähemalt meile kätte saadavate tõendite alusel siiski välja tuua ei saa.

Võib ju mõelda, et kui rumal saab keegi olla, kui maksab valele arvele nii palju raha. Kuid arvestada tuleb, et tegu oli rahvusvahelise äriga, kus eri pooled asusid maailma eri külgedel ning üksteise tavadest on raske aru saada. Lisaks, kuna kirjade ümbersuunamise ja arve väljastamise vahele jäi tervelt nädal aega Kurjategija vahendusel peetud meilivahetust, siis arve saamise hetkeks oli klient tarnijatega juba mitmeid kirju @mail.com ja @europe.com aadresside kaudu vahetanud, seega ei olnud need aadressid enam päris võõrad.

Mis järeldused sellest kõigest teha?

Konkreetsel juhul on kahju juba tehtud ning raske on uskuda, et jalutama läinud ülekannet enam tagasi pöörata saaks.

Selle konkreetse pettuse eest ei kaitse mitte ükski spämmi- ega viirusetõrje (ükski kiri ei olnud masspostitus ega sisaldanud viiruseid).

Kirjade võltsimise vastu võiks teoorias aidata SPF või DKIM reegel, aga kuna Kurjategija ei võltsinud aadresse, vaid vahetas need julmalt enda omade vastu, siis mingit hoiatust nende meetmete poolt ei oleks tekkinud.

E-posti klient võiks ju olla võimeline tuvastama, et adressaadid on lõime edenemise käigus vahetunud ja seda kuidagi ka hoiatuseks välja kuvada, kuid ka see kõlab lihtsamalt, kui tegelikult teostada saaks, nii et vähemalt praeguste võimaluste juures taolisi pettusi tehniliste vahendite abil ära hoida ei ole sisuliselt võimalik. Asja teeb raskemaks ka see, et paljud meilikliendid ei kuvagi üldse aadresse, vaid ainult saatjate nimesid.

Ainukene asi, mis oleks osapooli aidanud, oleks avaliku võtme krüptograafia kasutamine kirjade terviklikkuse ja autentsuse kontrollimiseks. Kui Eestis asuvate osapoolte vahel oleks selle teostamine ravuslikku PKI taristut kasutades lihtne, siis rahvusvaheliselt kahjuks veel nii ei ole.

Ainus mida kohe praegu teha saab, on olla ise tähelepanelikum. Ostja peab alati 100% veenduma, et saabunud arve peal on kõik korrektne ning viimase hetke muudatustesse arve numbris või muudes saaja atribuutides tuleb suhtuda äärmiselt skeptiliselt.

Müüja peab hoidma silmad lahti anomaaliate suhtes oma kirjavahetuses ning olulisi kirju saates mitte kasutada Reply või Reply To All nuppu, vaid alati kas aadressi käsitsi sisestades või kontakti valimisega aadressiraamatust.

Ühtlasi soovitame (eriti rahvusvalhelises!) äris mitte kasutada üldkasutatavaid e-posti identiteete nagu @hot.ee, @online.ee, @mail.com, @gmail.com ja suhtuda nende kirjavahetusse tekkimisse äärmise ettevaatlikkusega. Selliste aadresside kasutamisel on kirjavahetuse osapoole tuvastamine sisuliselt võimatu ja teise osapoole asemele hüppamine äärmiselt lihtne.

Usaldusväärses tippdomeenis ettevõtte enda nimele domeeni puhul on vähemalt mingitki abi registrite ja registripidajate tehtavast autententimistööst ning WHOIS protokollist.

Reply aadresside võltsimine on siiski ju niiöelda the ‘oldest trick in the book’, lihtsalt nüüd tehakse seda veelgi filigraansemalt kui varem.