Locked Shields 2017 – põhjalikult iganenud WordPress ja tööstuslikud kaitsemeetmed

Kui Andris nägi augulist drooni-scheduleri esimest korda päev enne Locked Shields’i algust – siis mina olin enda peale võtnud avaliku www ja selleks osutus WordPress, mille turvamisse ja puhastamisse olen ma viimase aasta jooksul matnud nii töö- kui puhke-aega. Suht plass lugu oleks kõige selle järel vastased mingi tähelepanematuse tõttu sisse lasta…

See postitus on kolmas osa järjejutust, mis võtab kokku Andrise ja Peetri poolt Locked Shields 2017 küberõppusel Eesti blue team’is osaledes kogetu.
Loe ka:
Osa 1 – sissejuhatus ja taust
Osa 2 – üks jube tudengiprojekt “väikse” tagauksega

Minu olukorra tegi eriti huvitavaks see, et ühelt poolt olen ma oma kaitsestrateegiat mõni aeg tagasi kirjeldanud ja demonud ka üritustel, kus muuhulgas kohal punase tiimi esindajad. Ja teisalt pidas meie psy-ops osakond oluliseks lekitada infot, nagu kaitseks veebi hoopis üks veebiturva-agentuur, kelle kaitsest mitte-läbi-saamine käiks selgelt punaste au pihta … miska tiimide võrdse kohtlemise printsiibist lähtudes eeldasin meile osaks saavat keskmisest võrdsemat tähelepanu.

Esimene pilk veebile

Loomulikult oli see REST-API auguga WordPress 4.7.1, teemade kataloogis lisaks kasutusel olevale ka 11 tarbetut ning pluginate all… 32 nimetust. Enamus uuendust vajavad, alternatiivina otse PHPd käivitavad või SQL-päringuid lubavad, sekka paar eelajaloolist ja autori poolt unarusse jäetud ronti ning üks konkreetselt pahatahtlik.

”WordPress oli lihtsalt selleks, et näha, kas osalejad vähemalt update-nuppu oskavad pressida” seletati mulle aftekal. Tegelikult oli lugu natuke nutusem, sest uuendamine on küll hea profülaktiline meede – aga ei aita, kui veebis on juba paharett sees. Sest et:

  • WPd uuendades kirjutatakse üle muutunud failid, aga kõik mittemuutunu, sh varasemate versioonide puhul kasutatud ja tänaseks tarbetuks muutunud failid, jääb alles.
  • Pluginate uuendamine on veidi nutikam st kataloog kustutatakse tühjaks ja tehakse sisuliselt uus paigaldus… aga seda ainult pluginatele, mille jaoks on uuendus saadaval. Valikus oli lisaks ka galerii-plugin, mis talletas pildid oma kataloogi alla ehk selle uuendamine tõmbas vee peale kasutaja poolt üles laetud sisule.

Seetõttu on häkkerite lemmikuks WP paigalduse juurkataloog, kuhu lisatud wp-misiganes.php failid ei hakka väiksema kogemuse korral silma, aga ka wp-includes mida uuenduse käigus ei puhastata, kasutult seisvad teemad ja tasulised või hüljatud pluginad, mille lihtne uuendamine (enam) võimalik ei ole. Kasutusel olev teema on samuti hea koht, sest sageli on keegi seda kohandanud ning uuendamise korral lähevad muudatused kaduma.

Advanced WordPersistent haxxors

Tavapäraselt sokutavad rendihäkkerid uuendusele mitte alluvasse kohta oma obfuskeeritud tagaukse ja webshellid ning need näevad juba kaugelt vaadates kahtlased välja. Meid oli aga kostitatud veidi peenemate nippidega – näiteks mõne turvafeatuuri väljakommenteerimise, või pisimuudatusega SQL-lauses:

Mis siin siis toimub? WP ei kasuta prepared statement’e, vaid laseb SQL-laused oma kiirpuhastusest läbi. Selle muudatuse järel liidetakse aga puhastatud lausele otsa kasutajalt saadud parameeter. Kuigi me üldiselt hoidume punaste häkkide avaldamisest – siis see on natuke liiga õpetlik näide ja ma tahan, et kõik veebide puhastamisega kokku puutujad mõtleksid sügavalt järgi, kas nende töövõtted – nt antiviiruse või yara-reeglitega skannimised – ikka toimivad.

Selliseid muudatusi ükshaaval taga ajada pole mõtet, vaja on süsteemsemat lähenemist. Mis oleks, kui vahetaks hoolikalt välja kogu WP koodi, 35 pluginat ja teemad? Hold my beer while…

Või oot, hoian ise – sest nagu ma muretsevatele tiimikaaslastele kommenteerisin: selle WPga tegelen ma õhtul kodus vasaku käega, mis jätab parema käe sobilikult õlle hoidmiseks vabaks.

Nimelt hakkasin ma aasta tagasi WPsid puhastades korduma kippuvaid käske tekstifaili koguma – ning ühel hetkel jõudis kollektsioon sinnamaale, et ma vormistasin selle üheks kenaks shelli-skriptiks. Nimeks clinup, sest see kasutas ekstensiivselt WP-CLI’d ehk WP käsurealiidest, mis võimaldab teha enamvähem kõike seda mida tavakasutajad teevad brauseris hiirega ringi klõpsides… aga ka asju, mida brauseris mugavalt teha ei saagi.

Kuri kood ja ohverdatav liivakast

Ahjah, enne, kui häkkerite poolt ülevõetud WP kasvõi käsurealt oma arvutis käima tõmmata… tasuks mõelda selle peale, et seal võib leiduda ka koodi, mis oskab teisi rakendusi nakatada (või faile krüptida :-). Minu tavapärane veebiarendus-platvorm ehk OSX all jooksev MAMP selliseks tööks mõistagi ei sobi.

Võiks ju võtta endale ajutiseks kasutuseks ühe Zone Virtuaalserveri… aga ma otsustasin tähtsa sündmuse puhul oma teadmisi veidi täiendada ja õppisin selgeks Andrise poolt paar päeva varem soovitatud Vagrant’i kasutamise: pärast väikest konfidega mängimist oli mul oma arvutis kasutusvalmis virtuaalmasin, mile ma saan ühe käsuga luua – ning hävitada, sest who cares, it’s just a VM:

vagrant up
vagrant ssh
[... teeme tööd, näeme vaeva ...]
vagrant destroy

Minu MacBook’ist sünkroniseeritakse sinna ainult üks vajalik veebirakenduse kataloog mis ettevalmistus-perioodil oli puhastatud veeb, aga õppuse ajal kontrolliks algversioon – et saaks veenduda toodanguserveris oleva puhastatu funktsionaalsuse vastamises algsele.

Vasaku käega puhastamine käib nii:

clinup init-git
clinup forensic
clinup safe

“Kas see on sul kusagil repos, saad jagada?” – saan ikka, aga privas ja ainult neile, kes on valmis omalt poolt parandusi / ideid kontribuutima. Sest (a) see on mu elu esimene shellscript ja mitte väga ilus (b) osakamatu kasutamise korral saab sellega endale jalga tulistada (c) me kasutame seda vaatamata punktidele A ja B igapäevases töös 🙂

Esimene käsk initsialiseerib git-repo ja lisab mõned ignore’d, teine vahetab WP ja kõik komponendid ükshaaval välja samade versioonide originaalidega tehes iga sammu järel git commit’i (olles enne normaliseerinud failiõigused, et mõni fail 444 tõttu alles ei jääks)… ning kolmas teeb kõigele uuendused viimaste versioonide peale, otsib uploads-kaustast faile mille nimes on .php või sees <?php … ja veel nipet-näpet nagu nt Perishable Press 6G .htaccess “tulemüüri” reeglite lisamine ning PHP otsekäivitamise piiramine wp-content kataloogi all:

Options -ExecCGI
Options -Indexes
RemoveType .php .php3 .phtml .inc
RemoveHandler .php .php3 .phtml .inc

<FilesMatch "\.(?i:php|php3|phtml|inc)($|\.)">
 Require all denied
</FilesMatch>

<IfModule mod_php7.c>
 php_flag engine off
</IfModule>

Kõige lõpus kuvatakse nimekiri failidest mida EI OLE muudetud … ehk mis vajavad käsitsi ülevaatamist.

Pildil iidsed ja pahatahtlikud pluginad, aga ka juurkataloogis näeb ls -la abil ära sinna sokutatud failid puhtalt kuupäeva järgi. Juuuube mugav.

Git’i diffide abil näen kõiki vastase poolt muudetud ridu (nt see sql-hack ülalpool) – selle pärast siis ka esimene ‘forensic’ ehk samade versioonidega asendamine. Ning kui järgnevad uuendused mingi funktsionaalsuse katki teevad, saab minna ajaloos tagasi viimase töötava commit’ini ning vajadusel muudatuse revertida.

“Aga mis sa siis teed, kui on nii vana WP et wp-cli ei käivitu või mõni plugin ta katki teeb?” On üks parameeter, mis paigaldab värske WP eraldi prefixiga, uuendab pluginad ilma neid sisse lülitamata ja siis switchib päris baasi peale tagasi. Oli teil veel mingeid muresid?

Otseloomulikult oli koodis ka üks die(), mis wp-cli käivitumist takistas… aga õnneks oli D.S. mind sarnase mõistatuse lahendamise eest just veidi aega tagasi kastikese õllega premeerinud… miska oli olemas nii teoreetiline kui materiaalne valmisolek 98% probleemide tööstuslikuks lahendamiseks.

2% käsitöö hulka kuulusid näiteks mõned kataloogid, kus oli .htaccess abil lubatud kataloogi-indeksi kuvamine – ilmselt eesmärgiga skoorida OWASP Top10 A6Sensitive Data Exposure” ning seejärel A4Insecure Direct Object Reference” – ning kasutust mitte omavate pluginate tuvastamine ja kõrvaldamine. Õppuse reeglite järgi olid kõik lisad “not just a plugin that can be removed, but installed for a reason”, aga eks me lubame need uuesti, kui keegi kobiseb.

