Sivustot ovat jatkuvan liikennevirran alla silloinkin, kun aitoja kävijöitä ei ole. Varsinkin WordPress kerää liikennettä hunajapurkin lailla, mutta ei muut julkaisujärjestelmät, kuten vaikka Drupal tai Joomla, yhtään helpommalla pääse. Kun yhtälöön lisätään verkkokauppa, niin tulijoiden määrä vain kiihtyy. Kysessä on bottiliikenne. Erilaiset crawlerit ja spiderit käyvät indeksoimassa ja analysoimassa sisältöä omiin tarpeisiinsa. Kaupan päälle saadaan turvallisuusaukkoja metsästävät yritelmät sekä murtoja yrittävät. Sivustoa kuormittavasta liikenteestä on helposti yli 80 % muuta kuin ihmiskävijöitä. Ja sen maksaa tavalla tai toisella sivuston omistaja.

Hakukonerobotit, kuten vaikka Google tai Bing, ovat tuttuja ja haluttuja. Niiden crawlerit ryömivät pitkin ja poikin sivuja indeksoimassa sisältöä hakuosumia varten. Päinvastoin kuin luullaan, niin hakukoneet käyvät kuitenkin melkoisen harvoin ja viihtyvät paikalla hyvinkin lyhyen aikaa. Siksi webmasterista saattaa tuntua siltä. että sisältö ei meinaa millään päätyä hakutuloksiin.

Hakukoneliikenne saattaa kuitenkin olla suurta. Ongelma on vain siinä, että ne eivät auta suomalaista sivustoa saamaan kävijöitä ja näkyvyyttä. Kiinalaiset hakukoneet eivät piittaa mistään mitään ja ovat aika ajoin saaneet hyökyaalloillaan sivustoja polvilleen. Samaa harrastavat venäläiset hakubotit, eikä etelä-korealainenkaan yritelmä ole tuntematon. Jos kyseessä on globaali sivusto, jolla on paljon kiinalaisia ja venäläisiä käyttäjiä – muitakin kuin spämmättävien sähköpostiosoitteisen metsästäjiä – niin tilanne saattaa olla haluttukin. Useimmille ei ole.

Hakukoneet eivät kuitenkaan ole suurin liikennöitsijä. Suurin kuorma tulee sisältöä varastavista kävijöistä. Ne ovat erilaisten markkinointi- ja SEO-yritysten botteja, jotka etsivät hakusanoja ja muuta dataa nettimainontaa varten. Ne ovat pahimmillaan huomattavan röyhkeitä ja saattavat hidastaa sivuston toimintaa silminnähden. Ne hyödyntävät muiden tekemää sisältöä omassa liiketoiminnassa antamatta mitään vastineeksi.

Sivusto niiaa

Tyypillinen tarina menee niin, että sivusto alkaa keräämään kävijöitä samalla kun sisältöä alkaa tulemaan. Jossain vaiheessa kun kävijöitä on yli tuhannen päivässä, niin ihmiset alkavat valittamaan hidastelusta ja satunnaisista 500-virheistä sivuston kaatuessa hetkittäin. Tilanne korjataan siirtymällä isompaan, kalliimpaan ja tehokkaampaan webhotelliin. Koska potkua löytyy enemmän ja kävijämäärätkin nousevat jopa yli 2000 käyntiin päivässä, niin viimeistään silloin innostutaaan monetisoimaan sivusto.

Monetisointi tarkoittaa sisällön valjastamista rahan ansaitsemiseen. Yleisin tapa on alkaa näyttämään mainoksia, mutta osa saattaa jopa alkaa pyörittämään verkkokoulutuksia. Kauppa ainakin käynnistetään. Viritetään jopa sähköpostilista markkinointiin. Kaikki nuo kuormittavat lisää ja yhtä äkkiä ollaan samoissa ongelmissa kuin aiemmin: sivusto hidastelee ja kaatuilee yllättäen. WordPress-ylläpitäjä alkaa saamaan Jetpackiltä aika ajoin ilmoituksia miten sivusto on ollut joistain minuuteista hieman pidemmäksi aikaa saavuttamattomissa. Kaatumiset keskittyvät uuden sisällön julkaisuun, kun sisälle ryntää huimaavat 100 ihmistä yhtä aikaa.

