Feltört WordPress, amit senki nem vett észre – esettanulmány

Egy „adatbázis-hiba”, ami valójában feltörés volt

Egy magyar rajongói közösség WordPress-oldalán 354 kamu adminisztrátort, 4 webshellt és 25 rejtett hátsó kaput (backdoort) találtam. A backdoor olyan rejtett belépési pont egy rendszerben, amely megkerüli a szokásos bejelentkezést és biztonsági ellenőrzéseket. Az oldal kívülről hónapokig teljesen normálisan működött. A gazdája semmit nem vett észre, csak egy átmeneti adatbázis-hibát.

Az esetet a domain neve nélkül írom le (a cikkben: ügyfeloldal.hu). A támadók által létrehozott fiókok, fájlnevek és dátumok viszont valódiak. Azért mutatom meg őket, mert jól látszik belőlük, hogyan néz ki egy feltört WordPress belülről – és hogy miért nem elég, ha az oldal „megy”.

Ha WordPress-oldalad van, ez a cikk neked szól. Ha fejlesztő vagy üzemeltető vagy, a technikai részeket ellenőrzőlistaként is használhatod.

Hogyan vettem észre

A bejelentés egyszerű volt: az oldal időnként „Hiba az adatbázis-kapcsolat létrehozásakor” üzenetet adott. Először egy sérült, üres wp-config.php gyanúja merült fel, de ez nem igazolódott, a hiba pedig estére magától megszűnt.

A hibakeresés közben azonban több apró, gyanús jel jött elő:

A tárhelyszolgáltató néhány nappal korábban csak olvashatóvá tette a webtárhely gyökerét, és egy diagnosztikai phpinfo fájlt hagyott ott. Ez általában annak a jele, hogy a szolgáltató is látott valamit.
Az adminisztrátorok listájában nem 3–4, hanem 357 admin jogú fiók volt.
A bővítmények között három ismeretlen nevű plugin futott (wp-core-e58e623a, w2s-fire-108929, w2s-guard-108929), a témák között pedig egy twk-d214b95f nevű.

Innentől már nem egy adatbázis-hibát kerestem, hanem egy feltört oldalt térképeztem fel. A legfontosabb tanulság már itt: a fertőzés hónapokig semmilyen látható tünetet nem okozott. Nem jelent meg rajta kaszinóreklám, nem lassult be, nem írt a Google. Ha nincs az a véletlen adatbázis-hiba, talán ma sem tudna róla senki.

Mit találtam: két külön fertőzés egymáson

Az oldalon két, egymástól független támadás nyomai voltak: egy friss, 2026 nyári automatizált hullám és egy 2024 eleje óta ott lapuló backdoor-hálózat.

Mikor	Mi történt
2026. november 10.	Adatbázis-hiba, vizsgálat és takarítás ugyanazon a napon
2026. november eleje	A szolgáltató csak olvashatóvá teszi a webtárhely gyökerét
2026. augusztus 16.	Felkerül három webshell-plugin és egy áltéma; az utolsó kamu admin létrehozása
2026. augusztus 8–15.	A csúcs: napi 29–40 új kamu adminisztrátor
2026. július 21.	Az első kamu adminisztrátor létrejötte
2024. január–március	A backdoorok fájljainak (hamisított) dátuma

1. A 2026 nyári hullám: 354 kamu adminisztrátor

Négy hét alatt 354 admin jogú fiók jött létre. A nevek és e-mail-címek egyértelműen automatizált eszközre utalnak: az álneveik GitHubon nyilvánosan elérhető wp2shell nevű bizonyító kódokra (PoC) mutatnak. Ilyen eszközt bárki letölthet, és tömeges szkennelésre használhat.

E-mail-domain	Fiókok száma	Példa felhasználónév
wp2shell.local	297	`w2s_6a413adc8acb`
bobresearchlabs.com	21	`bob_6c2e23e2cb03`
wp2shell.invalid	11	`wp2_ca305837`, `ngx_33`
az oldal saját domainje	8	–
nx.invalid	4	–
wordpress.org	3	–
local.host	3	–
egyéb (service.localhost, dapur.mbg, wordpress-svc.internal, shellcode.lol, exam.com)	7	–

