WordPress biztonság: mit érdemes beállítani?

A WordPress biztonságáról könnyű úgy gondolkodni, hogy kell egy security plugin, néhány kapcsolót be kell kapcsolni, és onnantól az oldal „védett”.

A gyakorlatban ennél összetettebb a helyzet.

Egy WordPress oldal több részből áll: maga a WordPress, a bővítmények, a sablon, a tárhely, az adatbázis, a felhasználói fiókok és sokszor további technikai hozzáférések is részei a rendszernek. Egyetlen beállítás ezért nem tud minden lehetséges problémát megoldani.

A cél nem is az, hogy lehetetlenné tegyünk minden támadást. Ilyen garanciát egy WordPress-beállítás vagy biztonsági plugin sem tud adni.

Sokkal hasznosabb három kérdésből kiindulni:

Hogyan csökkenthető egy sikeres kompromittálás esélye?
Hogyan korlátozható, hogy egy megszerzett hozzáféréssel mit lehessen megtenni?
Hogyan lehet gyorsabban észrevenni és kezelni, ha mégis történik valami?

A WordPress hivatalos biztonsági dokumentációja is abból indul ki, hogy a biztonság folyamatos tervezést, monitoringot és rendszeres karbantartást igényel, a kockázat pedig nem csökkenthető nullára. (WordPress Security) (developer.wordpress.org)

A legfontosabb alap: legyen friss a WordPress, a plugin és a sablon

A WordPress hivatalos dokumentációja az alapvető biztonsági intézkedések között kezeli a WordPress, valamint a telepített bővítmények és sablonok naprakészen tartását. (Hardening WordPress) (developer.wordpress.org)

Ennek oka egyszerű.

Ha egy komponensben ismert sérülékenységet javítanak, de az oldal továbbra is a régi verziót használja, akkor a javítás hiába létezik, a te weboldaladon még nincs jelen.

Ez nem jelenti azt, hogy minden frissítést gondolkodás nélkül, ellenőrzés nélkül kell telepíteni. Egy üzletileg fontos vagy összetettebb WordPress oldalnál a kompatibilitás és a működés ellenőrzése ugyanúgy része az üzemeltetésnek.

A rossz megoldás viszont az, ha a frissítéseket hónapokon keresztül azért halasztjuk, mert „most működik az oldal”.

Mi legyen az automatikus frissítésekkel?

A WordPress támogatja a core, valamint a pluginok és sablonok különböző automatikus frissítési lehetőségeit.

Hogy mindent automatikusan érdemes-e frissíteni, arra nincs minden oldalra érvényes válasz.

Egy egyszerűbb weboldalnál jó kompromisszum lehet, ha minél több biztonsági és karbantartási frissítés automatikusan települ.

Egy összetett WooCommerce oldalnál, egyedi fejlesztésekkel vagy érzékeny integrációkkal viszont fontosabb lehet a tesztelhető, kontrollált frissítési folyamat.

A lényeg nem az, hogy mindenhol ugyanazt az automatikus frissítési beállítást használd, hanem hogy legyen tényleges folyamat arra, hogy a frissítések belátható időn belül felkerüljenek.

Ne tarts meg olyan plugint és sablont, amelyre nincs szükség

Biztonsági szempontból nemcsak az számít, hogy mi aktív az oldalon.

Az is fontos, hogy egyáltalán mi van telepítve.

Egy régen kipróbált, majd kikapcsolt plugin könnyen ott maradhat évekre. Ugyanez megtörténhet régi sablonokkal vagy olyan komponensekkel, amelyekről már senki nem tudja pontosan, miért kerültek az oldalra.

Érdemes időnként végignézni:

mely pluginokra van ténylegesen szükség;
melyik sablont használja az oldal;
mely komponensek vannak csak megszokásból telepítve;
érkeznek-e még frissítések az adott projekthez.

A WordPress hivatalos hardening dokumentációja azt is javasolja, hogy a pluginok és sablonok megbízható forrásból származzanak. (Hardening WordPress) (developer.wordpress.org)

Ez nem azt jelenti, hogy a kevesebb plugin automatikusan biztonságos oldalt jelent. Egy rosszul megírt egyetlen bővítmény is lehet probléma, miközben több jól karbantartott komponens teljesen indokolt lehet.

A felesleges komponens viszont olyan kód, amelyből nem kapsz üzleti értéket, mégis karban kell tartani.

A WordPress adminisztrátori hozzáféréseket érdemes szűken tartani

Nem minden felhasználónak kell adminisztrátornak lennie.

