2022 on Eesti interneti juubeliaasta

Zone kuulutab 2022. aasta Eesti interneti juubeliaastaks, alustame sellega seotud blogipostituste ja muude sündmuste sarja, mis vältab järgmised 12 kuud.

On teenuseid, mis defineerivad ajastut ja millel on ülekaalukas mõju kogu ühiskonna toimimisele. Kui Tondile sõitvas trammis paluda mõnel reisijal selliseid teenuseid loetleda, osataks tõenäoliselt nimetada elektrivarustust, kuid väga vähetõenäoliselt mainiks keegi Eesti tippdomeeni või sellega seotud DNS (Domain Name System) teenust.

Ometi võib sellest samast DNS teenusest teatud juhtudel sõltuda nii elektrivarustuse kui ka mitmete teiste elutähtsate teenuste kättesaadavus.

On sümboolne aeg ühiskonna teadlikkust täiendada, sest just värskelt kätte jõudnud 2022. aastal täitub 30 aastat nii sellest, et Eesti Vabariiki hakkas globaalses võrgustikus tähistama .EE tippdomeen kui ka üldse püsivate internetiühenduste loomisest.

Robo-Pirgit ootab .EE tippdomeeni sünnipäeva

Püsiühendused lõid 1992. aastal esimestena kaks akadeemilist organisatsiooni: Küberneetika Instituut ning Keemilise ja Bioloogilise Füüsika Instituut (KBFI). Just KBFI oli ühtlasi see, kelle esindajatena isa-poja tandemil Endel ja Jaak Lippmaa õnnestus Internet Assigned Numbers Authority (IANA) juhilt Jon Postelilt saada endale õigus hallata Eesti Vabariigi nimel .EE tippdomeeni.

Kolme aastakümne jooksul on tippdomeen ressursina kasvanud akadeemikute, inseneride ja entusiastide kitsast ringist välja ning muutunud Eesti infoühiskonna tunnuseks ning võimaldajaks.

Zone tähistab 30 aasta möödumist .EE tippdomeeni sünnist läbi terve käesoleva aasta. Ees ootavad blogipostid, mis loodetavasti huvi pakuvad ja harivad, kampaaniad ning muud põnevat. Jääge meiega.

 

Domeenikratt sirutab e-riigi kaudu käe ettevõtja taskusse

Viimasel kuul oleme näinud kordumas kahjulikku mustrit, mis põhjustab uute firmade asutajaile tarbetuid kulusid ja stressi. Nimelt lõpeb ilmselt paljudele neist ettevõtte registreerimine e-äriregistris oma võimaliku interneti-identiteedi kaotamisega. Kutsume üles ettevaatlikkusele ja anname nõu, kuidas lihtsa võttega oma firmale kohalduv oht neutraliseerida.

Olen varem kirjutanud ja rääkinud sellest, et minu hinnangul ei käitu riik ettevõtjate andmetega ümber käies alati parimal võimalikul viisil. Siis on juttu olnud sellest, et majandusliku efektiivsuse (loe: tagasihoidliku sissetuleku) huvides on riik valmis ettevõtete ja nende juhatuse liikmete kontaktandmeid hulgi müüma ja rahaks tehtud andmed võivad lõpuks jõuda ka rämpsposti saatjateni või kurjategijateni.

Ka tänane teema puudutab natukene riiklikke registreid.

Nimelt põhjustab paljudele alustavatele ettevõtjatele peavalu asjaolu, et nutikad sahkermannid on leidnud endale tee Eestis värskelt asutatud äriühingute andmete juurde ja asunud nende ärinimedega .EE domeeninimesid hõivama, et neid siis ettevõtjatele endile suure vaheltkasuga hiljem edasi müüa.

Suller saagimas ettevõtja tooli jalga
Ettevõtja ei saa kahjuks tunda end firmat registreerides kindlalt.