A fiókok mellett az adatbázisban a támadás melléktermékei is ott maradtak:

363 adatkezelési kérelem (request) és 363 testreszabási változatkészlet (customize_changeset), mind 2020. január 1. 00:00:00 dátummal – ez a támadási technika ujjlenyomata;
két „x” című bejegyzés a revízióival;
392 oEmbed gyorsítótár-sor;
3222 árva metaadat-sor, köztük menüpontokhoz rendelt GitHub-linkek (github.com/BOB-RESEARCH-LABS, github.com/dinosn/wp2shell-lab, github.com/sergiointel/wp2shell-poc).

A számokból látszik a lényeg: ez nem egy célzott támadás volt, hanem több, egymástól független automata, amelyek mind ugyanazt a rést találták meg. Egy támadó nem regisztrál 354 admint. Sok, egymás után érkező robot viszont igen.

2. Webshellek – a távoli vezérlőpult

Augusztus 16-án három plugin és egy téma került fel, ami valójában webshell volt: egy böngészőből hívható PHP-kód, amivel a támadó tetszőleges parancsot futtathat a szerveren.

wp-content/plugins/wp-core-e58e623a/ – a neve szándékosan „core”, hogy hivatalosnak tűnjön
wp-content/plugins/w2s-fire-108929/ és w2s-guard-108929/
wp-content/themes/twk-d214b95f/

Három közülük aktív bővítményként futott: az aktív pluginok száma 14 helyett 17 volt.

3. A 2024-es backdoor-hálózat

A fájlok átvizsgálásakor egy régebbi, sokkal óvatosabb fertőzés is előkerült: 25 elrejtett, obfuszkált PHP-fájl. Az obfuszkált kódot szándékosan olvashatatlanná teszik: a működése nem változik, de sem egy ember, sem egy vírusirtó nem ismeri fel első ránézésre, mit csinál. Ezek a fájlok egy sütiben vagy POST-kérésben küldött kódot futtatnak le – a támadónak elég tudnia a fájl címét.

Hely	Darab	Példák
WordPress core mappái (`wp-admin`, `wp-includes`)	17	`wp-includes/images/rweyopgm.php`, `wp-includes/blocks/shortcode/admin.php`, `wp-includes/js/crop/profile.php`, `wp-admin/wp-login.php`
BeTheme téma	7	`functions/widgets/67efc93d.php`, `muffin-options/validation/email/css.php`
Feltöltések (`uploads`)	1	`wpallimport/files/lkjefufq.php`

Az álcázás módszerei tanulságosak:

Hihető nevek a helyükön: admin.php, options.php, profile.php olyan mappákban, ahol nincs ilyen fájl. A wp-admin/wp-login.php különösen alattomos, mert az igazi a gyökérben van.
Rejtett fájlok kamu kiterjesztéssel: .40d7d084.ccss, .19cd7505.ccss – a pont miatt az FTP-kliensek alapból nem mutatják, a „ccss” pedig stíluslapnak tűnik.
Véletlen nevek: iqtcfvov.php, 68c49fa6.php, gealzxjd.php.
Hamisított dátumok: a fájlok 2024. januári és márciusi dátumot viseltek, hogy a „legutóbb módosult fájlok” listájában ne tűnjenek fel.
Elrejtett kód: a függvényneveket chr()-hívásokból rakják össze, köztük kommentekkel (chr /* x */ (115)), így a sima szövegkeresés nem találja meg az eval vagy assert szót.

Ez a hálózat nagy valószínűséggel évekig észrevétlenül ült az oldalon. Aki ismerte a címeket, bármikor visszajöhetett.

Mit akartak a támadók?

