Mõtteid tehnoloogiast: turvariskidest ja nende maandamisest 

Kuidas sarnanevad Türgi valitsuse sammud noorte protestide mahasurumisel ja süsteemihalduri ponnistused häkkerite vastu võitlemisel?

Kuidas hallata olulisemaid riske turvalisuse saavutamiseks? Kas üritada teha midagi terviklikku ja suurt või üritada sihtida midagi pisikest ja väikest? Sellest johtuvalt klõbistan oma tänases mõtiskluses nii Türgi telekomi tupikutest kui igapäevastest väikestest häkkidest, mille abil turvariske maandada.

Tegemist on 14. nädala mõtisklusega õppeaines ITSPEA, mille koondnimetuseks on “Andmeturveː tehnoloogia, koolitus ja reeglid“.

Õppejõud on küsinud:

Vali üks suurematest IT-turvariskidest ja analüüsi seda. Mida tuleks “Mitnicki valemi” kolme komponendi (tehnoloogia, koolitus, reeglid) selle maandamiseks ette võtta?

– Kaido Kikkas

Kas probleem on süsteemis, süsteemi kasutajas või suures pildis?

Kevin Mitnick on üks kuulsamaid häkkereid, keda iseloomustab hea inimeste tundmine. Kui enamik häkkereid otsib süsteemidest tehnilisi turvanõrkusi, siis Mitnick leidis, et palju lihtsam on leida inimene, kellega suheldes saab süsteemi võtmed kätte. Ta väljendas, et suurim turvarisk pole enamasti süsteemis sees, vaid ta istub süsteemi terminali ees.

Mitnicku elulookirjeldusest leiab huvitavaid lugusid, kuidas tal õnnestus aastaid tasuta bussiga sõita või helistada, sest ta suutis leida inimesi, kes talle ligipääsu lõid. Lõpuks veetis ta oma tegude eest mitmeid aastaid tagaotsitava või kinnipeetavana kuni lõpuks jõudis järeldusele, et seaduslikult oma turbe-alaseid oskusi müüa on kasulikum kui tagauste kaudu tulu hankides.

Sellest tulenevalt sõnastaski ta kolm kõige olulisemat elementi, mille korrutisest koosneb süsteemi turvalisus. Idee siis ennekõike selles, et juhul kui mistahes komponent neist on puudu, siis on kogu süsteemi turvalisus olematu:

Turvalisus = Tehnoloogia * Turvareeglid * Kasutajate teadlikkus

Sellest tulenevalt kirjeldan nüüd paari näite varal, et kuidas võib üritada süsteemi turvalisust suurendada keskendudes neist ainult mingile konkreetsele aspektile.

Türgi telekommunikatsiooni tupikteed?

Esimene näide keskendub ainult tehnoloogilisele poolele konkreetse riigi tasandil. Ta näitab, kuidas väga laia pintslitõmbega on võimalik süsteeme hallata, nii et võrkude haldamise kaudu suunata ka ühiskonna toimimist endale sobivas suunas.

2013. oli kena kevad. Soe ja mõnus, mil Istanbulis hakkasid toimuma Gezi pargi kaitseks protestid, mis loetud nädalatega rullusid üle riigi. Asi algas kehvast kommunikatsioonist – linnavõim tahtis noorte poolt armastatud pargi täis ehitada. Et Türgi demokraatlik valitsus hakkas eelnevalt järk-järgult keskaegsemaid toone võtma, siis viskas lõpuks noortel üle. Tegemist oli viimase piisaga nende karikasse, sest rahulolematust oli nii elu-olu kui ka väärtuste pinnalt.

Eelnenud kolme aasta jooksul oli käima läinud Araabia Kevad. 2011. aastal algas Occupy Wall Street ja Hispaanias Indignados. Kõik keskendusid peaasjalikult tõdemusele, et noorema põlvkonna majanduslikul seisundil polnud lootustki paraneda.

Noored alustaid istumisprotestidest. Kõik suuremad pargid olid täis noori, kes plakatitega nõudsid, et “Käed eemale parkidest”. Kuna valitsusel polnud piisavalt kannatust, siis otsustati saata tänavatele märulipolitsei, pisargaas ja veekahurid.

