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.

Veel kord paroolidest

Paroolidega on meil kõigil keerulised suhted. Läbi infosüsteemide on see olnud pidev võitlus kahe poole vahel – süsteemide administraatorid, kes üritavad kasutajatele turvalisemate paroolide kasutamist peale suruda; ning kasutajad, kes üritavad nendes reeglite rägastikus endale meeldejäävaid paroole tekitada.

Pole ime, et uudised sellest, kuidas paroolid tuleks juba ammu ajalukku saata ja kohe-kohe on lõpuks saabumas tehnoloogia, mis seda just teebki, leiavad laia kõlapinda. Praktikas pole asi muidugi nii lihtne.

Kasutajate poolelt on probleem eelkõige selles, et parool on oma ideelt väga lihtne asi – enamvähem kõik saavad selle toimimisest aru ja kõik oskavad seda kasutada. Teine probleem on tehniline, kuid olulisemgi – iga autentimismeetod sisaldab alati ka parooli komponenti ning parool on ainuke, mida saab kasutada iseseisvalt. Seose mitmeastmelise autentimisega tuleb kindlasti tuttav ette, et autentimisvahendid saab jagada kolmeks:

  • See, mida sa tead (parool)

  • See, mis sul on (telefon, krüptovõti, id-kaart)

  • See, mis sa oled (sõrmejälg, nägu, iiris jt biomeetrilised meetodid)

Kõige parem kaitse saavutatakse loomulikult siis, kui kasutusel on kõik kolm – juba ühe puudumisel süsteemi sisse logida ei saa. Selle, mis sul on, saab sult lihtsalt ära varastada või ka ainult korraks “laenata” ning selleks, et autentimisvahend kohe sellisena kasutatav poleks, kasutatakse pea alati ka parooli komponenti (nt Eesti ID-kaardil PIN-koodid). Biomeetriaga on lood veel keerulisemad – lisaks eelnevale (ka biomeetrilised andmed on varastatavad ja/või kopeeritavad) on neil ka vahetamise probleem. Kui telefoni ja krüptovõtme saame varguse korral välja vahetada, siis kuidas vahetada sõrmejälgi? Parool on seega asi, mida me niikuinii kasutame peame ning paljude süsteemide turvatase võimaldab seda endiselt kasutada ka iseseisvalt.

Liiga lihtne: selles paroolis puuduvad ilmselgelt suur- ja väiketäht ning number, lisaks on pikkust vaid 7 märki ja tegemist kunstiteosega (see parool võib esineda popkultuuri-sõnabaasis). Foto: Matthew Brodeur

Turvalisim viis on lasta paroolid genereerida arvutil ning hoida neid krüpteerituna paroolihalduris ning sellest olen ma juba mõni aeg tagasi siinsamas blogis kirjutanud. Kuigi turvalised, on paroolihaldurid endiselt suhteliselt vähe levinud ja inimesed eelistavad oma paari parooli paremal juhul meeles pidada, halvemal juhul lihtsalt paberile üles kirjutada. Aga vaatame siis asja teisest küljest – mida saavad teha infosüsteemide omanikud, et kasutajad käiksid paroolidega turvalisemalt ümber? Kas me oleme seni teinud oma parima, et kasutajad saaksid turvalise(ma)lt käituda?

2016 aastal avaldas NIST (National Institute of Standards and Technology) dokumendi koodiga 800-63B, mis sisaldab uusi USA riigiasutustele (teoreetiliselt) kohustuslikke reegleid infosüsteemide autentimise haldamiseks ning mis tekitas turvamaailmas kerge maavärina. Kuigi uudisekünnis sai vähemalt hetkeks ületatud, polnud selle sisus tegelikult midagi uut – see muutis lihtsalt väga ametlikuks selle, millest mõned turvaeksperdid juba aastaid olid rääkinud. Lühidalt võib dokumendi sisu võtta kokku nelja punkti.

  • Paroolide regulaarse vahetamise nõue on minevik. Mitmed tehtud uuringud on üheselt näidanud, et see mitte ei suurenda vaid hoopis vähendab paroolide turvalisust. Paroole peab vahetama ainult siis, kui on kahtlus, et parool on lekkinud.