A két támadás nem épült egymásra, és mást akart. A 2024-es csendben a látogatókból akart pénzt csinálni, a 2026-os pedig hozzáférést gyűjtött. Ezt a backdoorok visszafejtett kódjából lehet kiolvasni. A kódot nem futtattam, csak elolvastam.

2024: rejtett forgalomterelés

A 25 fájl három szerepet töltött be:

Telepítő. Egy titkosított POST-kérésre tetszőleges PHP-fájlt ír az oldal egy véletlenszerűen választott, írható mappájába, véletlen, 8 karakteres néven, és visszaküldi a címét. Ez magyarázza, miért szóródtak szét a fájlok a core-mappákban.
Távirányító. Sütiben vagy POST-kérésben küldött kódot futtat le, így a támadó bármikor bármit végrehajthat.
Modultároló. A három .ccss fájl a saját végén titkosított modulokat tárol, és azokat minden betöltéskor lefuttatja. Mindháromban ugyanaz az egy modul volt: TdsClient.

A TDS (Traffic Distribution System) forgalomterelő rendszer. A modul minden oldalmegtekintésnél eldönti, hogy a látogató „használható”-e. Csak akkor lép működésbe, ha mind igaz:

a látogató Google-, Facebook-, Instagram-, TikTok-, YouTube-, Bing- vagy más kereső- vagy közösségi találatról érkezik, és ez a látogatás első oldala;
a böngésző nem robot (a Google- és Bing-robotokat, keresőket és szkennereket kiszűri);
nem az admin felületet, a belépési oldalt, a hírcsatornát vagy egy kép-, stílus- vagy szkriptfájlt kéri.

Ha a látogató megfelel, a modul elküldi az IP-címét, a böngészőjét, a nyelvét, a hivatkozó oldalt és a sütijeit a támadók szerverének (178.63.30.115). Az onnan kapott válasz alapján sütit állít be, JavaScriptet szúr az oldalba, vagy az egész oldalt lecseréli, például egy átirányításra. Hogy a látogató pontosan hova került volna, azt a kódból nem lehet tudni, mert a tartalmat a távoli szerver adja menet közben. Az ilyen rendszereket jellemzően csaló oldalakra, kamu nyereményjátékokra, értesítés-spamre vagy kártevő-letöltésre tereléshez használják.

Ez tehát nagyon is rejtőzködni akart. Az oldal gazdája jellemzően beírja a címet, vagy belülről kattint, ilyenkor semmit nem lát. A Google robotja sem lát semmit, így a kereső sem figyelmeztet. Csak az idegen, keresőből érkező látogatók tévednek el – és ők ritkán szólnak.

A felfedezés pillanatában a forgalomterelő valószínűleg nem futott. A .ccss fájlokat a PHP magától nem hajtja végre, és sem a fájlokban, sem az adatbázisban nem találtam betöltőt, ami meghívta volna őket. A betöltőt nagy valószínűséggel egy későbbi WordPress- vagy témafrissítés írta felül. A telepítő és a távirányító viszont működőképes volt, így a támadó bármikor újraéleszthette volna.

2026: a wp2shell és a hozzáférések gyűjtése

A nyári hullám belépési pontja ismert. A wp2shell két WordPress-core hiba láncolata (CVE-2026-63030 és CVE-2026-60137): a REST API kötegelt végpontján (/wp-json/batch/v1) keresztül bejelentkezés nélkül lehet adminisztrátort létrehozni, onnan pedig kódot futtatni. A hibát 2026. július 17-én hozták nyilvánosságra, és ugyanekkor javították a 6.9.5-ös és 7.0.2-es WordPressben. Az oldal a sérülékeny 6.9.3-on futott. Az első kamu admin július 21-én hajnalban jött létre – négy nappal a javítás megjelenése után. A 2020-01-01 dátumú kérelmek és változatkészletek ennek a támadási láncnak a melléktermékei.