Valmis tööks ja kodumaa kaitseks

WP puhtaks, .tar.bz2’ks kokku ja Linuxi-tiimile Ansible-playbook’i lisamiseks, koos juhistega millised on need vähesed kataloogid, kuhu veebiserver peaks omal käel kirjutada saama (sisuliselt wp-content/uploads – kõik muu olgu keelatud).

Apache ja PHP konfides said adminnidelt kinga kõik mitte-standardsed seadistused ja kergesti-leitavates kohtades olevad PHPmyadmin’id, ära keelati probleemsete funktsioonide nagu system() käivitamine, paika pandi open_basedir (et PHP ei saaks lugeda faile, kuhu vaikimisi veebiserveri õigustes võiks ligi pääseda). Ehk kõik nii askeetlikuks kui võimalik. Ja Apache ees SSL offloading’ut teinud Nginx – pomm alla ja põlema, vahet pole kas selle eesmärk oli meie tähelepanu hajutada või oli seal peidus ka mõni ründevektor. Ma nimelt kuulasin mõni aeg tagasi ühe punase loengut, kus oli jutuks kõrgema klassi maagia teostamine proxy-päistega nimelt sellises kontekstis ja see muutis mu eriti paranoiliseks… Burn, baby, burn…

Aga mõtleme veelkord, millised osad mul eelnevaga katmata jäid?

Kahtlased kasutajad andmebaasis, WP seadistused, widgetid ja postituste sisu. Igaks juhuks tasub üle vaadata ka wp_options tabel (hmm, miks need soolad siin asuvad?) ning eemaldada postituste revisionid, mida vaja pole. Ja kuidas teha nii, et ma saaksin õppuse käivitamise hetkel veel enne Ansible’t lahti neist jubedatest pluginatest? Kuidas suudaksin tagada, et legitiimsed admin-kasutajad ei saaks turvakaalutlusel keelatud ent igaks juhuks olemas olevat pluginat taas-lubada? Ja kuidas ma saan jälgida kõike toimuvat mõne audit-everything pluginaga nii, et admin-kasutajad ei saaks seda välja lülitada? Lisaks – korraldajad lubasid meil keelata ära tundmatult IPlt admin-liidesesse sisenemise admin-kasutajatel, jättes selle siiski avatuks nt toimetajatele…

Õnneks on WordPressil selline võimalus nagu must-use plugins – ehk luues wp-content/mu-plugins kausta saan sinna sokutada kraami, mis tõmmatakse käima enne kõike muud. Viskasin kiiruga valmis oma quick-hacks.php plugina, mis realiseeris valikulise IP-piirangu sisselogimisele, sisaldas nimekirja pluginatest mis tuli ära keelata ning tappis maha ka XML-RPC ja REST APId. Naabriks sai ta endale Stream plugina, mis sokutab ennast vahele igale muutmisoperatsioonile ning kuvab audit-logi.

<?php
/*
 * Place for LS17blue10 WP hacks
 * peeter@zone.ee / v0.1
 *
 * */

if ( ! defined( 'ABSPATH' ) ) {
 die( 'Horrible, terrible death - here be much dragons!' );
}

add_action( 'muplugins_loaded', 'blue10_muplugins_loaded', 9999 );

function blue10_muplugins_loaded() {
 deactivate_plugins(
 [
 'php-code-widget/execphp.php',
 'insert-php/insert_php.php',
 'ip-logger/ofc_handle_image.php',
 'sql-executioner/sql-executioner.php',
 ]
 );
}

Startex!

Mängu alguses oli meil “väike võrguikaldus”, mistõttu ükski hoolega ettevalmistatud Ansible playbook’idest oma süsteemi uuendamise tööd alustada ei saanud ja äkitselt oli laual küsimus – mis on plaan B?

Vähemalt toimis minu igaks-juhuks-kribatud skript, mis ühenduse tekkimisel kohe SSHga serverisse logis ja kõigist veebikomponentidest startex-seisuga koopia tegi. Järelikult võin ma käsitsi olulisemad parandused peale lasta kartmata, et ei suuda hiljem mõne probleemi ilmnemisel algset versiooni taastada … ja teha muid liigutusi, näiteks selle igaks-juhuks-tehtud-mu-plugina abil. Olemaks valmis, kui uuendused ei saa tehtud enne punaste poolt jäetud 30-minutist armuaega. Tööd jätkus sedapuhku mõlemale käele – aga matet saab õnneks käed-vabad režiimis ehk kõrrega juua, seega oli olukord talutav.

Kui veidi hiljem ka ettevalmistatud uuendused tehtud said, oli aega ringi vaadata. Ilmnes, et ma olin suutnud iidseks ja tarbetuks kuulutada ühe vormiplugina… millega oli realiseeritud mh failide üleslaadimist lubav kontaktivorm (uwaga! uwaga! pluginas realiseeritud failihaldus on alati ohumärk). Teoreetiliselt peaksid kõik muud kaitsed takistama selle kasutamist deface’inguks kvalifitseeruvate failide üles laadimiseks… aga hunt seda koodi auditeerida jõuab. Vorm on vorm ja lihtsam on see uuesti realiseerida. Reaalses elus paneks ma asemele tuntud ja turvalise vormiplugina ning vormistaks selle kliendile suureks heateoks (või väikseks arveks), aga kuna kasutajaid simuleeriv automaatika kontrollis nimelt selle plugina tunnust HTMLis oli lihtsam niipidi. Kasutajad said nuppu klikkida ja tulemus läks ka kenasti serverisse kirja. Aga natuke tiksus monitooringust miinust.

Rahulikumal hetkel mängisin oma Vagrant’i liivakastis samm-haaval läbi ka Apache’le Mod Security paigaldamise (see oli meil plaanis, aga ettevalmistuse käigus oli olulisemat teha) ning kirjutasin paigaldamise skriptiks, mis lubaks seda kiiresti korrata ka juhul, kui mängujuhid peaksid liiga hea kaitse preemiaks süsteemi ootamatult revertima augulisse algseisu. Läks lives käima küll. Õigupoolest midagi kaitsta vaja ei olnud, aga ma tahtsin ründajate taktika hilisemaks uurimiseks põhjalikumaid logisid koguda. Paraku olid nad selleks ajaks juba käega löönud ning midagi massiivselt ilusat ma ei leidnud.

Ja siis tuli psy-ops’i ülesande lõpule viimine – ma olin unustanud ära vajaduse sokutada veebi markereid, mis viitaksid kaitsjatele. Väike false flag… Mis sai liiga nähtavasse kohta peidetud ja kuuldavasti leidmata jäi, olgu siis siinkohal täies ilus ette näidatud:

robots.txt (inspireeritud Riigikohtu veebi kunagisest kaitsemeetmest):

# done: protect important files and folders from robots
User-agent: *
Disallow: /webarx-logs
Disallow: /humans.txt
# todo: protect important files from humans looking at robots.txt
Disallow: /robots.txt

humans.txt:

In order to save humankind Uber has agreed to execute one kitten for each visit to this URL:

http://goo.gl/GGaqDF (spelled: "googl golonel gaddafqi")

Please - be humane to humans!

Viidatud logid olid muidugi kah omal kohal (samuti neid produtseeriv plugin) ja sisaldasid avaliku logimise heale tavale vastavalt häkkerite tööd lihtsustavat informatsiooni meie veebi sise-elu kohta.

Olgu öeldud, et kui meie tõeline identiteet esimese päeva õhtu Aktuaalse Kaamera klipi näol paljastus… registreerus järgmisel hommikul autori õigustes veebikasutajaks keegi oliver.sild – ma olin kõige muu eest hoolitsedes jätnud märkamata selle, et WPs oli lubatud kasutajate registreerimine ja kõik liitujad said rolliks Author.

Üsna valus viga muidugi – aga ega ta seal suurt midagi teha ei saanud… ja Stream’i auditi-logist torkas kohe silma : )

Järjejutu kõik osad:

LS17 – üks jube tudengiprojekt “väikse” tagauksega

Siin postituses kirjeldan eelkõige ainult omaenda tegevust, kuid suures plaanis oli see vaid tilk meres, iga teine võistkonna liige tegi oma süsteemide kaitsmisel vähemalt sama palju või rohkem.

Veebirakenduse kaitsmisest pole suurt kasu, kui näiteks võrk ei tööta või serverid ei käivitu. Pealegi oli see vaid üks osa tehnilisest süsteemist, aga lisaks tehnilisele käis kibe töö ka muus osas, mis käis juba üle meie peade. Juriidiline osa, meedia, koordineerimine jne.

See postitus on teine osa järjejutust, mis võtab kokku Andrise ja Peetri poolt Locked Shields 2017 küberõppusel kogetu.
Loe ka:

Ettevalmistus

Esialgu teadsime nendest rakendustest ainult nii palju, kui üldskeemi pealt oli näha. Osaliselt võis aimata, et millega tegu, osaliselt mitte nii väga, nii et vähemalt mina midagi väga ette planeerida ei osanud.

Tutvumispäevadel, nädal enne õppuse algust, pääsesime ligi juba kõikidele süsteemidele, va. üks puuduv veebirakendus, mille kohta oli teada ainult selle üldkirjeldus. Kuna see veebirakendus oli üks minu ülesannetest, siis jäi sellevõrra rohkem aega vaadata üle muid oma vastutusvaldkonna asju. Koos kolleeg Peetriga majandasime erinevaid veebirakendusi ning saime selleks vajalikku tuletoetust Linuxi adminnidelt.