Webmasteri on ihmeissään, koska tehokkaampaa webhotellia ei saa rahallakaan. On aika siirtyä virtuaaliserverien ihanaan maailmaan. Kun noin käy, niin kannattaa säästää aikaa ja rahaa suuntaamalla samantien DigitalOceanille.

Ongelma on siinä, että kun sivulla on 2000 kävijällä esimerkiksi 3000 sivulatausta, niin samaan aikaan bottiarmeija on tehnyt 10 000 sivulatausta. 100 yhtäaikaisen kävijän piikki tuntuu useimmille kovalta määrältä, mutta sitä vastaan on koko ajan 24/7 satakunta yrittäjää arvuuttelemassa WordPressin salasanoja, yrittämässä murtoa xmlrpc:n kautta tai muuten vaan kokeilemassa josko verkkokaupan rahaliikenteeseen pääsisi käsiksi. Toinen samanmoinen porukka kyselee kaikkia mahdollisia joskus ja kauan sitten olleita aukkoja tai että löytyisikö sivuston uumenista bitcoin-lompakkoa.

Määrät eivät ole keksittyjä, vaan toteutuneita omilla sivustoilla.

Tuohon on olemassa ratkaisu, kun alla on virtuaaliserveri: Varnish.

Enemmän kuin cache

Varnish on yksinkertaistettuna serverin muistissa toimiva koko palvelimen välimuisti. Koska mitään ei kirjoiteta kovalevylle ja webpalvelin antaa vain ensimmäisellä kerralla pyydetyn sivun ja seuraavat saavat saman sivun suoraan muistista, niin Varnish on nopea. Mutta jutun kärki on siinä, että koska koko liikenne kiertää Varnishin kautta, niin Varnish pystyy tekemään (lähes) mitä vaan, kunhan se liittyy sivuston liikenteeseen – ja bottien tunnistaminen liittyy.

Cache on Varnishin pääkäyttö, mutta siinä ohessa itse säädän sillä nippua muutakin asioita:

• suodatan tunnetut botit ja ohjaan niiden IP-osoitteet Fail2bannin estettäviksi
• estän yritykset päästää paikkoihin, jonne ei kuulu päästä ja samalla juoruan IP-osoitteet Fail2bannille
• teen ehdollisia uudelleenohjauksia

Varnish on helppo asentaa, mutta sen säätäminen omiin tarkoituksiin sopivaksi voi olla joskus hermoja raastavaa – varsinkin jos ei ole alan osaaja, kuten minä en ole. Mutta kannattaa muistaa, että jokainen työkalu vaatii opettelua. Pääset mahtavasti alkuun, kun kopioit vaikka minun käyttämäni asetukset ja sitten myöhemmin muokkaat niitä itsellesi sopiviksi. Minä en ole tehnyt mitään mullistavan ihmeellistä, vaan sovellan vain perusasioita. Voisi sanoa, että lasken kertolaskuja funktiolaskimella. Kyse on edelleenkin siitä, että Varnishin avulla saat sivustollesi

• nopeutta välimuistin kautta
• tehokkuutta, kun asioita tehdään vain hyödyllisiin tarkoituksiin
• turvallisuutta, kun ulko-ovi laitetaan lukkoon ja ikkunat säppiin

Varnish on itsessään ilmainen, mutta ympäristö ei ole. Jos sinulla on alle 1000 kävijää päivässä, etkä pyöritä WordPressiä ja verkkokauppaa raskaampaa, niin pysy webhotellissa ja ratko kuormaongelmat muulla tavoin. Saat estettyä botteja myös .htaccess-tiedostossa, vaikka se ei tehokas ratkaisu olekaan. ja esimerkiksi WP Rocket hoitaa WordPressissä välimuistina nopeutta lisää.