Ha valakinek kizárólag cikkeket kell szerkesztenie, ahhoz nincs szüksége plugintelepítési, felhasználókezelési vagy más adminisztrátori jogosultságokra.

Ez a legkisebb szükséges jogosultság elve: mindenki csak akkora hozzáférést kapjon, amekkora a feladatához ténylegesen szükséges.

Ennek akkor van különösen nagy jelentősége, ha egy fiók hozzáférési adatai valamilyen módon illetéktelen kézbe kerülnek. Nem mindegy, hogy az adott fiókkal egy cikk szerkeszthető, vagy az egész WordPress telepítés adminisztrálható.

Időnként ezért érdemes átnézni:

kik rendelkeznek adminisztrátori jogosultsággal;
szükséges-e még minden felhasználói fiók;
volt munkatárs vagy külsős hozzáférése megmaradt-e;
megfelel-e a felhasználó szerepköre a jelenlegi feladatának.

A ritkán használt, de nagy jogosultságú hozzáférés nem lesz biztonságosabb attól, hogy hónapok óta senki nem lépett be vele.

Használj egyedi és erős jelszavakat

A jelszónál nem az a cél, hogy ember számára bonyolultnak tűnjön, hanem hogy ne legyen könnyen kitalálható vagy más szolgáltatásból megszerzett jelszóval újrahasználható.

Különösen rossz gyakorlat ugyanazt a jelszót használni:

WordPresshez;
tárhelyhez;
e-mailhez;
FTP/SFTP-hez;
és más szolgáltatásokhoz.

Ha egy másik rendszerből kiszivárog ez a jelszó, azzal a WordPresshez kapcsolódó hozzáférések is veszélybe kerülhetnek.

A gyakorlatban egy megbízható jelszókezelő sokkal életszerűbb megoldás, mint az, hogy minden szolgáltatáshoz külön hosszú jelszót próbálj megjegyezni.

Állíts be kétlépcsős hitelesítést a magas jogosultságú fiókoknál

A kétlépcsős hitelesítés, röviden 2FA, azt jelenti, hogy a jelszó mellett egy második tényezőre is szükség van a belépéshez.

Ez azért hasznos, mert egy megszerzett jelszó önmagában így nem feltétlenül elég a sikeres bejelentkezéshez.

A WordPress hivatalos dokumentációja külön foglalkozik a kétlépcsős hitelesítéssel. A WordPress core jelenleg nem biztosít általános, beépített 2FA-megoldást, ezért ezt jellemzően megfelelő bővítménnyel vagy külső hitelesítési rendszerrel lehet megoldani. (Two Step Authentication) (developer.wordpress.org)

Adminisztrátori és más magas jogosultságú fiókoknál a 2FA-t érdemes alapvető biztonsági követelményként kezelni, nem pusztán opcionális extraként.

Nem feltétlenül kell minden minimális jogosultságú felhasználóra ugyanazt a szabályt alkalmazni, de egy olyan fióknál, amellyel plugin telepíthető, felhasználók kezelhetők vagy az oldal működése jelentősen módosítható, sokkal nagyobb a megszerzett hozzáférés lehetséges hatása.

A 2FA sem tesz feltörhetetlenné egy WordPress oldalt. Egy sérülékeny plugin problémáját például nem javítja meg, és más támadási utakat sem zár le.

A bejelentkezési hozzáférés védelmét viszont jelentősen erősíti ahhoz képest, amikor kizárólag egy jelszóra támaszkodunk.

A bejelentkezési próbálkozásokat is érdemes védeni

A 2FA mellett külön kérdés az automatizált bejelentkezési próbálkozások és más nagy mennyiségű nem kívánt forgalom kezelése.

Erre szolgálhat többek között:

rate limiting;
login protection;
bizonyos botvédelmi megoldások;
alkalmazás-, webszerver- vagy WAF-szintű korlátozás.

A rate limiting lényege, hogy meghatározott feltételek alapján korlátozható, milyen gyakran érkezhetnek bizonyos kérések. Ez használható például egy login végpontot érő automatizált próbálkozások csökkentésére. A WordPress hivatalos brute force útmutatója is javasolja a bejelentkezési próbálkozások korlátozását, akár edge/WAF, akár webszerver szinten. (Brute Force Attacks) (developer.wordpress.org)

Itt viszont könnyű túl agresszív szabályt készíteni.

Nem jó univerzális recept például abból kiindulni, hogy néhány hibás jelszó után hosszú időre automatikusan tiltani kell egy IP-címet. Egyetlen publikus IP mögött több legitim felhasználó is lehet NAT, vállalati hálózat vagy más megosztott kapcsolat miatt. VPN-ek, mobilhálózatok és dinamikus IP-címek szintén megnehezítik az egyszerű IP-alapú következtetéseket.