Kasutajad leiavad parooli vahetamise nõudele rahuldamiseks kõige efektiivsema lahenduse.
  • Samamoodi on minevik paroolide keerukuse nõuded (peab sisaldama suur- ja väiketähti, numbreid ja erimärke). Täpselt samuti nagu paroolide regulaarne vahetamine, on seegi nõue tegelikult turvalisust hoopis vähendanud.

  • Paroolide kunstliku keerukuse asemel väärtustatakse paroolide pikkust – minimaalne lubatud pikkus peab olema vähemalt 8 sümbolit, maksimaalne lubatud pikkus vähemalt 64 sümbolit. Ning selleks, et kasutaja saaks enda jaoks mõistlikke, kuid ründaja jaoks keerulisi paroole kasutada, ei tohi olla olla ebamõistlikke piiranguid sümbolitele paroolis. Jah, ka tühikud ja isegi Unicode võiks olla OK.

  • Kohustus veenduda, et kasutajad ei kasutaks levinud ja ebaturvalisi paroole, lasub infosüsteemide omanikel. Eelkõige peab infosüsteem veenduma, et parooliks poleks üksikud sõnad sõnastikust (minimaalse lisaga, nt üks number), neid poleks lekkinud paroolide baasides ning parool ei sisaldaks kasutajanime ega korduvaid mustreid.

Populaarsed salasõnad, kultuurilised viited ja mugavad klahvijärjestused on esimesed, mida sissetungijad kasutada proovivad.

Kui nüüd natuke järele mõelda, ei ole selles midagi tervele mõistusele vastu käivat, kuid formaalselt on tegemist päris korraliku pöördega.

Esiteks ei toetuta paroolireeglite loomisel ainult loogikale ja kõhutundele vaid need toetuvad reaalsetele uuringutulemustele. Me võime küll arvata, et mingi reegel muudab me süsteemid turvalisemaks, aga kuidas on lood tegelikult?

Teiseks liigutab dokument olulise osa paroolidega seotud vastutusest kasutajalt infosüsteemide omanikele. Kuigi reaalsus on alati kompromiss turvalisuse ja kasutusmugavuse vahel, ei tähenda see seda, et me ei peaks kasutama võimalusi neid teineteisele lähemale toomiseks. Parool Karuvanaema tagumik on pärast 3. siilile istumist väga valus, on nii mugavam kasutajal meelde jätta kui ka turvalisem kui gT7ylak.0p – win-win situatsioon.

Samuti on väga oluline nihe panna seal, kus see tehniliselt võimalik on, paroolide turvalisuse eest vastutama infosüsteemide omanikud. Võrreldes seni domineerinud “kõik oleks turvaline, kui kasutajad käituks nii” suhtumisega on see suur muutus. Kui mingi probleemi lahendamiseks on tehnilised meetmed olemas, ei ole nende mitte rakendamiseks ning vastutuse kasutajatele lükkamiseks mitte mingit vabandust.

Kui nüüd kellelgi tekib (õigustatud) küsimus, et mis siis vahepeal muutunud on, et reeglid sellise pöörde tegid, on õige vastus – mitte midagi. Mees, tänu kellele me paroolide regulaarse vahetamise ja keerukusnõuete reegli all kannatanud oleme, tunnistas eelmisel aastal intervjuus, et see oli viga isegi 15 aastat tagasi.

Ka Zone vaatas eelmisel aastal kõige selle valguses paroolidele kehtestatud reeglid üle. Paroolide regulaarset vahetamist pole me küll kunagi nõudnud, kuid suur- ja väiketähtede jms reeglid on meie nõuetest kadunud ning pikad paroolid igasuguste sümbolitega lubatud. Seda kõikvõimalike sümbolite lubatavust ei maksa muidugi uisapäisa kasutama tormata. Näiteks klienditarkvara ei pruugi olla nii liberaalne kui Zone ning võib tema jaoks kahtlaseid sümboleid paroolis lihtsalt ignoreerida.

Samuti ei luba me parooli vahetades uues paroolis kasutada levinud paroolimustreid ja kasutajanime. Neist viimane halb harjumus tekitab reaalseid probleeme ka Zone kasutajatele ning Ardi on kirjutanud sellest ka meie blogis.

Vaatamata sellele, et info on avalik olnud juba mõnda aega, leiab ka Eestis suurel hulgal infosüsteeme, kus paroolid peavad endiselt olema nt 8-16 sümboliga, neil on keerulised keerukusnõueded ning neid tuleb iga kuu aja tagant vahetada. Sarnaseid nõudeid leiab endiselt turvapoliitikastest ja koolitusmaterjalidest ning sellest räägivad turvaeksperdid ajakirjanduses.

Kui ka sinu töökoha või kooli infosüsteemis endiselt sellised nõuded kehtivad, anna selle haldajale märku – viita sellele artiklile või palu guugeldada “NIST passwords 2016”. Aitame selle turvateatri lõpetada ning meie infosüsteeme ka tegelikult turvalisemaks muuta.

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 võimalik 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.

 

WP GDPR Compliance turvaprobleem