Kaikissa muissa tapauksissa ota Varnish käyttöön ja hyväksyt sen, että vanha fillari ei enää riitä ja tarvitaan järempää: se maksaa sinulle alkaen 20 euroa kuukaudessa. Itse hostaan muutamaa kohtuullisen liikennöityä WordPress-sivustoa, paria Woocommerce-verkkokauppaa, paria Moodle-verkkokurssiympäristöä sekä tarvittavat monitoroinnit sekä Matomoa käyttäjäseurantaan 40 euroa kuussa maksavalla virtuaaliserverillä.

Jos päätät antaa Varnishille mahdollisuuden, niin annan yhden vinkin: asenna eteen Nginx terminoimaan SSL. Backend voi olla Nginx tai Apache2, mutta Apache2 on helpompi. Tehoja ei kannata miettiä, koska cachen – oikeammin Varnish on reverse proxy — backend ei suuremmin tee mitään muuta kuin pyörittelee peukaloitaan. Nginxin etu on päättömän helppo tapa saada HTTP/2 käyttöön. Lisäksi mm. pahojen bottien tappajana Nginx on tehokkaampi kuin Apache2. Mutta käytät kumpaa tahansa, niin älä asenna Hitchiä – se ei todellakaan tee muuta kuin terminoi SSL:n, jolloin joudut tekemään aivan kaiken muun Varnishissa.

Botit kuriin

Voit käydä kurkkaamassa millaisilla asetuksilla olen säätänyt Varnishin toimimaan Nginxin ja Apachen välissä. Mutta otetaan sieltä esille ne tavat, joilla minä olen toteuttanut tuhmien bottin bannaamisen.

Tein erillisen bad-bots.vcl tiedoston, johon toin estettävien bottien käyttäjäagentit. Se täytyy tuoda default.vcl tiedostossa heti alussa, ennen backendin määrittelyä:

vcl 4.1;
...
# Bad Bad Robots
include "/etc/varnish/ext/bad-bot.vcl";
...
default backend...

Tiedoston muoto on yksinkertainen:

sub bad_bot_detection {
if (
      req.http.User-Agent ~ "360Spider"
   || req.http.User-Agent ~ "2345Explorer"
...
   ) {
      return(synth(666, "Forbidden Bot"));
   }
}

Kun keulassa olevalta Nginxiltä tulee Varnishille pyyntö (jonka se periaatteessa antaisi joko cachestään tai jatkaisi backendinä olevalle Apachelle, jossa virtual hostit ovat), niin se vilkaisee pyynnössä (request) olevaa http-headeria User-Agent ja jos sitä ei löydy kieltolistalta, niin sivun haku jatkuu. Jos user agent on kielletty, niin Varnish tekee itse virhesivun keksityllä virhekoodilla Error 666 Forbidden Bot.

Käytän keksittyä virhekoodia siksi, että se ei sekaantuisi mahdollisesti aidosta ja sinänsä viattomasta syystä tulevaan virheeseen. Fail2ban seuraa Nginxin lokia ja koodi 666 saa sen heräämään ja toisella yrittämällä IP-osoite bannataan.

if/elseif/else rakenteella saa sitten muutettua toimintaa sen mukaan miten user agentteja haluaa ryhmitellä. Minulla on eri tavat sen mukaan onko kyseessä

• paha botti
• tyhjä user agent
• hyödylliset botit
• monitorointi

Joukossa on myös yksi erikoistapaus: Googlebot-Image. Se kuuluu hyviksiin, vaikka ei robots.txt tiedostosta piittaakaan. Siinä on kuitenkin yksi vika. Se on liian utelias. Nimestään ja roolistaan huolimatta se ei tyydy pelkästään kuviin, vaan skannaa muutakin sisältöä. Kun kerta rajoitushommiin ruvettiin, niin sallitaan sille pelkästään kuvahakemistoihin pääsy. Jos urlissa on hakemistot uploads tai image, niin Googlebot-Image saa saapua. Jos ei, niin se saa Varnishin tekemän Error 403 Forbidden virheilmoituksen.

elseif (req.http.User-Agent ~ "Googlebot-Image") {
   if (!req.url ~ "/uploads/|/images/") {
      return(synth(403, "Forbidden"));
   }
   unset req.http.User-Agent;
}