Ez a négy nap elég lett volna a védekezésre. Ezért kell egy fejlesztőnek folyamatosan követnie a WordPress, a PHP és a szerver operációs rendszerének (Ubuntu, Debian) biztonsági közleményeit, a biztonsági cégek blogjait és a szakmai közösségeket, például a Reddit WordPress- és rendszergazda-csatornáit. Egy ilyen hír után órákon, legfeljebb napokon belül frissíteni kell. Ha ez valamiért nem megy azonnal, ideiglenes óvintézkedést kell tenni: a wp2shell esetében elég lett volna letiltani a bejelentkezés nélküli hozzáférést a /wp-json/batch/v1 végponthoz – pontosan azt, amit később a támadó tett meg maga után. És nem csak a WordPresst kell frissíteni, hanem a teljes architektúrát: a bővítményeket, a témát, a PHP-t, a webszervert, az adatbázist és az operációs rendszert is. Ezen az oldalon egy figyelő fejlesztő akár meg is akadályozhatta volna a feltörést.

A feltöltött webshell parancsai elmondják, mire készült:

Parancs	Mit csinál
`?p`	„WP2S::PONG::END” választ ad: a robot ezzel ellenőrzi, hogy a hozzáférés még él
`?c=`	tetszőleges parancsot futtat a szerveren
`?r=`	bármely fájlt kiolvas, például a `wp-config.php`-t az adatbázis jelszavával
`?w=`, `?up`	tetszőleges fájlt ír vagy tölt fel
`?sergei`	létrehozza vagy visszaállítja az `ahmetkaya` adminisztrátort (`recepcetin2327@gmail.com`), és be is lépteti

A legbeszédesebb részlet a harmadik plugin, a w2s-guard-108929. Ez szó szerint a nyilvános biztonsági ajánlásokban szereplő védelem: letiltja a bejelentkezés nélküli hozzáférést a sérülékeny végponthoz. A támadó bezárta maga mögött az ajtót, hogy a konkurens robotok már ne jöhessenek be. Működött is: augusztus 16-án került fel, és az utolsó kamu admin is aznap jött létre. Az oldalt tehát nem javították meg, hanem lefoglalták.

Ez egy tömeges, automatizált hozzáférés-gyűjtés mintája. A robotok működő backdoorokat gyűjtenek listába, amelyeket később eladnak, vagy maguk használnak spamküldésre, adathalász oldalak tárhelyének, kártevő-terjesztésre vagy más oldalak elleni támadásokhoz. A tükörben nem találtam nyomát annak, hogy november 10-ig ezt már ki is használták volna: a nyári időszakból csak a három plugin és a téma fájljai származnak, az ahmetkaya fiók pedig soha nem jött létre. A szerver kimenő forgalmát és levelezését viszont csak a tárhelyszolgáltató látja, ezért azt tőlük kell lekérni.

És az adatok?

Ezen az oldalon kevés személyes adat volt: néhány adminisztrátori fiók és egy szavazás adatai. A webshell-lel azonban a wp-config.php és azon keresztül a teljes adatbázis kiolvasható volt, és naplók hiányában nem lehet bizonyítani, hogy ez nem történt meg. Egy webshopnál vagy egy ügyféladatokat kezelő oldalnál ugyanez már adatvédelmi incidens, amellyel a tulajdonosnak külön foglalkoznia kell.

A takarítás lépésről lépésre

A teljes takarítás egy nap alatt lezajlott, SSH-hozzáférés nélkül, csak FTP-vel és egy ideiglenes adatbázis-kezelővel. A sorrend fontosabb, mint a gyorsaság: előbb bizonyíték és mentés, utána törlés.

