Koduleht on paljudele ettevõtetele peamiseks müügikanaliks. Kindlasti on tegemist olulise infoallikaga su olemasolevatele ja potensiaalsetele klientidele – ei jäta head muljet, kui see peaks maas olema. Veel hullem on, kui koduleht su enda teadmata pahavara jagab ning külastaja arvutit nakatab.

Kodulehe rünnaku tagajärjed võivad olla pikaajalised ja veel tõsisemad, kui maasoleku ajal saamata jäänud kasum. Mitte ainult külastajad ei jäta meelde, et just sinu ettevõtte koduleht nad viirusega nakatas – seda teeb ka Google. Nii võib juhtuda, et kaotad oma aastatega saavutatud otsingupositsiooni. Halvemal juhul võib Google su kodulehe üldse otsingutulemustest eemaldada. Muuhulgas kuvab Google Chrome sellisel juhul kõigile su lehe külastajatele punast hoiatusteadet.

Vaatame järgnevalt miks rünnatakse kodulehti, kuidas enda oma kaitsta ning mida teha, kui oled juba rünnaku ohvriks langenud.

Miks ja kuidas rünnatakse kodulehti?

Rünnakud kodulehtede vastu võib jaotada peamiselt kahte kategooriasse: Näostamised ja pahavaraga nakatamine.

Näostamise ehk Defacement rünnaku korral vahetatakse ära kodulehe sisu ja välimus. Enamasti asendatakse kogu kodulehe sisu mõne poliitilise sõnumi või lihtsalt rünnakuga hakkama saanud grupeeringu/häkkeri nimega. Näostamise rünnakud viiakse enamjaolt läbi käsitsi. Näostamise eesmärk pole üldjuhul kasumit teenida. Häkker teeb seda lihtsalt oma maine pärast. Eetilisemad näostajad ei muuda isegi kodulehe enda sisu, vaid lisavad sinna faili, mis tõestab, et nad on seal olnud.

Näostamise rünnakute puhul kasutatakse enamasti ära kas haavatavusi su kodulehte jooksutavas tarkvaras (näiteks WordPress, Joomla või Drupal). Teine võimalus on, et rünnatakse veebimajutuse teenuse pakkujat. Sellisel juhul kasutab häkker haavatavust näiteks veebiserveri või andmebaasi tarkvaras, mille üle sul virtuaalserveri kliendina suure tõenäosusega kontrolli pole. Teenusepakkuja vastu suunatud rünnaku korral näostatakse enamasti kõik seal hoiustatud lehed.

Näostamine võib olla ebameeldiv, kuid pole enamasti väga ohtlik. Suure tõenäosusega ei kustutata ära isegi faile serveris ega andmebaasi. Isegi, kui seda tehakse, saab su teenusepakkuja või sa ise kõik varukoopiatest taastada. Igaks juhuks peaksid perioodiliselt tegema varukoopiaid oma kodulehe failidest ja andmebaasist. Seda isegi, kui su teenusepakkuja seda samuti teeb.

Pahavaraga nakatamise korral pannakse su koduleht külastajate arvuteid viirusega nakatama. Tihti ei muuda kodulehe välimuses ega sisus midagi – lihtsalt lähtekoodi lisatakse read, mis installeerivad külastaja arvutisse pahavara. Pahavaraga nakatamise rünnakud on näostamisest ohtlikumad, kuna on tehtud kasu saamise eesmärgil ning on seeläbi ka professionaalsemad.

Varasemalt nakatati kodulehti ka lihtsalt eesmärgiga sisestada veebilehele varjatud linke ning sellega Google tulemustes kõrgemale tõusta. Kuna Google oskab sellist otsingutulemuste mõjutamist juba pea alati tuvastada ei ole see enam niivõrd levinud. Küll võidakse seda teha nn “negatiivse otsingumootoritele optimeerimise” eesmärgil.