Loetud arvu nädalatega on tõenäoliselt sadade ahjusoojade firmade juhid oma ärinime domeenina registreerima asudes avastanud, et keegi on seda juba teinud ja hoolega valitud ärinime interneti-versiooni tuleb mõnelt rehepapilt tavapärasest kümneid kordi kõrgema hinnaga välja osta.

Me ei tea veel, kas domeenide registreerimiseks kasutatavad andmed jagatakse riigi poolt välja avaandmetena, kas need müüakse maha raha eest või on keegi nutikas kodanik leidnud nõrkuse, mille kaudu nendele andmetele ligipääs saadakse. Kuid praktikas on näha, et ettevõtte e-äriregistris registreerimisest, kuni selle ärinime hõivamiseni domeenina võib kuluda vaid mõni tund.

Seepärast on mul kõikidele Eesti ettevõtjatele erakordne, kuid konkreetne nõuanne, mis aitab vältida seda, et sahkerdaja sul naha üle kõrvade ja taguotsa lohku tõmbab:

REGISTREERI SOOVITUD ÄRI-IDEELE VÕI ÄRINIMELE VASTAV DOMEEN ENNE, KUI KANNAD OMA ETTEVÕTTE ANDMED ÄRIREGISTRISSE!

Nii maandad oma värskele firmale kohalduvaid riske, väldid asjatuid kulusid ja nõmedaid emotsioone.

Lisanduvaks ebamugavuseks on asjaolu, et domeen tuleb esialgu registreerida enda nimele, kuid hiljem saab selle ettevõttele üle anda. Kindlustunne on seda väikest vaeva väärt.

Sellist meedet tuleks meie soovitusel ettevõtjatel rakendada vähemalt niikaua, kuni pole päris täpselt selge, kust andmeid ammutatakse, millisel määral on võimalik sellist domeenidega kauplemist vajadusel Domeenivaidluste Komisjonis vaidlustada ning milline on selle protsessiga seotud aja- ja rahakulu.

Tehke nii ja te ei pea uuele aastale minema vastu tundega, et saite just haneks tõmmatud.

Kinnitamaks, et meie soovituse taga pole omakasupüüdlikku motiivi, maksab nüüdsest Zone eraisikult ettevõttele .EE domeeni üleandmise administratiivsed kulud ise kinni.

Juhendame, kuidas võtta kasutusele PHP versioon 8.1

Käesoleva blogipostitusega loodame juhendada oma kasutajaid PHP uue versiooni kasutuselevõtul. PHP 8.1 lõplik versioon on täna olemas enamikes meie serverites ning  nädala lõpuks jõuab see kõikidesse meie poolt hallatavatesse serveritesse. Selle beta ja release candidate versioone on meie kliendid saanud testida juba mõned kuud.

Igaks juhuks tasub täpsustamist ka, et uue versiooni väljatulekuga kadus tugi versionile PHP 7.3. Samuti asendus PHP 7.4 aktiivne tugi turvatoega. Kellel huvi, siis täpsemalt saab sellekohase infoga tutvuda PHP arendajate lehel.

Vaikeversiooniks uutel serveritel ning alamdomeenidel on endiselt veel 8.0. Kui enamlevinud rakendused saavad toe 8.1 versioonile, siis muutub see ka meie serverites vaikeversiooniks. Hetkel planeeritult toimub see poole aasta pärast ehk juunis 2022.

Kuidas ma saan uut PHP versiooni kasutama hakata?

Märgin ära, et versioon 8.1 on veel vägagi uus ning kõik teemade ning pistikprogrammide arendajad ei pruugi olla jõudnud selle versiooni toega uuendusi reliisida. Sellisel juhul on tungivalt soovitav katsetada sama teekond läbi teha 8.0 versiooniga.

PHP uut versiooni saab testida eraldiseisval alamdomeenil, millele saad määrata vastava versiooni. Kui sinu veeb on rätsepalahendus, siis tuleks kindlasti ühendust võtta arendajaga ning paluda tal rakendust uuendada. Oma rakenduse kaasaegsana hoidmine on ülimalt tähtis, sest see teeb veebilehe kiiremaks ning rakenduse turvalisemaks.

