7 asja mida TEGELIKULT teha tuleks, et hoiduda pahavarast (ja kurikuulus säuts)

Peeter Marvet
Jaga:

Antud blogipostitus on 92 kuud vana ning ei pruugi olla enam ajakohane.

Reede-hommik algas “pahavara-ründega”, mis juhtumisi tabas ka mind üsna isiklikult järgmise süüdistuse näol:

Tõepoolest – kui veebilehele on paigaldatud pahavara mis saadab spämmi, siis me kõigepealt blokeerime sellel e-posti saatmise ja palume omanikul oma veeb ära paigata.

Kui probleemi ei kõrvaldata, taipavad sissetungijad varsti, et seda veebilehte enam spämmiks kasutada ei saa ning talle antakse mõni muu karmim ülesanne – DDoS ründed, pahavara levitamine vms.

Kõik need tegevused on seadusega keelatud, õnneks vabastab Infoühiskonna teenuse seaduse §10 meid kui teenusepakkujat vastutusest, seda siiski ühe väikese lisatingimusega:

§ 10. Vastutuse piirang andmete talletamise teenuse osutamise korral
(1) Kui osutatakse teenust, mis seisneb teenuse kasutaja pakutava teabe talletamises, ei vastuta teenuse osutaja teenuse kasutaja taotluse põhjal talletatava teabe sisu eest järgmistel tingimustel:
1) teenuse osutaja ei tea teabe sisu ega ole kahju hüvitamise nõude puhul teadlik faktidest või asjaoludest, millest ilmneb ebaseaduslik tegevus või teave;
2) käesoleva lõike punktis 1 nimetatud asjaoludest teadlikuks saades kõrvaldab teenuse osutaja kohe vastava teabe või tõkestab sellele juurdepääsu

Meie ärimudel on pakkuda parimat ja turvalisimat veebimajutuse teenust, selle hulka kuulub hulk tavakasutajale nähtamatut tööd nagu serveriplatvormi pidev turvapaikamine ja monitooring, millega tegeleme 24/7.