Esialgu tundus kõik üsna keeruline, tegelesin e-posti serveriga, kuhu olid paigaldatud ka veebipõhised mailikliendid ning rakenduste paljususe tõttu paistis auke igalt poolt. Minu suurimaks lemmikuks oli näiliselt juhuslike “vigade” (muutuja nime muutev trükiviga siin, konfiguratsiooniviga seal jne.) tõttu tekkinud olukord, kus veebi kaudu ligipääsetavasse faili logiti kõike, sh. kõikide kasutajate paroole, mida normaaloludes kuidagi juhtuda ei tohiks.

Teise päeva lõpuks tundus asi juba täiesti kontrolli all olevat. Toimetasin serveris rahulikult ringi, otsisin vigu, parandasin neid ning tegin koopiaid (vahetult enne võistlust tehti kõikidele süsteemidele initsialiseerimine ja parandused oleksid kaotsi läinud), kui monitooringu poolelt tuli äkki teade, et sellessamas masinas istub mingi beacon. Läksin ja vaatasin, tõepoolest olid monitooringus näha kummalised payloadid C&C serverisse.

Vasak silm hakkas tõmblema.

Päev 0

Esimene õppusepäev oli samuti harjutuspäev. Nüüd olid kõik süsteemid lõplikul kujul üleval ja saime nendega kuni õhtuni toimetada, mil need seekord juba viimast korda initsialiseeriti. See muidugi tähendas, et ka minule määratud üllatusrakendus oli masinas olemas.

Esialgu paistis see olevat tavaline PHP+MySQL veebirakendus, kuid ühes kaustas asusid veel mingid shelli skriptid ja teises asus midagi, mis paistis nagu Pythoni deemon. Juba põgusa pealevaatamise alusel võis hinnata, et rakendus oli kõikvõimalikke auke täis. Mis polnud ka ime, arvestades, et rakendus oligi kirjutatud spetsiaalselt selle võistluse jaoks.

Esimese asjana võtsin ette PHP koodis SQL-injectionid. Neid oli muidugi igat sorti, osaliselt olid koodis SQL argumendid töödeldud addslashes funktsiooniga SQL päringu stringi sees, osaliselt pandi $_REQUEST muutujast tulevad väärtused lausesse otse (injection!), osaliselt kasutati custom töötlemisfunktsioone, mis kasutasid muidu küll addslashes’it, aga tagastasid tulemusest vaid fikseeritud pikkusega osa (peidetud injection!), mis omakorda oleks võimaldanud stringe lõpetada tagurpidi kaldkriipsuga.

Joonis 1.  Kui $user_id oleks string, tuleks sealt eemaldada kõik, mis võimaldab kavandatud SQL lausest välja hiilida, täisarvu puhul oleks õigem teha kohe intval($user_id). addslashes() on turvalisema mysqli_real_escape_string() asemel kasutusel kuna maandas enamuse riskist, oli lihtsam lisada ja võimaldas seetõttu suurema hulga koodi üle käia. Päris-elus tuleks võtta kasutusele PDO ja prepared statement. Selles kiiruga tehtud paranduses on muideks üks kala sisse jäänud  😉

Parandasin seejärel kõikvõimalikke muid koodi ja konfiguratsioonivigu. Küll oli vales kaustas lubatud valet tüüpi faile käivitada kui PHP’d (kirjutasin uued .htaccess reeglid kõikide kaustade jaoks), küll olid pildifailid PHP koodi täis (kirjutasin hex editoriga nendesse uue koodi), kõikvõimalikud tmp ja puhvri kaustad asusid web root kaustas ning olid muidugi ka veebist loetavad. Siis veel mitmel eri viisil koodi käimatõmbamine valest failist (ehk include $_REQUEST[‘page’];), veebist loetavad konfiguratsioonifailid (MySQL konto andmed!), kasutaja sessiooni andmete muutmine cookie kaudu jne.

Sinna juurde veel vead Apache enda konfiguratsioonis (täiendav rivi faililaiendeid, mida käivitati PHP koodina, lahtine cgi-bin, server-status jmt), eelinstalleeritud cron, kummalised PHP seaded (aegunud sessioonide GC oli välja lülitatud) jmt. Päeva lõpuks tundsin juba end päris hästi, paistis, et kõik on kontrolli all.

Joonis 2. Kui oled lasknud oma serveri üle võtta, tasub kahelda kõiges. Ükshaaval selliste pisimuudatuste otsimine on võimatu – turvalisem on kõik-kõik-kõik asendada originaalide või oma koostatuga. Ning jälgida, et süsteem ikka tõesti võtab konfifaile sealt, kust sina arvad.
Päev 1.

Algas esimene tegelik õppusepäev, kõik süsteemid olid taastatud jälle algseisu ning meile anti pool tundi peale mängude käivitamist, et oma parandused süsteemis ära teha. Kuna automaatsete parandustega tekkis mingi jama, lükkasin oma veebirakenduse muudatused üles kiirelt käsitsi. Kontrollisin, kõik töötas, läksin võtsin kohvi.

36 minutit ja 6 sekundit peale mängude algust lendas peale esimene rünnak, mis kohe ka õnnestus. Rakenduse veebilehelt vahtis vastu “Peace Brigade is here” sõnum, maatriksi rohelised kukkuvad sümbolid taustal. Suu kukkus lahti, mul oli kõik ju kontrolli all?

Tuli välja, et muidugi ei olnud asjad kontrolli all. Olin ära unustanud templiidifailid põhjalikult üle käia. Kuigi osa html koodi escape’imist tegin ära juba PHP koodi poolel, siis põhitöö käis templiitides. Midagi olin nagu teinud, aga ilmselt mitte piisavalt. Ahvikiirusel käisin siis kõik templiidifailid läbi ja toppisin escape filtreid täis ning kirjutasin baasis muudetud kirjed üle, et defacementi eemaldada.

Päris korda kohe kõike ei saanud, veidi läks veel neidsamu defacemente läbi ning lisaks õnnestus mul osad templiidid nii ära rikkuda, et osa funktsionaalsusest enam ei töötanud, kuna templiiti ei saanud laadida. Parandasin süntaksivead ükshaaval ära ning tundus, et kõik on jälle kontrolli all.

Kell 13:00 hakkas teine faas ning sellega koos hakkasid laekuma SQL-injectioni katsed. Nendega paistis siiski kõik korras ning kasutajad nimega 1=1 sisse logida ei saanud.

Joonis 3. Syslog ei pruugi olla küll kõige mõistlikum koht… aga hädaga ajab kiirema asja ära. Allpool loginäide lihtsamat sorti SQLi’st:
Apr 26 10:09:45 scheduler[9524]: url=/admin/login.php message=Login failed for "or/**/1=1# session=[]
Apr 26 10:09:45 scheduler[9524]: url=/admin/login.php error=Wrong username or bad password session=[]

Veel 10 minutit hiljem hakkasid tuvastamata põhjustel toimuma anomaaliad. Kõigepealt tekkisid vead rakenduse näitamisel, ilmnes et kettaruum on otsa saanud. Kettaruumi oli ära kulutanud /tmp kaustas asuv hiigelsuur fail. Vaatasin seda less’iga ja nägin vaid suurt kogust nullbaite.

Siis juba ilmnesid probleemid baasiga. Või õigemini selle puudumisega, keegi oli nimelt kell 13:41 andmebaasi ära kustutanud. Lisaks ilmselgele probleemile – veebikasutajal oli õigus kutsuda välja DROP DATABASE, mis sai käigu pealt ka parandatud, oli ikkagi küsimus, et kuidas?

Taastasime baasi backupist.

Mõne aja pärast hakkas veebirakendus näitama out of memory veateateid. Tuli välja, et baas oli jälle läinud. Seekord küll mitte täielikult (polnud enam kustutamise õiguseid), vaid tabelid olid tühjaks tehtud, va. üks mis oli täis gigabaitide jagu x tähti (selleks andis võimaluse tõsiasi, et viimne kui üks tekstiväli andmebaasis oli TEXT tüüpi). PHP rakendus proovis kõiki neid ridu ühte massiivi sisse lugeda ja sellest ka veateade.

Taastasime baasi backupist.

Nüüd läks asi päris hulluks. Otsustasin teada saada, et kuidas see kustutamine juhtub ning hakkasin kõikvõimalikku logimist peale keerama. Viga parandada ei proovinud, kuna ei teadnud, et kust otsida. Selle asemel lootsin saada uutest rünnakutest piisavalt palju infot, et auk selle kasutamise järgi üles leida.

Joonis 6. Tavapäraselt jookseb veebiserveri logisse päring – ja GET-päringu puhul ka parameetrid. POST-päringu body’s olevad parameetrid, aga ka küpsised jms, jäävad peitu. Nende logimiseks saab kasutada nt Mod Security’t, aga kui on kiire, tuleb leiutada. Igas rakenduses on mingi konfifail, mis laetakse igal päringul – see on ideaalne koht oma logimislahendusele… ja pilt on lõigatud ära realt, kust algas kaitsemeede.

Keegi kustutas baasi ära, meie lasime selle kohe tagasi ja nii mitmeid kordi. Lõpuks hakkas tekkima failidesse pahaseid sõnumeid, et tegeleme cheatimisega. Mõtlesin, et võiks kuidagi vastata, aga ei viitsinud. Sest lõpuks oli eesmärk käes, sain piisavalt infot, et mis toimub. Paraku kaasnes sellega ka 250 miinuspunkti, sest pidev taastamine kohtunikele ei meeldinud.

See keegi kasutas rakendust ennast webshellina. Saatis sinna kodeeritud pakette, mis tõmmati mingil viisil PHP koodina käima. Päris hästi ei saanud aru, et kuidas see mehhanism töötab, aga paha payload oli kätte saadud ning panin sisenemisaugu kinni, nii et seda rohkem käivitada ei saaks.

Joonis 4. Veebirakendus endiselt töötab