Az eredeti állapot rögzítése. Teljes adatbázis-mentés az élesből, ebből egy zárolt, írásvédett példány SHA-256 ellenőrző összeggel. Ez a bizonyíték, és ez a visszalépési pont, ha a takarítás valamit elrontana.
Fájltükör készítése, biztonságosan. A teljes webtárhelyet letöltöttem (a több GB-os uploads mappa nélkül). A helyi másolat fertőzött PHP-t tartalmaz, ezért azonnal letiltottam a webes elérését (Require all denied). Egy helyi fejlesztői webszerver különben a helyi hálózatról futtathatóvá tenné a webshelleket.
A WordPress core összevetése a hivatalos kiadással. A wp core verify-checksums minden core-fájlt ellenőriz, és kilistázza azokat, amelyeknek ott sem kéne lenniük. A 17 core-mappába rejtett backdoor így került elő.
Mintázat-alapú keresés a pluginokban, a témában és a feltöltésekben. Minden PHP-fájlból kivágtam a kommenteket és a szóközöket, és utána kerestem: halmozott chr()-hívások, kis fájlban $_COOKIE vagy $_POST értékadás, eval/assert szuperglobális változóval, PHP-kód nem PHP kiterjesztésű fájlban. A több GB-os uploads mappát nem töltöttem le, hanem távolról jártam be, és csak a végrehajtható vagy rejtett fájlokat néztem meg.
A találatok kézi átnézése. Egy szkenner sosem dönt helyettem: a Wordfence, az UpdraftPlus vagy a WP Rocket legitim kódja is akad hasonló mintákra. Minden gyanús fájlt egyenként megnéztem, és csak a bizonyítottan kártékony 25 + 4 találat került a törlési listára.
A webshellek törlése. A három álplugin és az áltéma mappájának törlése, majd az aktív pluginok listájának javítása 17-ről 14-re. Ez az érték szerializált PHP-tömb; sima szövegcserével elrontanám, ezért teljes, ellenőrzött értékre cseréltem – feltétellel, hogy csak a várt régi értéket írja felül.
Adatbázis-takarítás – előbb helyben, utána élesben. A takarító SQL-t először a helyi másolaton futtattam és ellenőriztem, csak utána élesben, egyetlen tranzakcióban. Töröltem a támadás kezdete (2026. július 21.) után létrehozott 354 felhasználót a metaadataikkal, a 2020-01-01 dátumú kérelmeket és változatkészleteket, az „x” bejegyzéseket, a támadás alatti oEmbed-sorokat és az árva metaadatokat. Az adminokat nem a felhasználólistából, hanem a jogosultság-metaadatokból (capabilities) azonosítottam – a listában elrejthető egy admin, ott nem.
Minden munkamenet kiléptetése. A session_tokens törlésével minden bejelentkezett felhasználó, a támadó élő munkamenetei is, kikerültek.
A 25 backdoor-fájl törlése és visszaellenőrzése. Az FTP-lista nem mutatja megbízhatóan a ponttal kezdődő rejtett fájlokat, ezért törlés után mindegyikre külön lekérdezéssel igazoltam, hogy tényleg nincs ott.
A titkos kulcsok (salt) cseréje. A wp-config.php mind a nyolc kulcsát újrageneráltam. Ezzel minden korábbi belépési süti és „emlékezz rám” token érvénytelenné vált.
A rejtett belépés újraélesztése. Az oldal egy régi „Hide My WP” bővítménnyel rejti el a belépési oldalt. Ez a süti nevét és a rejtett URL előtagját a saltokból számolja, és beégeti a .htaccess-be. A salt-csere után ezért a .htaccess két sorát is össze kellett hangolni, különben az admin felület mindenkinek 404-es hibát adott volna.
Saját admin fiók, ideiglenes eszközök törlése. Új, erős jelszavú adminisztrátori fiók a karbantartáshoz – az admin felület helyett SQL-lel, az okát lent leírom. A munkához ideiglenesen feltöltött adatbázis-kezelőt (véletlen nevű mappában) a nap végén töröltem – egy ott felejtett adminisztrációs eszköz maga is támadási felület.
Végső ellenőrzés. Újra lefuttatott szkennelés, belépés minden legitim fiókkal, a nyilvános oldalak és űrlapok átnézése. Az adminok listáján végül 357 helyett a 3 eredeti és 1 új fiók maradt.

Egy félrevezető jel: „You’re spam! aren’t you?”

