Meie veebimajutuse tarkvaraplatvorm uueneb

Täna (2019.03.01) alustasime veebimajutusteenuse klientide lisamist Zone uuele serveriplatvormile, mille aluseks on spetsiaalselt meie klientide vajadusi arvesse võttes loodud uus Linux operatsioonisüsteemi distributsioon.

Uue platvormi vundamendiks on Container Linuxi arendatav tehnoloogia, mis omakorda jagab oma “geneetilist” pagasit Gentoo Linuxi ja Google arendatava Chrome OS operatsioonisüsteemiga. Kuigi oma eluteed alustas see projekt meil sisemiselt koodnime “Ashrak” all, jääb see produktsioonis kandma nime ZoneOS.

Olemasolevaid veebisaite tänane sündmus ei mõjuta, sellest on kohe mõjutatud vaid uued lisatavad veebisaidid.

Oleme pingutanud selle nimel, et üleminek uuele platvormile toimuks võimalikult sujuvalt, mistõttu oleme üritanud vältida suurte muudatuste tegemist. Mõned väiksemad muutused sai siiski tehtud, mida meie platvormi kasutavatel arendajatel ja integraatoritel on hea teada:

  • uuenesid paljud teegid ja utiliidid, mille värskendamine kasutajaid oluliselt ei mõjuta;
  • kasutusele tuli uus Node.js versioon, milleks on 10.15.1
  • krüpteeritud HTTPS protokolli teenindamiseks kunagi kasutatud eraldi DocumentRoot kaust “domeen.tld/secure/htdocs” kadus ära – maailm on edasi liikunud ja krüpteeritud ühendused on de facto uus normaalsus – edaspidi teenindatakse ka HTTPS päringuid vaikimisi “domeen.tld/htdocs” kaustast
  • PHP.INI failid asuvad edaspidi “domeen.tld/phpini/” all asuvates alamkaustades “http”, “https” ja “global” – see viimane mõjutab mõlemat protokolli
  • domeen.tld/cgi-bin/” kataloog ja tugi CGI skriptide käivitamisele kaovad ära – klientide poolne nõudlus ja vajadus selle võimekuse järel puudub ning selle säilitamine (eriti ilma aktiivse kasutuseta) on seotud turvariskiga
  • PHP versioone alla 5.6 ei ole uuel platvormil võimalik ka erandina pakkuda, esiteks kujutavad need endast turvariski ja lisaks pärsivad teiste teekide ja rakenduste uuendamist
  • serveripoolne veebilehe külastusstatistika asub edaspidi “domeen.tld/stats/webalizer/“ all olevates kaustades, Webalizeri külastusstatistika täpse seadistamise võimalus kadus ära – seda ei kasutanud sisuliselt mitte keegi
  • Virtuaalserveri haldusliidesest kaob uut platvormi kasutavatel klientidel,  “Veebiserver -> Monitooring” alamleht ära – see naaseb mõne aja pärast palju kvaliteetsemate andmetega
  • Virtuaalserveri haldusliidesest kaob “Statistika ja andmemaht -> Andmesidemaht” leht ära, kuna meil pole juba ammu üheski Virtuaalserveri teenuspaketis andmemahule piiranguid.

Muidu on nagu ikka – uus on kiirem, turvalisem ja muidu parem. Esimeste vanemat platvormi kasutavate serverite üleviimisega uuele operatsioonisüsteemile tahame alustada juba aprillis, kuid kõikide klientide üleviimine saab kestma ilmselt aasta lõpuni.

Päris katsejänestena ei pea uuele platvormile lisatavad kliendid end tundma, kuna uuel operatsioonisüsteemil põhinevad juba nii meie uus e-posti platvorm kui ka viimase poole aasta jooksul lisatud andmebaasiserverid ja muud infrastruktuuriga seotud serverid. Sellegipoolest on tagasiside ja tähelepanekud väga oodatud.

Kuigi šampanja lahtikorkimiseks on veel veidi vara, tahan tänada meie IT ja tarkvaraarenduse valdkondade meeskondi, kelle jaoks on meie uue platvormi näol tegemist viimase 3-4 aasta töö kulminatsiooniga.

Oluline info PHP pärandvara kohta