Monitooringuga kaasneb paraku see, et me saame seaduses mainitet “nimetatud asjaoludest” teadlikuks. Lisaks, isegi kui meie ise ei märka, siis enamikul juhtudel tuleb peagi kuri kiri Riigi Infosüsteemi Ameti infoturbeintsidentide käsitlemise meeskonnalt CERT-EE (https://www.ria.ee/ee/cert.html), sest veebilehel tegutsevate kurikaelte pahateod on eskaleerunud veebikülastajate nakatamise või andmete õngitsemiseni.

Eelnev viib selleni, et oleme sunnitud ligipääsu veebilehele piirama, nagu viitab ka CERT-EE vastus Karile:

Säutsus viidatud Zone “ärimudel” seisnes selles, et soovitasime oma teavituskirjas (milles soovitame oma veebimeistriga suhelda) oma kasutajatele ka partneri Nimbusec monitooringuteenust ehk “veebilehe suitsuandurit”. (Selle käibemaksuta baashind algab muide 1.99€ juures ja kasumlikkust Zonele iseloomustab kolleeg Ardi sõnadega “rõõm riigile käibemaksu tasumisest”).

Jah, kui sul on probleem, siis tuleb seda tunnistada ning vajadusel abi küsida – või siis abi pakkuda, kui märkad kellegi teise probleemi.

Vaatamata teravale algusele pühendasin (küberaktivistina) inimõiguste kaitsele poole oma nädalavahetusest ja nende veebide puhastamise lugu kubiseb õppetundidest, mida peaksid arvestama nii tulundus- kui mittetulundusühingud – ja kõik, kes veebe teevad või hooldavad.

Ääremärkus – Palun ärge rohkem proovige mind sellise nipiga oma veebe puhastama panna. Aga kui abi vaja, siis võib alati info@zone.ee tellida kas probleemse veebi puhastamist või küsida tehnilist nõuannet.

Kui veebiarendajal või -agentuuril on soov oma inimesi (või kliente) harida turvalisuse või veebide puhastamise osas, siis võib küsida ka otse minult peeter@zone.ee – tulen, räägime olemasolevast, leiame uusi nippe, kontrollime tulemust.

Lühikokkuvõte toimunust

… on täpselt sama, mis 98% veebi turva-probleemide puhul (sh nende puhul, kus mina ise olen probleemi põhjustanud):

  • aastaid tagasi tehtud veebi sisuhaldustarkvara ja selle lisasid ei ole pidevalt uuendatud (turva-augu ärakasutamine algab sageli juba avastamise päeval);
  • osa kasutatud teemadest / pluginatest on tasulised ja ilma paigaldamata litsentsita või pärit allikatest, mis isegi ei võimalda lihtsat uuendamist;
  • lisasid on suurel hulgal – iga huvipakkuva funktsionaalsuse realiseerimiseks on lisatud mingi plugin, sageli üsna keerulise koodiga;
  • osa paigaldatud teemadest / pluginatest ei ole isegi kasutusel;
  • puudub hooldusleping veebimeistriga, kes võtaks enda peale vastutuse veebi turvalisuse tagamisel;
  • veebiarendus ja hooldus toimuvad otse serveris, sissetungi korral ei ole olemas puutumatut versiooni, mis võimaldaks serveris oleva kompromiteeritud koodi kustutamist ja uuendatuga asendamist
  • turvaintsidendi lahendamisel eeldatakse ekslikult, et veebi teeb korda mingi lisa-plugin või maagiline teenus

Lühikokkuvõte lihtsatest soovitustest

… on aga selline:

  • kui paigaldad ise veebitarkvara, siis taga uuendamine – meie Zone+ abil paigaldatud rakenduste puhul uuendatakse ka aktiivsed pluginad, kui oled lubanud automaatse uuendamise;
  • kui tellid veebi agentuurist/arendajalt, siis sõlmi ka vastutusega hooldusleping, mis tagaks vajalikud uuendused ja turvaintsidentide lahendamise; kui tellid veebi (riigi)hankega või projektirahadest, siis peaks ka hooldus sisalduma sõlmitavas lepingus;
  • kui otsustad ise lisada teema või pluginaid, siis kasuta tuntud autori tehtut mille puhul on näha perioodilisi uuendusi, WordPressi puhul kasuta wordpress.org pakutavaid, mitte mõnest veebist laetut;
  • harrasta kasinust – mida vähem lisasid ja lihtsam veeb, seda kiiremini see töötab ja seda kergem on turvalisusts tagada;
  • kustuta ära kõik tarbetu – vanad versioonid, kasutuseta teemad/pluginad, lahkunud töötajate kontod jne;
  • ükski turvalahendus ei tuvasta kõiki tagauksi – ainus variant on vahetada paigatud koodi vastu välja kõik kompromiteeritud serveris olnu ning puhastada üleslaetava meedia kataloog; selleks on oluline, et arendajal oleks oma arvutis olemas kindlalt puutumatu kood – mistahes veebiserveris “väike vigade parandamine” on välistatud
  • paroolid turvaliseks ja https – veebirakenduse parool olgu pikk ja unikaalne, et ei saaks proovimisega leida või mõnda lekkinud paroolibaasi kasutada; https-ühendus tagab, et parool ja küpsised ei ole pealtkuulatavad

Aga nüüd tehnilisemalt – ja algusest peale, nagu Agu Sihvka. Kui jutt liiga keeruline tundub, siis saada link oma veebimeistrile. Või pane keerulise koha peal silm kinni ja loe natuke altpoolt edasi.

Millal kõik algas?

Ammu. Täpset algust ja esimese ründe kohta on takkajärgi raske tuvastada – tõenäoliselt on seejärel tarkvara uuendatud, pahavara korduvalt eemaldatud ja uuesti paigaldatud. Võimalik, et kellegi poolt paigaldatud tagaukse on avastanud ja üle võtnud konkureeriv kollektiiv.

On ka võimalik, et veeb on üle võetud kasutades varasemat veebiversiooni – kevadest meenub juhtum, kus üks veeb võeti üle kahe nädala jooksul alates alamkataloogi “/uus” paigutamisest ehk enne, kui see üldse avalikuks kuulutati. Takkajärgi raske öelda, kas põhjuseks oli nõrga parooli kasutamine, uuendamata plugin uues või turvaauk vanas.

Ajalugu saab aga uurida logifaili abil, kui ei ole nende kättesaadavust virtuaalserveri haldusest sisse lülitanud võid alati küsida vajaliku perioodi kohta väljavõtte. Logid on üsna suured, nt humanrights.ee poole aasta omad lahtipakituna 979 megabaiti ning nendest olulise väljasõõlamine nõuab kogemust – Wordis neid faile ei ava. Enamasti kasutatakse käsurealt grep’i ja teades mõne kahtlase faili nime võib vaadata, millal selle poole on esimest korda pöördutud.

grep "POST /wp-content/plugins/Login-wall-" minulogifailinimi

Olgu siinkohal üks näitlik logikirje:

139.xxx.xx.xxx - - [10/Nov/2015:06:30:27 +0200] "POST /wp-content/plugins/Login-wall-etgFB/login_wall.php?login=cmd&z3=hwbXlucGazGU&z4=wLWNvbnbnQv2lucy8cGx1L3dRlZ%3d HTTP/1.1" 200 234 "[pole-oluline].ee" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Andris seletas äsja spämmi-saatmise näitel lahti, mida selline päring teha võib ja kuidas veebide ülevõtmine käib. Antud puhul märkasime, et keegi on WordPressile lisanud Login Wall võlts-plugina, täpsemalt kirjutab sellest Sucuri LoginWall Imposter Exposed. Kui ma suudan su veebi adminnina sisse logida, siis saan ma ka oma plugina paigaldada. Lisapunktid selle eest, et tegemist on näiliselt turva-pluginaga mis toimib pahavarana.

Juuni alguses on näha Hiina IP-sid, nende päringud näevad välja veidike teistmoodi ja mingit dua_test kataloogi serveris pole, sest .htaccess rea RewriteRule ^(.*)_(.*)/(.*).lskop$ index.php?site=$1&id=$3&temp=$2 [L] abil suunatakse päringud kuhu-vaja:

123.xx.xx.x - - [06/Jun/2016:10:57:02 +0300] "GET /dua_test/10001.lskop HTTP/1.1" 200 7244 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36"

Samal ajal madistavad veebi teises osas tegelased, kes kasutavad vaheldumisi Keenia, India ja Venemaa IPsid:

112.xxx.xx.xx - - [31/Jul/2016:06:10:03 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/admin-language-switcher.php HTTP/1.0" 200 189 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"

Kuna logid sisaldavad ka päris-veebiliiklust, otsimootorite roboteid ja turva-aukude otsimise päringuid, nõuab reaalsete ründajate leidmine parasjagu kogemust – alustada võiks näiteks POST-päringutest, seejärel võiks maha arvata oma IP ja kõik need arvukad katsed parooli ära arvata… Tasapisi müra eemaldades hakkavad sõelale jääma need, kes tegelikult serveri kallal möllavad.

POST päringuid, mis tavapäraselt on kasutusel sisselogimisel, veebisisu toimetamisel ja vormide saatmisel, on poole aasta jooksul logisse kogunenud 221 megabaiti, see on 22,5% kogu logist. Enamus sellest on sissetungikatsed või suhtlus paigaldatud pahavaraga.

Puhtalt aukude otsimine näeb aga logis välja selline – süstemaatiliselt proovitakse läbi kõikide teadaolevate turva-aukude asukohti, näiteks suvalisele failile ligipääsu lubavaid:

GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php
GET /wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php
GET /wp-content/plugins/db-backup/download.php?file=../../../wp-config.php
GET /wp-content/plugins/plugin-newsletter/preview.php?data=../../../../wp-config.php
GET /wp-content/plugins/simple-download-button-shortcode/simple-download-button_dl.php?file=../../../../wp-config.php
GET /wp-content/themes/trinity/lib/scripts/download.php?file=../../../../../wp-config.php

Mis meelde jätta: õpi logisid uurima, lülita sisse logide kättesaadavus või telli kasutajatoelt vajaliku perioodi logid.

Kustutame siis selle plugina või pahalase failid ära

Kõlab loogiliselt, eriti kui tunned parajasti suurt rõõmu esimese avastatud tagaukse üle. Paraku on häkker ilmselt paigaldanud hulga täiendavaid taga-uksi, mis lubavad funktsionaalse koodi kustutamisel uuesti üles laadida.

Kusagil monitooringus läheb punane tuli põlema ja “uus peremees” saadab hiljemalt järgmise vahetuse tehnikud riket kõrvaldama. Puhastatud veebi logidest on huvitav näha, kuidas tuleb päring ühe tagaukse pihta ja siis veel paar-kolm (javascripti jt veebikomponentide laadimine viitab sellele, et prooviti tavapärase veebibrauseriga minna PHP-shelli kasutama, aga saadi 404-veateatega leht):

94.xxx.xxx.xxx [18/May/2016:01:53:26 +0300] "GET /wp-content/plugins/w3-total-cache/configs/settings.php HTTP/1.1" 404
94.xxx.xxx.xxx [18/May/2016:01:53:27 +0300] "GET /wp-includes/js/wp-emoji-release.min.js?ver=1.0.5 HTTP/1.1" 200
...
94.xxx.xxx.xxx [18/May/2016:01:53:55 +0300] "GET /wp-content/plugins/akismet/config.phtml HTTP/1.1" 404 10535 
94.xxx.xxx.xxx [18/May/2016:01:54:09 +0300] "GET /wp-content/themes/thematic/local.php HTTP/1.1" 404 10535

Seejärel sekkub kõrgema taseme spetsialist (või robot), käies üle täieliku nimekirja:

198.xx.xxx.xx [18/May/2016:01:54:14 +0300] "GET /wp-content/plugins/wpml-translation-management/menu/updater.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:15 +0300] "GET /wp-content/plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Storage/include.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:15 +0300] "GET /wp-content/plugins/w3-total-cache/lib/W3/Plugin/base.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:17 +0300] "GET /wp-content/plugins/akismet/config.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:17 +0300] "GET /wp-content/plugins/w3-total-cache/configs/settings.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:19 +0300] "GET /wp-admin/user/db.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:20 +0300] "GET /wp-content/plugins/wordpress-seo/inc/options/lib.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:20 +0300] "GET /wp-content/themes/thematic/local.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:21 +0300] "GET /wp-content/plugins/wpml-string-translation/inc/gettext/cache.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:22 +0300] "GET /wp-content/plugins/w3-total-cache/lib/Microsoft/WindowsAzure/Diagnostics/local.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:23 +0300] "GET /wp-includes/images/icon-pointer-flag.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:24 +0300] "GET /wp-content/plugins/gravityformsmailchimp/api/Mailchimp/db.phtml HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:24 +0300] "GET /wp-content/plugins/wordpress-seo/vendor/yoast/api-libs/google/service/config.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:25 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/term-taxonomy-menus/limits.php HTTP/1.1" 404 
198.xx.xxx.xx [18/May/2016:01:54:26 +0300] "GET /wp-content/plugins/sitepress-multilingual-cms/menu/users.php HTTP/1.1" 404