A login protection célja nem az, hogy a legitim felhasználókat is kizárjuk, hanem hogy az adott oldal használatához és forgalmához illeszkedő módon csökkentsük az automatizált visszaélések hatását.

Ne csak a WordPress-jelszóra gondolj

Egy WordPress oldalhoz általában nem csak a /wp-admin felületen keresztül lehet hozzáférni.

A környezettől függően lehet:

tárhelyszolgáltatói hozzáférés;
SFTP vagy FTP;
SSH;
adatbázis-hozzáférés;
deployment rendszer;
DNS- vagy domainkezelő fiók;
e-mail-fiók, amelyen keresztül jelszó-visszaállítás kezdeményezhető.

Ezek közül néhány még nagyobb hozzáférést biztosíthat, mint maga a WordPress admin.

Hiába nagyon erős tehát a WordPress adminisztrátori jelszó, ha ugyanahhoz a rendszerhez egy régen létrehozott FTP-fiókkal, gyenge hosting jelszóval vagy már nem használt fejlesztői hozzáféréssel továbbra is be lehet jutni.

A biztonsági felülvizsgálatnál ezért érdemes a teljes hozzáférési láncot látni, nem csak a WordPress felhasználókat.

Nézd át az Application Passwords és más integrációk hozzáféréseit is

A WordPress támogat úgynevezett Application Passwords hozzáféréseket.

Ezek külön, visszavonható, egy adott WordPress-felhasználóhoz kapcsolódó hitelesítési adatok, amelyeket programozott hozzáféréshez lehet használni, például egy alkalmazás, integráció vagy script számára. Nem a normál böngészős bejelentkezés helyettesítésére készültek. (Application Passwords) (developer.wordpress.org)

Az Application Passwords önmagában nem biztonsági probléma. Egyik előnyük éppen az, hogy egy integrációnak nem kell átadni a felhasználó normál WordPress-jelszavát, az alkalmazáshoz tartozó hozzáférés pedig külön visszavonható. (developer.wordpress.org)

A probléma inkább az lehet, ha évek alatt több integráció kerül az oldalra, majd később már senki nem tudja, melyik hozzáférés mire szolgál.

Érdemes ezért időnként felülvizsgálni:

milyen alkalmazás-hozzáférések léteznek;
melyikre van még szükség;
melyik felhasználóhoz tartoznak;
megfelelő-e az adott felhasználó jogosultsága.

Ugyanez az elv más API-kulcsokra és integrációs hitelesítési adatokra is alkalmazható.

Az API-kulcs és más secret is hozzáférési adat

Egy modern WordPress oldal a normál felhasználói jelszavakon és Application Passwords hozzáféréseken kívül más érzékeny hitelesítési adatokat is használhat.

Ilyen lehet például:

külső API-kulcs;
SMTP hitelesítési adat;
fizetési szolgáltatáshoz tartozó secret;
webhook secret;
deployment token;
más integrációs hozzáférés.

Ezekre érdemes ugyanolyan érzékeny hozzáférési adatként gondolni, mint egy jelszóra.

Egy szerveroldali secret például ne kerüljön indokolatlanul publikus repositoryba, nyilvános dokumentációba vagy kliensoldali JavaScriptbe, ha annak ott nincs helye. Ugyanígy nem jó, ha olyan emberek vagy rendszerek férnek hozzá, amelyeknek nincs rá szükségük.

A pontos tárolási mód környezetfüggő. Egy egyszerű WordPress oldalnak nem feltétlenül van szüksége külön vállalati secret management infrastruktúrára.

Az alapelv sokkal fontosabb: tudd, milyen érzékeny hitelesítési adatok tartoznak az oldalhoz, hol vannak tárolva, mire használják őket, és kinek van hozzáférése hozzájuk.

HTTPS legyen az egész oldalon, különösen az adminisztrációban

A HTTPS nem csak a böngészőben megjelenő lakat miatt fontos.

A titkosított kapcsolat védi a böngésző és a szerver között továbbított adatokat attól, hogy azok egyszerűen olvasható formában utazzanak a hálózaton.

A WordPress hivatalos dokumentációja kifejezetten ajánlja a HTTPS használatát a WordPress-bejelentkezések és a látogatók biztonsága érdekében. (HTTPS) (developer.wordpress.org)

Ma már egy normál WordPress weboldalnál nem igazán érdemes úgy tervezni, hogy csak bizonyos admin oldalak használjanak HTTPS-t, miközben az oldal többi része HTTP-n működik.