Aasta 2019 tõi paljude jaoks endaga kaasa ebameeldiva üllatuse, 1. jaanuari seisuga muutusid pärandvaraks (“legacy”) kaks seni väga populaarset PHP versiooni 5.6 ja 7.0, mis enam arendajalt turvauuendusi ei saa.

Pärandvara kasutamine toob endaga kaasa riske, kuna see ei käi kaasas heade tavade ja praktikatega ning võib läbi paljastatud, kuid parandamata turvanõrkuste omandada ründajate kätes vaenuliku funktsiooni, pakkudes tagauksi seda kasutavatesse süsteemidesse.

Pärandvaraks muutunud tarkvaral on loomulikult muidki puuduseid kaasaegse tarkvaraga võrreldes, mida ilmestab juuresolev illustratsioon.

PHP versioone toetatakse arendaja poolt aktiivselt kaks aastat, misjärel pakutakse aasta jagu neile veel turvauuendusi.

Käesoleva aasta seisuga on arendajate poolt turvauuendustega toetatud kolm PHP versiooni:

  • 7.1 (kuni 1.12.2019)
  • 7.2 (kuni 30.11.2020)
  • 7.3 (kuni 6.12.2021).

Vanemate PHP versioonide kasutajad peaksid need vahetama mõne ülal nimetatud versiooni vastu.

Lugejale võib siinkohal tunduda, et ta ei kuule vajadusest kasutusel olevat PHP versiooni vahetada esimest korda, mis on ilmselt tõsi. Kuid sarnaselt paljudele teistele riskide maandamise vajadusest jutlustavatele epistlitele, mis räägivad näiteks vajadusest hoida piirkiirust, paigaldada suitsuandur või vahetada õigeaegselt välja talverehvid, kipuvad paljud seda sõnumit ignoreerima.

Seda ei maksa siiski teha, sest uuenenud pole mitte ainult PHP versioonid, vaid ka küberruum, kus neid rakendatakse. Hiiglaslike hüpetega arenevad nii tehnoloogilised platvormid kui ka ühiskond. Mis toob mind kahe olulise tõdemuseni:

  • esiteks, päris vanu PHP versioone ei ole Zonel peagi võimalik enam töökindlalt pakkuda, isegi kui kasutaja on valmis selleks võtma teatud turvariske nagu seni, põhjuseks on asjaolu, et teegid mida vanemad PHP versioonid vajavad kaovad järjest ajalukku;
  • teiseks, küberruumi reguleerivad üha rangemad ja spetsiifilisemad õigusaktid, mis otsesõnu nõuavad infosüsteemide omanikelt teadaolevate infoturberiskide maandamist – Euroopa Liidu tasandil on kehtestatud isikuandmete kaitse üldmäärus, kohalikul tasandil on vastu võetud küberturvalisuse seadus, peagi hakkab ilmselt kehtima e-Privaatsuse direktiiv, kuigi konkreetseid vahendeid nagu PHP nendes loomulikult ei mainita, rikub teadaolevate nõrkustega tarkvara kasutamine seaduste mõtet ja nende nõudmistele mittevastamine võib tõsisema intsidendi korral endaga kaasa tuua reaalsed, märkimisväärsed sanktsioonid.

Seega, hoiatan ette. Zone kaotab oma järgmise põlvkonna serveriplatvormist juba väga aegunud (ilmselt <= 5.5) PHP versioonide toe ära. Üleminek uuele platvormile hakkab meil juba aprillis, mil hakkame ise järgemööda võtma ühendust nende klientidega, keda see puudutab.

Lisaks võib juhtuda, et mõne tehnoloogiliselt toetatud, kuid tootja poolt juba hüljatud PHP versioonid (ilmselt <=7.0) peame määratlema pärandtarkvarana, mille teenindamisele tuleb kehtestada täiendav teenustasu, et senisest jõulisemalt suunata kliente kasutama turvalisemat, kiiremat ja efektiivsemat tarkvara; ning kompenseerida Zonele pärandtarkvara toetamisega seotud reaalsed kulud ja riskid.

Tööd saab olema paljudel. Täna kasutab veel sadu Zone kliente peagi 20 aastaseks saavat PHP 4. põhiversiooni. Turvaparandusi ei ole selle alamversioonidele välja lastud juba üle 10 aasta (sic!).