Yksi asia on kuitenkin tehtävä, että mikään noista ylipäätään toimisi. Alirutiinia täytyy kutsua jossain sopivassa kohdassa vcl_recv osiota. Kohtuullisen alussa on hyvä, koska silloin ei tuhlata aikaa ja vaivaa pyyntöön, joka menee roskikseen:

call bad_bot_detection;

Turhat koputtelut

Varsinkin WordPressissä on koko ajan koputtelijoita, jotka kyselevät sinällään viattomasti readme– tai JS-tiedostoja. Yleensä etsitään lisäosia tai teemoja. Niistä on aina löytynyt joku haavoittuvuus tai aukko, jota haluttaisiin hyödyntää. Niistä ei sinällään ole haittaa, jos päivitykset ovat kunnossa, ja vielä vähemmän, jos moista lisäosaa tai teemaa ei ole edes asennettu. Mutta ne ovat ärsyttäviä ja ilmaantuvat 404-ilmoituksina näkyviin.

Moisiin yrityksiin voi suhtautua kolmella tavalla:

• ei piittaa ja poistaa näkyvistä turhat 404-ilmoitukset
• tekee niihin 410 redirectin, jolloin ne eivät enää näy 404-listoissa
• estää ne Varnishissa ja bannaa IP:t Fail2banin avulla

Minulla on periaatteellinen sotatila turhien koputtelijoiden kanssa, joten bannaan se mahdollisuuksien mukaan aina tavattaessa. Itse asiassa suurin osa moisia yrittelevistä on niin kädettömiä hackerin urallaan, että bannaus jopa onnistuu. Jos ne ohittaa, niin kuormitus kuitenkin pysyy, vaikka silmät onkin sulkenut. Yleensä sillä ei ole suurtakaan merkitystä, vaan on tärkeämpää tappaa turhat spiderit, mutta muutaman kerran olen saanut vastaani niin suuren aallon, että oltiin jo palvelunestohyökkäyksen (DDoS) kynnyksellä – viimeinen oli joulunpyhinä, jolloin kaikilla maailman script kiddieillä oli vapaa päivä. Aidossa DDoS-hyökkäyksessä työkaluni olisivat olleet vähäiset, mutta tuosta selvisin Varnishin ja Fail2bannin yhteistyöllä – taas yksi syy käyttää kumpaakin.

Tiedän, että koputtelijoiden ja kokeilijoiden jahtaaminen on hävitty taistelu, mutta saanpahan ainakin hidastettua niiden puuhailua.

Toteutin sen tismalleen samoin kuin bottien bannaamisenkin. Tein tiedoston 403.vcl, johon laitoin suljetut urlit:

sub stop_pages {
   if (
      req.url ~ "^/inject.phtml"
      || req.url ~ "^/index[0-9].php"
      || req.url ~ "^/infe/verify/mkcode"
      || req.url ~ "^/installation$"
      || req.url ~ "^/installer.php"
      || req.url ~ "^/installer-backup.php"
      ...
      ) {
         return(synth(666, "The site is frozen"));
      }
}

Käytän samaa synteettistä virhekoodia, mutta eri tekstillä. Teksti on osaksi siksi, että vain huvitti tehdä niin, mutta kun teen virheen ja bannaan jotain mitä ei kuuluisi, niin saan sillä nopeammin haarukoitua missä virhe sijaitsee.

Tuokin on ensin liitettävä default.vcl tiedoston alkuun:

# Stop knocking
include "/etc/varnish/ext/403.vcl";

Lisäksi sitä on kutsuttava ja sama paikka jossa bad botteja kutsutaan, oli minusta sopiva paikka:

call stop_pages;

Ehdollinen 404

Minulle alkoi jossain vaiheessa kertyä lisäosa- ja teemayrityksiä niin paljon, että tiedosto alkoi olla kopio WordPressin reposta (sinällään huolestuttavaa, jos niissä kaikissa on tosiaan ollut jossain vaiheessa sellainen haavoittuvuus, että sitä kannattaa metsästää). Tulin siihen tulokseen, että asiaan täytyy olla parempikin ratkaisu. Joku osaavampi olisi varmaan kyennyt tyylikkäämpään ratkaisuun, mutta itse tein sen ehdollisena error 404 säätönä.

