Turvallisuus

WordPress kansiorakenteen turvallisuus: Kuinka estää pääsy wp-includes-kansioon

  • 9 minuuttia lukemista
  • Hostragons-tiimi
WordPress kansiorakenteen turvallisuus: Kuinka estää pääsy wp-includes-kansioon

WordPress kansiorakenteen turvallisuus edellyttää wp-includes-kansioon kohdistuvan suoran pääsyn rajoittamista mahdollisimman järkevällä tavalla: on tärkeää estää kansiossa olevien PHP-tiedostojen suorittaminen ja hakemistolistaukset, mutta sallia edelleen staattisten tiedostojen (JS, CSS, kuvat) lataus. Koska wp-includes sisältää WordPressin ytimen tarvitsemia JavaScript- ja CSS-tiedostoja sekä muita staattisia tiedostoja, koko kansioon kohdistuvan pääsyn täydellinen estäminen voi rikkoa sivuston ulkoasun, editorin tai lisäosien toiminnallisuudet. Oikea tapa on Apache-palvelimella .htaccess-sääntöjen avulla, Nginx-palvelimella server block -määrityksillä estää PHP-tiedostojen suoritus wp-includesissa – ja varmistaa muutokset 403/404-virheiden ja kriittisten sivujen testauksella.

Yksi WordPress-turvallisuuden yleisimmistä virheistä on luottaa pelkkään vahvaan salasanaan tai tietoturvalisäosaan. Hyökkääjät kuitenkin etsivät usein ydintiedostoja, vanhoja lisäosia, puutteellisia tiedosto-oikeuksia ja avoimia hakemistolistauksia – ja wp-includes on yksi näistä kohteista. Tässä oppaassa käydään läpi, miten rajoitat wp-includes-kansion pääsyä oikeilla sääntöillä, mitkä säädöt voivat rikkoa sivuston, annetaan esimerkit Apachelle ja Nginxille, testausmenetelmät sekä ylläpidon tarkistuslista. Lisäksi kannattaa huomioida WordPress hosting turvalliselle pohjalle ja SSL-sertifika suojakerroksena koko sivustolle.

Mikä on wp-includes-kansio ja miksi se pitää suojata?

wp-includes on WordPressin ytimen keskeinen kansio, jossa sijaitsevat tärkeimmät kirjastot, luokat, funktiot, editorin osat, REST API, mediatoiminnot ja useita JavaScript-tiedostoja. Käytännössä wp-includes on WordPressin moottoritila – siellä ei ole sisältöä, jota kävijän pitäisi suoraan selaimella nähdä.

Tavallinen kävijä ei koskaan avaa osoitetta sivusto.fi/wp-includes/. Silti sivun lähdekoodissa voi näkyä wp-includes-kansion staattisia tiedostoja, kuten skriptejä, emoji-loaderia tai editorin osia. Turvallisuusratkaisun tavoite on siis selvä: estä PHP-tiedostojen suoritus ilman että staattiset tiedostot estetään. Tämä lähestymistapa on ammattilaisen WordPress kansiorakenteen turvallisuuden perusta: satunnainen pääsyn estäminen tuo lyhyellä tähtäimellä turvaa, mutta voi aiheuttaa valkoista sivua, rikkinäistä admin-paneelia, toimimatonta editoria tai virheellistä teemaa. Tavoitteena on suojata ydintiedostot ja kaventaa hyökkäyspinta.

Mitä hyötyä wp-includes-kansion pääsyn rajoittamisesta on?

Pääsyn rajoittaminen wp-includes-kansion PHP-tiedostoihin ei yksin estä kaikkia hyökkäyksiä, mutta vähentää huomattavasti sivuston haavoittuvuutta. Esimerkiksi haittaohjelmat hyödyntävät usein pääsyä kansioihin, joihin voi ladata tai suorittaa PHP-tiedostoja. Estämällä suora pääsy wp-includesin PHP-tiedostoihin, luot lisäesteen näille hyökkäyksille.

Tämä toimenpide tuo seuraavat edut:

  • Rajoittaa ytimen PHP-tiedostojen suoraa kutsua URL-osoitteella.
  • Auttaa estämään kansiolistauksen näkyvyyttä, jos se on vahingossa päällä.
  • Vähentää automaattisten bottien tekemää tiedon vuotoa.
  • Tarjoaa suojaa palvelintason sääntöjen kautta, vaikka lisäosaa ei olisi.
  • Vahvistaa kerroksellista tietoturvaa WAF:n, SSL:n, ajantasaisen PHP:n ja tiedosto-oikeuksien kanssa.