Enamasti ei vii rünnakut läbi mitte inimene käsitsi vaid robot, mis otsib internetist haavatavaid kodulehti. Nii on võimalik haavatavuse tuvastamisel nakatada suures koguses kodulehti ilma, et selle taga olev rühmitus peaks kõigist neist isegi teadlik olema. Pahavara levitav veebileht satub väga kiirelt Google huviorbiiti ning hakkab külastajatele vastavat hoiatusteadet kuvama. Mida teha, kui see juba su kodulehega juhtunud on, kirjeldan allpool.

Veendu, et kasutad uusimat tarkvara versiooni

Valdav enamik rünnakutest kodulehtedele pannakse toime kasutades teadaolevaid turvaauke su kodulehte sisuhalduse tarkvaras. Kui kasutad populaarset sisuhaldustarkvara võid eeldada, et kriitilistele turvaaukudele väljastatakse parandus enamasti paari päeva jooksul. Avatud lähtekoodiga lahenduse, nagu seda on WordPress, puhul võib see juhtuda veel kiiremini. Seetõttu tuleks kõik uuendused alati installeerida esimesel võimalusel.

Kõige olulisem asi, mida saad teha oma kodulehe turvamiseks, on sisuhaldussüsteemi alati esimesel võimalusel uuendada. Enamasti langevad häkkerite ohvriks just vananenud tarkvaral jooksvad veebilehed. Kui turvaauk avalikuks tuleb, ei lähe pahalastel enamasti kaua aega, et kirjutada robot haavatvate lehtede otsimiseks. Edasi toimub kõik juba automaatselt:

1. Robot leiab internetist su veebilehe
2. Robot tuvastab, et see kasutab haavatavat tarkvara
3. Robot ründab automaatselt kodulehte kasutades ära juba leitud turvaauku
4. Robot muudab kodulehe sisu või faile, enamasti lisades sinna pahavara levitavad koodiread.

Seetõttu ei tohiks kunagi turvapaiga installeerimisega venitada. Kusjuures mida populaarsem on su veebileht, seda suurem on võimalus, et robotid selle haavatavuse(d) avastavad.

Kodulehe tarkvara uuendamine võib tunduda keerulisena, kuid enamasti seda tegelikult pole. Kui su koduleht kasutab WordPressi on uuenduste paigaldamine väga lihtne. Sisuhaldussüsteem annab sulle sisse logides kohe teada, et uus versioon on saadaval.

Seejärel saad tarkvarauuenduse paigaldada haldusliidese seest – see ei vaja mingeid tehnilisi teadmisi. Sama võimekus on ka teistel tuntumatel sisuhaldustarkvaradel nagu Joomla ning e-poe platvormidel nagu Magento, Prestashop. Kui su koduleht jookseb mõnel teisel tarkvaral võib uuendamine olla keerulisem, näiteks Drupali puhul on protsess mõneti keerulisem. Sellisel juhul tasub ühendust võtta ettevõttega, kes kodulehe valmistas või selle tehnilise haldusega tegeleb.

Eemalda pluginas, mida sa (enam) ei kasuta

Paljud sisuhaldussüsteemid võimaldavad vaikimisi funktsionaalsust laiendada. Seda teevad “pluginad” – kolmandate osapoolte poolt loodud laiendused, mis annavad sisuhaldustarkvarale juurde uusi funktsioone või täiendavad olemasolevaid.

On väga tõenäoline, et sina või kodulehe tarnija on proovinud erinevaid laiendusi või neid aja jooksul välja vahetanud. Sellisel juhul saab plugina deaktiveerida, pärast mida pole ta enam osa su kodulehe tervikust. Plugina lihtsalt deaktiveerimine ei kustuta selle faile serverist. Nii võib juhtuda, et mõnest deaktiveeritud pluginast leitakse kriitiline haavatavus. On võimalik, et plugina haavatavat faili saab rünnata ka siis, kui see pole enam installeeritud. Seetõttu tuleks kõik pluginad, mida sa enam ei kasuta, mitte lihtsalt deaktiveerida vaid kustutada. Ainult nii pole see enam potensiaalne turvarisk.