Az ésszerű alap az, hogy az egész weboldal HTTPS-en legyen elérhető.

A WordPress előtt is lehet védelmi réteg

Egy WordPress oldal technikai felépítése nem feltétlenül úgy néz ki, hogy a látogató közvetlenül a WordPresst kiszolgáló webszerverhez kapcsolódik.

Bizonyos környezetekben a folyamat például ilyen lehet:

látogató → CDN / reverse proxy / WAF → webszerver → WordPress

Nem minden oldal használ ilyen architektúrát, és önmagában ettől még egy rendszer nem lesz biztonságosabb.

Egy reverse proxy a látogató és a háttérben futó webszerver közé kerül. Egy CDN emellett többek között statikus tartalmak kiszolgálásában és forgalomkezelésben is részt vehet. Ezekhez kapcsolódhat WAF, vagyis Web Application Firewall is.

A WAF bizonyos rosszindulatú vagy nem kívánt HTTP-kéréseket képes szabályok alapján szűrni még azelőtt, hogy azok elérnék az alkalmazást. Ismert példa ilyen szolgáltatásra a Cloudflare, de hasonló képesség több szolgáltatónál vagy hosting környezetben is elérhető. A WAF-ok kezelhetnek egyedi vagy menedzselt szűrési szabályokat, valamint rate limitinget is. (developers.cloudflare.com)

Ennek lehet értéke például automatizált rosszindulatú forgalom vagy egyes ismert támadási minták kezelésében.

Egy WAF viszont nem helyettesíti:

a WordPress és a komponensek frissítését;
a biztonságos alkalmazáskódot;
a megfelelő jogosultságkezelést;
a 2FA-t;
a megfelelő szerverkonfigurációt;
vagy a rendszeres üzemeltetést.

Ha az alkalmazásban van egy sérülékenység, abból nem érdemes kiindulni, hogy azt a WAF biztosan minden esetben meg fogja állítani.

Ez egy további védelmi réteg, nem a többi réteg helyettesítője.

A fájl- és szerverjogosultságok se legyenek indokolatlanul lazák

WordPress esetén időnként előfordul, hogy egy jogosultsági problémát azzal „javítanak meg”, hogy a fájlok vagy könyvtárak a szükségesnél jóval szélesebb írási jogosultságot kapnak.

Ez lehet, hogy rövid távon megszüntet egy telepítési vagy frissítési hibát, de biztonsági szempontból rossz irány.

A WordPress hardening dokumentációja külön foglalkozik a fájljogosultságokkal, és abból indul ki, hogy a különböző fájlokhoz csak az kapjon írási hozzáférést, akinek arra ténylegesen szüksége van. (Hardening WordPress) (developer.wordpress.org)

A pontos beállítás függ a tárhely és a szerver architektúrájától, ezért univerzális jogosultságszámokat nem érdemes vakon minden környezetre ráhúzni.

Ha egy plugin csak akkor működik, amikor gyakorlatilag mindenki írhat mindenhová, inkább azt érdemes megérteni, miért van erre szüksége.

A `wp-config.php` külön figyelmet érdemel

A wp-config.php a WordPress egyik fontos konfigurációs fájlja. Többek között az adatbázis-kapcsolathoz és más WordPress-beállításokhoz szükséges adatokat tartalmazhat.

Emiatt nem érdemes egyszerűen ugyanolyan fájlként kezelni, mint egy nyilvánosan kiszolgált statikus képet.

A WordPress hivatalos dokumentációja több, wp-config.php-hoz kapcsolódó biztonsági és fejlett konfigurációs lehetőséget is ismertet.

Itt sem az a cél, hogy minél több interneten talált „hardening snippet” kerüljön a fájlba.

A kevesebb, de érthető és a konkrét környezethez illeszkedő beállítás jobb, mint egy hosszú konfiguráció, amelyről később senki nem tudja, mit csinál.

Kapcsold ki a nyilvános hibamegjelenítést éles oldalon

Fejlesztés közben hasznos, ha egy hiba részletes információt ad.

Éles weboldalon viszont nem jó, ha a látogató előtt jelennek meg PHP-hibák, fájlútvonalak vagy más belső technikai részletek.

A WordPress hivatalos hardening dokumentációja ezért külön kezeli a hibák megjelenítésének kérdését. (Hardening WordPress) (developer.wordpress.org)

Ez nem azt jelenti, hogy a hibákat el kell rejteni az üzemeltető elől.

Éppen ellenkezőleg: a cél az, hogy szükség esetén naplózva legyenek, de ne a publikus weboldalon jelenjenek meg részletes technikai információként.