On tärkeää muistaa, että kyseessä on vain yksi suojakerros. Jos lisäosat ovat vanhentuneita, admin-salasanat heikkoja tai FTP-tili kaapattu, wp-includes-sääntö ei yksin riitä. Turvallisuus syntyy hostingin, WordPressin, käyttäjähallinnan ja ylläpidon yhdistelmästä. Hyvän perustan luomiseksi kannattaa tutustua Turvallinen Web Hosting ja Domainin turvallisuus sisältöihin.

Wp-includes-kansion pääsyn eston yleisimmät virheet

Koko kansion estäminen

Yleinen virhe on estää kaikki HTTP-pyynnöt wp-includes-kansioon (esim. 403 kaikkiin osoitteisiin). Tämä vaikuttaa loogiselta, mutta WordPress lataa useita staattisia tiedostoja tästä kansiosta; seurauksena voi olla rikkinäinen editori, toimimattomia JavaScript-tiedostoja tai pieniä mutta kriittisiä ulkoasun ongelmia.

Sääntöjen testaamatta jättäminen

.htaccess- tai Nginx-sääntöjen väärä asettelu voi aiheuttaa 500 Internal Server Error -virheen. Varsinkin isolla sivustolla suoraa käyttöönottoa ilman varmistusta tulisi välttää. Ota aina varmuuskopio, testaa staging-ympäristössä ja vasta sitten ota sääntö käyttöön. Hostragonsin palvelussa varmuuskopiointi tai staging on helppo toteuttaa – Verkkohosting varmuuskopiointi toimii luonnollisena linkkinä.

Liika luottamus tietoturvalisäosiin

Lisäosat ovat hyödyllisiä, mutta palvelinsääntö estää pyynnön jo ennen kuin WordPress käsittelee sen – näin säästät resursseja. Siksi palvelintason sääntöjä ei kannata ohittaa, vaikka käyttäisitkin tietoturvalisäosia.

Ennen muutosta: tarkistuslista

Wp-includes-kansion pääsyä rajoittaessa kannattaa tehdä pieni valmistelu, joka vähentää katkon riskiä. Suositeltava tarkistuslista:

  • Varmuuskopioi nykyinen .htaccess tai Nginx-konfiguraatio.
  • Päivitä WordPress, teemat ja lisäosat ajantasaisiksi.
  • Varmista, että PHP-versiosi on tuettu ja turvallinen.
  • Tarkista tiedosto-oikeudet: kansiot 755, tiedostot 644.
  • Älä jätä wp-config.php:n tai .htaccessin kirjoitusoikeuksia tarpeettomasti avoimeksi.
  • Jos käytät välimuistia, CDN:ää tai tietoturvalisäosaa, suunnittele cache-tyhjennys muutoksen jälkeen.
  • Laadi testilista admin-paneelille, etusivulle, blogiartikkelille, yhteydenottolomakkeelle ja maksusivulle.

Tarkistus vie 10–15 minuuttia, mutta säästää tuntikausia mahdolliselta katkosta. Yrityssivustoilla kannattaa ajoittaa muutos hiljaiselle aikavälille.

Wp-includes PHP-pääsyn rajoittaminen Apache-palvelimella (.htaccess)

Apache- ja LiteSpeed-palvelimilla .htaccess on helpoin tapa. Lisää WordPressin juuresta löytyvään .htaccess-tiedostoon oikeat säädöt – ja ota aina varmuuskopio ennen muutosta.

Suositeltu .htaccess-sääntö

Alla oleva sääntö estää wp-includes-kansion PHP-tiedostojen suoran suorittamisen, mutta sallii staattiset tiedostot:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Säännön logiikka: jos URL alkaa wp-includes ja päättyy .php, pyyntö estetään. Näin PHP-tiedostot eivät ole suoraan selaimella kutsuttavissa, mutta JS, CSS, PNG, SVG ym. tiedostot latautuvat normaalisti. Tämä tasapaino suojaa sekä etusivua että admin-paneelia.

Hakemistolistauksen estäminen

Lisäksi kannattaa estää hakemistolistaukset. Lisää .htaccessiin seuraava rivi:

Options -Indexes

Tämä piilottaa kansiot, joissa ei ole index-tiedostoa. Useimmissa hosting-palveluissa tämä on oletuksena päällä, mutta tarkistaminen kannattaa.

