Vieraskynä: Katsaus WordPress-sivustojen tietoturvaan

Vieraskyna

Mikko Virenius. Artikkelin kirjoittaja on yksi Suomen kokeneimmista WordPress-asiantuntijoista, joka on kehittänyt sivustoja WordPressillä päätoimisesti vuodesta 2008 lähtien.

WordPressin tietoturvaan kohdistuu säännöllisin väliajoin (joskus myös aiheellistakin) kritiikkiä ja sen maine yleisesti tietoturvan osalta on vähintäänkin kyseenalainen. Aihe nousee esiin lähes poikkeuksetta tapauksissa, kun WordPressiä suunnitellaan käytettävän jonkin hieman laajemman ja tiukempaa tietoturvaa vaativan palvelun alustana.

Wordpress_kaltereiden_takana

Yksi syy huonoon maineeseen on se, että WordPressin laaja suosio vetää puoleensa paljon automaattisia ja puoliautomaattisia hyökkäyksiä, joiden aiheuttamat vahingot saavat paljon huomiota. Viimeisin laajasti uutisoitu hyökkäys tapahtui heinäkuun lopussa.

Syy näiden automaattisten hyökkäysten onnistumiseen puolestaan ovat lukemattomat päivittämättömät ja valvomattomat WordPress-asennukset, joiden kautta päästään pahimmassa tapauksessa käsiksi myös jaetun webhotellin tai virtuaalipalvelimen muihinkin sivustoihin. Sen sijaan itselleni ei ole vielä tullut vastaan tapausta, jossa oikein konfiguroituun ja ylläpidettyyn WordPress-sivustoon olisi päästy tuosta noin vain murtamaan.

WordPressin puolustukseksi on sanottava että tietoturvaraporteissa puhutaan usein ”WordPressin haavoittuvuudesta”, vaikka lähes poikkeuksetta paikkaamattomat haavoittuvuudet löytyvät jostain kolmannen osapuolen toteuttamasta lisäosasta tai teemasta. Joitain onnistuneita WordPressiin kohdistuneita hyökkäyksiä on tehty myös vanhentuneiden palvelinohjelmistojen, kuten PHP:n, kautta.

Ajoittain suunnittelupalavereissa kuulee jopa kehotuksia WordPressin täydelliseen välttämiseen, mitä itse pidän tietoturvan toteutumisen kannalta hieman jopa vaarallisena ajattelumallina. Mielestäni on riskialtista tuudittaa itsensä ja asiakkaat väärään turvallisuudentunteeseen väittämällä jotain toista järjestelmää kategorisesti turvallisemmaksi ja siirtämällä näin vastuun tietoturvasta itseltä järjestelmän vastuulle.

Oman kokemukseni mukaan WordPressillä voidaan toteuttaa myös tiukempaa tietoturvaa vaativia palveluita, kunhan tietoturvaa muistetaan lähestyä kokonaisuutena ja huomioida kaikki tietoturvan osa-alueet, jotka olen tässä katsauksessa jakanut palvelintason-, sovellustason- ja käyttäjätason tietoturvaan. Toisin sanoen WordPressin tietoturvaan pätevät kaikki samat asiat, jotka pitää huomioida ylipäätään verkkopalveluita suunnitellessa.

Tämän katsauksen tarkoituksena ei ole antaa vaihe vaiheelta –tyyppistä ohjeistusta tai tarkkaa reseptiä tietoturvallisen WordPress-sivuston ylläpitämiseen, vaan hieman laajentaa kuvaa WordPress-sivustojen tietoturvasta, joka esitetään yleensä kasana erilaisia temppuja ja niksejä.

Palvelintason tietoturva

Turvallinen palvelin on verkkopalvelun tietoturvan perusta, oli verkkopalvelu toteutettu sitten WordPressillä tai millä tahansa muulla julkaisujärjestelmällä. Mikäli palvelintason tietoturva ei ole kunnossa, sovellustason tietoturvatoimenpiteet ovat kokonaisuuden kannalta kuin Titanicin kansituolien järjestelyä.