Az XML-RPC-t se tiltsd le csak egy checklist kedvéért

WordPress security checklistekben gyakran szerepel az XML-RPC kikapcsolása.

Az XML-RPC egy WordPress API, amelyet különböző külső kliensek és integrációk használhatnak. A WordPressben alapértelmezetten elérhető funkció, és a hivatalos dokumentáció külön API-ként kezeli. (developer.wordpress.org)

Biztonsági szempontból az XML-RPC lehet automatizált visszaélések egyik célpontja. A WordPress aktuális brute force útmutatója ezért azt javasolja, hogy ha nincs rá szükség, korlátozható vagy kikapcsolható, használat esetén pedig megfelelő védelem és rate limiting alkalmazható. (developer.wordpress.org)

A „kapcsold ki minden WordPress oldalon” viszont túl egyszerű tanács.

Ha egy ténylegesen használt szolgáltatás vagy integráció függ az XML-RPC-től, a vak kikapcsolás működési problémát okozhat.

Először ezért azt érdemes tisztázni:

használja-e valami;
szükség van-e rá;
milyen kockázatot szeretnél kezelni;
és ehhez valóban a teljes kikapcsolás-e az ésszerű megoldás.

Ez ugyanaz a szemlélet, mint a többi hardening beállításnál: ne azért tiltsunk le valamit, mert szerepel egy listán, hanem azért, mert értjük a funkcióját és a konkrét kockázatot.

A biztonsági mentés is a WordPress biztonság része

Egy mentés nem akadályozza meg, hogy az oldal kompromittálódjon.

Mégis az egyik legfontosabb biztonsági alap.

Ha valami komoly probléma történik, nagy különbség van aközött, hogy van egy ellenőrzött, visszaállítható korábbi állapotod, vagy csak abban bízol, hogy a tárhelyszolgáltató talán készített valamilyen mentést.

A WordPress hivatalos dokumentációja szerint egy tipikus WordPress oldal teljes visszaállításához a fájlokra és az adatbázisra is szükség van. (Backups) (developer.wordpress.org)

Fontos azonban, hogy a backup nem lesz automatikusan jó attól, hogy létezik.

Érdemes tudni:

pontosan mi kerül bele;
milyen gyakran készül;
mennyi ideig marad meg;
hol tárolódik;
vissza lehet-e valóban állítani.

Azt is érdemes átgondolni, mennyire van elkülönítve a mentés az éles rendszertől.

Ha az éles weboldal és az egyetlen backup ugyanazon a szerveren vagy ugyanabban a könnyen együtt érinthető környezetben található, akkor egy komolyabb infrastruktúrahiba vagy biztonsági incidens egyszerre veszélyeztetheti mindkettőt.

Ezért érdemes legalább egy megfelelően elkülönített mentési példányban gondolkodni. Ezt gyakran off-site backupnak nevezik: a lényeg nem egy konkrét szolgáltató vagy technológia, hanem az, hogy ne minden visszaállítási lehetőség ugyanattól az egyetlen rendszertől függjön.

A WordPress fájlmentési dokumentációja is azt javasolja, hogy ne kizárólag a tárhelyszolgáltató szerverén lévő mentésre támaszkodjunk. (developer.wordpress.org)

A mentés részletesebb megtervezése külön téma, ezért ezt a Biztonsági mentés WordPresshez: mit, milyen gyakran és hova érdemes menteni? cikkben érdemes tovább bontani.

A staging és fejlesztői környezet se maradjon védtelen

Egy staging oldal attól még nem érdektelen biztonsági szempontból, hogy nem az éles domainen működik vagy normál esetben nem használják látogatók.

Egy staging vagy fejlesztői környezet tartalmazhat például:

az éles adatbázisból készült másolatot;
felhasználói vagy ügyféladatokat;
adminisztrátori fiókokat;
API-kulcsokat;
más secreteket;
az éles környezethez hasonló konfigurációt.

Emellett egy nem megfelelően izolált fejlesztői környezet más rendszerekhez vagy akár éles szolgáltatásokhoz is kapcsolódhat.

Ezért az, hogy „ez csak staging”, nem jó indok arra, hogy régi komponensekkel, gyenge hozzáférés-védelemmel vagy szükségtelenül nyilvánosan működjön.

Ez nem jelenti azt, hogy minden staging környezetet pontosan ugyanúgy kell felépíteni és védeni, mint az éles rendszert.

Azt viszont érdemes végiggondolni, milyen adatok és hitelesítési adatok kerülnek bele, ki férhet hozzá, milyen rendszerekhez kapcsolódhat, és valóban szükséges-e nyilvánosan elérhetőnek lennie.