Täpselt nagu sisuhaldustarkvara, tuleks esimesel võimalusel uuendada ka kõiki pluginaid. Võimalus, et haavatavus avastatakse pluginast on vähemalt sama suur, kui baastarkvara puhul, ehk isegi suurem. Enamasti on pluginate täpselt sama lihtne, kui baastarkvara puhul, mistõttu pole see otseselt probleem.

Pluginad võivad oma funktsioonidega olla väga atraktiivsed. Sellest hoolimata ei tasu unustada, et pluginaid ei kontrolli otseselt su sisuhaldustarkvara tarnija. Seetõttu on võimalik, et mõni neist sisaldab turvaauke, vahel isegi tahtlikult. Seetõttu peaksid kasutama ainult neid laiendusi, mida sul tõesti vaja läheb.

Ära anna ligipääsu inimestele, kes seda (enam) ei vaja

Kodulehe sisuhaldusele, failidele ja andmebaasile tohivad ligi saada ainult need inimesed, kellel seda tõesti vaja on.

Igal inimesel, kes kasutab kodulehe sisuhaldust, peaks olema oma kasutaja. Nii saad vajadusel neid individuaalselt deaktiveerida. Seda peaksid tegema isegi siis, kui usaldad kõiki, kellel sisule ligipääs on. Tihti ei pruugi tekitatud kahju olla tahtlik. Näiteks võib pahatahtlik isik nende konto üle võtta õngitsemise või ebaturvalise WiFi võrgu liikluse jälgimise tõttu (Sellest, mis on õngitsemine, olen pikemalt kirjutanud siin ning avalike WiFi võrkude turvalisest kasutamisest siin).

Sama kehtib ka ligipääsu osas su kodulehe failidele ning andmebaasile. Kui oled sisse ostnud kodulehe arenduse, on teenusepakkujal vaja ligipääsu failidele ning andmebaasile. Küll aga pole vaja seda säilitada, kui kõik tehtud on. Seetõttu peaksid peale kodulehe valmimist muutma ära oma FTP ning halduspaneeli paroolid. Seda peaks tegema ka siis, kui usaldada oma veebilehe loojat. Nimelt on mitmeid viiruseid, mis otsivad nakatunud arvutist FTP kasutajanimesid ning paroole ja nakatavad leitud kodulehed. Suure tõenäosusega on teenusepakkuja ligipääsu andmed oma arvutisse salvestanud, et vajadusel kiirelt muudatusi teha. Tegemist pole väga tõenäolise ründevektoriga, kuid olen ise selliste juhustega kokku puutunud.

Ära hoia vana versiooni kodulehest serveris

Tellides uue kodulehe jäetakse tihti vana versioon kuhugi serverisse, näiteks /old aadressile. Põhjus on enamasti, et “igaks juhuks saaks vana taastada” või “pääseks ligi vanal kodulehel olnud andmetele”.

Esimene neist kahest on tegelikult absurdne – piisab lihtsalt failide ja andmebaasi koopiast. Leht ei pea jääma internetist ligipääsetavaks. Teise puhul peaksid pigem laskma arendajal oma kodulehe kuhugi mitte-avalikult üles panna, et saaksid kõik sisu üle tõsta. Kui see tõstetakse sinna ajutiselt, näiteks kuuks ajaks peale uue kodulehe valmimist, pole tegemist tegelikult turvariskiga. Küll muutub selleks sinna pikemaks ajaks jäetud kodulehe vana versioon.