Hullem lugu on PHP 5. põhiversiooniga, mis lasti välja 2004. aastal. Selle populaarsed alamversioonid 5.2, 5.4 ja 5.6 muutusid pärandvaraks vastavalt 2011, 2015 ja 2018. Nende versioonide kasutajaid on kahjuks jätkuvalt tuhandeid.

Ülalnimetatud olukord ei ole kuidagi tekkinud Zone osavõtmatusest, oleme järjepidevalt teinud kõik uuemate PHP versioonide populariseerimiseks:

  • uued versioonid on muutunud klientidele kättesaadavaks kohe, kui nad on arendaja poolt välja lastud;
  • oleme tutvustanud oma blogis laiemale üldusele uute PHP versioonide peamiseid eeliseid;
  • avaldame serveriteenuste haldusliideses järjepidevalt meeldetuletusi klientidele, kes kasutavad PHP vanemaid versioone;
  • keelasime uutel klientidel vanemate PHP versioonide kasutuselevõtu;
  • keelasime PHP versiooni vahetajatel tagasipöördumise vanematele versioonidele;
  • oleme teostanud oma serverites löök-inventuure, mille käigus oleme PHP sätted kaasaegsemate vastu ära vahetanud nendel alam- ja põhidomeenidel, kus PHP-d parasjagu reaalselt ei kasutata;
  • jne.

Kõigel sellel on olnud mõju, kuid kahjuks mitte piisavalt suur ja see mis meid siia toonud, kahjuks edasi meid enam ei vii.

Ära seda soovitust jälgi: täna on rahvusvaheline paroolivahetamispäev

Tõepoolest, väidetavasti on 1. veebruar “change your password day” ning seega äärmiselt sobilik hetk rääkida … tõsiselt halbadest infoturbe-nõuannetest.

Me oleme paroolidega seotust kirjutanud korduvalt: nt Hasso pikem lugu Veel kord paroolidest, siis täpselt seal välja toodud halva parooli-nõuande kasutamise tulemusest Nõrgast paroolist häkitud WordPressini 42 katsega ja loomulikult rahvusvahelise mõõtmega “Paha Panda” varastab postkaste.

Häid nõuandeid jagab aga NIST, mille “Special Publication 800-63B” võtab arvesse seniste parooli-reeglite tekitatud ebaturvalised käitumismustrid. Võid selle spikriks kõrvale võtta ja proovida vastata küsimusele:

Millised järgnevatest EI OLE NIST’i nõuded turvalisele paroolile?

(õiged vastused postituse lõpus)

  1. peab olema vähemalt 10 märki pikk
  2. peab olema vähemalt 8 märki pikk
  3. peab olema vähemalt 6 märki pikk, võib koosneda ainult numbritest
  4. peab sisaldama suur- ja väiketähte, numbrit, märki
  5. peab vähemalt X kuu järel vahetama
  6. ei tohi olla sama, mis viimased X parooli
  7. parooli või kasutajanime sisestamise lahtris ei tohi toimida copy ja paste
  8. ei tohi sisaldada nime, järjestikuseid märke, levinud salasõnu

Kasutasin seda nimekirja just turva-teemalisel esinemisel ja tuleb tunnistada, et paljud kuulajad noogutasid täpselt valede kohtade peal. Põhjuseks see, et IT-osakonnad jõustavad endiselt iganenud reegleid ning neid tirazeeritakse endiselt nii paberil kui digitaalses meedias.

Milline on siis hea ja milline halb reegel?

Hea parooli-nõue on selline, mis ei koorma liigselt kasutajat ning ei sunni teda ebaturvalisele optimeerimisele – inimene pole rumal, küll aga evolutsiooniliselt harjunud leidma kõige tõhustamat teed seatud eesmärgi saavutamiseni. Samas peaks see reegel aitama infosüsteemide arendajatel ja haldajatel meid kaitsta.

Näiteks – selleks, et parooli ei saaks N korda proovides ära arvata, peaks rakendus suutma sellist rünnet tuvastada ja takistada (konto ajutiselt lukustama), ent samas vältida teenustõkestusrünnet läbi kontode lukku ajamise.

Levinud tavad nagu sage vahetamine ja keerukusnõuded annavad aga soovitule vastupidise tulemuse: kasutaja lisab sõnale mõne numbri ja märgi ning siis suurendab sammhaaval numbrit või kasutab selleks aasta-arvu.