Muutos jälkeen: testaa

Testaa sääntö seuraavasti:

  • Avaa sivusto.fi/wp-includes/ – kansiolistausta ei tule näkyä.
  • Kokeile ladata wp-includes-kansion PHP-tiedosto suoraan – saat 403 tai 404.
  • Tarkista etusivu, blogi ja admin-paneeli.
  • Käytä selaimen kehitystyökaluja (Console & Network) – ei uusia 404/403-virheitä.
  • Tyhjennä välimuisti, jos käytät cachea tai CDN:ää.

Jos kaikki toimii, sääntö voidaan pitää tuotannossa. Jos tulee 500-virhe, poista lisätyt rivit ja palauta varmuuskopio.

Wp-includes PHP-pääsyn rajoittaminen Nginx-palvelimella

Nginx-palvelimella .htaccess ei toimi. Sääntö lisätään Nginx-konfiguraatioon server blockin sisään. Tarvitset SSH-yhteyden ja oikeudet muokata konfiguraatiota – epävarmoissa tapauksissa kannattaa pyytää hosting-tukea.

Suositeltu Nginx location-sääntö

Perussääntö:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Tämä estää PHP-tiedostojen suoran latauksen wp-includes-kansiosta. Testaa muutos komennolla:

nginx -t

Jos testi onnistuu, lataa konfiguraatio uudelleen:

systemctl reload nginx

Reload ei katkaise yhteyksiä yhtä rajusti kuin restart. Silti muutos kannattaa tehdä hiljaisena aikana.

Nginx-vinkit ja huomioitavaa

  • Varmista, että sääntö on oikeassa server blockissa – yhdellä palvelimella voi olla useita sivustoja.
  • Jos käytät CDN:ää tai reverse proxya, tyhjennä CDN:n cache ennen testausta.
  • Varmista PHP-FPM-konfiguraation rajaukset.
  • Tarkista lokit: access.log ja error.log auttavat virheiden löytämisessä.

Nginxissä väärä location-järjestys voi aiheuttaa odottamattomia tuloksia. Tarkista, ettei sääntö aiheuta ristiriitoja WordPressin permalink- tai PHP-sääntöjen kanssa.

Menetelmien vertailu

Alla olevassa taulukossa on yhteenveto WordPress wp-includes-kansion pääsyn rajoittamisen tärkeimmistä tavoista:

Menetelmien vertailu
MenetelmäYmpäristöHyödytHuomioitavaa
.htaccess-sääntöApache ja LiteSpeed hostingNopea ottaa käyttöön, toimii jaetuissa hosting-palveluissaVäärä syntaksi voi aiheuttaa 500-virheen
Nginx location-sääntöVPS, dedikoitu, hallittu palvelinTehokas ja suorituskykyinen palvelintason suojausVaatii SSH-taitoja ja konfiguraatio-osaamista
TietoturvalisäosaVähemmän tekniset käyttäjätHelppo hallita käyttöliittymässäKaikki säännöt eivät toimi palvelintasona
WAF ja CDNKorkean liikenteen tai hyökkäyksen kohteena olevat sivustotSuodattaa botit ja haitalliset pyynnöt jo varhaisessa vaiheessaVäärä sääntö voi estää oikeat käyttäjät
Tiedosto-oikeudetKaikki WordPress-sivustotPerustason tietoturvaEi yksin estä pääsyä URL-tasolla

Parhaat tulokset saavutetaan yhdistämällä menetelmiä: esimerkiksi Apache-hostingissa .htaccess-sääntö, oikeat tiedosto-oikeudet, päivitetty WordPress, SSL ja varmuuskopiointi luovat kerroksellisen suojan. Hostingissa tietoturvapalomuuri ja eristys ovat tärkeitä – Yrityshosting on hyvä valinta vaativille sivustoille.

Tiedosto-oikeudet ja omistajuus

Wp-includes-kansion pääsyn rajoitus on turha, jos tiedosto-oikeudet ovat väärin. WordPressissä kansioiden suositus on 755 ja tiedostojen 644. Näin web-palvelin voi lukea tiedostoja, mutta turhat kirjoitusoikeudet on minimoitu. Joissain hosting-palveluissa käyttäjä- ja ryhmäasetukset voivat vaihdella, joten seuraa oman palveluntarjoajan ohjeita.

