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.

Szoftverfrissí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ása 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 (tartalmi 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 designer-ek kezéből kikerült témákra különösen oda kell figyelni, és csakis megbízható forrásból letölteni ezeket.

Plugin-ek

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 plugin-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 plugin-t is megnéztem, amelyek 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. Ezek 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 az 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ázisré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ásszintű tűzfal segítségével korlátozhatjuk az ehhez szükséges állományok (wp-comments-post.php) elérését, vagy egyszerűen le is törölhetjük a szerverről…

Remote Publishing

Ez 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:

http://andrews.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 terjedt 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 oldalaink 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 haszná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, amelyek 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 script-tel 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általán nem igaz? Ugyanis, az a bizonyos titkos prefix ott van a konfigban, és mivel majd’ minden script 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ázisstruktúránkat. Létezik ugyan plugin, ami többek között ezt is elvégzi helyettünk – a plugin-okná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és – 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 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.