WordPress – biztonságosan

 

„Minden rendszer csak annyira biztonságos, mint a benne szereplő leggyengébb láncszem!”

A  fenti mondatot mindenképp érdemes már a tervezés során is figyelembe venni, hiszen egy ilyen látszólag egyszerű alkalmazás esetében is, a teljes rendszer valójában nagyon sok összetevőből áll. Ha ezek közül bármelyiket is figyelmen kívül hagyjuk, azzal a többi ‘láncszem’ biztonságosabbá tételébe fektetett munkát – és ezen keresztül az egész projekt sikerét kockáztatjuk.

Erről szól, az ehhez szorosan kapcsolódó másik cikkem:  WordPress – és ami mögötte van

Valóban, ezen a szinten is sokat tehetünk weboldalaink biztonsága érdekében, de mindez semmit nem ér, ha az előzőekre nem figyelve, biztonsági réseket hagyunk máshol.

Szoftver frissítések

Biztosan elcsépelt, ám a gyakorlatban a legtöbb betörést már publikusan ismert és hivatalosan javítással rendelkező, de az adott szerveren még nem javított hibák teszik lehetővé! Így a rendszerünk frissen tartása – kifejezetten ügyelve a biztonsági javításokra – elengedhetetlen fontosságú.

A WordPress rengeteg kényelmi megoldásai közül egyik a frissítés lehetősége egyetlen gombnyomással. Ez azonban  csak akkor működik, ha a webszerver felül tudja írni a WordPress rendszer állományait  – ami hosszútávon rendkívül sok veszélyt hordoz magában. Erre a következő megoldást javaslom:

  • Manuálisan végezzük a frissítéseket – ami kevésbé kényelmes.
  • vagy: csak a frissítés idejére adjuk meg ideiglenesen a kívánt jogokat

Fontos, hogy minden frissítéskor elveszíthetjük az olyan változtatásokat amiket a kódban végeztünk, akár az állományok (tartalni vagy jogosultsági) módosításával akár törlésével értük ezt el. Így ezeket a változtatásokat minden frissítés után ellenőrizni – szükség esetén pedig –  újra végre is kell hajtani!

Témák

Meglepő lehet, ám sokszor a témák is biztonsági réseket hozhatnak a rendszerünkbe, sőt nem egyszer fordult már elő, hogy preparált témákat is találtak, amik telepítés után backdoor-t hoztak létre készítőjük számára…. Így a különböző, ismeretlen designerek kézből kikerült témákra különösen oda kell figyelni, és csakis megbízható forrásból letölteni ezeket.

Pluginek

Ez már nem annyira meglepő, és annál gyakoribb probléma, hogy egy-egy plugin telepítése és használata újabb biztonsági réseket jelent weboldalaink számára. Itt is csak azt tudom általánosságban mondani, hogy csak a valóban szükséges pligin-eket telepítsük, és azokat is csak megbízható forrásból!

WordPress – és ami mögötte van cikkben részletezett állomány jogosultságok alkalmazása esetén a legtöbb veszélyes plugin nem is fog működni… Természetesen itt megint csak mérlegelni kell, hogy az általa nyújtott kényelem/szolgáltatás megéri e a kockázatot, és ennek megfelelően dönteni a használatáról.

Sok olyan plugint is megnéztem, amik pont a rendszerünk biztonságát hivatottak szolgálni, ám cserébe az állományok jogosultságain kell itt-ott, ilyen-olyan mértékben lazítanunk, hogy egyáltalán működhessenek – Ez használatát egyáltalán nem tartom jó ötletnek.

Hozzászólások

Nyilván az oldalaink típusától függ, szeretnénk-e hogy oldalainkon megjelenő cikkekhez írhasson-e bárki hozzászólásokat vagy sem… Az azonban biztos, hogy ez potenciális veszélyforrás lehet, hiszen egy-egy hozzászólás azonnal az adatbázisba kerül, és a támadónak sikerülhet olyan kódot vagy karaktersorozatot bejuttatni, aminek segítségével illetéktelenül módosíthat vagy hozzáférhet más adatbázis részekhez is.

Ha mindenképp szeretnénk a hozzászólások lehetőségét biztosítani, akkor is célszerű ennek módját szabályozni a „Settings -> Discussion” menüpont alatt. Itt dönthetünk arról is, hogy a hozzászólások azonnal megjelenjenek-e vagy csak jóváhagyás után…

Ha biztosan nincs szükségünk erre a lehetőségre, akkor alkalmazás szintű tűzfallal segítségével korlátozhatjuk az ehhez szükséges állományok (wp-comments-post.php) elérést, vagy egyszerűen le is törölhetjük a szerverről…

Remote Publising

Egy egy remek lehetőség arra, hogy ne a WordPress beépített – és limitált lehetőségekkel ellátott – szerkesztőjét kelljen használni egy-egy cikk megírására, hanem különböző egyéb kliensek segítségével írhassunk, és jelentessünk meg cikkeket oldalainkon. Lehetőséget ad azonban arra is, hogy illetéktelenek – egy esetleges szoftverhibát kihasználva – ezen a felületen keresztül hozzáférjenek vagy épp módosítsák az oldalaink tartalmát!

Ha erre nincs szükségünk, akkor kapcsoljuk ki ezt a lehetőséget a „Settings – > Writing” menüpont alatt! Még jobb, ha a szükségtelen állományok elérhetőségét korlátozzuk, vagy egyszerűen eltávolítjuk őket:

  • xmlrpc.php
  • wp-app.php
  • wp-atom.php
  • wp-mail.php

Felhasználók

Ha nem szeretnénk, hogy bárki saját felhasználót hozhasson létre magának, akkor ezt a lehetőséget szintén ki lehet kapcsolni az admin felületről.