Turvariskiks muutub ta, kuna suure tõenäolisega ei uuendata vana kodulehe tarkvara. Eelnevalt mainisin, et kõige olulisem osa oma kodulehe turvalisuse tagamises on selle tarkvara uuendamine. Uuendama peab mitte ainult kodulehe sisuhaldussüsteemi, vaid kogu tarkvara serveris. Kui oled paigaldanud näiteks külastusstatistikat genereeriva lahenduse peab ka see olema alati uuendatud uusimale versioonile. Sama kehtib ka veebipõhiste intranettide, kliendihaldustarkvarade, WIKIde jms kohta. Kui mõnda neist ühel hetkel enam ei kasutata on lihtne see täiesti ära unustada. See juhtub peaaegu alati veebist ligipääsetavate kodulehe vanade versioonidega. Keegi ei installeeri sinna enam uuendusi ega turvapaikasid. Aja pikku unustatakse ilmselt ära, et vana versioon kodulehest üldse olemas on – olen seda korduvalt oma klientidega kohanud. Paraku muutub üles jäetud ja unustatud vananenud versioon kodulehest järjest haavatavamaks, kuna pidevalt leitakse uusi turvaauke. Kriitiline turvaauk vana kodulehe tarkvaras võib häkkeril lubada üle võtta nii su uue kodulehe kui kõik teised samas serveris asuvad rakendused.

Kasuta https’i. Alati!

Https, ehk ssl sertifikaadiga turvatud internetiliiklust pole kolmandal osapoolel võimalik pealt kuulata. Tihti soovitatakse ssl sertifikaati kasutada ainult juhul, kui su koduleht töötleb konfidentsiaalseid isikuandmeid ning haldab makseid. Tegelikult on sellisel juhul https ühenduse kasutamine kohustuslik* ning muul juhul tungivalt soovitatav.

Kui su veebileht ei kasuta https ühendust on su administreerimisliidese kasutajanime ja parooli võimalik väga lihtsate vahenditega pealt kuulata. Seetõttu peaksid httpsi kasutama ka juhul, kui su koduleht ei töötle konfidentsiaalseid isikuandmeid. Aastaid tagasi olid ssl sertifikaadid väga kallid, mistõttu ei olnud see enamike ettevõtete ja eraisikust koduleheomanike jaoks mõistlik investeering. Tänapäeval saab tavakasutuseks sobivaid sertifikaate tasuta või võileiva-hinna eest. Millised on https ühenduse kasutamise võimalused ja hinnad pead uurima oma veebimajutusteenuse pakkuja käest.

* Euroopa Liidu direktiivid kohustavad kõiki teenusepakkujaid kasutama “vajalike meetmeid” isikuandmete turvalisuse tagamiseks. Liikluse krüpteerimist võib antud kontekstis lugeda vajalikuks meetmeks. Päeva lõpuks oled sina vastutav oma süsteemi poolt töödeldud andmete turvalisuse eest ja turvalisust on võimatu tagada kasutades krüpteerimata liiklust.

Vali turvalised paroolid

Isegi kõige uuemal tarkvaral jooksev koduleht võib rünnaku ohvriks langeda, kui häkker peaks teada saama või ära arvama sisuhalduse või veebimajutuse konto parooli. Oleme pikemalt kirjutanud turvalise parooli valimisest siin.

Kodulehe sisuhalduse, veebimajutuse haldusliidese ja FTP konto parooli valimisel on oluline meeles pidada, et seda poleks lihtne ära arvata. Parool ei tohiks kunagi sisaldada ettevõtte nime, ükskõik mis vormis. Kui su ettevõtte nimi on Suurfirma AS, ei tohiks paroolina kasutada kombinatsioone “Suurfirma1”, “5uur51rma” jms. Need on lihtsalt ära arvatavad – mitte inimese, vaid spetsiaalselt selle jaoks loodud programmi poolt.

Kui iga kasutaja võib valida ise oma parooli peaks ettevõte seadma kindlad reeglid seoses paroolidega. Näiteks, et paroolid peavad olema vähemalt 9 tähemärki pikad ning ei tohi sisaldada ettevõtte ega kasutaja nime. Rohkem ideid paroolireeglite koostamiseks leiad artiklist “Kuidas valida turvalist, kuid meeldejäävat parooli”.

Tehnilises näpunäited

Kontrolli failide ligipääsu õigusi

Suure tõenäosuega kasutab su kodulehte jookutav server Linux’it. Seetõttu on oluline tunda Linux’i failide ligipääsusüsteemi. Kui oled siiani ainult kokku puutunud Windows’iga võib Linux’i failide ligipääsusüsteem keeruline tunduda. Tegelikult see nii pole, see on lihtsalt Windows’ist erinev.