Zone+ kasutajatele oleme teinud versioonimuutmise võimalikult lihtsaks. Siiski tahab mainimist, et kui sa pole veebiarenduse (või -haldusega) varem kokku puutunud, siis võta kõrvale mõni teadjam abimees.

Versioonimuutmise protsess võiks välja näha järgmine:

  • Loo testimiseks alamdomeen ning määra selle PHP versiooniks 8.1. (alamdomeeni valmimine võtab aega kuni 10 minutit).
  • Kui sul on kasutusel vähemlevinud PHP mooduleid, siis veendu, et vajalikud moodulid oleksid uues versioonis olemas ning aktiveeritud. Kui rakendus on paigaldatud läbi Zone+ ning mooduleid pole spetsiaalselt, siis võib üsna kindel olla, et sellele punktile ei pea tähelepanu pöörama.
  • Kopeeri rakendus loodud alamdomeenile ning testi põhjalikult! Tihtilugu tuleb ette olukordi, kus veebileht ise töötab, aga just tellimust esitades või halduspaneelis tellimust hallates ilmnevad probleemsed kohad. Kui käia läbi kõik vajalikud protsessid, siis saab lehe katkimineku riski maandada minimaalseks.
  • Soovi korral luba ligipääs staging lehele ainult oma IP’lt! Loe lähemalt päringute lubamisest vaid ühelt konkreetselt IP-aadressilt. Kui sa ei tea, mis on sinu IP-aadress, siis vaata siit, mis on sinu IP-aadress. Kuna .htaccess kirjutatakse rakendust paigaldades üle, siis võib selle reegli lisada Apache direktiividesse.
  • NB! Pärast testimist kustuta loodud staging rakendus ära, sest paljud näotustamised toimuvad just rippuma jäänud testlehtede kaudu. Alamdomeeni võid jätta tulevikuks alles, et ka järgmise uue versiooniga seda testida.
  • Enne lõpliku otsust PHP versioon uuendada, tee rakendustest ühe nupuvajutusega varukoopia!
  • Kui leiad koodis mõne vea, mis üle jõu käib, siis võta ühendust oma veebiarendajaga.
  • Pärast uuendust võib mõni tehnilisema taibuga isik ka PHP logisid jälgida, mille järgi võib potentsiaalselt tuvastada veel mõningaid nõrkasid kohti.

Kui rakendus on testkeskkonnast PHP versiooniga 8.1 testitud ning vigu ei esinenud, siis toimub peasaidi versiooni upgrade nähtamatult ning veebileht jääb klientidele kättesaadavaks ka vahetusprotsessi hetkel.

Kui tahad kindel olla, et muudatus on jõustunud ning kasutusel on uus PHP versioon, siis saad näiteks Worpdressi puhul hetkel kasutusel olevat PHP versiooni näha wordpressi halduspaneelist:

-> Tools -> Site health – > Info -> Server -> PHP version

WordPressi saab lihtsalt nupuvajutusega sisse logida läbi Minu Zone.

Siinkohal leiab nii mõnigi lugeja end mõttelt, et „aga ma saaks eelnevat protsessi palju lihtsamalt ja valutumalt läbida järgmise PHP versiooniga?”

Jah, aga tähelepanu tasub pöörata järgmisele:

  • WordPressi puhul ära muuda kunagi teema ja plugina faile otse! Uuendamisel võidakse kirjutada failid üle ning muudatused lähevad kaotsi. Teemade muutmiseks tee näiteks child theme.
  • Hoia rakendus, selle teemad ja pluginad alati kõige viimasel versioonil!
  • Rakenduse (WordPressil ka teemade ja pluginate) automaatse uuendamise saad sisse lülitada Minu Zone halduse kaudu.
  • Tee koostööd ainult usaldusväärsete veebiarendajatega! Tihtilugu tähendab odav veebileht küll kiiret valmimist, kuid selle järelhooldus saab reeglina olema puudulik. Ohukohaks on kindlasti väide, et WordPressi versiooni ei tohi uuendada ning ebameeldivusena ilmnev asjaolu, et sul puudub võimalus osta tehtud veebitöödele järelhooldusteenust.