A takarítás közben volt egy furcsaság, aminek az okára csak később jöttem rá. Amikor az admin felületen új adminisztrátort akartam létrehozni, vagy egy kamu admint átnevezni, a mentés után csak egy üres oldal jött be ezzel a sorral: You’re spam! aren’t you?

Egy ennyire feltört oldalon először én is arra gyanakodtam, hogy ez is a támadók műve: egy kártevő, ami így védi a kamu adminokat. Nem az volt. Az üzenet az oldalon futó régi Hide My WP biztonsági bővítmény 2023-as, 6.2.11-es változatának beépített komment-spamszűrőjéből jön. Ez a szűrő elvileg csak a hozzászólások beküldését figyeli, és eldobja azt a kérést, amelyikben van email mező, de nincs benne a bővítmény saját rejtett mezője.

A hiba egy PHP 8-as változásban van. A bővítmény úgy dönti el, hogy kommentbeküldésről van-e szó, hogy megnézi: a meghívott fájl neve a beállításokban megadott átnevezett komment-címre végződik-e. Ezen az oldalon ez a beállítás üres volt. PHP 7 alatt az üres szövegre keresés hamis eredményt adott, PHP 8 óta viszont igazat: minden szöveg „végződik” üres szövegre. A szerver PHP 8.4-re váltása óta ezért a szűrő az oldal minden POST-kérését kommentként vizsgálta, és mivel a felhasználó-szerkesztő űrlapon van email mező, minden felhasználómentést spamnek minősített.

A bővítmény számlálója szerint 105 ilyen kérést dobott el. A 354 kamu admin ugyanakkor gond nélkül létrejött, mert a támadók nem ezen az űrlapon jöttek be. A „biztonsági” bővítmény tehát a jogos adminisztrátorokat zárta ki a felhasználók kezeléséből, a támadókat nem. Ha egy oldal gazdája hónapokkal korábban észreveszi, hogy nem tudja menteni a felhasználókat, és utánajár, a kamu adminok is hamarabb előkerülnek.

A saját adminisztrátori fiókomat ezért végül közvetlenül az adatbázisban, SQL-lel hoztam létre. A WordPress frissítése ezen nem segít, mert a hiba a bővítményben van. A bővítmény legfrissebb, 6.2.12-es változata 2025 februárjából való, és a gyártó hivatalosan csak a WordPress 6.7-ig vállal kompatibilitást, miközben a WordPress már a 7.1-nél tart. A 6.2.12-es változat kódját is átnéztem: a hiba abban is változatlanul benne van, így a bővítmény frissítése sem javítaná meg. A 6.2.11 (2023. szeptember) és a 6.2.12 (2025. február) között közel másfél év telt el, azóta pedig újabb közel két év. Egy biztonsági bővítménynél ez nagyon hosszú csönd. Ez tehát nem kártevő volt, hanem egy nem megfelelően karbantartott bővítmény. Az ilyet egy automatikus biztonsági szkenner nem jelzi: egy fejlesztőnek kell észrevennie, ki kell derítenie az okát, és le kell cserélnie a bővítményt. Áthidalásként egy kis, külön betöltődő kiegészítőt (mu-plugint) tettem fel, ami a szűrőt csak a valódi kommentbeküldésnél hagyja futni. A tartós megoldás a bővítmény cseréje egy karbantartott alternatívára.

Miért történhetett meg

A 2026-os támadás belépési pontja egyértelmű: a wp2shell-hiba a nem frissített WordPressben. A 2024-esét utólag nem lehet bizonyítani, mert a szerver naplóihoz nem fértem hozzá, és azóta évek teltek el. A körülmények viszont egyértelműek: az oldalon egyszerre több ismert kockázat volt jelen, és a támadóknak elég volt egy.