sub vcl_backend_response {
...
if (beresp.status == 404 && 
   (bereq.url ~ "^/wp-admin/" 
    || bereq.url ~ "^/wp-content/themes" 
    || bereq.url ~ "^/wp-content/plugins" 
    || bereq.url ~ ".js")
) {
   set beresp.status = 666;
   set beresp.ttl = 86400s;
   return(deliver);
   }
...
}

Jos on yritetty urliin, joka alkaa wp-admin, wp-content/themes, wp-content/plugins tai on pyydetty mitä tahansa JS-tiedostoa, ja backendin Apache on todennut, että moisia ei ole eli antaa error 404, niin kysyjälle ilmoitetaan jo tutuksi tullut error 666 – josta seuraa IP-osoitteen bannaaminen Fail2banin avulla. Pyyntö pidetään 24 tuntia cachessä, niin seuraavien yrittäjien takia ei tarvitse heti Apachea vaivata uudestaan, vaan voidaan heti osoittaa ovea.

Tuo aiheuttaa logeihin 404 errorin, koska on täytynyt ensin kysyä, että onko moista lisäosaa, teemaa tai javascriptiä olemassa. Sitä ei pysty välttämään, mutta nyt tiedän, että kun poistan sen WordPressin 404-logeista, niin homma on silti hoidossa.

Lisäsäätöä

Laitoin samaan 403.vcl tiedostoon muitakin samantyyppisiä.

Osa boteista väärentää viittaavan sivuston spämmitarkoituksessa, jolloin headerissa oleva referer (kirjoitetaan aika usein väärin referrer) ei pidä paikkaansa. Ne ovat omalla tavallaan suurempi ongelma kuin ns. tavalliset botit, koska moisella tempulla voidaan onnistua tuhoamaan sivuston näkyvyys Googlessa ja hävittämään SEO-arvo. Niillä ei siis saa mitään viittaavan sivuston lisäarvoa, kuten osa luulee. Yksi syy lisää siihen miksi logeja on syytä seurata. Minulle niitä ei ole tullut kuin muutama:

if (
   req.http.Referer ~ "site.ru"
   || req.http.Referer ~ "www.google.com.hk"
   || req.http.Referer ~ "ivi-casinoz.ru"
   || req.http.Referer ~ "zvuqa.net"
   || req.http.Referer ~ "mp3for.pro"
   || req.http.Referer ~ "www.facebook.net/"
   ) {
      return(synth(666, "The site is frozen"));
      }

Edellä olevat ovat kaikki tuollaisenaan globaaleja asetuksia. Ne koskevat jokaista serverillä olevaa domainia. Jos sinulla on vain yksi sivusto, niin silloinhan asialla ei ole mitään merkitystä. Mutta joskus tulee tarve säätää asioita per domain ja siitä selvitään yhdellä if-lausekkeella:

if (req.http.host == "eksis.one" || req.http.host == "www.eksis.one") {
   if (
      req.url ~ "/adminer"
      || req.url ~ "^/vendor/"
      || req.http.User-Agent ~ "jetmon"
      || req.http.User-Agent ~ "Jetpack by WordPress.com"
   ) {
      return(synth(666, "Server is confused"));
      }
}

Minulla on yhden domainin takana Adminer asennettuna, jonka takia en voi estää sitä kokeilevia serveritasolla. Sama juttu vendor-hakemiston kanssa, koska se on yhdessä Woocommercessa. Jetpack ei luovu yrittämästä, vaikka se olisi poistettu, mutta koska eräs sivusto käyttää sitä, niin en voi estää kokonaan (aidosti niin kylläkin tapahtuu, koska kun Jetpack yrittää muita domaineja, niin se bannauttaa hissukseen koko käyttämänsä IP-avaruuden serverin palomuurille).

default.vcl tiukennukset