Kui oled kõik need augud kinni toppinud, tõmmatakse sait nimekirjast maha ja jätkatakse raha teenimist mujal. Enamasti aga on midagi ikka märkamata jäänud, mispeale teine pool ennast lihtsalt sügavamalt sisse kaevab.

Mis meelde jätta: kui tahad veebi puhtaks rookida, pead üles leidma absoluutselt kõik pahalased.

On ju Nimbusec, öelge mis failid ma pean ära kustutama

Kurinahkade poolt paigaldatu jaguneb laias laastus failihalduriteks millega saab serveris teha-mida-vaja, funktsionaalseks koodiks mis saadab spämmi/levitab pahavara/reklaamib imerohtusid, ja pisikesteks tagausteks mille kaudu saab tagasi sisse pugeda.

Esimesed kaks kategooriat on reeglina tuvastatavad – meie testide kohaselt on Nimbusec umbes sama hea kui Sucuri ning need mõlemad tuvastavad sama hästi, kui VirusTotal’is olevad enamvähem kõiki maailma antiviiruseid kokku (ühe Eesti meedias pidevalt veebide puhastamise teemal sõna võtva startupi tulemus on oluliselt nõrgem ning nende väidetaval “htaccess-tulemüüril” ei leidnud mina WordPressi kaitsmisega küll muud seost peale turundusteksti).