En missään nimessä vastusta esimerkiksi yksinkertaisen yrityssivuston asentamista hyvään webhotelliin, mutta tietoturvan kannalta vaativimmassa palveluissa, kuten verkkokaupoissa, oma palvelininfrastruktuuri joko ylläpidettynä tai omassa ylläpidossa on mielestäni ehdoton minimivaatimus.

Tosiasia kuitenkin on, että jaettu webhotelli kun on yhtä turvallinen kuin sen heikoin lenkki. Mikäli palvelin sisältää esimerkiksi 100 erillistä sivustoa, on hyvin todennäköistä, että joukossa on yksi tai useampia sivustoja, joiden sovellustason tietoturvasta ei ole huolehdittu riittävän tarkasti. Tämä puolestaan avaa huonosti konfiguroidulla palvelimella mahdollisesti pääsyn myös palvelimen muihin sivustoihin. Toki yleensä ei näin ole.

Kun valitsen palveluntarjoajaa itselle tiukempaa tietoturvaa vaativaa palvelua varten, pyrin varmistumaan ainakin seuraavien asioiden toteutumisesta.

Päivitykset. Käyttöjärjestelmän ja palvelinohjelmistojen päivitykset ovat ajan tasalla ja niistä huolehditaan säännöllisesti.

Varmuuskopiointi. Palvelussa on mahdollisuus datan (tiedostot, tietokannat) varmuuskopiointiin kyseisen palvelimen ulkopuolelle.

Palomuuri. Mikäli palvelinta käytetään ainoastaan www-palvelimena, saapuvan liikenteen tulisi olla rajattu ainoastaan portteihin 80 (Apache) ja 22 (SSH) ja muiden porttien olla suljettuna.

SSH-palvelimen asetukset.

  • kirjautuminen root-käyttäjänä tulisi olla estetty
  • kirjautuminen pelkkää salasanaa käyttämällä on estetty = kirjautuminen tapahtuu SSH-avainparia käyttämällä)
  • kirjautumiseen tulisi käyttää vain vahvempaa protokollaa 2
  • kaikilla palvelimen käyttäjillä on tarpeisiin rajatut käyttöoikeudet ja oikeudet on annettu vain niitä todella tarvitseville henkilöille
  • brute force –hyökkäyksiin on varauduttu

Tiedostojen käyttö- ja omistusoikeudet. Tiedostojen käyttö- ja omistusoikeudet eivät saa olla liian väljät ja kriittisten tiedostojen sekä hakemistojen (.git/.svn/.htaccess) tulee olla suojattuna. Lisäksi jos palvelimella sijaitsee useampia sivustoja, tulee varmistaa, että PHP-tiedostot suoritetaan aina omistajiensa alla (suPHP). Muussa tapauksessa yksittäisen sivustojen käyttäjät voivat lukea esimerkiksi toisten käyttäjien wp-config.php-tiedostoja.

Valvonta. Palvelimella olisi hyvä olla käytössä jatkuva seuranta (esim. Zabbix tai New Relic) ja automaattiset sähköposti- tai tekstiviesti-ilmoitukset annettujen raja-arvojen ylittyessä suoritinkäytön, muistin tai PHP-virheiden osalta.

Hyökkäyksiltä suojautuminen. Yhteyksien tarjoajalla tulisi olla mahdollisuus reagoida hajautettuihin palvelunestohyökkäyksiin (DDoS) esimerkiksi liikennettä suodattamalla tai rajoittamalla liikenteen vain tiettyihin maihin. Lisäksi SSH-palvelinta kohtaan tehtävien brute force –hyökkäyksien esto pitäisi olla toteutettuna DenyHostsin, Fail2ban:in tai vastaavan ohjelman avulla.

Mikäli itsellä ei ole valmiuksia turvallisen alustan ylläpitämiseen tai mahdollisilta hyökkäyksiltä suojautumiseen, kannattaa palvelimen ylläpito ulkoistaa luotettavalle ja asiantuntevalle taholle.

Sovellustason tietoturva