Mida teha siis, kui kasutusel on vanem PHP versioon, mis pole enam toetatud – näiteks 5.6 või 7.0?

Täpselt sama eelkirjeldatud protsessi saab kasutada ka vanemate versioonide puhul. Juhin siiski tähelepanu, et Zones pole juba aegunud PHP versioone võimalik kasutusele võtta. Kui pärast produktsioonirakenduse uuendamist selgub, et see ikkagi ei tööta, siis on võimalik mittetoetatud PHP versioonile tagasi lülituda 24 tunni jooksul.

Kui aga sul on soov kasutusele võtta senisest uuem PHP versioon, mis ise on juba pärandtarkvara nimekirjas, siis on sul võimalik meile kirjutada info@zone.ee ning erandkonnas saab ka nii PHP versiooni uuendada. See on aga kindlasti ajutine lahendus ning seetõttu on soovitav lehe kallale saata arendustiim, kes viib tarkvara juba ise kaasaegseks.

Pärandtarkvarast on täpsemalt kirjutanud Ardi juba kolm aastat tagasi. Kui versiooninumbrid välja arvata, siis muu info on seal endiselt aktuaalne: Oluline info PHP pärandvara kohta.

Mida teha siis, kui ma olen paigaldanud WordPressi iseseisvalt ning soovin kasutusel võtta Zone+’i?

Lihtsamad rakendused saab meie kliendtugi tasuta siduda rakenduse Zone+ halduriga, millega saad:

  • logida rakendusse ilma WordPressi salasõnata läbi Minu Zone halduse;
  • aktiveerida automaatsed versiooniuuendused (seehulgas teemad ja pistikprogrammid);
  • luua ning taastada rakenduse varukoopiaid;
  • kopeerida rakenduse teisele alamdomeenile või teise Zones paiknevasse serverisse;

Kui sul peaks mõni sellistest soovidest olema, siis kirjuta meile info@zone.ee. Enamikel kordadel Zone+ sidumine õnnestub. Kui aga mitte, siis annab klienditugi sulle sellest teada ning kõik see ei lähe sulle mitte midagi maksma.

Log4Shell turvanõrkus

Käesolevas postituses teeme kiire ülevaate infotehnoloogia maailma tormina tabanud turvanõrkusest Log4Shell ja sellest, kuivõrd see mõjutab (või ei mõjuta) Zone kliente.

Möödunud 24 tundi on olnud ülemaailmselt infotehnoloogia valdkonna jaoks pingelised. 