777-oikeus (kaikki voivat kirjoittaa) on vakava riski – se mahdollistaa haitallisten tiedostojen lataamisen. Jopa wp-content/uploads-kansiossa PHP-suoritus tulisi estää. Wp-includes-kansio ei normaalisti tarvitse kirjoitusoikeutta kuin WordPress-päivityksissä.

Tarkista ainakin:

  • wp-includes-kansio: 755
  • wp-includes PHP-tiedostot: 644
  • wp-config.php: mieluiten 600 tai hostingin suositus
  • .htaccess: 644, ei turhaa kirjoitusoikeutta

Asetukset voivat vaihdella palvelimen mukaan. Väärät oikeudet voivat estää päivitykset tai tiedostojen lukemisen. Muutoksen jälkeen tarkista WordPressin terveystilanne ja lokit.

Tehokkuus tietoturvalisäosilla

Wordfence, iThemes Security ja muut tietoturvalisäosat voivat ehdottaa hardening-toimia automaattisesti. Ne suojaavat brute force -hyökkäyksiltä, tiedostomuutoksilta, haittaohjelmilta ja kirjautumisen turvallisuudelta. Wp-includes-pääsyn estäminen riippuu lisäosasta – tarkista, mitä ne tekevät!

Useat lisäosat lisäävät .htaccess-sääntöjä automaattisesti, jotkut suojaavat vain sovellustasolla. Sovellustason suojaus toimii vasta, kun pyyntö on jo WordPressillä – palvelintason sääntö on tehokkaampi. Ammattimainen lähestymistapa on yhdistää lisäosa ja palvelinmääritykset.

Jos käytät tietoturvalisäosaa, tarkista:

  • Lisäosa lisääkö .htaccess- tai Nginx-sääntöjä.
  • Ei tule päällekkäisiä sääntöjä kahden lisäosan välillä.
  • Lisäosan päivitys ei muuta tietoturva-asetuksia.
  • Seuraa cachea ja serverin resurssien käyttöä vaikutusten arvioimiseksi.

Usean tietoturvalisäosan käyttö ei yleensä ole hyvä idea – päällekkäiset palomuurit, login- ja rewrite-säännöt voivat hidastaa sivustoa tai aiheuttaa virheellisiä estoja.

Wp-includes-kansion suojauksen testaaminen: käytännön skenaario

Pelkkä sivuston avautuminen ei riitä – testaa suojauksen onnistuminen seuraavalla 7 kohdan listalla, joka sopii pienyrityksestä verkkokauppaan:

  • 1. Avaa etusivu incognito-tilassa – tarkista, ettei ulkoasu ole rikki.
  • 2. Siirry blogiin, kategoriaan ja hakutuloksiin.
  • 3. Kirjaudu wp-adminiin – testaa blokieditori ja mediakirjasto.
  • 4. Tarkista selaimen kehitystyökalujen Console.
  • 5. Network-välilehdellä varmista, että wp-includesin staattiset tiedostot latautuvat.
  • 6. Kokeile ladata wp-includes-kansion PHP-tiedosto suoraan – odota 403/404-virhettä.
  • 7. Tarkista serverin virhelokit.

Testi vie noin 5 minuuttia ja paljastaa väärät säädöt nopeasti. Verkkokaupassa kannattaa testata myös ostoskoria, maksua ja käyttäjätiliä – pienikin JavaScript-virhe voi vaikuttaa konversioon.

Lisäturva WordPress-kansiorakenteeseen

Wp-includesin suojaus on hyvä lähtökohta, mutta WordPressin suojaus tulee ajatella kokonaisvaltaisesti. Seuraavat lisätoimet vähentävät hyökkäyspintaa entisestään:

  • Pidä WordPress aina päivitettynä – älä luota version piilottamiseen.
  • Poista käytöstä vanhat teemat ja lisäosat täysin.
  • Tee admin-käyttäjät vaikeasti arvattaviksi.
  • Käytä kaksivaiheista tunnistautumista.
  • Rajoita XML-RPC:n käyttö, jos sitä ei tarvita.
  • Aseta rate limit tai lisävahvistus wp-login.php:lle.
  • Tee automaattinen varmuuskopiointi ja testaa palautus.
  • Käytä HTTPS/SSL koko sivustolla – ilman SSL:ää tiedot ovat riskissä.