Elavult WordPress. Az oldal a 6.9.3-as verzión futott, miközben már a 7.1-es ág volt az aktuális. A wp2shell-javítás (6.9.5) július 17-én megjelent, az első támadó négy nappal később bejött. Egy automatikus biztonsági frissítés ezt a támadást megállította volna.
Nulled (feltört) bővítmények. A pluginok között volt egy nem hivatalos forrásból származó „prémium-letöltő” kliens, és két, gyanús nevű prémium biztonsági plugin-mappa is. Az ilyen forrásból származó kód gyakran már eleve backdoort tartalmaz, és frissítést sem kap.
Fájlkezelő bővítmények. Két, a böngészőből fájlfeltöltést és -szerkesztést engedő plugin nyomai voltak az oldalon. Ezek a WordPress-támadások egyik legkedveltebb célpontjai.
Titkosítás nélküli FTP. A tárhely csak sima FTP-t támogatott, TLS nélkül. A jelszó így olvasható szövegként utazik minden kapcsolódáskor.
Elavult szerver-operációs rendszer. A szerver Debian 11-en fut, amelynek hosszú távú támogatása lejárt.
A régi fertőzés soha nem lett kitakarítva. A 2024-es backdoorok éveken át működőképesek maradtak. Hiába frissített volna közben bárki, a fertőzött fájlokat egy frissítés nem feltétlenül távolítja el.

És egy fontos részlet: az oldalon volt „biztonsági” bővítmény, de csak olyan, ami elrejti a belépési oldalt. Fájlváltozásokat és gyanús kéréseket figyelő biztonsági bővítmény nem futott: a Wordfence-t én telepítettem a felderítés napján, amikor már minden megtörtént. Egy ilyen bővítmény hasznos, de csak akkor, ha a fertőzés előtt fut, valaki olvassa a riasztásait, és a frissítéseket sem pótolja. A biztonság folyamat, nem egy telepített plugin.

Megelőzés: ellenőrzőlista WordPress-tulajdonosoknak

A lista nagy része nem igényel programozót, csak rendszerességet. Ha ezeket betartod, a fenti eset nagy valószínűséggel meg sem történik.

Frissítések

A WordPress core, a téma és minden plugin legyen naprakész. A kisebb biztonsági frissítéseket érdemes automatikusra állítani.
A nagyobb frissítéseket előbb egy tesztkörnyezetben (staging) próbáld ki, utána élesben.
A PHP verziója legyen támogatott (jelenleg 8.2 vagy újabb). Ha a sablon vagy egy plugin miatt nem lehet váltani, azt javíttasd ki, ne maradj a régi PHP-n.

Bővítmények és témák

Óvakodj a feltört (nulled), „ingyenes prémium” vagy ismeretlen forrásból származó bővítményektől és témáktól. Ezek gyakran már eleve backdoort tartalmaznak, és frissítést sem kapnak. A licencdíj töredéke egy takarítás árának.
Ha a fejlesztőd prémium (fizetős) bővítményt használt, kérd el tőle a licenckulcsot, vagy kérd meg, hogy az oldal átadása után a te licenceddel állítsa be a bővítmény frissítését. Licenc nélkül egy prémium bővítmény nem frissül, és évekig senki nem veszi észre, hogy elavult.
Ha erre nincs lehetőség, inkább cseréld le egy ingyenes, a WordPress.org bővítménytárában elérhető alternatívára. Ott látszik, mikor frissült utoljára és melyik WordPress-verzióval tesztelték, a frissítés pedig egy kattintás.
Ami nincs használatban, azt ne csak kapcsold ki, hanem töröld. Egy kikapcsolt plugin fájljai továbbra is elérhetők a webről.
Fájlkezelő és kódszerkesztő pluginokat csak az adott munka idejére telepíts.
A wp-config.php-ba kerüljön be a define( 'DISALLOW_FILE_EDIT', true ); sor, hogy az admin felületről ne lehessen PHP-fájlt szerkeszteni.
Ha valami az admin felületen hirtelen nem működik (nem menthető egy felhasználó, üres oldal jön, furcsa üzenet), ne kerüld meg, hanem derítsd ki az okát. A régi, nem karbantartott biztonsági bővítményeket cseréld le: egy PHP-frissítés után váratlan helyeken törhetnek el.