Tagaustega on keerulisem – need on sageli konkreetse ründaja poolkäsitöö, lisatud hulgale veebirakenduse osaks olevatele failidele ja maskeeritud. Väär-positiivsete tulemuste ehk täiesti tavapärase koodi peale hädakella löömise vältimiseks peab tundlikkus olema piisavalt madal, tasakaalu leidmine on keeruline ja nõuab pidevat sisendit. Kõik mis meie käsitsi leiame, laeme üles Nimbusec’i meeskonna shellray.com lahendusse (ja pärast togime neid, kui tuvastamine piisava kiirusega tööle ei hakka – aga olgu öeldud, et meie koostöö on igati viljakas).

Nimbusec – samuti mistahes teine pahavara-otsija või anti-viirus – on seega tõesti suitsuandur. Hakkab piiksuma, aga kuna tulekollete täpne iseloom, asukohad ja kustutamise strateegia on igal objektil erinev, siis võluvitsaga tegu ei ole.

Mis meelde jätta: suitsuandur, antiviirus ja turvalahendused näitavad, et sul on probleem. Puhastamiseks ei piisa ainult ettenäidatud vigade eemaldamisest – tuleb kogu veeb üksipulgi läbi käia.

Aga on ju turvapluginad, miks sa neid ei kasuta?