Veetsin selle aasta Türgi pealinnas Ankaras. Minu igapäevane ajaviide enne ja peale tööpäeva oli mõista millise teekonna peaksin valima, sest valesse tänavasse sattudes võis protestijate ja sõjaväelaste risttulle sattuda. Selleks tuli vaadata hashtagi põhjal sotsiaalmeedia kanalitest, et millistel tänavatel parajasti protestid toimusid.

Kuna protestijate kõige olulisemaks ja kiireimaks omavaheliseks suhtluskanaliks kujunesidki Twitter ja Facebook, siis hakkas valitsus neid regulaarselt kinni keerama. Samuti tegema regionaalseid piiranguid võrguliikluse jälgimiseks ja piiramiseks. Piiranguid seati sisse vastavalt konkreetse olukorra kujunemisele. Kinni keerati üksjagu uudiskanaleid. Filtreeriti märksõnu. Kõik see oli pisut ettearvamatu – ühel hetkel oli kättesaamatu praktiliselt kogu veeb või siis valitud hulk sotsiaalmeedia kanaleid, mis järgmisel hetkel võis taas lahti olla.

Üsna kummaline kui osa internetist on kinni keeratud. Sisestad otsingusse märksõna ja kolmandik tulemusi avavad reaalse vastuse asemel hoopis riikliku telekommunikatsiooniministeeriumi helesinise taustaga lehekülje, kus on kirjas, et nimetatud veebilehekülg on mustas nimekirjas ja kättesaamatu. Kogu internetis navigeerimise kogemus meenutas pisut nagu labürindis kobamist, sest alati eksisteeris tõenäosus, et järgmise lehe puhul avaneb taas selline tupik nagu alltoodud ekraanipildil:

Valitsuse esindajad ise väitsid ametlikes kanalites, et nad tegid seda kõike kodanike kaitsmiseks arvutiviiruste eest. Samuti halvale teele ja kuritegevusele kaldumise eest. Noh – keegi mind selle aasta jooksul seal veebi kaudu ei rünnanud, mistõttu äkki oligi neil omamoodi isegi õigus. 🙂

Kui pisut mõelda sellise algatuse tehniliste tagamaade peale, siis ilmselgelt oli tegemist robustse ja võimsa tööriistaga, millega infot juhtida. Kui riiki saabuvad ühendused läbivad riigi kontrolli, siis on võimalik tsentraalselt võimalik neid valikuliselt sisse ja välja lülitada.

Kasutajate seisukohalt on tegemist aga loomulikult väga destruktiivse lähenemisega. Kuigi sellest ei räägitud kusagil ametlikes kanalites, tuli tavainimestega ikkagi jutuks, et sulgemiste tõttu oli igapäevaelu päris korralikult häiritud kui näiteks mingites haiglates ei õnnestunud kriitilises seisundis patsientide päästmiseks võtta midagi ette, sest internetiühendus oli maas.

Samas – ei elanikkonna arvamuse kujundamist ega reeglite kehtestamist ei võtnud Türgis keegi kuigi tõsiselt. Üheks hetkeks protestid vaibusid ja valitsev režiim pidi leppima, et vähemalt Gezi park jäi püsti.

Aukude ükshaaval kinnitoppimise strateegia

Teise näitena tooksin 15-aasta tagused esimesed katsetused võrguturvalisuse suurendamiseks enda isiklikul omaaegsel veebilehel. Nimetatud juhtum keskendub osaliselt “tehnoloogia”-lülile turvalisusest, aga kõige otsesemalt “koolituse” komponendile, kuna kirjeldan isiklikke võitlusi võrguturbe teadmiste omandamisel kui oma teadmisi kippus vajaka jääma. Niisiis – kirjutan samast serverist, kus praeguseidki artikleid on võimalik lugeda.