Ma ei hakka siinkohal avaldama, et kuidas webshell täpselt töötas, kuna hammustasin selle lahti alles peale võistlust. Võistluse ajal sain vaid aru, et payload on base64 kujul mingisugune läbu, olid omad kahtlused selle sisu formaadi kohta, aga päris kindel ei olnud. See jõudis rakenduseni ja seal siis mingi asi võttis payloadi lahti ja pani käima.

“Aga miks te lihtsalt päringu parameetreid ei filtreerinud?” Kui pahalane on sinu koodis sees, siis võib ta mõelda välja lõputult lahendusi, kuidas see kood saab oma peremehega suhelda. Oleme kavalad ja teeme intval($some_id) – aga võibolla tilguvad käsud sisse selle sama ID järjestikuste väärtustena? Ainus lahendus on tagauks üles leida, ideaalmaailmas tehes totaalse code-review… piiratud ressursi puhul tuleb logida ja leppida sellega, et mõned ründed läbi pääsevad.

Vaikselt hakkas ka paranoia tekkima. Iga nurga tagant paistsid punaste kõrvad:

Mul on siin mingid kummalised OPTIONS päringud. JA NEED TULEVAD LOCALHOSTIST!
Need on monitooringupäringud
Aa okei, hea küll

Päeva lõpus prooviti veel üht auku, mis oli pool-lahti. St. et saadi käima tõmmata PHP funktsioone, kuid selleks funktsiooniks, mida käima prooviti saada, oli system (kusjuures jälle läbi templiidisüsteemi, aga teise augu kaudu), mis oli Linuxi adminni poolt just 5 minutit tagasi ära keelatud. Seega ei läinud see funktsioon käima ning suutsin vastava augu ka kiirelt kinni panna, et teisi funktsioone proovida ei saaks.

Kui kell viis mängu võrk kinni pandi oli kergendus suur, aga tunne oli pigem positiivne, kõik paistis olevat kontrolli all. Õhtul võtsin koodi kodus ette ja käisin templiidid veel korralikult üle, et kõik oleks korralikult escape’itud.

Päev 2.

Esimese asjana uuendasin koodifailid ära, et oleks kõik kindel. Paraku hakkasid üsna pea samad jamad peale nagu eelminegi päev. Andmebaasi ilmus kummaline rida uue kasutajaga, kellel olid märgitud rakenduse adminni õigused. Toimusid mingid anomaaliad. Tundus, et midagi oli selle templiidisüsteemiga endiselt väga valesti. Käisin järgmiseks üle koodi poole, kus templiiti välja kutsuti ning eemaldasin kõik templiidile edastatavad muutujad, mida polnud hädasti vaja. See paistis aitavat, anomaaliad kadusid. Tagantärgi selgus, et olin õhtuste parandustega vana augu uuesti lahti teinud.

Üsna pea tekkisid katsed kasutaja õiguste eskaleerimiseks, kus küpsise abil üritati sättida endale selliseid sessiooni andmeid, mida tegelikult ei olnud. Seda võimaldav viga oli juba ammu parandatud ja seega üritus läbi ei läinud.

Küll aga olid endiselt alles tegelikult juba eelmisel päeval välja tulnud probleemid õigustega – kasutajad said teha rohkem, kui neil oli lubatud. Meetodite autoriseerimiskontrollid olid nõrgad (adminnile ette nähtud tegevusi sai teha ka tavakasutaja) või puudusid üldse (igaüks kes oskas õige päringu koostada sai tegevust läbi viia). Ning seda muidugi kasutati ka ära. Õnneks sain nende aukude puhul kiirelt jaole ja muutsin käsitsi muudetud andmed tagasi, seekord me andmebaasi taastamist ei teinud.

Mingi hetk läks juba igavaks, kõik teadaolevad augud olid kinni, mis andis võimaluse minna üle ofensiivsemale taktikale. Kuna mul oli logimine päris hästi paigas, oli reaalajas ülevaade, et mis parasjagu rakenduses toimub ja kes seal toimetab, tuvastasin kahtlase liikluse kohe selle tekkimisel.

Kohe kui ründaja midagi teha üritas, tegin oma liigutused vastu. Ründaja registreeris uue konto. Mina kustutasin selle konto baasist ära ja tegin PHP sessiooni kausta tühjaks. Ründaja tegi uue konto. Mina kustutasin ära. Ja nii väga palju kordi. Vahepeal lasin ka veidi toimetada, vaatasin, et millega tegeleb, aga esimese POST päringu peale lendas konto jälle minema. See ei olnud mingil viisil skriptitud, tegin kõike käsitsi.

Ühel hetkel aga hakkas üks “päris” kasutaja kurtma, et tal ei õnnestu uude kontosse sisse logida, mille tagajärjel pidin oma hoogu maha tõmbama. Hiljem tuli välja, et kuna punastel konto loomine minu vastutegevuse tõttu (millest nad ei teadnud) ei õnnestunud, palusid nad seda proovida ühel “päris” kasutajal ning kuna see sattus ajaliselt ja välimuselt kokku punaste tegevusega, arvasin, et ka see “päris” kasutaja on punane ja kustutasin ka tema kontod ära. Üldine arvamus punaste poolel oli, et tegeleme cheatimisega, taastame cronist baasi iga hetke tagant ning peaksime saama miinuspunkte. See siiski ei olnud nii ja õnneks miinuspunkte ka ei saanud.

Punaste kahjuks ja minu õnneks oli tava-trafficu genereerimine korraldajate poolt üsna kehval järjel või puudus üldse, mis andis kogu punaste tegevuse mulle selleks hetkeks nagu peo peal ette. Nemad arvasid, et tegutsevad suitsukatte all, mina aga vaatasin seda tegevust sisuliselt läbi suurendusklaasi.

Joonis 5. Tüüpiline monitooringuvaade veebirakenduse staatusest võistluse ajal

Päris lõpus keskendusid põhirünnakud juba muude süsteemide vastu, veebi poolel midagi põrutavat ei toimunud. Üritati vahelduva eduga mingeid lihtsamaid SQL-injectioneid stiilis id=sleep(1337) ning ka skriptifailide üleslaadimist, aga kui midagi osaliselt kehvade õiguste kontrolli tõttu läkski läbi, sain sellise augu momentaalselt elimineeritud, nii et ründaja ei saanud ilmselt arugi, kui tal miski õnnestus.

Tulemus

Veebiosa lõpptulemus oli väga hea, kuna punased suutsid püstitatud eesmärkidest meie vastu saavutada vaid üksikud. Peetri asjadest ei saadud vist üldse läbi ja minul olid need mõned custom rakenduse augud, millest läbi saadi. Väga suur osa selles tulemuses oli ka Linuxi adminnidel, tänu kellele sai leitud mitmeid konfiguratsiooniauke ning kes aitasid rakendusi kogu selle aja püsti hoida. Oli väga hea tiimitöö ning tulemus oli ka näha, sest meie võistkond sai kokkuvõttes teise koha, kaotades üldvõitjale väga napilt.

Ühtepidi oli muidugi kahju, et võistlus läbi sai, aga nii intensiivset koormust taluda ei oleks enam väga kaua suutnud. Kokkuvõttes võib öelda, et sellised õppused on väga vajalikud, kuna reaalse ründesituatsioonita võib ju teoretiseerida, et kuidas end kaitsta, aga kui käsi tegelikult mustaks ei tee, siis see jääbki ainult teooriaks. Õppisin nädalaga rohkem, kui muidu aastaga ja see vist oligi kogu asja eesmärk. Mission accomplished.

Järjejutu kõik osad:

Locked Shields 2017 – sinine seestvaade

Aprilli lõpus toimus kaheksandat korda NATO CCDCOE korraldatud Locked Shields küberkaitseõppus: pea 900 osalejat 25 riigist ning 19 meeskonda kaitsmas ja puhastamas fiktiivse Berylia-nimelise saareriigi simuleeritud lennuvälja infosüsteeme.

Eesti – ja eriti kaitsva ehk sinise meeskonna kokku kutsunud CERT-EE – taktikaks on aastaid olnud kõigi osapoolte pidev harimine ja kaasamine. Lisaks RIA ja CERT’i meeskondadele said seekordsest õppusest osa Elektrilevi, Kaitseministeeriumi, Kaitseväe, Linx Telecomi, SEB panga, Starmani, Telia ja meie ehk Zone Media eksperdid, kes konservatiivse hinnangu kohaselt panustasid kokku vähemalt ühe inim-aasta jagu tööaega. Meie vaatest andis iga kulutatud päev vastu mitme tavalise tööpäeva jagu kogemust ning vähim, mida me teha saame, on õpitut edasi jagada.

Selleks paneme Andrisega kogetu järjejutuna kirja, püüdes vältida järgmistel õppustel väärtust omavate ülesannete täpsete lahenduskäikude lahtiseletamist, ent tuues välja laiemat rakendust omavad nipid ja selle, mida õppisime.

Veidi tausta

Meie mängu-võrk koosnes ligemale 150st seadmest ja oli mängu alguseks vägagi põhjalikult vastase ehk punase meeskonna poolt üle võetud.

Mängu-võrgus olid tulemüürid, avalikud ja sisekasutuseks mõeldud serverid, sadakond tööjaama erinevate operatsioonisüsteemidega, paar SCADA-lahendust (näiteks: kogu lennujaama elektrivarustus ja lennukikütuse tankimine), parasjagu lennus olev droon ning kõrged pealikud, kes tahavad näha liikuvat pilti ja saada 2x päevas raportit toimuva kohta. Lisaks tähelepanu nõudev meedia ja fake news, strateegiline kommunikatsioon ja juriidiline nõustamine… ning kõige tipuks reaalsed ja simuleeritud tavakasutajad, kellega meil oli 15-minutiline SLA (teenustasemeleping) ehk mistahes neid häiriv probleem, sealhulgas kaitsemeetmest tingitu, pidi saama selle aja jooksul mitte ainult vastatud, vaid ka lahendatud.