Linux’i kasutajaõiguste süsteemi nimi on chmod (tuleb inglisekeelsetest sõnadest change mode). Kuidas täpelt toimib Linux’i failiõigustesüsteem on teema tulevaseks artikliks, kuid vaadates failide õigusi, tohiks 777 olla ainult kataloogidel, kuhu faile üles laed. 777 tähendab, et faili või kataloogi võivad muuta kõik protsessid – nii operatsioonisüsteem, veebilehe tarkvara kui häkkeri pahatahtlik kood. Kui vaatad faile oma serveris FTP tarkvaraga nagu FileZilla saad failide õigusi vaadata enamasti parema klikiga, valides “File Premissions” või sarnase vaste.

 

 

Suure tõenäosusega pole kodulehe omanikuna sul otseselt vaja teadagi, mis ligipääsu õigused on kõigil failidel. Küll võid kodulehe loonud ettevõttelt küsida kinnitust, et ühelgi ebavajalikule failile ega kataloogile poleks jäetud 777 faili õigust. Õige failide õigus kindlustab, et ka haavatavuse tuvastamisel ei pääse ründaja ligi olulistele failidele. Liiga suurte õigustega fail on seevastu haavatav.

Kontrolli, mida otsingumootorid indekseerida tohivad

Otsingumootorid skaneerivad kõiki kodulehti internetis pidevalt. See kindlustab, et Google annab igale otsingule alati kõige õigema ja ajakohasema tulemuse. Samas võib su lehel olla sektsioone, mis võiks mitte otsingutulemustes välja tulla – näiteks administreerimispaneel. Õnneks saad otsingumootoritele öelda, mida nad tohivad indekseerida ning kust nad peaks oma käpad eemale hoidma.

Seda saad teha robots.txt failiga. Robots.txt faili kontrollivad kõik otsingumootorid enne, kui nad lehte indekseerima hakkavad. Kui seal on reegel, et mingid osad lehest peavad jääma indekseerimata, siis nad seda ei kajasta. Kuidas täpselt toimib robots.txt jääb välja selle artikli skoobist – hetkel on lihtsalt oluline, et võimalik on oma kodulehe osasid otsingumootorite eest peita. Täpsemat infot võid küsida kodulehe loojalt.

Oluline on märkida, et robots.txt kaitseb sind ainult avalike otsingumootorite, mitte pahatahtlike veebirobotite eest. Mainisin varem, et tihti loovad kurjategijad roboti, mis otsib internetist haavatavaid kodulehti ning nakatab need pahavaraga. Need robotid ei austa ilmselgelt robots.txt faili ega jäta ühtegi seal olevat URLi skanneerimata. Vastupidi, robots.txt faili koostades peab olema ettevaatlik – pahatahtlik kasutaja saab selle avada ningi näha milliseid faile ja katalooge sa kaitsta tahad. See võib anda talle infot selle kohta, millist tarkvara sa kasutad või kus võivad olla konfidentsiaalsed failid.

Parema kliki keelamine on mõttetu

Tihti üritatakse oma koduelehe sisu ja lähekoodi kaitsta parema kliki keelamisega. See on täiesti mõttetu – igaüks, kes soovib kodulehe avalikule koodile või seal olevatele piltidele ligi pääseda saab seda teha nagunii. Ainus, mida teeb parema kliki keelamine, on su kasutajate ärritamine.

Võib arvata, et ilma parema klikita ei ole võimalik vaadata lehe HTML koodi. See pole loomulikult tõsi, näiteks Google Chrome veebilehitsejas näeb iga leht HTML lähtekoodi vajutadas kas control + shift + u Windowsis või options (alt) + command + u Macis. Täpselt sama on ka piltidega. Kasutaja saab iga pilti kodulehel alla laadida, mida ta näha saab. Sa võid keelata parema kliki, kuid  Chrome (või teiste veebilehitsejate) arendajate töötriistast on võimalik ligi pääseda kõigile piltidele, mille veebilehitseja serverist alla laadis.