Kaks reeglit, mille puhul tasub viidata sellel blogipostile:

  • märgi-põhised keerukusnõuded
  • parooli kohustuslik vahetamine iga X ajavahemiku järel (aga: NIST nõuab vahetamist juhul kui  on kahtlus, et see on lekkinud)

3+2 lihtsat reeglit, mida järgida

  • salasõna asemel räägime sala-fraasist – veidi pikem isekomponeeritud liitsõna või sõnamäng/kalamburism on väga hea (jalgpallisupikulp, lumehangumine, vt insipratsiooni twitter.com/keitivilms)
  • ära kasuta sala-fraasis enda või kasutuskoha nime, levinud (sala)sõnu (Passw0rd!, kalamaja) ja järjestikuseid märgijadasid (q1w2e3r4)
  • oluliste teenuste jaoks (töökoha kasutajakonto, e-post, sotsmeedia) kasuta unikaalset sala-fraasi

Sellega on 98% tööd tehtud, kaks veidi suuremat pühendumist nõudvat soovitust on aga veel:

  • lülita olulistes teenustes (e-post, sotsmeedia) sisse kaheastmeline autentimine (2fa ehk two-factor authentication – nt SMSiga saadetav turvakood)
  • kasuta parooliseifi (LastPass, 1Password, KeepAss) unikaalsete paroolide loomiseks ja haldamiseks, pea meeles ainult üks tugev ehk seifi sala-fraas