Felhasználók és belépés

Havonta nézd át az adminisztrátorok listáját (Felhasználók → Szerepkör: Adminisztrátor). Minden ismeretlen admin azonnali riasztási ok.
Mindenki csak annyi jogot kapjon, amennyi a munkájához kell. Egy cikkírónak nem kell admin jog.
Erős, egyedi jelszavak jelszókezelővel, és kétlépcsős azonosítás minden admin fiókon.
A felhasználói regisztráció legyen kikapcsolva, ha az oldalnak nincs rá szüksége, az alapértelmezett szerepkör pedig legyen „Feliratkozó”.

Szerver és tárhely

Csak titkosított kapcsolat: SFTP vagy legalább FTPS. Ha a szolgáltató csak sima FTP-t ad, kérj másikat, vagy válts szolgáltatót.
Kérdezd meg a szolgáltatót, milyen operációs rendszer és PHP fut a szerveren, és mikor frissítik.
Az uploads mappában ne lehessen PHP-t futtatni (ezt a szolgáltató vagy egy .htaccess-szabály intézi).
Ha a szolgáltató szól, hogy valami gyanúsat látott, vagy zárolja a tárhelyet, azt ne bosszantó adminisztrációnak tekintsd, hanem részletes vizsgálat indítójelének.

Mentés és figyelés

Automatikus, napi mentés fájlokról és adatbázisról, a szerveren kívüli tárhelyre. Negyedévente egyszer próbáld ki a visszaállítást is.
A mentésekből több hónapnyi maradjon meg. Egy hosszú ideje lapuló fertőzésnél a tegnapi mentés már fertőzött.
A biztonsági plugin riasztásai olyan e-mail-címre menjenek, amit valaki tényleg olvas.
Évente legalább egyszer legyen egy alapos átvizsgálás: core-fájlok ellenőrző összege, ismeretlen PHP-fájlok, adminok, aktív pluginok.

Tanulságok

Az, hogy az oldal működik, nem jelenti azt, hogy rendben van. Ez az oldal hónapokig hibátlanul jelent meg a látogatóknak, miközben több száz idegen adminja volt.
Nem kell célpontnak lenni ahhoz, hogy feltörjenek. Egy rajongói közösség oldalán nincs bankkártyaadat. A robotokat ez nem érdekli: ami támadási felületet találnak, azt kihasználják, és az oldalt később spamküldésre, kártevő-terjesztésre vagy más oldalak támadására használhatják.
Egy fertőzés ritkán jár egyedül. Az új támadás keresése közben találtam rá egy két évvel korábbira. Egy feltört oldalt ezért mindig a teljes fájlrendszeren és adatbázison végig kell vizsgálni, nem elég a látható tünetet megszüntetni.
A takarítás fele a dokumentálás. Eredeti mentés, ellenőrző összeg, helyben kipróbált SQL, fájlonkénti lista. Ennél a pontnál dől el, hogy egy takarítás visszakövethető és visszavonható lesz-e.
A karbantartás olcsóbb, mint a takarítás. Egy havi frissítés és átnézés néhány óra munka. Egy feltört oldal vizsgálata és rendbetétele nagyságrendekkel több – és a hosszú ideig fertőzött domain hírneve a keresőkben és a levélszűrőkben is sérülhet.

Az eset után még van teendő: a WordPress és a bővítmények frissítése tiszta forrásból, a nulled és fájlkezelő pluginok eltávolítása, az adatbázis- és FTP-jelszavak cseréje, és a szolgáltatóval egyeztetve a szerver frissítése. A takarítás az első lépés, nem az utolsó.

Ha nem tudod, mikor frissült utoljára az oldalad, vagy hány adminisztrátora van, most nézd meg. Ha gyanús dolgot találsz, vagy szeretnéd, hogy valaki rendszeresen karbantartsa a WordPress-oldaladat, keress meg bizalommal.

Források és hasznos linkek

Az esetben használt források

Amit egy WordPress-fejlesztőnek érdemes követnie