WordPress ja pluginad vajavad igapäevast ja soovitavalt automaatset uuendamist, sest nagu näitab järjekordne juhtum, suurendab uuenduse avaldamine probleemi ärakasutamist.

Sedapuhku on süüdlaseks WP GDPR Compliance plugin, mille koodis ei kontrollita kasutajaõiguseid ning nii saab kestahes WordPressi admin-ajax.php kaudu save_setting funktsiooni poole pöördudes muuta suvalisi seadeid (lisaks saab do_action() abil ligi WP muudele funktsionaalsustele).

Haavatavad on WP GDPR Compliance versioonid kuni 1.4.2 (kaasa arvatud), paigatud versioon on 1.4.3

Tüüpilised ründeviisid näivad hetkel olema sellised:

  • lubatakse kasutajate registreerimine users_can_register ja pannakse uue kasutaja rolliks (default_role) administrator … misjärel saab lisada meelepärase tagaukse muutes mõnda teema või pluginafaili – või enda tööriistakomplekti üles laadida
  • muudetakse ära site_url seaded (veebi baas-url), misjärel hakkab veeb laadima kõiki skripte ründaja poolt antud aadressilt… ning need skriptid suunavad kasutaja edasi kuhu-vaja (veebi aadress ja lehesisu udustatud):


Näites kasutatud veebilehe koodist on näha, kuidas skriptid ja CSS tulevad wtools[.]io pealt:

Varem on kasutusel olnud ka pastebin.com ja erealitatea[.]net

Kuidas puhastada?

Kui veebi home ja siteurl on muudetud, siis on esimeseks probleemiks haldusliidesele ligi pääsemine. Seega on vaja saada ligipääs, uuendada pluginad ja rookida välja kõik probleemne.

  • taasta phpMyAdmin’i kasutades andmebaasis siteurl ja home väärtused – selleks on sinu veebi URL (teataval puhul võivad need ka erinevad olla):

  • logi WP haldusliidesesse sisse ja uuenda WP GDPR Compliance plugin
  • kontrolli üle kasutajate registreerimine – Seaded > Üldine valikust: kasutajate registreerimine võiks mitte olla lubatud (kui see ei ole veebi jaoks oluline funktsionaalsus) ja roll võiks olla Lugeja ehk Subscriber:

  • kontrolli üle kasutajate nimekiri, eemalda tundmatud tegelased
  • ja seejärel kontrolli, ega külalised veel midagi maha ole poetanud – selleks on hea abivahend minu ctimer.php skript, mille kasutamise näite leiab blogipostitusest CSI küber – kas keegi on mu serveris faile muutnud?

Sellest probleemist kirjutavad ka:

pluginvulnerabilities.com – Unlike Wordfence and Other Security Providers We Warned About WP GDPR Compliance Before Websites Started to Get Hacked (08.11.2018)

Wordfence – Privilege Escalation Flaw In WP GDPR Compliance Plugin Exploited In The Wild (08.11.2018)

Sucuri – Erealitatea[.]net Hack Corrupts Websites with WP GDPR Compliance Plugin Vulnerability (09.11.2018) ja Hackers Change WordPress Siteurl to Pastebin (13.11.2018)

Kuidas e-smaspäevaks e-pood kiireks saada?

Kaks korda aastas toimuv e-smaspäeva poodlemis-kampaania on Zone jaoks erilise tähendusega: kuna me oleme aastaid olnud eelistatuim valik e-poe veebimajutuse valikul, jooksevad umbes pooled e-poed meie serverite peal.

Zone 74
Elkdata 16
Cloudflare, Inc. 6
Telia Eesti AS 5
Microsoft Corporation (Azure) 4
Hetzner Online GmbH 3
GleSYS Internet Services AB 3
Radicenter 3
OU cloud.ee 3
Wavecom 3
CITIC Telecom CPC Netherlands B.V. 3
kõik ülejäänud 29

Targa majutuse-valiku kõrval mängib olulist rolli ka veebi-poe kood: kasutusel olev Magento, WordPress vms rakendus võiks suuta lehekülje serveerida vähem kui sekundiga, selle kuvamiseks võiks olla vaja maksimaalselt 100-150 faili ning esilehe suurus peaks jääma alla 1-2 megabaidi.

Testisin 12. novembri kampaanias osalevaid poode ning panin tulemuste põhjal kokku lühikese video peamiste soovitustega:

Lisaks video ülevaatele leiad siitsamast blogist ühe varasema postituse, mis annab veel mitu head nippi, kuidas e-pood paremini tööle panna, kui klikid järgmist linki: https://blog.zone.ee/2018/05/13/seitse-nippi-kiire-e-poeni/