Viimase punkti juurde vihjeks, et KeePass on täiesti tasuta ja LastPassis saab erakonto teha tasuta (ja kui su tööandja peaks LastPassi ametlikult kasutusele võtma saad era- ja töökontole ligi ühe sisselogimisega – seejuures mõistagi nii, et tööandja EI SAA sinna ligi 🙂

Ja lõpuks…

See paroolivahetuspäev on Gizmodo klikimeelitustrikk aastast 2012, seeria viimane lugu kannab muideks pealkirja Don’t Change Your Password ning jõuab umbes samade soovitusteni ehk “ära vali lolli parooli”.

Kui su IT-osakond Gizmodot adekvaatseks allikaks ei pea, siis olgu öeldud, et maikuus on tulemas World Password Day ning TheRegister on selle kokku võtnud pealkirjaga It’s World (Terrible) Password (Advice) Day!


Õige vastus – NISTi nõuded EI OLE 1, 4, 5, 6, ja 7.

Nõrgast paroolist häkitud WordPressini 42 katsega

Sattusin puhastama ühte WordPressi, mille puhul oli ilmseks sissetungi-viisiks halduri-õigustes kasutaja parooli ära-arvamine.

Vaatamata sellele, et iga turva-nõuanne hakkab pihta tugeva parooliga ja enamus kasutajaid sedaküsimise peale ka esimese meetmena nimetavad… on nõrga parooli kasutamine endiselt reaalne probleem.

Esimene samm: kasutajanimede kogumine

Seekordne näide põhineb ühe reaalse ründe logifailidel, alustuseks otsitakse WordPressi kasutajanimesid lapates läbi autorite arhiivi:

163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=1 HTTP/1.1" 301
163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=2 HTTP/1.1" 301
163.172.xxx.xxx [10/Dec/2018:20:39:22] "GET /?author=3 HTTP/1.1" 404

Kood 301 on edasisuunamine: kui proovida minna lehele https://blog.zone.ee/?author=16, siis on selleks https://blog.zone.ee/author/petskratt/ … ja minu kasutajanimi petskratt on selles kenasti näha.

Teine samm: parooli mõistatamine:

Kui kasutajanimi teada, võib hakata proovima sisselogimist:

163.172.xxx.xxx [10/Dec/2018:20:39:25 +0200] "POST /wp-login.php HTTP/1.1" 200 

Selliseid ridu on logis 41 ning kõigi nende puhul on WordPress väljastanud teate, et parool ja/või kasutajanimi ei klapi.

Ma olen selliseid katseid kogunud ja tüüpiliselt on proovitavad mustrid kasutaja petskratt ja veebilehe zone puhul sellised:

petskratt2017
petskratt2018
P@ssw0rd
petskratt1234
petskratt12345
petskratt@123456
12345678
petskratt@zone
zone2018

Siia sobib kenasti Hasso postitus Veel kord paroolidest ehk kuidas aegunud parooli-nõuded on õpetanud kasutajad justnimelt selliseid lihtsalt ära-arvatavaid paroole kasutama.

Ja niimoodi nad siis huupi lappavad, kuni mõne veebi puhul mõne kasutajaga näkkab. Sedapuhku on juba  42. rida on veidi erinev:

163.172.xxx.xxx [10/Dec/2018:20:39:54 +0200] "POST /wp-login.php HTTP/1.1" 302

302 on jällegi edasi-suunamine ning selle sihiks on /wp-admin … Rohkem IP-aadress 163.172.xxx.xxx logis ei esine, sest töö sai tehtud. 32 sekundiga.

Mõni päev hiljem:

103.76.xxx.xxx [12/Dec/2018:06:06:07 +0200] "POST /wp-login.php HTTP/1.1" 302

Kui 163.172.xxx.xxx oli pärit Prantsusmaa internetiteenusepakkuja võrgust, siis 103.76.xxx.xxx külastab meid Indiast, Tamil Nadu osariigist. Kontrollib logini toimimist ja rohkem teda näha pole.

Kolmas samm: parooli ärakasutamine

Ilmselt läheb toimiv kasutajanimi+parool müüki ning uus omanik asub selle abil saiti lammutama:

46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "POST /wp-login.php HTTP/1.1" 302
46.148.xxx.xxx [17/Dec/2018:22:29:54 +0200] "GET /wp-admin/ HTTP/1.1" 200
46.148.xxx.xxx [17/Dec/2018:22:39:29 +0200] "POST /wp-admin/update.php?action=upload-theme
46.148.xxx.xxx [17/Dec/2018:22:39:32 +0200] "GET /wp-content/themes/[...]/db.php?u
46.148.xxx.xxx [17/Dec/2018:23:00:32 +0200] "POST /wp-content/themes/[...]/db.php?u

Ehk siis login, oma teema üleslaadimine, selles oleva db.php tagaukse toimivuse kontroll ja ärakasutamine. Kui huvi, siis see näeb välja selline:

IP 46.148.xxx.xxx viitab Kiievile, aga kuulub sealsele veebimajutusteenusele ja kuigi tegemist võib olla ka VPNi või veebi-proksi kasutajaga viitavad mõned logiread skriptitud tegevusele, näiteks selle üleslaadimis-käsu puhul on logis referrer-väljal http://$st2/wp-admin/theme-install.php?browse=featured.

Mida sellise jama vältimiseks teha?

  • ära kunagi kasuta lihtsat parooli – ei enda kontol ega kolleegile / kliendile konto tegemisel (isegi, kui on plaanis see hiljem ära muuta – tõenäoliselt ei muuda seda keegi)
  • vaata üle veebirakenduse admin’i / halduri õigustes kasutajate nimekiri ja kustuta lahkunud töötajad / endised arendajad jms kasutajad, keda enam vaja ei ole (või pane nende rollik subscriber / lugeja)

Lisalugu: aga kelle parool lekkis?

Kuna selles veebis oli mitu haldurit, siis pakkus mulle suurt huvi konkreetse kasutaja tuvastamine. See ei pruugi alati võimalik olla, aga tasub vaatada wp_user_meta tabelis olevaid session_token kirjeid. Sedapuhku oli kasutaja 2 kohta kirjas järgnev:

a:2:{s:64:"bff45f4a[...]";a:4:{s:10:"expiration";i:1547071064;s:2:"ip";s:11:"77.72.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1545861464;}s:64:"a3c7456[...]";a:4:{s:10:"expiration";i:1548253873;s:2:"ip";s:11:"91.90.xxx.xxx";s:2:"ua";s:124:"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3198.0 Safari/537.36 OPR/49.0.2711.0";s:5:"login";i:1547044273;}}

Ülalpool näha oleva 46.148.xxx.xxx loginit ei ole enam näha (sest ta ei ole välja loginud? liiga ammu?), küll aga on näha 2 teist IPd, esimese asukohaks annab MaxMind Stoke-on-Trent’i ja teise omaks Odessa. Huvilised võivad tuvastada ka sisselogimise aja… ning logist on kenasti näha nende askeldamised 🙂

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.