Teen muutaman muunkin hieman turvallisuutta parantavan asian default.vcl tiedostossa vcl_recv osiossa ennen kuin kutsun bad bottien ja suljettujen osoitteiden alirutiineja.

if (req.url ~ "^/robots.txt") {
   return(pass);
}

Päästän kaikki ne, jotka läpäisevät Nginxin (suodatan nykyään siellä botit, en Varnishissa) vapaasti lukemaan robots.txt tiedoston. Sinne pääsevät return(pass) komennon takia myös ne. jotka kuitenkin olisivat Varnishinkin estolistalla. Nyt voin vilkaista logeista ketkä ovat käyneet sitä kurkkaamassa ja saan samalla bannilistalle itselleni hyödyttömät botit. Minulle on itseasiassa aivan yhdentekevää tottelevatko ne robots.txt sääntöjä vai eivät, koska bannaan rutiinisti kaikki sinne saapuneet minulle tuntemattomat.

 

if (req.method == "GET|POST" && req.url ~ "^/xmlrpc.php" && !client.ip ~ whitelist) {
   return(synth(666, "Post not allowed for " + client.ip));
}

Kuka tahansa, joka kysyy xmlrpc.php tiedoston olemassaoloa tai yrittää lähettää sen kautta, eikä tule sallitusta IP-osoitteesta, saa virheen 666 ja IP-osoitteensa bannatuksi. Ainakin periaatteessa. Tämä ei aidosti tee yhtään mitään muuta kuin on varoiksi. Olen estänyt xmlrpc.php käytön jokaisen domainin vhostissa, Nginxissä ja Apachessa, joten niistä tulee suoraan error 403. Nginx kirjaa yritykset erilliseen logiin, josta Fail2ban tekee bannit.

Lopetin xmlrpc.php kokeilijoiden bannaamisen ja annan webserverin vain näyttää suljettua ovea, vaikka heillä onkin aina vain pahat mielessä. Syy on niin masentava, että yrityksiä tulee aivan tolkuttomia määriä. Minulla on ollut parhaimmillaan kymmeniä tuhansia IP-osoitteita bannattuna. Ei se serverin ja palomuurin toimintaan mitään vaikuta, mutta Fail2banniin vaikuttaa. Kaikki toimenpiteet, kuten käynnistämiset, sammuttamiset tai vahingossa bannattujen IP-osoitteiden vapauttamiset kestävät aivan päättömän kauan.

 

if (req.http.User-Agent ~ "curl/" && !client.ip ~ whitelist) {
   return(synth(666, "Forbidden Method"));
}

Tämä on vastaava omaa elämää helpottava säätö. Jos curl-komento ei tule sallitusta IP-osoitteesta, niin se estetään. Curl (kuten muutkin vastaavat kirjastot) on sinänsä melkoisen harmiton, eikä sillä saa tehtyä varsinaisesti mitään vahinkoa.  Sillä voi kylläkin selvittää löytyykö sivustolta jotain hyödynnettävää aukkoa ja koska tavallinen kulkija ei tarvitse curlia mihinkään vieraalla sivustolla, niin olen rajoittanut sitä.

Error 666 ja fail2ban

Fail2ban on oma ohjelmansa, mutta koska ohjaan Varnishissa pahat, rumat & turhat virheelle 666 Fail2bannin takia, niin toki se silloin liittyy Varnishiin ja bad botteihin oleellisesti. Viritys on perustasoa ja jos jo käytät Fail2bania, niin tässä ei ole mitään uutta sinulle.

jail.local

[varnish-666]
port = http,https
filter = varnish-666
logpath = /var/log/varnish/varnishncsa.log
maxretry = 1 findtime = 24h
bantime = -1
enabled = true

filter: varnish-666.conf

[Definition] 
failregex = ^<HOST>\, .*  - - .* "(GET|POST|HEAD).*HTTP.*" 666 .* .* .*$

ignoreregex =

Nginx