Registreerisin 21 aastat tagasi domeeni rillo.ee ja panin sinna püsti staatilised lehed – CV, mõned artiklid juhtimise ja EL projektide kohta. Tundus olevat vahva idee, kuidas oma mõtteid laiema üldsusega jagada. Pool aastat hiljem lisasin Iconboardi-põhise foorumi, mis toimis PERLi scriptide, PHP ja MySQL abil suhteliselt automaatselt. Seejärel tuli omandada mingid esimesed PHP ja jQuery põhialused, et panna püsti sisuhaldussüsteem, milleks tollal oli Postnuke‘i-nimeline CMS.

Viimased komponendid lisandusid sinna 2002. aastal kui hakkasin õpetama TTÜs tudengeid. Veebileht tundus olevat sobiv vahend oma koolitusmaterjalide jagamiseks ja arutelufoorumi tekitamiseks, kus omavahel juhtimisalaseid teemasid läbi mõelda ja mõtestada.

Tegemist oli tõelise põlve-otsas nikerdamisega. Nimelt tuli süsteemi serverisse paigaldada suhteliselt kahvatute juhiste põhjal. Kuna süsteem polnud lõpuni läbi mõeldud ja mul endal puudus IT-valdkonna baasteadmised, siis häkkerite rünnakud rikkusid mingi osa tehtust pea igal nädalal ära.

Niisiis – sarnast kogemust nagu ülaltoodud Türgi valitsusel – olen saanud katsetada omaenda koduse serveri püsti pidamisel. Samal ajal oli ka väljakutse, et kuidas kogu seda kupatust niimoodi püsti hoida, et 200-300 tudengit sinna ligi pääseksid ja võiksid süsteemi kasutada ilma mingite probleemideta.

Kuidas .HTACCESS üritas päeva päästa?

Kuna PHPga midagi turvalisemat ise ei osanud veel ehitada, siis oli mu peamiseks tööriistaks samamoodi nagu Türgi valitsusel – lõputute kivide müüride ladumine .htaccess-faili nimelisse müüri. Nimelt on “.htaccess” veebiserveri juurkataloogis asetsev fail, mille abil on võimalik määratleda, et kuidas veebiserver mingitele päringutele reageerib.

Esimese sammuna hakkasin jälgima häkkerite rünnakute logisid. Kui tuvastasin mingi IP aadressi, kus järjekordne pahalane on midagi teinud või siis üritanud teha, siis lisasin nimetatud IP aadressi keelatute sekka. Lisasin üha uusi IP aadressi alltoodud loetellu kuni see ulatus juba üle mitme lehekülje:

<Files .htaccess>
order allow,deny
deny from all
</Files>
<files *>
deny from xx.xx.xx.xx

See võitlus ei tahtnud mitte kuidagi lõppeda, sest niipea kui üks auk sai kinni topitud, tuli järgmisest august järgmine tegelane sisse. Lõpuks otsustasin, et äkki oleks otstarbekam, et mingid kagu-aasia riikide IP aadresside piirkonnad tervikuna:

RewriteEngine on
RewriteCond %{REMOTE_ADDR} ^66\.249\.74\.
RewriteRule ^ - [F]

Ka sellest ei piisanud päris hästi, sest järgmise sammuna selgus, et minu foorumisse hakkasid suvalised tegelased postitama mingit suvalist spämmi. Niisiis avastasin, et äkki õnnestuks blokeerida mingeid märksõnu või viiteid mingitest rämpspostiga seotud allikatest ja suunata nad lihtsalt veateadet kuvavale leheküljele. Ka see loetelu oli alguses suhteliselt lühike, aga lõpuks kasvas mitmekümne lehekülje pikkuseks.

Miinusena hakkas ühel hetkel selguma, et juhul kui ma mingid märksõnad ära keelan, siis võib tulemus olla üpris destruktiivne. Näiteks mingil hetkel olid mingid hasartmängurid kõvasti spammimas, et kandsin musta nimekirja sõnad “bingo” ja “blackjack”. Seepeale ei saanud ka tudengid enam kellelegi tunnustuseks hõigata “bingo!”. Niisiis – selliste mustade nimekirjade koostamine viis põhimõtteliselt sarnaste tulemusteni nagu Türgi valitsuse sammud – nende kasutamisega hakkasid pihta saama ka süsteemi õiged ja soovitud kasutajad.