Pluginad-schmuginad… Sucuri‘st on kindlasti kasu, kui tellida neilt oma veebile website firewall teenus (maksab rohkem kui virtuaalserver) – ja suunata kogu oma veebiliiklus käima üle nende. Aga kui sa proovid nende veebist aru saada, mida täpselt teeb üks või teine toode, siis avastad ennast peagi turundustekstide keskel ringiratast käimas. Mis maksab veebi puhastamine? Kuidas erinevad firewall ja antivirus?

Sucuri Scanner WP plugin on mõnevõrra abiks, mh see osa mille rolliks on website hardening – aga ei tuvasta kindlasti kõiki auke ja võidki neid lappima jääda. Tulemuse saavutamiseks tuleks ikkagi teenus osta.

Wordfence on kah päris tubli, loetleb üles kõik riigid, kust rünnata proovitakse ja näitab värvilisi lipukesi. Leiab üles WordPressi kataloogides ja wordpress.org pealt laetud pluginates olevad pahalased. Võimalik, et oleks abiks, kui veebi veel ei ole üle võetud. Aga ei leia üles kõike seda, mida ma ülalpool esile toon. Jah, see oli ka humanrights.ee peal kasutusel, abi oli aga täpselt niipalju, et Kari oli käega löömas – seda asja ei saagi enam puhtaks, peame uue tegema.

Mis meelde jätta: suitsuandur, antiviirus ja turvalahendused näitavad, et sul on probleem. Puhastamiseks ei piisa ainult ettenäidatud vigade eemaldamisest – tuleb kogu veeb üksipulgi läbi käia.

No teeme siis need uuendused nüüd ära

Uuendades näiteks WordPressi asendatakse küll olemasolevad failid uute ja puhastega, aga nende kõrvale sokutatud kraam jääb alles. Rakenduse kood on küll lapitud, aga keda see morjendab kui sait on juba üle võetud.

Veidi parem lugu on pluginatega – uuendamisel toimub sisuliselt kustutamine+paigaldamine, aga see kehtib mõistagi vaid nende pluginate kohta, mille jaoks on uuendus olemas.

Kui tegemist on iidse pluginaga mida keegi enam uuendada ei plaani, oled selle alla laadinud mujalt kui wordpress.org plugina-kataloogist või on tegemist näiteks tasulise mitmekeelsus-plugina WPMLiga, millele veebitegijad tihti jätavad litsentsi paigaldamata… siis ei toimu mõistagi ka mingit uuendamist. Üks juhtimiskeskus elas aga nimelt WPMLis (ajalooline katalooginimi on sitepress-…):

changed-files

Nagu näha, oli hulk tagauksi ka teemades – nii uuendamata TwentyTen all kui ammu _s poolt välja vahetatud Tootlbox’is. Ja Simple Fields plugina autor teatab oma lehel, et selle projektiga on nüüd bye-bye…