Kahepäevane õppus … mis kestis kaks nädalat

Eesti meeskonna kokku pannud CERT-EE (ametlikult tuntud kui Riigi Infosüsteemi Ameti intsidentide käsitlemise osakond) jaoks oluliselt kauem, aga ülejäänutele nägi ametlik ajaplaan välja selline:

  • Nädal enne õppust teisipäeva hommikust kolmapäeva õhtuni saame ligipääsu mängu-võrgule ning võimaluse kaardistada kõik puhastamist vajav ning katsetada oma kaitselahendusi (teades, et ükski meie tehtud muudatus ei jää kehtima, sest süsteemid viiakse algseisu… ja korraldajad võivad enne õppust omapoolseid muutusi teha)
  • Õppuse nädala teisipäeval ehk 0-päeval saame “üheksast viieni” näha lõplikku mängu-võrku ning katsetada oma lahenduste kiiret paigaldamist, sest…
  • Kolmapäeva ehk esimese päeva hommikuks on kõik uuesti algseisus ja meil tuleb esimese 30 minutiga ehk enne kui ründed peale hakkavad see ära lappida, mäng ise kestab tööpäeva lõpuni, siis on õnneks timeout …
  • … kuni neljapäeva hommikuni, mil kõik läheb uue hooga lahti teadmises, et iga tunniga muutuvad punaste ründed julmemaks ja sa ootad kell viis saabuvat lõppu rohkem, kui mistahes tavalisel tööpäeval.

Ja see on muidugi vaid ametlik ajakava – tegelikult läksid paljudel mängu ka ööd ja nädalavahetused ning isegi kui sa parasjagu ei tegelenud oma vastutusalas oleva süsteemi putitamisega, siis nägid sa sellest vähemalt und.

Väga konservatiivselt paneks ma kirja kaks täispikka töönädalat – korrutades selle 23 osalejaga saame tulemuseks umbes ühe inim-aasta.

Respekt siinkohal kõigile asutustele ja ettevõtetele, kes oma töötajate aega Eesti tiimi panustasid. See oli meile kaks nädalat väga pingelist koolitust, millega võrreldes tavamõistes väga vinged hands-on-hacking koolitused on nagu jalutuskäik rannapromenaadil koos tüdruk- (või poiss-)sõbra ja jaheda rosèga. Raha eest sellist asja ei osta.

Kas kõik tiimid olid niimoodi kokku toodud?

Ei, iga sinine ehk kaitsev meeskond sai VPN-seadme, mis võimaldas mängu-võrguga liitumist neile sobilikust kohast. Meie jaoks sobisid väga hästi RIA kontori ühendatud nõupidamisteruumid-õppeklassid.

Korraldav meeskond – rohelised (infra ehitajad ja tehniline tugi), valged (mängujuhid, rollimängijad nagu tavakasutajad ja ajakirjanikud, hindajad jne), kollased (situational awareness ehk hindasid suutlikkust toimuvast õigesti aru saad) ning punased (ründajad) asusid aga ühes Tallinna konverentsikeskuses, mille sisevaadet näeb õppuse korraldaja NATO CCD COE ametlikust pildigaleriist Flickris (sealt on lingitud ka pildid). Kõik need tiimid koosnesid osalevate maade lähetatud ekspertidest.

Sealtsamast on pärit ka näiteks selline huvitav pilt:

Selline võrguskeem oli teil olemas – või pidite ise kõik välja nuhkima?

Olemas. Selle väikse vahega, et pildil on suur sõjasaladus ehk see on “not for blue eyes” versioon, kus on peal ka mõned täielikult punaste kontrolli all olnud süsteemid lennujaama toitesüsteemi ja droonijuhtimise võrgu segmentides, mis tõesti tuli ise avastada.

Kokku oli meie süsteemide tabelis üle 50 nimetuse, seejuures erinevatel operatsioonisüsteemidel põhinevaid tööjaamu kümnete kaupa, kokku ligemale 150 ühikut.

Lihtsustatud pilt kübermänguplatsist on aga selline:

Üsna tavapärane mitme segmendiga võrk, kus eraldi “demilitariseeritud tsoonis” ehk DMZis on kõik avalikud veebi- ja postiserverid, eraldi OPSis lennuvälja juhtimine serverite ja tööjaamadega, LABis kõik R&D tegevus… sealhulgas üks eksperimentaalne veebileht ja kurat-teab-kelle-poolt paigaldatud DSL ühendus. Lisaks kenasti eraldatuna ICS lennukitesse kütuse pumpamiseks, PWR elektitoite halduseks ja GDT droonide lennutamiseks. Kaks ruuterit tõrkekindlaks ühenduseks kahe eraldi ISPga – ja kolm tulemüüri, üks neist MicroTIK (eelmine aasta olla ühe tulemüüriga liiga igav olnud, ilmselt punastel).

Vastavalt vajadusele oli jagatud sise- ja välisvõrgu-aadresse (nii IPv4 kui IPv6) ning lisaks oli igal seadmel eraldi aadress haldusvõrgus, mille kaudu käisime tööd tegemas meie. Nagu videost näha, siis igaüks oma läpakaga ja kahe suure government grade monitoriga.

Kui realistlik see olukord tundus?

Sinu ja minu võrgus on mõistagi kõik tip-top korras 24/7/365…

Aga kui meid kõrvale jätta, siis üsna realistlik. Iga võrk peegeldab organisatsiooni vanust, arengut ja aja jooksul tehtud otsuseid. On paratamatu, et kõrvuti toimetavad Windows 7, 8.1 ja 10 – õnneks päris NT4 Service Pack 1’ni asjad ei läinud, küll aga oli sinna-tänna sokutatud lahendusi, mida kohe kuidagi ei andnud turvalisena tunduva versioonini uuendada, sest nende peal jooksvad rakendused läksid lihtsalt katki. Life is hard – and then you die.

Lisaks olid kõik süsteemid punaste poolt hoole ja armastusega – sügav respekt nende põhjalikkusele – ära ussitatud. Oli äärmiselt põnev otsida, avastada ja proovida mõista kavandatud ründevektorit ning mõelda välja teostatavaid ja võimalusel ettearvamatuid kaitseviise. Nii teadaolev kui ainult selleks õppuseks loodud pahavara, rootkit’id, muutmata vaikeparoolid, juurkasutaja õigustes veebirakendused, turvaprobleeme loovad seadistused, kellegi poolt CRONi unustatud käsurida ja kompilaatorid serverites, kus neid teps mitte vedelema ei peaks. Ehk siis süsteemi haldamisel tehtud vead + vastane, kes on nende kaudu sisse tunginud ja ennast korralikult sisse kaevanud.

Meie ainsaks lohutuseks oli teadmine, et oleme appi kutsutud rapid response team, kes ei ole masendavas olukorras vähemalt ise süüdi. Me lihtsalt peame sellest aastatega kogunenud kultuurikihist minimaalse ajaga probleemid üles leidma.

Mida hinnati – ja kas punased kah punkte said?

Meie lõppskoor nägi välja selline, üleval summa ja selle all juppideks jagatuna:

  • Attack – miinused õnnestunud rünnete eest
  • Availability – süsteemide kättesaadavus hindamisrobotitele (algsest punktihulgast tiksusid punktid maha, nt kui veeb ei olnud IPv4 või IPv6 võrgust kättesaadav või Selenium-test ei leidnud lehelt elementi mida otsis)
  • Inject – mängujuhtide poolt ette sokutatud tegevused, nt ajakirjaniku kiri või juriidilise abi vajadus
  • Report – 2x päevas tehtav sitrep “riiklikule kaitsekomiteele”
  • Revert – roheliste abi vajamine, peamiselt täielikult üle võetud virtuaalmasinate viimine algolekusse
  • Special – kategoriseerimata miinused tegevuste (või tegevusetuste) eest, mis mujale ei mahu
  • Usability – kasutatavus ehk sa ei saa oma kasutajatel kraane nii kinni keerata, et nad oma äärmiselt turvalises keskkonnas enam mõnuga tööd teha (sh epostis olevaid linke klikkida ja manuseid avada) ei saa, sest kohe hakkavad miinused jooksma

Tegemist siis tasakaalustava süsteemiga kus igal otsusel on hind – ning osad skaalad nagu availability logaritmilised, ehk mida kõrgemal punktitasemel oled seda suurem väärtus on igal uptime’i lisaminutil.

Punased tegutsesid ühe meeskonnana ja punkte ei teeninud (ega kaotanud) – küll oli neil ees pikk nimekiri rünnetest mis tuli läbi viia, võrdselt kõigi siniste tiimide vastu. Aga ka rünnete skaalat võiks lugeda logaritmiliseks, st olid eesliinihäkkerid kes lammutasid nii kaugele kui suutsid, kui sinised neid sisse lasta ei tahtnud oli olemas ka “teise taseme tugiüksus” ning kui vaja, toodi tagatoast välja raskekahurvägi kuni clientside-rünneteks kasutatava Cobalt Strike’i autori Raphael Mudge ehk Raffini välja.

Mis me siis ikkagi täpselt tegime?

Kogu meeskond pidi katma ära rollid alates võrgust, Win ja Linux platvormidest, automaatikast ja logianalüüsist kuni juhtimise, juristide ja strateegilise kommunikatsioonini. Minu ja Andrise nurk olid veebid.

Ja kuigi veebe oli tegelikult hulgim – sh RoudCube veebimeil koos nurka ununenud iidse SquirrelMailiga, MediaWiki mõnede indutseeritud turvaprobleemidega jpm – siis peamiseks huvitavaks sihtmärgiks oli “scheduler” ehk avalikkusele mõeldud droonilendude registreerimise süsteem, mille saime kätte 0-päeval ja mis nägi välja nagu tundegitest programmeerijate grupitöö ainsa eesmärgiga funktsionaalsuse teostatuse pealt arvestus kirja saada. Nagu ilmnes oli see mulje veidi petlik, sest turvaprobleemide õpikunäidete taha oli sokutatud väga huvitavat kraami. Seda kaitses Andris ja järgmises osas võtabki ta nähtu tehnilisest vaatest kokku ja räägib sellest, mida tegi kaitseks.