Ha biztosra akarunk menni, akkor a funkcióhoz szükséges URL-ek korlátozása lehet a megoldás:

https://zrubi.hu/wp-login.php?action=<action>

Ahol az <action> a következők valamelyike lehet:

  • logout,
  • lostpassword, retrievepassword,
  • resetpass, rp,
  • register,
  • login,

Azt hiszem, mindegyik magáért beszél…

Jelszavak

Szintén elcsépelt, de a manapság már minden alkalmazásba beépített jelszó erősség mutatók ellenére is, úgy a legkönnyebb egy rendszerbe bejutni, ha ‘kitaláljuk’ valakinek a jelszavát…  És ez a ‘kitalálás’ régóta gépesített, akár több gigabájtnyi szótárállománnyal megtámogatott ‘játék’. Sokszor a médiában is szándékosan ferdítenek egy-egy ‘betörés’ alkalmával, ahol tulajdonképpen gyenge jelszavak használata miatt illetéktelenek férnek hozzá valakinek az adataihoz/rendszereihez. Szóval komolyan kell venni, és rendes jelszavakat használni! – Erre szintén sok plugin létezik, amelyik meg is követelheti – különböző szabályok szerint – a megfelelő jelszó használatát a felhasználóktól – akik sokszor adminisztrátori jogokkal bírnak egy-egy oldalon!

wp-cron

A WordPress egyik beépített lehetősége, hogy ütemezett megjelenéseket lehet beállítani benne. Ehhez szükség volt egy beépített ütemező megoldásra. Ez – nagyon röviden – úgy működik, hogy az oldalak betöltésekor – ha szükséges – meghívja az ütemezőt (wp-cron.php)

Mivel ez egy bárki által meghívható script, ezzel könnyen vissza lehet élni, és ha mást nem is, de feleslegesen nagy terhelést lehet okozni a szerverünknek… Ennek elkerülése szintén az URL elérésének korlátozásával (üzemszerűen csak a ‘localhost’-ról jöhetnek ilyen kérések), vagy a funkció teljes kikapcsolásával lehetséges.

A teljes kikapcsoláshoz a következő sort kell a wp-config.php állományba illeszteni:

define(‘DISABLE_WP_CRON’, true)

Security through obscurity

Avagy: titkolózáson alapuló (hamis) biztonság!

De mit is jelent ez? Azt, hogy ha valamilyen – a rendszer felépítésével kapcsolatos – információt ‘eltitkolunk’, akkor az attól biztonságosabb lesz… Ezt sokan túlértékelik, annyira hogy, mára ezen alapuló tévhitek garmadája terjed el mindenféle témakörben. Nincs ez másképp a WordPress esetében sem, lássuk mik is ezek:

  • Verzió információk eltűntetése

Ha megnézzük az oldalink forráskódját, találunk benne ilyesmit:

<meta name="generator" content="WordPress 3.2.1" />

Ez viszont információt ad az esetleges támadóknak arról, hogy pontosan milyen verziójú szoftvert hsználunk. Ha a szoftverünk nem naprakész, akkor ezen információval már sokat segítettünk a gonosz hackereknek – de ne legyenek illúzióink, enélkül is könnyedén be lehet azonosítani a pontos verziószámot.

Ennek eltávolítására több plugin is létezik, amik az oldal generálódásakor szedik ki az ilyen – és ehhez hasonló – verzióinformációkat a html kódból.

  • Nevezzük át az adminisztrátor accountot

Ez határeset, ugyanis automata scriptel végzett támadások ellen tényleg véd. Legjobb, ha már telepítéskor más felhasználót nevezünk ki adminisztrátornak. Ha később szeretnénk módosítani, akkor előbb nevezzünk ki legalább egy másikat adminisztrátornak, utána letörölhetjük az ‘admin’ nevűt…

  • Változtassuk meg az adatbázisban használt tábla prefixet

Állítólag, ha tábla prefixnek a default ‘wp_’ helyett egy más, titkos karaktersorozatot használunk, az véd 0 day SQL injection hibák ellen is….

Hogy is fogalmazzam meg finoman, hogy ez így egyátalán nem igaz? Ugyanis, az a bizonyos titkos prefix ott van a konfigban, és mivel majd minden sript használja, így kideríteni nem nagy feladat. Magát a módosítást utólag elvégezni viszont az, amivel jól össze is boríthatjuk az egész adatbázis struktúránkat. Létezik ugyan plugin, ami többek között ezt is elvégzi helyettünk – a pluginokál már részletezett fájlrendszer jogok lazításáért cserébe – ám pl: ‘Multisite’ esetén egyáltalán nem működik.

Aki hisz ebben, annak azt tudom javasolni, hogy már a telepítésnél változtassa meg, akkor a későbbiekben – várhatóan – nem lesz belőle probléma. Azonban semmiképp ne gondolja, hogy ettől sokkal jobb lett a rendszere!

Ez a prefix eredetileg arra való, hogy egy adatbázist használhasson több WordPress telepítést – ami biztonsági szempontból amúgy sem javasolt – ám egy korlátozott hosting szolgáltatás esetén mégis szükségünk lehet erre.

Összegzés

Végül ismételten javaslom, hogy ha biztonságosabb weboldalakat szeretnénk létrehozni WordPress segítségével, ne csak a jéghegy csúcsát nézzük! WordPress – és ami mögötte van

Már tervezéskor vegyük figyelembe a szolgáltatók által nyújtott lehetőségeket, így biztosan a sikerül megtalálni a számunkra legjobban megfelelő megoldást.

Ha pedig inkább mégis szakértőkre bíznák weboldalaik biztonságos kialakítását, elhelyezését, vagy védelmét: lépjenek kapcsolatba velünk, szinte minden igényre tudunk megfelelő megoldást nyújtani.