Legyen valamilyen monitoring, ne csak akkor nézz az oldalra, amikor már baj van

Egy weboldal akár úgy is hibásan működhet, hogy a tulajdonos napokig nem veszi észre.

Biztonsági problémánál ugyanez igaz.

A monitoring célja nem kizárólag az, hogy megmondja: „feltörték az oldalt”. Ennél reálisabban arra jó, hogy bizonyos rendellenességekről vagy változásokról hamarabb tudomást szerezz.

Lehet például:

uptime monitoring;
fájlváltozások figyelése;
biztonsági események naplózása;
sikertelen belépések követése;
frissítési hibák figyelése;
szolgáltatói biztonsági értesítések.

A WordPress hivatalos dokumentációja is külön üzemeltetési területként foglalkozik a monitoringgal. (Monitoring) (developer.wordpress.org)

Itt sem az a cél, hogy minden lehetséges eseményről e-mail érkezzen. Ha egy monitoring rendszer naponta száz érdektelen riasztást küld, egy idő után senki nem fogja őket elolvasni.

Olyan jelzéseknek van értelmük, amelyekből valóban következik valamilyen ellenőrzendő feladat.

A naplózás akkor a leghasznosabb, amikor még nem történt incidens

Egy kompromittálás után gyakori kérdés, hogy pontosan mikor és hogyan történt a jogosulatlan módosítás.

Ilyenkor a megfelelő naplók sokat segíthetnek.

Csakhogy naplózást utólag már nem lehet visszamenőleg létrehozni.

A környezettől függően hasznos lehet például:

webszerver access log;
error log;
hosting security log;
autentikációs események;
releváns alkalmazás- vagy rendszerlog.

Azt is érdemes előre tudni, mennyi ideig őrzi meg ezeket a szolgáltató vagy a rendszer.

A hosszabb naplómegőrzés önmagában nem jelent jobb biztonságot, és természetesen adatvédelmi, tárhely- és üzemeltetési szempontjai is vannak. A lényeg az, hogy egy fontos eseménynél ne akkor derüljön ki először, hogy a szükséges log soha nem is készült, vagy már törlődött.

A log pedig önmagában nem garantálja, hogy egy későbbi támadás teljes története rekonstruálható lesz. Bizonyítékot és támpontot adhat, de csak olyan eseményekről, amelyeket az adott rendszer ténylegesen rögzített.

A security plugin hasznos lehet, de nem helyettesíti az alapokat

Egy jó WordPress biztonsági plugin tud hasznos funkciókat adni.

A konkrét terméktől függően lehet benne például:

bejelentkezés-védelem;
2FA;
fájlváltozások ellenőrzése;
biztonsági naplózás;
értesítés;
bizonyos támadások szűrése.

A problémát az okozza, amikor maga a plugin válik a teljes biztonsági stratégiává.

Egy security plugin nem teszi feleslegessé:

a frissítéseket;
az erős és egyedi hozzáféréseket;
a megfelelő jogosultságokat;
a tárhely és a szerver megfelelő konfigurációját;
a mentéseket;
a monitoringot.

És attól sem lesz egy oldal automatikusan biztonságosabb, hogy egyszerre három különböző security plugin fut rajta.

Érdemes először azt eldönteni, milyen problémát akarunk megoldani, és csak utána eszközt választani rá.

A „wp-admin URL elrejtése” nem legyen a biztonsági stratégia alapja

Gyakori WordPress biztonsági tanács a bejelentkezési URL megváltoztatása.

Ennek lehet gyakorlati haszna. Csökkentheti például az alapértelmezett belépési URL-t automatikusan próbálgató forgalom egy részét, és bizonyos környezetben kevesebb felesleges login próbálkozást eredményezhet.

De ettől még nem érdemes úgy kezelni, mintha maga lenne a WordPress adminisztráció védelme.

Ha valaki megszerzi az adminisztrátori jelszót és a tényleges bejelentkezési URL-t, az URL átnevezése már nem véd.

Ugyanezért fontosabb alap:

az egyedi jelszó;
a kétlépcsős hitelesítés;
a felesleges admin fiókok eltávolítása;
az aktuális komponensek;
a hozzáférések rendszeres felülvizsgálata.

Az URL megváltoztatása lehet egy plusz réteg vagy üzemeltetési döntés, de nem helyettesíti ezeket.

Nem minden biztonsági tanács javít ténylegesen a helyzeten

WordPress security témában rengeteg olyan checklist kering, amelyben egymás mellett szerepelnek fontos beállítások és olyan változtatások, amelyeknek legfeljebb korlátozott jelentőségük van.