Avalik veeb oli WordPress ja väidetavasti oli selle peamine roll kontrollida, kas kaitsjad üldse midagi uuendada ja paigata viitsivad – aga loomulikult oli seal sees ka kavalamaid auke, ainult pahavarast koosnevaid pluginaid ja iganenud komponente, millest paigatud versiooni polnud mõtetki otsida. Selle sain endale mina.

Ja siis oli veel üks päris custom veeb ehk pood – Tomcat’i peal jooksev Java-rakendus millest meil sortsu põld… küll aga olid punased näinud vaeva, et selle kaitsmine liiga lihtne ei oleks ja osa funktsionaalsust mh websocketite peale viinud. See saab olema neljas järjejutt, kah minult.

Et neid osasid mitte maha magada… võib meldida ennast meie FB-kanalile või Twitterisse. Või panna monitori peale kleepsu ning käia blogi kontrollimas.

Järjejutu kõik osad:

Tõestisündinud lugu e-posti võltsimise tõttu kaotatud rahast

Lahkame keerukat ent elulist e-posti võltsimise juhtumit, mis lõppes kannataja jaoks märkimisväärse rahalise kahjuga. Soovitan seda analüüsi lugeda kõigil, kes e-posti teel arveid saadavad või vastu võtavad. Loetu võib säästa teid peavalust ja raskelt teenitud raha kaotamisest.

Esmalt kirjeldan meie tragöödia osapooled. Algses kirjavahetuses oli neid kolm: Eesti ettevõtja (Müüja), tema partner Hiinas (Tootja) ning klient Aasias (Ostja).

Osapoolte vaheline suhtlus käib kogu aeg e-posti teel ‘Reply To All’ meetodil ehk et iga järgmine kiri adresseeritakse kõigile kirja päises mainitud aadressidele. Algab kirjavahetus tavalisest ärisuhtlusest, lepitakse kokku mida ja kuhu saata, täpne transpordiviis ja muud taolist. Osalisi on lõpuks kirjavahetuse To (adressaat) ja Cc (koopia) ridadel palju.

Ühel hetkel jõutakse nii kaugele, et Eesti ettevõtjast Müüja koostab Ostjale ettemaksuarve, kus on loetletud kauba hind ning transpordikulu. Ostja saab arve kätte, maksab selle ära ja jääb kaupa ootama. Mida ei tule, on kaup. Kui Ostja pöördub lõpuks Müüja poole selgitusnõudega, saab ta vastuseks, et viimane pole raha näinud ja seetõttu kaupa väljastanud.

Mis Ostja rahaga juhtus?

Juhtus see, et meie kurbmängu neljandal osapoolel – Kurjategijal – oli õnnestunud üle võtta kas Müüja, Tootja või Ostja juures mõne kirjavahetuses osalenud inimese postkast. Kelle oma täpselt, ei ole teada ega antud kontekstis ka oluline. Mis järgnes, on aga šokeerivalt lihtne.

Kurjategija sättis ennast osapoolte kirjavahetuses vahemeheks, napsas Müüja poolt Ostjale teele pandud arve, muutis selle rekvisiidid ja saatis selle ise Ostjale edasi. Kuna muus osas oli arvega kõik korras ning see saabus eksisteeriva kirjalõime käigus, koos varasema kirjavahetuse koopiaga, mitte kahtlaselt eraldi, kandis klient tellimuse summa Kurjategija kontole.

Täpsemalt on arve väljastajaks märgitud küll ettevõte ise, kuid saaja pangakonto asub ühes Inglismaa ühistupangas ja kontoomaniku nimeks on märgitud keegi “Mr X”. Arve muu osa – arve read, maksmisele kuuluv summa, ettevõtte logo jne, olid muutmata ja ehtsad.

Kirjavahetuse analüüs

Vaatame nüüd täpsemalt, et kuidas sündmuste käik välja nägi.