Sovellustason tietoturvalla tarkoitan tässä katsauksessa itse WordPress-asennuksen ja sen lisäosien sekä teemojen tietoturvaa.

Lähtökohtaisesti sovellustason tietoturvatoimenpiteet alkavat jo asennuksesta. Henkilökohtaisesti suosittelen WordPressin osalta aina mukautettua asennusta ”Yhden klikkauksen” -asennusten sijaan. Mukautetulla asennuksella varmistetaan, että asennuksessa ei käytetä oletusasetuksia esimerkiksi WordPressin tai tietokannan käyttäjänimissä, tietokannan nimessä, tietokantataulujen etuliitteissä tai salausavaimissa. Samalla WordPressin pääkäyttäjätunnuksen ja tietokannan salasanat päästään asettamaan riittävän vahvoiksi.

Lisäosien sekä teemojen asentamien WordPressin lisäosahakemistosta on lähtökohtaisesti turvallista, mutta lisäosahakemiston ulkopuolelta asennettavat kannattaa teemat ja lisäosat käydä ainakin pintapuolisesti läpi myös koodipuolelta. Sama toiminnallisuus kun voidaan saada aikaan tietoturvan kannalta joko huonolla tai hyvällä koodilla. Toimivan tietojenkalasteluohjelmankin piilottamiseen vaaditaan vain yksi ainoa rivi.

Kun WordPress on asennettu, ainoa varma tapa välttyä ongelmilta on ohjelmiston, lisäosien ja teemojen säännöllinen päivittäminen sekä varmuuskopiointi. Sivuston päivittämisessä ja kehitystyössä suosittelen käyttämään aina paikallista kehitysympäristöä ja versionhallintaa, kuten Git:iä. Tällöin kaikki koodiin tehtävät muutokset tulevat dokumentoitua ja ne ovat tallessa useassa paikassa esimerkiksi mahdollisen palvelinvirheen varalta. Työskentelyn helpottumisen lisäksi versionhallinnan avulla on helppo seurata myös muuttuneita tiedostoja, mikä mahdollistaa onnistuneiden hyökkäysten tunnistamisen mahdollisimman varhaisessa vaiheessa.

Sovellustasolla tietoturvan parantamiseen on useitakin eri lisäosia ja niksejä, joita löytyy esimerkiksi Sofokuksen artikkeleista 20 tapaa parantaa WP-asennuksesi turvallisuutta: osa 1 ja osa 2. Lisäisin artikkeleissa mainittuihin vinkkeihin vielä mm. WordPressin sisäisen koodieditorin piilottamisen, koska editoria käytetään jatkuvasti koodin syöttämiseen teemojen tiedostoihin osana automaattisia hyökkäyksiä. Myös etäjulkaisuun käytettävä XML-RPC –rajapinta on usein hyökkäysten kohteena ja sen poistaminen käytöstä on monissa tapauksissa kannattavaa, mikäli se ei ole esimerkiksi mobiilisovelluksen käytössä.

Pääsääntöisesti nämä tietoturvakikat ja -lisäosat ovat hyviä ja toimivia, mutta haluan tässäkin yhteydessä korostaa, että sivuston kokonaistietoturva ei saisi rakentua pelkästään niiden varaan.

Käyttäjätason tietoturva

Käyttäjätason tietoturva koskee sekä palvelimen ylläpitäjiä että WordPressin ylläpitäjiä ja sivuston muita kirjautuneita käyttäjiä. Käyttäjätason tietoturvasta huolehtiminen on erityisen tärkeää palvelin- ja sovellustason ylläpitäjille, mutta en väheksyisi myöskään itse sivuston päivittäjien vastuuta tietoturvan kokonaisuudessa.

Keskeistä kaikilla tasoilla on, että käyttöoikeuksia myönnetään vain niitä tarvitseville henkilöille ja myönnettävät käyttöoikeudet on rajattu mahdollisimman tiukasti käyttäjän tarpeiden mukaan. Esimerkiksi kaikki WordPress-sivuston ylläpitäjät eivät tarvitse pääkäyttäjän tunnuksia, vaan sisältöjen päivitys onnistuu myös alemmilla käyttöoikeustasoilla.