Maailma ühe eelistatuma tarkvaraarendusplatvormi Java populaarsest logide käitlemise raamistikust Log4j avastati turvanõrkus (https://nvd.nist.gov/vuln/detail/CVE-2021-44228), mida on väga lihtne ära kasutada. Nõrkuse edukal ekspluateerimisel on ründajal võimalik panna ohvri server, arvuti vms seade  oma pilli järgi tantsima. Seepärast on nõrkus saanud endale ka vastava nime: Log4Shell.

Nagu arvata võite, siis on süsteemiadministraatorid, tehnikud ja tarkvaraarendajad jt üle maailma  rakkes sellega, et maandada selle nõrkusega seotud riske.

Sellest, kuivõrd laialdane on selle intsidendi mõju, annab aimu järgmine nimekiri mõjutatud ettevõtetest ja platvormidest: https://github.com/YfryTchsGD/Log4jAttackSurface

Nõrkus saab ilmneda pea igas situatsioonis kus üritatakse logida midagi, mis saabub ründajalt. Olgu see siis kasutaja veebibrauseri User Agent või vea tekitanud sisend. Turvaauk tekkiski sellest, et logimise mugavdamiseks mõeldud funktsionaalsus oli kättesaadav igale logisõnele mis log4j-ni jõudis. Võimalus küsida lisainfot JNDIga suvalisest LDAP kataloogiserverist (sellest ka näidetes leiduv jdni:ldap:// osa) võimaldab serverisse tõmmata täiesti ründaja valitud Java objekte. See on juba püha graal igale ründajale.

Zone poolt hallatud veebimajutusteenuste osas oli Log4j nõrkuse ärakasutamise risk õnneks minimaalne, ka täiendavaid turvameetmeid rakendamata.

Meie pakutavas platvormis pole lihtsalt kuigi palju Java põhiseid komponente, mis seda teeki kasutaks. 

Välja toomist tasub neist vaid üks – Elasticsearch, aga Zone teenuste raames kliendile pakutav Elasticsearch instants pole interneti kaudu saabunud külastajatele või teistele klientidele ligipääsetav, mis maandab nii selle kui ka teiste sarnaste nõrkuste ärakasutamise riski.

Sellegipoolest rakendasime juba eile Elasticsearchi osas täiendavaid turvameetmeid, et takistada teadaolevaid nõrkuse ärakasutamise meetodeid.

Meie kliendid peaksid siiski pöörama tähelepanu sellele, et nende tarkvaraarendajad või veebimeistrid võivad olla ise paigaldanud meie serveritesse tarkvara, mis Log4j kasutab. Selline tarkvara vajab kindlasti uuendamist või nõrkusega seotud riskide maandamist.

Täiendus: Ilmselt on üks levinumatest mõjutatud rakendustest Minecraft, kui teil tiksub kuskil pilve nurgas mõni ununenud Minecrafti server, siis nüüd on õige aeg sellega tegeleda!

Soovitame teemast huvitatutele ja mõjutatutele jälgimiseks järgmist Redditi jutulõime: https://www.reddit.com/r/netsec/comments/rcwws9/rce_0day_exploit_found_in_log4j_a_popular_java/

Rõhutame ka, et üldlevinud rakendused nagu WordPress, Drupal, Joomla ja nende laiendused, ei kasuta reeglina Java põhiseid komponente, mis võiksid sõltuda Log4j teegist.

Miks on omanimelise domeeni registreerimine hea mõte?

Jätkates paari nädala eest üleskerkinud teemat (loe: https://blog.zone.ee/2021/10/21/voimalikest-pahatahtlikest-domeeniregistreerijatest/), tahan käesoleva blogipostitusega kõnetada ennekõike neid, kelle jaoks on tema nimi ja selle avalik kasutus oluline. Ole sa siis kunstnik või poliitik, muusik või näitleja, sportlane või ärihai ehk kokkuvõtvalt avaliku elu tegelane, kelle nimi aeg-ajalt tee uudis- ja sotsiaalmeediaveergudele leiab.

Sinu nimi on su parim bränd.

Üldiselt kipub enamus end mõistlikkuse kitsasse spektrisse sättivatest inimestest eeldama, et kõik inimesed meie ümber on ilusad ja head ning oma tegemistes tiivustatud vaid parimatest kavatsustest ja motiividest. Kas see eeldus tuleneb naiivsusest, soovist parandada maailma või millestki kolmandast, jääb siiski käitumisteadlaste ja psühholoogide otsustada. Igapäevaelu virrvarr paraku näitab seda, et see eeldus on ekslik ja et teps mitte kõik meie ümber sagivatest liigikaaslastest ei pea või ei taha kinni pidada ühiskonda toestavatest kirjutatud ja kirjutamata reeglitest.

Nende kirjutamata reeglite hallile alale heidavad oma tumeda varju näiteks suhtumine „mis pole keelatud, on lubatud” ning sellist suhtumist oma tegutsemise lipukirjaks sättivad kodanikud ka virtuaalses maailmas. Ehkki Internet on meie elusid mõjutanud ligi 40 aastat (maailma esimene domeen registreeriti 1985. aastal, aga TCP/IP protokoll läks laiemasse kasutusse aastal 1983) ning Zone omaltpoolt on siinsete inimeste teadlikkust domeenidest ja interveebi otsatutest kasutamisvõimalustest püüdnud kujundada viimased 22 aastat, pole virtuaalse kooseksisteerimise käitumisnormid kõigile veel sugugi mokkamööda. Nii põrkamegi (õnneks siiski harva) selliste tegelaste otsa, kes otsekui mässavate teismelistena püüavad Metsiku Lääne vaimus krabada kõike, mis ripakil ja millel potentsiaalne kuid moraalselt kaheldav väärtus.

Üks liik sedasorti ripakil „väärtustest” ongi mõne avaliku elu tegelase ees- ja perekonnanimest koosnev registreerimata domeeninimi, mis mõnele kullakaevurile võib tunduda sedavõrd atraktiivse saagina, et see esimesel võimalusel ära napsata. Ja panna see võõraste sulgedega ehitud hoiupõrsana püüdma träfikut või üritada nime tegelikule omanikule soolase tasu eest maha parseldada. Kusjuures mitte keegi sellisele tegevusele preventiivselt kätt ette panna ei saa, sest kui domeen on vaba, siis saab selle registreerida kes-ees-see-mees põhimõttel kes iganes meie seast…

Ehk siis: mitte keegi ei saa takistada, kui mõni käesoleva blogipostituse lugejast registreerib endale näiteks hetkel täiesti vaba domeeni jaanusputting.ee ja paneb selle domeeni näitama sisu, mis minuga mitte kuidagi seotud pole. Jah, .EE domeenireeglid võimaldavad mul alles sellise asjaolu ilmnemisel ehk hiljem alustada selle domeeni registreeringu vaidlustamist läbi Domeenivaidluste Komisjoni, mis suure tõenäosusega langetab mõne aja möödudes ka minule kasuliku otsuse. Kuid kuni selle otsuseni võib minunimelise domeeniga laiutav virtuaal-lindprii mulle piisaval hulgal peavalu valmistada, mille silumiseks võib kuluda kuid. Kui mitte aastaid. Igal juhul on protsessimine aeganõudev ja kulukas – seda enam, kui vaidlustama on vaja hakata nimesid .COM jms geneerilistes domeenides.

Kuigi otseseid tehnilisi hoobasid sellise tegevuse ennetamiseks pole, saame kirjeldatud olukordi vältida. Esimese asjana saab neid tülikaid olukordi ennetada igaüks, kes oma nime avalikku kasutamist oluliseks peab, registreerides omanimelise domeeni esimesel võimalusel ise ära. Zones saad sellise domeeni seejärel täiesti tasuta suunata (nn aliasena) oma olemasolevale veebilehele või selle alamlehele.

See käib eriti lihtsalt:

  • logi oma Zone kontole
  • vali teenuste ülevaatelehel vasakul asuvast menüüst Virtuaalserverid
  • uuel avanenud lehel klõpsa menüüs lahti valiku Veebiserver alammenüü
  • klõpsa lingile Aliase tellimine ning järgi kõiki seal kuvatavaid juhiseid

Teise ning sugugi mitte vähem olulise ennetuse saame läbi  ühiselt heakskiidetud hoiaku, et kellelegi teisele kuuluva ehk elava inimese nime ilma sellekohase loa või kokkuleppeta tegemine oma domeeniks on läbi ja lõhki mage ja taunitav.

Ainus koht, kus me võiksime rääkida potentsiaalsest erandist, on virtuaalne hauakivi meie seast lahkunud inimesele, kuid ka siis tasuks selline tegevus võimalusel olla heaks kiidetud kas lahkunu lähedaste või tema ajaloolise jalajälje seaduslike esindajate  poolt. Hea paralleelina tooksin autoriõiguse, mille kohaselt kehtib autoriõigus ka 70 aastat pärast autori surma.

Millised erandeid pakuksid välja Sina, hea lugeja?