RewriteEngine On 
RewriteCond %{HTTP_USER_AGENT} ^Bingo [OR] 
RewriteCond %{HTTP_USER_AGENT} ^Cash [OR] 
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR] 
RewriteCond %{HTTP_REFERER} (bingo) [NC,OR]
RewriteCond %{HTTP_REFERER} (blackjack) [NC,OR]
RewriteCond %{HTTP_REFERER} (cash) [NC,OR]
RewriteRule ^(.*)$ http://%1 [R=301,L]

Järgmise sammuna jõudsin järeldusele, et arvatust oluliselt suurem probleem on lihtsalt see, et minu veebis kasutatav PHP-failide struktuur on väljapoole liiga lihtsalt mõistatatav, mistõttu haavatavused tekivad puhtalt sellepärast, et mõned tegelased suudavad tekitada nutikaid süstimisrünnakuid. Seepeale otsustasin olulisema osa veebilinke taas samas .htaccess failis ära peita:

RewriteRule ^Forum-([0-9]+)\.html$ /index.php?name=PNphpBB2&file=viewforum&f=$1 [L,NC,NS]
RewriteRule ^Download-([0-9]+)\.html$ /index.php?module=Downloads&func=sublevel&cid=$1 [L,NC,NS]
RewriteRule ^File-([0-9]+)\.html$ /index.php?module=Downloads&func=prep_hand_out&lid=$1 [L,NC,NS]

Nimetatud piirangust oli lõpuks vast kõige rohkem kasu, sest enamik “brute force” rünnakutest lõppes seepeale ära ning suurem rahu saabus peale seda kui Postnuke’i arendajad lõpuks ise oma rakendusega turvalisema versiooni peale üle läksid. Niisiis – paigaldasin endale samuti lõpuks Zikula-nimelise CMS süsteemi, mis tundus oma piirangute osas turvalisuse mõttes mõnevõrra robustsem kui varasem versioon.

Kuidas täna – mil viisil WordPressi turvalisust kasvatada?

Nonii. Lõpetuseks mõtleks siis selle peale samuti, et kas lisaks tehnoloogilisele lahendusele ja iseenda koolitamisele olen kehtestanud ka mingeid reegleid, et süsteemi turvalisust tagada. Üldiselt võib vist paralleeli tuua viimaste aastatega.

2015. aasta suvest siirdusin enamike lahendustega stabiilsema ja lihtsama WordPressi peale üle, mille puhul turvalisuse saavutamiseks on võimalusi palju rohkem. Kuigi populaarseima sisuhaldussüsteemina kipub globaalselt olema WP häkkerite poolt enim rünnatud keskkonnaks, siis tegelikult on mõnede lihtsamate lahenduste abil võimalik hoida see süsteem pahalaste eest kaitstuna. Niisiis – lõpuks ometi saan rääkida ka mingitest lihtsatest reeglitest, mille olen loonud, et süsteemi hallata.

Lisaks ülaltoodud .htaccess-faili jätkuvale aktiivsele kasutamisele olen astunud järgnevaid samme:

1. SSL server: Olen kõik veebilehed tänaseks paigaldanud SSL sertifikaadiga veebiserveritesse, mida laiem üldsus tunneb https://-ga algava lingiga ja keelanud www-eesliite kasutamise, et veebilehekülgede ümbersuunamisi minimaalseks muuta.
2. PHP versioon: kõikides serverites olen paigaldanud viimase PHP stabiilse versiooni 8.* ja üritanud seda kaasajastada igal võimalusel kui uus süsteem on väljas ja olulisemad WordPressi teegid (plugin) seda toetavad.
3. CHMOD õigused: kõik avalikud kataloogid ja failid olen kaitsnud vastavalt 755 ja 644, piiratud juurdepääsuga failid (nt. wp-config.php) olen nimetanud ümber ja pannud turvalisuse tasemeks 400.
4. Otsingumootori piiramiseks olen piiritlenud robots.txt failis selgelt ära, et millistest kataloogidest luban koopiaid ja millistest mitte.