Kuidas ma need augud siis leidsin? Tuima käsitööga – laadisin alla kogu veebi ning panin selle GIT versioonihaldusesse mis jälgib failide muutumist ja kuvab kenasti erinevusi. Seejärel hakkasin süstemaatiliselt kustutama ja asendama katalooge – kõigepealt WordPress ise, siis täpselt samad versioonid teemadest. Teemade allalaadimise-linkides sisaldub versiooninumber (nt https://downloads.wordpress.org/theme/twentyten.2.1.zip) ning seda muutes saab kätte täpselt sama, mis hetkel veebilehel.

Pluginatega on natuke lihtsam – Force Plugin Updates plugin lubab sundida peale kõikide pluginate uuendamise… aga mõistagi ei aita see vanemate WPMLide ja mujalt kui wordpress.org pealt allalaetud pluginate puhul. Kui neid vaja on – või peaks olema suur huvi lihtsalt kontrollida – tuleb need ükshaaval kokku korjata ja asendada. Minul on endise veebiarendajana lisaks WPML konto olemas, seal pääseb ligi mistahes versioonidele.

Vahemärkus: sellisteks katsetusteks tuleks pruukida virtuaalmasinas olevat veebiserverit või mõnel muul moel hoolitseda, et potentsiaalne pahavara uues ja huvitavas kohas rändama ei läheks.

Koodi võrreldes hakkas aga silma veel üks rida:

fixing-core

Nimelt on keegi teinud muudatuse plugina failides – ja kui kommentaari uskuda, läheb mingi asi sellepeale katki. WPML kirjutatud kenasti modulaarsena ja probleemi kõrvaldamiseks oleks võinud oma teema koodi lisada vastava remove_action käsu… aga seadpuhku siis sedapsi.

Õnneks hakkasin ma seepeale uurima, et miks on umbes 10 lehe, ühe vormi ja ühe annetus-nupuga veebil üldse toodete import. Ilmnes, et kunagi oli plaanitud oluliselt suuremat veebi – WooCommerce e-poe-plugin, seda toetav vinge kujundusteema ning kõik selle poolt soovitatud pluginad. Kokku 28 pluginat, millest vaja oli kaheksat.

Mitte-vajalike hulgas oli aga näiteks Ninja Forms, mis tänavu mais sisaldas näiteid praktiliselt kõigist turva-augu-liikidest sh suvaliste failide üleslaadimine (vaid SQLi oli üllatuslikult puudu). Miks? Sest ninjad olid ühiskonna hüvanguks pannud pluginaga kaasa ka versiooni 3 beeta-koodi.

Kõige käsitöörohkem on minu jaoks aga tasuliste teemade kasutamine – kõigepealt ei õnnestu harilikult leida kasutatud versiooni faili, kohandamine on tehtud mitte alam-teemana vaid teema enda faile muutes … ja ilmselt pole suuremat lootust saada tegijatelt litsentsikoodi või loginit, mis võimaldaks alla laadida värsket teemat.

Kuna ma usun inimeste headusesse, siis eeldan, et tegemist on mõne varasema kliendi jaoks päriselt ostetud teemaga mida GPL litsentsi tõttu võibki edasi jagada. Ja vahest on lihtsalt läbi saanud aastane toe-periood, mille käigus uuendusi sai laadida. Aga vingete ja kasutaja poolt tuunitavate teemadega käivad sageli kaasas ka vinged pluginad – nt Visual Composer või Slider Revolution – koos oma turva-aukudega, aga ilma iseseisvalt uuendamise võimaluseta.

Skeptiline pool minust nõuab sellise teema fail-haaval läbi kammimist, sest olen kohanud ka kahtlastest kohtadest allalaetud piraatversioone koos eelpaigaldatud pahavaraga. Rääkimata sellest, et suvaline mitteuuendatava teema fail on ideaalne koht oma pahavara peitmiseks.

Kuna eesmärk oli saada aru kellegi teise tehtud veebide loogikast, võtta kood üle oma arenduskeskkonda, leida pahalased ka mittekasutatud pluginates (et saaks politseile vajadusel näited saata), vaadata üle logid, eemaldada kõik mittevajalik, uuendanda pluginad ja PHP-versioon, viia kaks veebi üle HTTPS peale, kontrollida nende toimivust ning parandada tekkinud konfliktid, siis tiksus kokku umbes 16 tundi (sedapuhku vabahtlikku ja loodetavasti Maksuameti silmis ühiskasulikuks kvalifitseeruvat) tööd.

Miks nii kaua läks? Selline oli pilt hetkel, kui pool tööd oli tehtud ehk turvaprobleemid kõrvaldatud. Nüüd tuleks kõik see kaunidus uuesti tööle kah panna – vajadusel lappides kujundusteemat ja proovides aru saada sellest, kust tuleb parempoolse menüü tekst (vihje: ei tule menüüst) või esilehel olevad lingid:

deprecated

Mis meelde jätta: vähegi keerulisema veebi puhastamine nii, et see ka puhastatuks jääb, on töömahukas ettevõtmine.

Kas jääb nüüd pidama, annad garantii?

Kuna saidi ülevõtjal on omad ärihuvid – või tekitab käesolev tekst kelleski sportliku huvi – siis olen ma siinkohal ettevaatlik. Aga jälgime mängu – ning osa ajakulust sai pandud ka selle peale, et järgmine ülevõtmine võimalikult raske oleks. Mis ma selleks tegin?

  • versioonihaldus – kogu veebisaidi kood on GIT versioonihalduses, täpsemalt bitbucket.org teenuses; kõik edaspidised muudatused (mida teen mina või kesiganes tahab selle projekti üle võtta) on omavahel krüptograafiliselt seotud ning isegi kui keegi peaks suutma seal midagi muuta, siis on võimalik see tuvastada
  • deployment – repositooriumist veebiserverisse läheb kood kasutades deployhq.com teenust; kui ülevõtmine peaks korduma, siis ma saan mõne klikiga laadida üles puhta versiooni – ning siis tegeleda täpse sissemurdmiskoha tuvastamisega
  • Zone+ – mõlemad veebid on imporditud meie Installatroni-süsteemi, mis sunnib jõuga peale versiooniuuendused; sorry, kui midagi katki läheb seetõttu – vähemalt hoiame ära suurema jama
  • paroolid vahetatud – andmebaasiparoolid, WordPressi loginid jne (loodame, et kasutajad valivad endale turvalised paroolid)
  • https – kõik saidid kasutavad nüüd Let’s Encrypt sertifikaate ja turvalist https ühendust, vältimaks paroolide lekkimist ja kasutajate liikluse sisu jälgimist
  • veidike .htaccess-maagiat – väikeste nippidega saab piirata PHP-koodi käivitamise kohtades, kuhu on tavaks pahavara paigutada
  • jälgin logisid – sealt näeb loodetavasti varsti ära, kes millist tagaust otsima tuleb
  • veel mõned nipid – ega ma kõigest siin ei räägi kah, vahest hiljem kui tulemuses kindel olen 🙂

Küsimusi on? Lase käia! Küsi siinsamas või kirjuta peeter@zone.ee 🙂

Populaarsed postitused

CloudFest 2024: AI annab riistvarale uue hingamise

Ingmar Aasoja
Läinud nädalal istus Zone tiim lennukisse ja sööstis taaskord CloudFesti põnevasse maailma, et heita pilk veebimajutusteenuste arengusuundadele. Meie...

Zone+ WordPressi Assistent: kuidas AI abiga sekunditega veebileht luua

Jaanus Putting
See aeg on läbi, mil vajadus kodulehe järele tähendas telefoniraamatust või guuglist veebidisaineri kontaktide otsimist. Tõenäoliselt üks viimase...

Aegunud PHP on aegunud PHP

Hasso Tepper
Kui esimene tänapäevane PHP versioon 25 aastat tagasi avalikuks tehti, oli internet hoopis teistsugune. Nõudmised veebilehtedele olid tagasihoidlikud...

Zone Veebiakadeemia - kuidas end Internetis nähtavaks teha

blogi
Zone Veebiakadeemia uusima episoodiga hakkame tutvustama ägedaid Zone koostööpartnereid. Seekord on meil külas Nobel Digitali tootejuht ja partner...