Käyttäjätason päivittäisessä tietoturvassa on lähtökohtaisesti kaksi perusasiaa. Ensinnäkin käytettävien salasanojen on oltava riittävän vahvoja. Toiseksi esimerkiksi WordPressissä ei tulisi käyttää samaa salasanaa, joka on jo käytössä jossain toisessa palvelussa, kuten sähköpostissa. Mikäli salasana pääsee vuotamaan WordPressin kautta ja samalla salasanalla pääsee kirjautumaan käyttäjän sähköpostiin, on todennäköistä, että sähköpostista löytyy joko lisää tunnuksia muihin palveluihin (esim. webhotellien tilausvahvistukset) tai sitten sähköpostitiliä voidaan käyttää salasanojen vaihtamiseen käyttäjän muissa palveluissa.

Nämä kaksi edellä mainittua ehtoa saa täytettyä parhaiten käyttämällä salasanojen muistamissovellusta. Sovelluksen valinnassa kannattaa kuitenkin käyttää harkintaa esimerkiksi sen suhteen, että synkronoidaanko tallennetut tiedot pilveen vai ei.

Edelleen lisäturvaa WordPressin hallintaan kirjautumiseen saa kaksivaiheisella todennuksella, jonka käyttö on kuitenkin vielä suhteellisen harvinaista. Lisäksi on hyvä muistaa, että myös palveluihin kirjautumiseen käytettävällä internetyhteydellä on merkitystä. En esimerkiksi suosittelisi käyttämään kriittistä palvelua esimerkiksi suojaamattoman julkisen WiFi:n kautta.

Suositukset

Katsauksen pohjalta voin antaa kolme suositusta kaikille WordPressiä ammattimaisesti hyödyntäville tahoille:

  1. Käytä vain luotettavien palveluntarjoajien palvelinratkaisuja ja ulkoista palvelimen ylläpito, mikäli omat resurssit eivät riitä turvallisen alustan ylläpitämiseen.
  2. Tee WordPressin päivittämisestä ylläpitosopimus, mikäli et aio itse huolehtia WordPressin, teemojen sekä lisäosien päivityksistä.
  3. Käytä lisäosa- ja teemakehitykseen ammattitaitoisia yrityksiä ja henkilöitä. Pelkkä yhteen asiaan erikoistuminen ei riitä, vaan toteuttajan pitää nähdä myös sivuston kokonaisuus, jonka yksi osa tietoturva on.

Tämän katsauksen tarkoituksena oli laajentaa kuvaa WordPressin tietoturvasta ja toisaalta korostaa, että ei ole samantekevää, että millaisella palvelimella WordPressiä ylläpidetään ja millaiset tekijät sivustoasi kehittävät. Henkilökohtaisesti uskaltaisin luottaa vaativammankin WordPress-toteutuksen esimerkiksi Aucorin, H1:sen tai Sofokuksen käsiin. (Henkilökohtainen mielipide, ei maksettu mainos). Toinen keskeinen viestini on se, että kun kokonaisuus on tietoturvan osalta kunnossa, WordPressiä voidaan käyttää hyvinkin monipuolisten palveluiden alustana. Tietenkään kaikkea ei kannata WordPressin pohjalle toteuttaa, mutta sen päätöksen pohjana ei pitäisi olla pelkästään tietoturva vaan soveltuvuus asiakkaan tarpeeseen muilla mittareilla.

Tietoa kirjoittajasta

Mikko VireniusMikko Virenius on yksi Suomen kokeneimmista WordPress-asiantuntijoista, joka on kehittänyt sivustoja WordPressillä päätoimisesti vuodesta 2008 lähtien. Nykyään Mikko konsultoi muita WordPressiin erikoistuneita digitoimistoja mm. teema- ja lisäosakehityksessä yrityksensä Adian Oy:n kautta. Seuraa Mikkoa Twitterissä.

Kuvitus: Kuvittaja Pirita Tolvanen