Esimeste kirjade päised näevad välja nii (aadressid on siin ja edaspidi muudetud, ostja.tld tähistab kliendi domeeni, müüja.tld Eesti ettevõtte domeeni ja tootja.tld Hiina tehase domeeni, numbrid #1,#2,#3 jne. tähistavad erinevaid isikuid):

From: Ostja #1 <mailto:ostja_1@ostja.tld>
Date: 2016-10-07 12:26
To: Müüja <mailto:müüja_1@müüja.tld> ;
 Tootja #1 <mailto:tootja_1@tootja.tld>
CC: Ostja #2 <mailto:ostja_2@ostja.tld> ;
 Müüja #2 <mailto:müüja_2@müüja.tld> ;
 Müüja #3 <mailto:müüja_3@müüja.tld> ;
 Ostja #3 <mailto:ostja_3@ostja.tld> ;
 Ostja #4 <mailto:ostja_4@ostja.tld> ;
 Ostja #5 <mailto:ostja_5@ostja.tld>

Selliseid üsna paljude osapooltega kirju liigub kõikide osapoolte vahel palju. Muutuvad vaid aadresside asukohad kirja päises – kord on mõni aadress To, kord From real, vastavalt siis konkreetse kirja saatmisele.

Kirjade liikumise logides on kõik samuti korras ja seda senimaani, kuni saabub üks kummaline kliendipoolne kiri. Täpsemalt näeb logirida välja nii:

03:15:35 (2016-10-10) ... client=mout.gmx.com[74.208.4.200]
03:15:35 (2016-10-10) ... message-id=
 <trinity-...@3capp-mailcom-lxa16>
03:15:35 (2016-10-10) ... from mout.gmx.com[74.208.4.200];
 from=<ostja_1.ostja@mail.com>
 to=<müüja_1@müüja.tld>
 proto=ESMTP helo=<mout.gmx.com>
03:15:35 (2016-10-10) ... to=<müüja_2@müüja.tld>
03:15:35 (2016-10-10) ... to=<müüja_3@müüja.tld>

Nagu näha, on meiliteenusepakkuja GMX avanud ühenduse meie MX serverisse ning saadab Eesti ettevõttest Müüja kolmele esindajale kirja. Saajate näol on tegu siis nende aadressidega, mis asuvad kirja To ja Cc ridadel. Mis aga võiks kohe tähelepanu äratada on saatja aadress, mis varasemates kirjades on alati olnud kujul “ostja_1@ostja.tld”, aga nüüd on hoopis “ostja_1.ostja@mail.com”. Lisaks on teenusepakkujaks GMX, mitte kliendi senine tavapärane ISP.

See kiri sisaldab aga kogu eelnevat samas lõimes toimunud vestlust ja aadressiridadel on olemas kõik seotud osapooled, seega Müüjale midagi kahtlast selles ei tundu.

Samuti Cc real olnud Tootja esindaja vastab kirjale (ka tema ei märka midagi kahtlast) ja kogu vestlus käib edasi nagu tavaliselt. Samas kui vaadata edaspidise vestluse osapooli, siis on pilt drastiliselt muutunud.

Nimelt on selles kirjas Eesti e-posti aadressid ja Hiinas asuva Tootja aadress korrektsed, aga kõigi Kliendi esindajate aadressid, nii From kui Cc väljadel on muutunud kujule “ostja_N.ostja@mail.com”. Kuna kirjavahetus käib edasi ‘Reply To All’ meetodil, siis edaspidi jäävad kirjavahetuses kõikide kliendi esindajate aadresside asemel juba võltsitud @mail.com aadressid. Mitte keegi toimunud viga ei märka ja suhtlus käib endiselt edasi.

From: Ostja #1 <mailto:ostja_1.ostja@mail.com>
Date: 2016-10-11 14:56
To: Müüja #1 <mailto:müüja_1@müüja.tld>;
 Tootja #1 <mailto:tootja_1@tootja.tld>
CC: Ostja #2 <mailto:ostja_1.ostja@mail.com>;
 Müüja #2 <mailto:müüja_2@müüja.tld>;
 Müüja #3 <mailto:müüja_3@müüja.tld>;
 Ostja #3 <mailto:ostja_3.ostja@mail.com>;
 Ostja #4 <mailto:ostja_4.ostja@mail.com>;
 Ostja #5 <mailto:ostja_5.ostja@mail.com>

Kurjategija ei hoia mail.com aadressidele saadud kirju vaka all ja saadab laekunud kirjad ilusti Ostja aadressidele edasi, kuid ka seal on toimunud omad muudatused. Nendes kirjades, mis Ostjani jõuavad, on Ostja aadressid õiged, kuid muudetud on Müüja ja Tootja aadressid.

Kusjuures, löödud on üsna laia lauaga, sest Eesti inimeste domeeniks määrab Kurjategija @europe.com ja Hiina Tootja aadressis saab @asia.com.

From: Tootja #1 <mailto:tootja_1.tootja@asia.com>
Sent: ‎11-‎10-‎2016 12:38
To: Ostja #1 <mailto:ostja_1@ettevõte_1>;
 Müüja #1 <mailto:müüja_1.müüja@europe.com>
Cc: Ostja #2 <mailto:ostja_2@ostja.tld>;
 Müüja #2 <mailto:müüja_2.müüja@europe.com>;
 Müüja #3 <mailto:müüja_3.müüja@europe.com>;
 Ostja #3 <mailto:ostja_3@ostja.tld>;
 Ostja #5 <mailto:ostja_4@ostja.tld>;
 Ostja #5 <mailto:ostja_5@ostja.tld>

Vastuskirjades vahetatakse aadressid jälle teistpidi tagasi.
Sisuliselt võib öelda, et ründav pool hakkab proksiks Ostja, Müüja ja Tootja vahele teostades nö Man In the Middle rünnaku. Kirjad jõudsid kõik kohale, kuid seda läbi GMX serveri, kus ründaja omas kõiki vastavaid @mail.com, @europe.com ja @asia.com aadresse ja täielikku kontrolli kirjade sisu üle.

Ründaja eesmärk oli jõuda nii kaugele, et Eesti ettevõtja Müüja väljastaks Ostjale arve. Siis napsas ta selle vahelt, muutis ära ja edastas muudetud kujul Ostjale. Edasi polnudki muud teha, kui oodata rahalaeva laekumist.

Kes on tekkinud olukorras süüdi?

Kuna esimene võltskiri tuli Ostja poolelt, siis kahtlustaks, et Ostja postkast oli häkitud. Samas seda sajaprotsendilise kindlusega väita ei saa, sama hästi võis see ka ükskõik milline teine osapool olla, aadressaate käis tänu vestluse ‘Reply To All’ iseloomule kirjavahetusest läbi ju palju.

Samuti ei ole teada, et kuidas esimese võltskirja lõime istutamine täpselt käis. Kas see oli 100% võltsitud, st selle koostas ründaja ise või oli see kuidagi vahelt võetud, ehk selle kirjutas klient, kuid ründaja muutis seda enne kohale toimetamist endale sobivaks. On ka võimalik, et häkitud oli hoopis Hiina Tootja postkast ja IMAP’i kaudu vahetati seal Ostja poolt saadetud legitiimne kiri ära võltsingu vastu.

Igatahes on fakt, et ründajal oli ligipääs mõne osalise kirjakastile, sest ainult nii sai ta tekitada selle esimese võltsitud Reply kirja, mis sisaldas ka sama lõime eelnevate kirjade sisu. Konkreetset häkitud postkasti aga vähemalt meile kätte saadavate tõendite alusel siiski välja tuua ei saa.

Võib ju mõelda, et kui rumal saab keegi olla, kui maksab valele arvele nii palju raha. Kuid arvestada tuleb, et tegu oli rahvusvahelise äriga, kus eri pooled asusid maailma eri külgedel ning üksteise tavadest on raske aru saada. Lisaks, kuna kirjade ümbersuunamise ja arve väljastamise vahele jäi tervelt nädal aega Kurjategija vahendusel peetud meilivahetust, siis arve saamise hetkeks oli klient tarnijatega juba mitmeid kirju @mail.com ja @europe.com aadresside kaudu vahetanud, seega ei olnud need aadressid enam päris võõrad.

Mis järeldused sellest kõigest teha?

Konkreetsel juhul on kahju juba tehtud ning raske on uskuda, et jalutama läinud ülekannet enam tagasi pöörata saaks.

Selle konkreetse pettuse eest ei kaitse mitte ükski spämmi- ega viirusetõrje (ükski kiri ei olnud masspostitus ega sisaldanud viiruseid).

Kirjade võltsimise vastu võiks teoorias aidata SPF või DKIM reegel, aga kuna Kurjategija ei võltsinud aadresse, vaid vahetas need julmalt enda omade vastu, siis mingit hoiatust nende meetmete poolt ei oleks tekkinud.

E-posti klient võiks ju olla võimeline tuvastama, et adressaadid on lõime edenemise käigus vahetunud ja seda kuidagi ka hoiatuseks välja kuvada, kuid ka see kõlab lihtsamalt, kui tegelikult teostada saaks, nii et vähemalt praeguste võimaluste juures taolisi pettusi tehniliste vahendite abil ära hoida ei ole sisuliselt võimalik. Asja teeb raskemaks ka see, et paljud meilikliendid ei kuvagi üldse aadresse, vaid ainult saatjate nimesid.

Ainukene asi, mis oleks osapooli aidanud, oleks avaliku võtme krüptograafia kasutamine kirjade terviklikkuse ja autentsuse kontrollimiseks. Kui Eestis asuvate osapoolte vahel oleks selle teostamine ravuslikku PKI taristut kasutades lihtne, siis rahvusvaheliselt kahjuks veel nii ei ole.

Ainus mida kohe praegu teha saab, on olla ise tähelepanelikum. Ostja peab alati 100% veenduma, et saabunud arve peal on kõik korrektne ning viimase hetke muudatustesse arve numbris või muudes saaja atribuutides tuleb suhtuda äärmiselt skeptiliselt.

Müüja peab hoidma silmad lahti anomaaliate suhtes oma kirjavahetuses ning olulisi kirju saates mitte kasutada Reply või Reply To All nuppu, vaid alati kas aadressi käsitsi sisestades või kontakti valimisega aadressiraamatust.

Ühtlasi soovitame (eriti rahvusvalhelises!) äris mitte kasutada üldkasutatavaid e-posti identiteete nagu @hot.ee, @online.ee, @mail.com, @gmail.com ja suhtuda nende kirjavahetusse tekkimisse äärmise ettevaatlikkusega. Selliste aadresside kasutamisel on kirjavahetuse osapoole tuvastamine sisuliselt võimatu ja teise osapoole asemele hüppamine äärmiselt lihtne.

Usaldusväärses tippdomeenis ettevõtte enda nimele domeeni puhul on vähemalt mingitki abi registrite ja registripidajate tehtavast autententimistööst ning WHOIS protokollist.

Reply aadresside võltsimine on siiski ju niiöelda the ‘oldest trick in the book’, lihtsalt nüüd tehakse seda veelgi filigraansemalt kui varem.

Veebi turvalisusel on ka äriline mõõde

Sageli ei võeta veebiga seotud pahavarahoiatust tõsiselt – ah mis sealt ikka võtta on, kui mul Outlookis post käib võite veebiserverist spämmi saatmise lihtsalt kinni keerata. Aga tagajärjed võivad kesta kaua.

Willem De Grooti blogipostitus 5900 online stores found skimming (eestikeelne meediakaja: Mitmed tuntud Eesti veebipoed on nakatatud pahavaraga, mis varastavad sinu krediitkaardi andmed) on krediitkaardiandmeid kurjategijatele saatva pahavaraga nakatunud e-poodide nimekirja paari jõudsalt kahandanud: 5900st on pea 2000 tänaseks ära puhastatud.

Loodetavasti tekitas tuntud nimede nägemine ka paljudes teistes vajaduse oma veebid üle vaadata – kui ei, siis paneme aga hagu alla ja vaatame, kuidas pahavara mõjutab mitte ainult ettevõtte mainet, vaid kõiki neid netiturundusega seotud asju mille nimel me nii kõvasti pingutame. Ehk anname sellele loole ärilise mõõtme ning mõtleme lõpuks selle peale, mis võiks olla lahenduseks.

Kuna Timo Porval Lavii.ee‘st küsis meil Zones külas olles “aga mis siis ikkagi juhtub, kui veeb on nakatatud” – siis tegime koos ka ekspromt-videoloengu mis sai oluliselt pikem, kui allolev tekst.

Kõik järgnevad anonüümsed näited on muidu igati eeskujulike Eesti ettevõtete veebidest – aga neid ühendab mingil hetkel uuendamata jäänud veebitarkvara ning pahavara, mis saadab rämpsposti, avaldab otsimootori-spämmi ehk peidetud linke või suunab kasutajad edasi saitidele, mis tegelevad nende arvutite nakatamisega.

Veebiserver saadab spämmi

See on sageli esimene töö, mis pahavaraga veebisaidile antakse – lisatud programmijupp saab perioodiliselt pöördumisi, mille sisuks on saatmist vajav rämpspost ja selle saajate nimekiri. Kui lasta sellisel saatmisel mõnda aega toimuda, siis hakkavad juhtuma järgmised asjad:

  • suuremad postiteenused nagu Gmail tuvastavad spämmi saatva IP-aadressi ja domeeni ning hakkavad nende pealt saabuvat e-posti tagasi põrgatama
  • varem või hiljem märkavat saatjat ka SpamCom, SpamHaus jt ning lisavad need ka oma musta nimekirja – ning nende teenust kasutavad juba paljud väiksemad postiteenused

Need piirangud puudutavad mõistagi mitte ainult spämmi, vaid kõiki kirju mida veebiserver saadab: e-poe tellimused, kontaktivormide teavitused, parooli-muutmise ja uue kasutaja registreerimise kirjad jne.

Aga see ei ole veel kõik: kui oled varem selleks, et vajalik post ikka Gmaili kohale läheks lisanud oma domeenile SPF- ja DKIM kirjed mis näitavad, et sellest serverist võib sinu nimel kirju saata… siis on postiteenustele võimalik märkida su domeeni reputatsiooniks “spämmer”, sest väljunud kirjad on ju varustatud domeeni digitempliga.

Google Postmaster Tools
Ühe spämmi saatva pahavaraga e-poe Google Postmaster Tools graafik – 13. oktoobri keskpäeval eemaldati sealt Nimbusec’i abil tuvastatud failid, tänaseks on graafik nullis ehk rohkem sealt spämmi ei saadeta, küll aga läheb aega, kuniks selle domeeni posti enam spämmiks ei loeta.

Nüüd ei ole see sinu jaoks enam tehniline, vaid äriline probleem.

Meie jaoks on mure aga laiem: kui kasutad virtuaalserverit, mille puhul sama IP-d jagab suurem hulk kliente, siis mõjutab IP sattumine musta nimekirja ka kõiki ülejäänuid. Selle vältimiseks on ka meil omad filtrid, mis märkavad spämmi ja keelavad sinu serveril saatmise. See on “hädatapp”, mis loodetavasti aitab vältida suuremat kahju ka sinu domeenile. Aga need kontaktivormid ja tellimused… ei lähe ikkagi kuhugi.

Veebiserver osaleb otsimootori-spämmis

Kui kirjade saatmine on blokeeritud tuleb kurjategijatel sellele uus rakendus leida. Üks võimalus on sokutada lehtedele linke nende poolt reklaamitavatele teenustele – harilikult on nendeks “kanada apteegid”, eskort-teenused ja muu hämaramat sorti äri. Pahavara on seejuures piisavalt nutikas, et kuvada neid linke vaid otsimootoritele, sest igaühele nähtav link oleks märk sissetungist ja võiks viia saidi puhastamiseni.

Sinu jaoks on ka sellel probleemil selge hind – nimelt jälgivad otsimootorid nii sisenevaid kui väljuvaid linke ning proovivad selle alusel ennustada, kas sisu vastab sinu äriga seotud sõnu otsivate kasutajate soovile. Nii võib juhtuda, et vaatamata pingutustele satud ürtidega rikastatud käsitöö-seebi kategooriast kahtlaste taimsete toidulisandite alla ning kaotad vaevarikka SEO-tööga otsimootorites saavutatud positsiooni.

Seda muidugi vaid juhul, kui otsimootor ei märka spämm-linke. Kui märkab, siis määratakse saidile karistus – pagerank tõmmatakse alla ja positsioon … koos sellega. Kui oled seadistanud Google Search Console, siis tuleb selle kohta loodetavasti ka teavitus. Kui ei, siis võid nädalate kaupa analüütikat vaadata ja imestada, et kuhu küll need külastajad järsku kadusid.

Webmaster Tools - hidden links
Google on tuvastanud peidetud lingid ühe majutusasutuse veebis. Pilt ajast, kui täna Google Search Console nime kandev tööriist oli veel Webmaster Tools. Sarnaseid tööriistu on ka teistel, näiteks Bing Webmaster Tools.

Veebiserver jagab pahavara

Post ei toimi, otsimootori-positsiooniga on kah kehvasti – aga kas saab ka hullemaks minna? Ikka! Sellist veebi saab endiselt ära kasutada külastajatele pahavara jagamiseks või kasutaja-andmete õngitsemiseks. Nime järgi tuleb mingi hulk külastajad ikka kohale, aga võib ka kuhugi peita ühe Gmaili avalehega sarnaneva võlts-logini ning spämmi abil külastajad kohale meelitada.

See on juba karmim kuritegevus ja vastavaid lehti proovivad leida erinevad turva-ettevõtted, aga ka Google’i otsimootori indekseerija. Sa näed vaeva, et Google sind külastaks – ja esimese asjana kaevab ta uksemati alt välja laiba ja teatab sellest kõigile.

Google Safe Browsing
Chrome kuvab pahavara sisaldavat saiti külastavale kasutajale hoiatust. Oma v või konkurendi – saidi olekut saab kontrollida Google Safe Browsing lehel, mitmest nimekirjast otsimiseks on hea kasutada VirusTotal’it. Kui saidiga on seotud mõne otsimootori webmaster tools, siis leiab sealt täpsema selgituse ja e-postile tuleb ka automaatne teavitus.

Kui sait ära puhastada ja Google’i Search Console’is paluda tulemus üle vaadata, siis reeglina saab 72 tunniga hirmsa punase palaka maha ja äri uuesti käima.

Aga võib ka minna hullemini – kui piisavalt kiiresti ei reageeri, võivad jaole jõuda ka teised musta-nimekirja-pidajad ning kõigi nende avastamine ja ükshaaval teavitamine on päris mahukas töö.

Kevadel aitasin ühte klienti (saidi puhtus käsitsi üle kontrollitud) ning tulemus oli selline:

  • sait puhastatud märtsi algul, kõik korras, Google toimib
  • 16. märts teatab külastaja, bing.com otsimootor hoiatab pahavara eest; vaatamata korduvatele katsetele õnnestub sealne review alles pärast jaanipäeva (Bing ühtegi näidet pahavarast ei paku)
  • 30. märts teatab teine külastaja, et tema antiviirus/tulemüür keelab mõnede alamlehtede külastamise – ja sellest süsteemist tulebki lehti ükshaaval eemaldada, fortiguard.com nimekirja kõigist nende meelest probleemsetest URLidest ei paku ja abi saame vist ainult tänu maaletoojale (aprilli keskel)
  • 28. augustil tuleb teade Kaspersky’lt, et nüüd on nemad kah selle kevadise probleemi avastanud ja asuvad blokeerima, me ei leia esimesel katsel isegi kohta kust seda eemaldada – ning kohale kust lõpuks teatame ei järgne Kaspersky poolt mingit tegevust

Pool aastat on möödas ja sõltuvalt kasutatavast otsimootorist, viirusetõrjest või tulemüürist satuvad kliendid endiselt teate otsa, et sait on ohtlik.

Olgu öeldud, et algne nakatamine toimus pool aastat enne märtsikuist avastamist. Nakatati sait kahe nädala jooksul, mil ta polnud isegi veel avalik ja asus veebis alamkataloogis /uus. Ilmselt oli vana veeb pahavara täis ja selle “operaatorid” märkasid kiiresti, et tulemas on uus versioon ning sellist võimalust ei saa kasutamata jätta.

Aga see pole veel kõik – rünnak sinu firma vastu

Kuigi eelnev peaks andma juba piisavalt põhjust oma neti-turvalisus oluliseks ärihuviks tõsta, on mul pakkuda veel üks võimalus sinu veebi kurjasti ära kasutada ja sedapuhku on sihtmärgiks sinu firma, selle pangakonto, kliendinimekiri, sisevõrgus olevad andmed … ja kindlasti veel midagi, mis mulle hetkel pähe ei tule, küll aga mõnele kriminaalsele geeniusele.

Clarified Security Hands-on-Hacking turvakoolituste stsenaariumid põhinevad reaalsetel juhtumitel ja NATO Locked Shields küberõppusel vaenlase mängimise kogemustel ning algavad justnimelt ettevõtte veebilehe ülevõtmisest.

Nii saab kurjategija rahulikult, omas tempos profileerida veebiga tegeleva töötaja brauseri ning leida sobiliku turva-augu – aga võibolla pole seda isegi vaja, sest kui sisselogimise lehte veidi muuta saab kätte ka parooli, mida ta seal kasutab… ja võibolla ka mujal, näiteks e-postis.

Logides sisse postkasti näeb kirjavahetust ja kontakte – vahest saadaks raamatupidajale maksmiseks mõne arve või paluks enne palgapäeva avanssi, kandmisega “tuttava kontole, väga delikaatne teema, palun ära küsi”? Või faili, mis nakatab ta arvuti pahavaraga… sest kuigi “kummalisi kirju” ei avata ei kehti see reegel ju juhul, kui kolleeg saadab pisikeste parandustega versiooni Wordi dokumendist, mille olid talle ise tund tagasi saatnud.

Mis on siis lahendus?

Lahendus hakkab pihta hulk aega enne seda, kui mõni ülalkirjeldatud probleemidest endast märku annab.

Kui tellid veebilehe, siis tuleks kohe kokku leppida ka see, kes ja millise raha eest hakkab seda järgmistel aastatel hooldama – mõistlik on panna selleks kõrvale vähemalt ühe töötunni raha kuus (sõltuvalt tegijast vahemikus 35-75€+km, aga odavamate puhul tuleks ilmselt arvestada mitme tunniga) või mingi protsent veebitegemise hinnast (näiteks 10-20% aastas, nagu põhivara amortisatsioonil).

Ise tehes on raha raskem arvestada ja nokitsemise tunnid mööduvad kiiremini kui arvad – aga rehkendades jõuame me lõpuks ikka sarnaste numbriteni välja ja virtuaalserveri eest küsitav 4,80€+km on ilmselt kõige väiksem kulu, mis sul veebiga seoses kanda tuleb. Eriti kui arvestada, et keerulisem probleem nõuab abiväge ning sageli ei anna “tuttav itimees” oodatud tulemust, sest kuigi abivalmis (ja mis peamine – soodne) ei ole ta otseselt veebimeister ning kogemus nähtamatu vaenlasega võitlemiseks puudub.

Kui oled nõus natuke maksma – no ütleme, et teise 5€ kuus lisaks – siis pakuks sulle Voog’i, mille puhul on küll võimalused piiratumad, aga veeb on see-eest ehitatud üles nii, et keegi teine sinna koodi laadida ei saa. Välimust aitavad vajadusel tuunida nende partnerid, aga veeb püsib ise püsti ja ei vaja pidevat paikamist.

Majutades meie juures oma WordPress’i, Joomla!’t, Durpal’it või Magentot saab need lisada (või juba algusest peale paigaldada) Zone+ haldusesse mis tagab pideva uuendamise ja turvatunde – ning lisada 2€+km eest kuus Nimbusec’i, mis skannib kord nädalas veebis olevad failid üle ja annab lootust, et leiad pahavara leiab üles enne Google’it.

Sealt edasi hakkab aga kallimaks minema – korralikum WordPressile keskendunud majutus algab 30€ kandist, Sucuri või CloudFlare “turvateenuste” odavam pakett on 15-20€ aga üldiselt ilmneb peagi, et selle eest saab vaid “basic security” mis mõeldud väiksemale blogijale.

Ja me oleme jälle tagasi selle “enamvähem 1 töötunni hind” juures. Võibolla on parem, kui selle saaks endale sinu veebimeister, ikkagi omakandi tegelane kes teab ja tunneb enda ehitatut?

Aga sama suurusjärk kehtib ka meie, Zone puhul – “töötunni eest kuus” saame lisada turvalahendusi, muuta WordPressi seaded turvalisemaks, pakkuda seadistusi tulemüürile ning tagada, et probleemi avastame meie ja helistame sulle, mitte vastupidi.

Sellist paketti meil hetkel avalikus hinnakirjas pole, sest tegu on väga eksklusiivse tootega. Aga kirjuta mulle peeter@zone.ee ja vaatame, mida teha annab 😉