Ilyen lehet például, amikor valaki kizárólag azért:

átnevez bizonyos URL-eket;
rengeteg tiltó szabályt másol a szerverkonfigurációba;
minden ismeretlen kérést IP-cím alapján próbál blokkolni;
vagy telepít több, egymást átfedő biztonsági plugint.

Ezek között lehet hasznos megoldás is, de nem attól jó egy WordPress biztonsági konfiguráció, hogy minél hosszabb a hardening checklist.

Az XML-RPC jó példa erre. Egy funkció letiltása lehet teljesen indokolt egy adott oldalon, de csak akkor érdemes megtenni, ha értjük, hogy az oldal használja-e, és milyen problémát szeretnénk a változtatással kezelni.

Az a fontos, hogy a fő kockázatok kezelve legyenek, és az üzemeltető értse is, milyen szabály miért került a rendszerbe.

A WordPressen kívüli környezet ugyanúgy számít

A WordPress csak egy alkalmazás a mögötte és adott esetben előtte lévő technikai rendszerben.

Ha a hosting fiók hozzáférése kompromittálódik, a szerver nincs megfelelően karbantartva, vagy egy másik, ugyanazon környezetben futó alkalmazáson keresztül hozzá lehet férni az oldal fájljaihoz, azt egy WordPress plugin nem feltétlenül tudja megoldani.

Bizonyos architektúrákban a WordPress előtt proxy, CDN vagy WAF is működhet. Ezek további védelmi lehetőségeket adhatnak, de szintén nem helyettesítik a mögöttük futó alkalmazás és szerver megfelelő kezelését.

Ezért egy WordPress oldal biztonságát több rétegben érdemes vizsgálni: az oldal előtt működő CDN, reverse proxy vagy WAF; maga a WordPress és a telepített komponensek; a felhasználók és integrációk; a fájlok és az adatbázis; a tárhely vagy szerver; valamint a kapcsolódó fiókok és eszközök.

Nem minden WordPress oldal rendelkezik minden felsorolt réteggel, és nem feltétlenül te kezeled mindegyiket. Shared hostingnál például a szerver jelentős részéért a szolgáltató felel.

De azt érdemes tudni, hogy melyik rész kinek a felelőssége.

Mit érdemes elsőként beállítani egy WordPress oldalon?

Ha nem egy teljes hardening projektet akarsz indítani, hanem a legfontosabb alapokat szeretnéd rendbe tenni, én nagyjából ebben a sorrendben gondolkodnék:

Legyen naprakész a WordPress, a pluginok és a sablonok.
Távolítsd el a ténylegesen nem használt komponenseket és fiókokat.
Használj minden fontos hozzáféréshez egyedi, erős jelszót, a magas jogosultságú fiókoknál pedig kezeld alapkövetelményként a 2FA-t.
Nézd át az adminisztrátori és WordPressen kívüli hozzáféréseket, valamint a használatban lévő Application Passwords, API- és integrációs hozzáféréseket.
Tartsd számon és megfelelően védd az API-kulcsokat, tokeneket és más secreteket.
Legyen HTTPS az egész weboldalon.
A kockázathoz és forgalomhoz igazodva használj megfelelő login protectiont, rate limitinget, illetve ahol indokolt, proxy/CDN/WAF védelmi réteget.
Legyen működő, visszaállítható és megfelelően elkülönített mentés.
Legyen alapvető monitoring és megfelelő naplózás.
A staging és más kapcsolódó környezeteket se hagyd régi komponensekkel vagy indokolatlanul gyenge hozzáférés-védelemmel.
Legyen folyamat arra, hogy ezeket később is rendszeresen felülvizsgáld.

Az utolsó pont könnyen kimarad.

Pedig a WordPress biztonság nem egyszeri beállítás.

Egy ma szükséges adminisztrátori fiók fél év múlva már lehet felesleges. Egy plugin, amelyet ma aktívan fejlesztenek, később elhagyottá válhat. Új integrációk, API-kulcsok és hozzáférések kerülhetnek a rendszerbe. Egy ideiglenes staging környezet pedig könnyen hosszabb életűvé válhat, mint eredetileg tervezték.

Ezért az egyszer elvégzett hardeningnél fontosabb, hogy a weboldalnak legyen normális üzemeltetési folyamata.

Mi történik, ha ezek ellenére feltörik az oldalt?

A megelőző intézkedések célja a kockázat csökkentése, nem a 100%-os garancia.