PS. Haluatko Vierityspalkin artikkelit sähköpostiisi? >> Tilaa kuukausikirje

  1. Sami kirjoitti:

    Pakko kysyä etteikö kirjoittaja näe riskinä huonojaohjelmistokehitystapoja mitä vilisee jopa wp:n coressa? Koskiessa lähdekoodiin törmää tuon tuosta villisti käyttettyihin globaaleihin muuttujiin, käsin tehtyihin sql-queryihin (prepared statementin sijaan) ja includeisiin jotka sisältävät globaalin scopen muuttujia.

    Toki näiden hyväksikäyttöä on pyritty korjaamaan hyvinkin eksoottisilla menetelmillä.

  2. Nicke kirjoitti:

    SSH:n jättäminen porttiin 22 ei todellakaan kuulu ammattimaisen palvelinylläpitäjän työkalupakkiin.
    SSH:n tulisi mieluiten kuunnella jossain vähemmän ilmeisessä portissa ja mieluiten jopa niin, että SSH-yhteyden voisi muodostaa vain ja ainoastaan VPN:n kautta.

  3. Mikko Virenius kirjoitti:

    Kiitos kysymyksestäsi Sami! Tottakai tunnen WordPressin rajoitteet ja tiedän, että sen lähdekoodi elää jopa PHP:n mittakaavassa ”hieman” menneisyydessä, mutta tosiasia myös on, että sen päällä pyörii lähes 20% webistä. Tätä taustaa vasten en näe todennäköisenä, että WordPressin käyttö julkaisujärjestelmänä loppuisi kovin pian.

    Koko kirjoituksen ideahan oli nimenomaan korostaa kokonaistietoturvan merkitystä WordPress-sivustoja suunniteltaessa (kun niitä kuitenkin toteutetaan) eikä suinkaan kieltää mahdollisia tietoturvariskejä.

    Mitä tulee tuohon WordPressin lähdekoodiin koskemiseen, niin toivottavasti olet tehnyt kaikista näistä hyvistä huomioistasi tiketit Trac:iin https://core.trac.wordpress.org/ seuraavaa WordPressin versiota varten.

  4. Mikko Virenius kirjoitti:

    @Nicke Kiitos huomiosta – ylipäätäänkin standardiporttien välttäminen on hyvä käytäntö, joskin oman kokemuksen mukaan suurin osa suomalaisista webhotelleista sekä ylläpidetyistä virtuaalipalvelimista käyttää silti SSH:n kanssa standardiporttia. Mukaan lukien suurimmatkin toimijat.

  5. Pirkka kirjoitti:

    Maailman suosituimpaan julkaisujärjestelmään kohdistuu erityisesti näitä tietoturvaan liittyviä haasteita. Uskon, että valtaosa toteutuneistä ongelmista johtuu ihmisestä, oli kyse sitten päivittämättä jääneestä palvelimesta, sen huonosta konfiguroinnista, päivittämättä jääneestä sovelluksesta tai siihen laiskasti koodatusta pluginista tai niistä salasanoista…

    Tietoturva (tai muut hähmyiset riskit) on aiheena helppo jättää taka-alalle, kunnes sitten tuulettimeen osuu.

    Mitä mieltä olet Mikko WP:n nykyisistä automaattipäivityksistä?

  6. Mikko Virenius kirjoitti:

    @Pirkka: Automaattipäivitykset ovat tietysti hyvä asia, koska niillä saadaan pidettyä edes osa webhotelleihin ”unohdetuista” sivustoista ajan tasalla.

    Toisaalta teemat ja lisäosat sekä isommat versiopäivitykset (esim. 3.9 -> 4.0) ovat ainakin toistaiseksi automaattipäivitysten ulkopuolella, jos niiden päivitystä ei erikseen salli: http://codex.wordpress.org/Configuring_Automatic_Background_Updates

    Ylipäätään lisäosissa yhteensopivuus edellisten versioiden kanssa vaihtelee ja tämän vuoksi päivitykset on hyvä muutenkin tehdä manuaalisesti ja testata paikallisessa kehitysympäristössä ja staging-serverillä ennen muutosten viemistä tuotantopalvelimelle.