Jossain vaiheessa into bottien häätämisessä parivaljakolla Varnish ja Fail2ban hävisi hohto. Vaikka bottiryntäys ei  saa Varnishia huojumaan, niin ei niitä myöskään saa opetettua. Ne tulevat kerta toisensa jälkeen aivan riippumatta millaisen vastauksen ne sivustolta saavat. Aloin kallistua ajatukseen pysäyttää ne jo ulko-ovella ilman, että kiepautan ne pyöröoven kautta takaisin.

Nginx on mielenkiintoinen webpalvelin. Apache2 on paljon helpompi, mutta Nginx tarjoaa työkaluja, joita Apachessa ei ole, kuten että se voi toimia itsekin reverse proxynä. Tosin olen vakaasti sitä mieltä, että yhteen asiaan keskittyvä ratkaisu on aina parempi kuin jokin all-in-one, mutta Nginxin ”proxymaisuus” tuo mukaan yhden edun: sekin on kykenevä hoitamaan asiat muistissa. Apache taasen käy aina levyllä.

Minulla Nginx on koko ajan hoitanut vain muutamaa perustehtävää:

• hoitaa SSL:n
• mahdollistaa HTTP/2 yhteydet ulkomaailmaan
• tekee uudelleenohjaukset http:stä https:ään (portista 80 porttiin 443)
• tekee uudelleenohjaukset pelkästä domainista www:hen (example.com > www.example.com)

Nginx sai kuitenkin laajentaa hieman repertuaariaan ja nyt se tekee lisäksi kahta ekstrahommaa:

• pysäyttää botit heti ulko-ovella
• vahvistaa WordPressin turvallisuutta

Nähdäkö vaivaa?

Kun taistelee botteja vastaan, niin on oivallettava, että on koko ajan altavastaajana. Pahantahtoiset yrittäjät osaavat meikata yrityksensä piiloon paremmin ja ahneimmat SEO-roistot jopa myyvät palvelujaan kärjellä, että homma salataan kohdesivustoilta. Kyse on kahdesta asiasta:

• pidetään perusturvallisuus (serverin palomuuri, päivitykset, salasanat, tunnetut laajennokset) kunnossa, jolloin koputtelijat eivät pääse tekemään mitään
• määrä saa sivuston ja serverin hitaudesta polvilleen

Kun millä tahansa työkalulla estetään suurimman kuorman aiheuttavat botit ja crawlerit, niin ohivuodolla ei ole enää merkitystä toimivuuden kannalta. Erittäin huonomaineinen etelä-korealainen crawler Daum kävi eilen sivustolla 322 kertaa, keskimäärin viiden minuutin välein. Kun moinen estetään, niin on ihan se ja sama piipahtaako muutama verkosta livahtanut pikkukala sivustolla vai ei.

Toki sivustojen suurimmat pullonkaulat tulevat sivustojen omasta tekniikasta. Käytetään liikaa huonosti tehtyjä ja aidosti hyödyttömiä lisäosia (kuten vaikka Jetpackiä), teema on raskas ja pyörittää kehnoa page builderia ja webmaster työntää gigakokoiset valokuvansa suoraan kamerasta ja pienentää niitä tekstiin CSS:llä. Silloin CDN:n käyttö ei pelasta miltään (ei se useimmilla auta muutenkaan) ja on aivan sama paljonko botteja estää .htaccess-tiedostossa (joka tekniikkana on itsessään kuormittava, mutta muutakaan ei webhotelleissa ole).

Ongelma on kertymisessä. Kun webmaster on kasannut hidasteita toinen toisensa päälle, niin moinen sivusto ei kestä enää yhtään hidastuspomppua lisää. Silloin bottien estäminen on kriittistä. Jos on muutoin tehnyt kaikki (järkevät) toimenpiteet sivuston nopeuttamiselle, niin bottien estäminen ei sinällään anna silminnähtävää etua. Se etu tulee näkyviin siinä vaiheessa kun saa omalle julkaisulleen pöhinää ja yhtä äkkisen yleisöryntäyksen: jos iso osa uusista kävijöistä saa hitaan sivuston ja satunnaisia 500-erroreita jääden ainutlaatuisiksi vierailijoiksi vain sen takia, että tehot menevät SEO-robottien palveluun, niin mikä on sinun tekosyysi olla estämättä niitä?