Võid seda ise proovida. Google Chrome arendajapaneeli saad avada vajutades shift + control + j Windowsis või coptions (alt) + command + j Macis. Seejärel valik “Network” ning “Img”. Peale lehe uuesti laadimist näidatakse all nimekrja kõigist pildifailidest, mis veebilehitseja laadinud on. Nimekiri täieneb reaalajas, kui lehel ringi liigud. Tehes parema klõpsu ükskõik millisele failile nimekirjas saad selle alla laadida.

Kontrolli, et versioonide ajalugu poleks üles laetud

Arendades kodulehte salvestavad arendajad selle progressi järk-järgult versioonihaldustarkvaras. Versioonihaldustarkvara võimaldab lihtsa vaevaga projekt tagasi viia varasemasse versiooni, kui midagi vahepeal katki läks. Samuti võimaldab see mitmel arendajal korraga töötada ühe projekti kallal ilma üksteise muudatusi üle kirjutamata. See on täiesti normaalne osa arendustegevusest – küsitav oleks pigem, kui arendaja versioonihaldustarkvara ei kasutaks.

Paraku juhtub tihti, et koos kodulehe failidega laetakse üles ka versioonihaldustarkvara arhiiv. Sellisel juhul on täiesti avalikult võimaik ligi pääseda kogu kodulehe lähtekoodile (tavaolukorras ei ole võimalik kasutajal näha kodulehe lähtekoodi, ainult sisuhaldustarkvara poolt genereeritud HTML koodi) ja sinna salvestatud paroolidele. Ei ole välistatud, et arendaja võib kogemata andmebaasi paroolid üles laadida.

Õnneks pole raske kontrollida, kas su arendaja on kogemata ka versioonihaldustarkvara üles laadinud. Lihtsalt mine aadressidele

• sinukoduleht.ee/.git
• sinukodulet.ee/.hg
• sinukoduleht.ee/.svn

Kui ühtegi neist kataloogidest olemas pole (tulemuseks on 404 vealeht), ei ole versioonihaldust üles laetud. Kui kasvõi üks neist peaks olemas olema, võta koheselt ühendust oma kodulehe arendajaga!

Mida teha, kui su koduleht on häkitud

Esimese asjana pead tuvastama, kuidas su kodulehte rünnati. Selleks tasub ühendust võtta oma veebimajutuse pakkujaga. Kui tegemist oli nn massilise näostamisega, kus rünnati otse teenusepakkujat, ei saa sa ilmselt suurt midagi teha. Siis peab teenusepakkuja lehe viimasest varukoopiast taastama.

Kui rünnatud on su oma kodulehte, mitte teenusepakkujat, tuleb tuvastada ründevektor; vastasel juhul pole veebilehe taastamisest ilmselt kasu. Veendu, et kasutatav tarkvara oleks uusim ning vaheta kõik paroolid. Kui paroolid on vahetatud, taasta kogu oma kodulehe sisu rünnakueelsest varukoopiast (vajadusel pärast seda tarkvara uuendades).

Kui häkker pani su veebilehe pahavara levitama ning Google on su lehe juba “musta nimekirja” lisanud pead neile avalduse saatma selle taastamiseks. Seda saad teha aadressil https://safebrowsing.google.com/safebrowsing/report_error/?hl=en. Enne avalduse saatmist veendu, et pahavara oleks kodulehelt kindlasti eemaldatud.

Mida teha, kui ründaja muutis su lehe sisu ja Google on selle vahepeal indekseerinud? Sellisel juhul ei saa teha muud, kui muuta sisu tagasi ning Webmaster’s tools’i kaudu Google’t muudatusest teavitatada. Selleks vali oma veebileht ning avanenud lehel parempoolsest menüüst “Crawl” ning “Fetch as Google”.  Avanenud vaates vajuta “Fetch” ilma seadeid muutmata ning peale päringu edukat lõppu kliki “Request indexing”. Avanenud aknas vali “Crawl this URL and its direct links”, mis ütleb Google robotile, et ta peaks kogu su kodulehe uuesti üle käima.