Ha egy WordPress oldalon gyanús módosítást, malware-t, ismeretlen adminisztrátort vagy más kompromittálásra utaló jelet találsz, onnantól már nem a megelőző beállítások finomhangolása az első feladat.

A konkrét helyreállítási lépésekkel külön foglalkozom a Feltörték a WordPress oldalam: mit tegyek? cikkben.

Ha pedig már megtisztítottad az oldalt, de ugyanaz vagy egy hasonló probléma újra megjelenik, akkor azt érdemes vizsgálni, mi teszi lehetővé a visszatérést. Erről szól a Miért fertőződik újra a WordPress oldal a tisztítás után? cikk.

Gyakori kérdések

Kell security plugin minden WordPress oldalra?

Nem feltétlenül ugyanaz a plugin vagy ugyanaz a funkciókészlet szükséges minden oldalhoz.

Egy security plugin hasznos eszköz lehet például 2FA-hoz, naplózáshoz, fájlellenőrzéshez vagy bizonyos támadások szűréséhez. Ettől azonban az alapvető üzemeltetési és hozzáférés-kezelési feladatok nem válnak feleslegessé.

Először azt érdemes meghatározni, milyen védelmi funkcióra van szükséged, és utána választani eszközt.

Elég a WordPresst és a pluginokat rendszeresen frissíteni?

Nagyon fontos, de önmagában nem elég.

A frissítések mellett ugyanúgy számítanak a felhasználói hozzáférések, a jelszavak, a kétlépcsős hitelesítés, a tárhely, a fájljogosultságok, a mentések és a monitoring.

Kell 2FA a WordPresshez?

Adminisztrátori és más magas jogosultságú fiókoknál a 2FA-t érdemes alapvető biztonsági követelményként kezelni. A WordPress hivatalos brute force útmutatója is a 2FA engedélyezését javasolja az adminisztrátori fiókok számára. (developer.wordpress.org)

A 2FA nem old meg minden WordPress biztonsági problémát. Nem javít ki sérülékeny plugint, és nem helyettesíti a frissítéseket vagy a többi védelmi réteget.

Egy megszerzett jelszóval történő bejelentkezés kockázatát viszont jelentősen csökkentheti.

Kell WAF egy WordPress oldal elé?

Nem minden WordPress oldalnak van szüksége pontosan ugyanarra az infrastruktúrára.

Egy megfelelően konfigurált WAF hasznos további védelmi réteg lehet, mert bizonyos rosszindulatú vagy nem kívánt HTTP-kéréseket már azelőtt szűrhet, hogy azok elérnék magát az alkalmazást. WAF-szinten rate limiting és más forgalomkezelési szabályok is megvalósíthatók. (developers.cloudflare.com)

Ez azonban nem helyettesíti a WordPress frissítését, a megfelelő jogosultságokat, a 2FA-t vagy a biztonságos üzemeltetést.

Biztonságosabb lesz a WordPress, ha megváltoztatom a wp-admin URL-t?

Bizonyos automatikus próbálkozások és felesleges login forgalom csökkentésére hasznos lehet, de nem helyettesíti a valódi hozzáférés-védelmet.

Egyedi jelszó, 2FA, megfelelő jogosultságok és a rendszeres frissítés fontosabb biztonsági alapok.

Az inaktív plugin jelent biztonsági kockázatot?

Az inaktív plugin nem fut ugyanúgy, mint egy aktív plugin, de a fájljai továbbra is jelen lehetnek a szerveren.

Ha nincs rá szükség, általában ésszerűbb eltávolítani, mint évekig ott tartani és külön gondoskodni a karbantartásáról.

Elég, ha a tárhelyszolgáltató készít mentést?

Lehet, hogy igen, de ezt nem érdemes feltételezni.

Meg kell nézni, pontosan mit ment a szolgáltató, milyen gyakran, mennyi ideig őrzi meg, hogyan működik a visszaállítás, és mennyire független ez a mentés magától az éles rendszertől.

Egy backup rendszer értékét végül az mutatja meg, hogy szükség esetén ténylegesen vissza tudsz-e belőle állni.

Van olyan WordPress biztonsági beállítás, amely garantálja, hogy nem törik fel az oldalt?

Nincs.

A biztonsági beállítások célja a támadási lehetőségek csökkentése, a hozzáférések védelme, egy esetleges kompromittálás hatásának korlátozása és a problémák gyorsabb észlelése.

A WAF, a 2FA, a backup, a monitoring vagy egy security plugin külön-külön sem ad 100%-os biztonságot.

A jó WordPress biztonság ezért nem egyetlen kapcsoló vagy plugin, hanem több, egymást kiegészítő réteg.