SSL ei suoraan estä wp-includes-pääsyä, mutta turvaa käyttäjät, lomakkeet ja admin-liikenteen. SSL on siis WordPress-tietoturvan peruskerros – Osta SSL-sertifika ja Ilmainen SSL-asennus ovat suositeltavia linkkejä.

Milloin kannattaa pyytää ammattilaisen apua?

Yksinkertaisessa Apache-hostingissa .htaccess-sääntö onnistuu useimmilta. Mutta monimutkainen Nginx-konfiguraatio, multisite, WooCommerce-kauppa, vilkas uutissivusto tai yritysportaali vaatii ammattilaisen osaamista – turvallisuussääntöjen on oltava oikein ja liiketoiminnan kannalta turvallisesti toteutettuja.

Ammattilaisen apua kannattaa pyytää, jos:

  • Palvelimella on useita WordPress-sivustoja.
  • Käytät yhdistelmänä Nginx, Varnish, CDN ja WAF.
  • Viime muutoksen jälkeen 403, 404 tai 500-virheet lisääntyvät.
  • Sivusto on aiemmin kärsinyt haittaohjelmista.
  • Käsittelet maksutietoja, jäsenyyksiä tai henkilötietoja.

Turvallinen hosting, eristys, varmuuskopiointi ja asiantuntijatuki ovat WordPress-tietoturvan näkymätön, mutta kriittinen osa. Hostingvalinnassa kannattaa katsoa muutakin kuin tilaa: varmuuskopiointi, palomuuri, PHP-tuki, SSL-hallinta ja tuen laatu ovat tärkeitä. Hostragons hostingpaketit ja WordPress-sivuston siirto ovat hyödyllisiä sisältöjä vertailuun.

Yhteenveto

WordPress kansiorakenteen turvallisuudessa wp-includes-kansion oikea suojaus ei tarkoita koko kansion estämistä, vaan PHP-tiedostojen suoran pääsyn rajoittamista ja hakemistolistauksen sulkemista. Apachelle .htaccess-sääntö, Nginxille location-määritys – ja aina varmuuskopiointi sekä testaus admin-paneelissa ja sivuston etuosassa.

Pähkinänkuoressa: älä estä staattisia tiedostoja, rajoita PHP-tiedostojen suoritus, sulje hakemistolistaus, tarkista tiedosto-oikeudet ja pidä sivusto ajan tasalla. Hostragonsin hosting-, domain- ja SSL-ratkaisut sekä asiantuntijatuki varmistavat hallittavan WordPress-turvallisuuden.

Usein kysytyt kysymykset

Onko koko wp-includes-kansion estäminen turvallista?

Ei yleensä. Wp-includes sisältää WordPressin tarvitsemia JavaScript-, CSS- ja staattisia tiedostoja. Täysi esto voi rikkoa sivuston ulkoasun tai admin-paneelin. Turvallisempi tapa on estää vain PHP-tiedostojen suora pääsy.

Jos saan 500-virheen .htaccess-säännön lisäämisen jälkeen, mitä teen?

Poista viimeiset lisätyt rivit tai palauta varmuuskopioitu .htaccess. Tarkista sääntöjen syntaksi. Jos virhe jatkuu, tarkista hostingin virhelokit tai pyydä teknistä tukea.

Toimiiko .htaccess Nginx-palvelimella?

Ei. .htaccess toimii Apache ja LiteSpeed -palvelimilla. Nginxissä rajoitukset tehdään server blockin location-säännöillä – ja muutos testataan nginx -t -komennolla.

Tekeekö tämä sivustostani täysin turvallisen?

Ei. Wp-includes PHP-tiedostojen pääsyn esto on tärkeä kerros, mutta ei yksin riitä. Päivitykset, vahvat salasanat, kaksivaiheinen tunnistautuminen, SSL, varmuuskopiointi, palomuuri ja oikeat tiedosto-oikeudet tulee yhdistää.

Kannattaako lisätä wp-includes-sääntö, jos käytän tietoturvalisäosaa?

Riippuu lisäosasta. Osa lisää .htaccess-sääntöjä automaattisesti, osa suojaa vain sovellustasolla. Paras ratkaisu on estää suora PHP-pääsy palvelintason säännöllä ilman päällekkäisiä sääntöjä.

Jaa tämä artikkeli:

Hostragons-tiimi

Asiantuntijatiimimme ajantasaiset oppaat webhotellista, palvelimista ja verkkotunnuksista. Löydätään yhdessä projektiisi sopiva ratkaisu.

Ota meihin yhteyttä