WordPress biztonsági kalauz – Feltört oldalak helyreállítása

[Ezt a cikket 17 perc elolvasni.]

Rengeteget hallani feltört CMS alapú weboldalakról, sokan emiatt is idegenkednek a WordPress használatától. Tény, hogy alapos munka és kellő szakértelem szükségeltetik ahhoz, hogy ki tudjuk védeni a hackerek és botok – sokszor automatizált – támadásait, de nem lehetetlen elérni egy olyan védettségi szinten, ami képes kiszűrni legalább a leggyakoribb támadásokat. Sajnos azonban szinte minden WordPress felhasználó életében eljön az a pont, amikor szembetalálja magát egy feltört weboldallal. Ilyenkor az első kérdés általában az, hogy most hogyan is lehetne visszaállítani az eredeti állapot (lehetőleg minél hamarabb), valamint, hogy hogyan is kellene elkezdeni a tisztítás folyamatát. Ez az írás igyekszik megválaszolni a fenti kérdéseket.

Mielőtt azonban belevágnánk, érdemes átvenni a legalapvetőbb biztonsági lépéseket, mintegy prevenció gyanánt.

Korábban már elkezdtük a WordPress és a biztonság témakörének alapozását, így kezdetnek azt ajánlom, hogy olvassuk át az erről szóló cikkemet: [link]

Az alapok után érdemes beállítani egy biztonsági bővítményt is, erre az iThemes Security tökéletesen megfelel. Szerencsére erről is írtam nemrégiben egy részletes cikket. Természetesen az írás megjelenése után néhány nappal a fejlesztők megváltoztatták a plugin vezérlőpultjának kinézetét, de azért továbbra is könnyedén be lehet konfigurálni az alábbi útmutatóm alapján: [link]

Mindez azonban mit sem ér, ha nincsen rendszeres, teljes biztonsági mentés, ehhez pedig egyszerű és gyors megoldást nyújt a BackWPuP: [link]

Tehát megtettük, amit lehet, óvatosak vagyunk, beállítottuk az iThemes Security-t is, de mégis feltörték a weboldalunkat. Hogyan tovább?

Az árulkodó jelek

  • A weboldalunk nem töltődik be, helyette esetleg fehér képernyő vagy hibaüzenet jelenik meg
  • A főoldalunk helyett átirányításra kerülünk egy teljesen más (sokszor kéretlen tartalmat megjelenítő) oldalra
  • A főoldal helyén teljesen más tartalom jelenik meg (sokszor “hacked by XY team” szlogennel)
  • Betölt ugyan az oldalunk, de a linkekre kattintva külső oldalra irányít át
  • Gyanús SPAM szövegek jelennek meg random helyeken, sokszor linkesítve (viagra és társai)
  • A látogató számára láthatatlan, úgynevezett rejtett SEO SPAM linkek kerülnek beágyazásra az oldal forráskódjába
  • A tárhelyszolgáltatótól üzenet érkezik, hogy a tárhelyről túl sok a kimenő kéretlen e-mail üzenet
  • A Google Webmaster Tools jelzi, hogy gyanús aktivitás történik a weboldalunkon
  • A Google veszélyesnek ítéli meg a weboldalt, ezt pedig a találati listában is jelzi
  • Feketelistára kerül az IP címünk, a domainünk alól küldött e-mailek nem érkeznek meg a címzetthez
  • Hirtelen megnövekszik a weboldalunk sávszélesség használata
  • Megváltozott tartalom, esetleg átirányítás, de csak mobilos látogatóknak

Természetesen ez csak néhány a temérdek árulkodó jel közül, azonban ha ilyesmit tapasztalunk, akkor bizony nem árt komolyan venni a dolgokat, mert az oldalunk és a keresőkben elfoglalt pozíciójának elvesztésén kívül látogatókat, forgalmat, ezáltal pedig eladásokat és konverziókat is veszíthetünk.

A színfalak mögött

Hogyan is törnek fel egy weboldalt? Sokszor bizony jóval egyszerűbben, mint gondolnánk. Elég csak lefuttatni egy kis alkalmazást, ami a jól ismert sebezhetőségek után kutat, ezután pedig ezeket kihasználva már gyerekjáték kártékony kódot feltölteni vagy éppen a meglévő fájlokat módosítani.

A három bevett módszer egy weboldal feltörésére:

  • A szerveren keresztül
  • A felhasználón keresztül
  • A weboldal sebezhetőségeit felhasználva

Menjünk sorban. Ugye nyilvánvaló, hogy hiába az összes védelem, a legerősebb jelszavak és minden biztonsági intézkedés, ha a tárhelyünk és a szerver sebezhető. Ha valaki képes root (rendszergazdai) jogosultságot szerezni, akkor a szerveren található összes adat veszélybe kerül. Ugyanekkora probléma, ha a szerveren nincsen frissítve az operációs rendszer és a csomagok, ha a tárhelyek nincsenek érdemben elválasztva egymástól, ha a szolgáltató nem figyel oda a rendszeres automatikus mentésekre és még sorolhatnám. Tehát alapszabály, hogy a tárhelyen nem spórolunk és legfőképpen nem választjuk az ingyenes csomagokat, amik a leírás szerint mindent tudnak, amit a nagyok, mégis általában ezeket törik fel a leghamarabb. Az “olcsó húsnak híg a leve” elv itt is érvényesül. Mindenképpen érdemes olyan szolgáltatót választani, amiről könnyedén találni jó értékeléseket és tapasztalatokat az interneten is. A külföldi versenyzők közül nagyon népszerű a GoDaddy és a Hostgator, itthon pedig a Tárhelypark csapata az, akivel személyesen is jó tapasztalatom van. Ha pedig VPS-re lenne szükség, akkor bátran ajánlhatom a Linode-ot vagy a DigitalOcean-t.

Van megbízható szerverünk, védjük az oldalt, de password123 az adminisztrátor jelszavunk és az összes elmentett FTP kapcsolatunkat Total Commanderben tároljuk. Nincs vírusirtó a gépünkön és az asztalon megjelenő újabbnál újabb kéretlen programok ikonjait is megszoktuk már. Ebben az esetben sem szabad csodálkozni, ha rövidesen a weboldalunkat is feltöri valaki. A felhasználó mindig is az egyik leggyengébb pont volt, sajnos ez valószínűleg így is marad már. Nem elég az erős jelszó, az is fontos, hogy mit kezdünk vele. Nem lenne szabad semmilyen formában elmenteni a számítógépünkön, de ha mégis erre lenne szükség, akkor csakis titkosítva (például KeePass segítségével). Ezen felül mindenképp használjunk vírusirtót, okosan és körültekintően telepítsünk és netezzünk, mert nagyon könnyű összeszedni egy olyan malware-t, ami menti az összes billentyűleütést és naplózza az internetes tevékenységet és forgalmat. Rendszeresen ellenőrizzük és takarítsuk a gépünket, ütemezzünk rendszerindítás előtti teljes vírusellenőrzést (az ingyenes Avast is tudja ezt!). Ezt pedig nem lehet elégszer hangsúlyozni, de a jelszavunkat SOHA ne adjuk meg másnak és lehetőleg minden oldalnál használjunk egy teljesen új jelszót.

A legtöbb feltörés azonban mégis a weboldal sebezhetőségei által történik. Általánosságban kijelenthetjük, hogy nem maga a WordPress core az, ami sebezhető, hanem leginkább a pluginek és sablonok. Persze volt és lesz is rá példa, hogy a WordPress kódjában is találni sebezhetőséget, de ezt szinte rögtön javítja a fejlesztő csapat, tehát nekünk csak annyi a dolgunk, hogy mindig járjunk nyitott szemmel és frissítsük a rendszert, amilyen gyorsan csak lehet. A valódi probléma ott van, ha egy olyan bővítményt vagy sablont használunk, ami ismert sebezhetőséggel rendelkezik és a fejlesztése már meg is állt vagy éppen nagyon lassú. Nem kell messzire menni, elég csak visszagondolni a nem olyan távoli Revolution Sliderben felfedezett sebezhetőségre. Szinte az összes prémium themeforest sablon tartalmazza ezt a plugint, így ennek hatására a WordPress weblapok igen nagy százaléka sebezhetővé vált. Ráadásul ez egy csomagolt bővítmény, tehát az automatikus frissítéseket sem kaphatta meg, így meg kellett várni, míg a sablonok készítői kiadták az új verziót (már, ha kiadták). Amíg ez megtörtént rengeteg weboldalt törtek fel (és törnek fel a mai napig emiatt a sebezhetőség miatt). Hogy ez hogyan is történik pontosan azt jól szemlélteti a következő angol nyelvű kis tanulmány: [link] Sokaknak ismerős lehet még a timthumb képméretező scriptben talált sebezhetőség is, ez is számtalan sablonba volt integrálva, és ennek is számtalan WordPress oldal esett áldozatául.

Gondolom mindenki kíváncsi arra, hogy kívülről mit is lehet kideríteni a weboldaláról. Nézzünk is utána! Több eszközt is használhatunk, a legegyszerűbbek a webes detektorok, mint például ez: [link] A weboldalunk linkjének megadása után már meg is adja, hogy melyik sablont is használjuk (verziószámmal!) és a telepített pluginekről is értesít. Aki tudja mit csinál, az akár már ennyi információ segítségével is képes lehet elindulni. Ennél létezik egy jóval komolyabb eszköz is a sebezhetőségek felderítésére, ez pedig a WPScan névre hallgat. Telepíteni csak Linux alapú operációs rendszerekre tudjuk, viszont nagyon hatékony eszköz, oldalunk minden egyes szegletét felderíti és ha létezik kihasználható sebezhetőség, akkor ezeket listázza is. A mi kezünkben roppant hasznos, de képzeljük el, hogy mit tud ezzel kezdeni mondjuk egy hacker.

A károk helyreállítása

Ha megtörtént a baj cselekedni kell. Általában a tárhelyszolgáltató lép először és inaktiválja a feltört oldalt a takarítás és a helyreállítás idejére, ez idő alatt sem mi, sem a látogatóink nem fogják tudni elérni böngészőn keresztül. Ami továbbra is használható marad az a tárhely kezelőfelülete és az FTP kapcsolat. Amennyiben a szolgáltató mégsem inaktiválná az oldalt úgy nekünk kell ezt megtennünk. Drasztikusnak tűnhet, de az összes fájlt el kell távolítanunk a tárhelyünk gyökérkönyvtárából, csak így lehetünk biztosak benne, hogy nem marad semmi kártékony és futtatható állomány. Természetesen ezt csak akkor tegyük meg, ha van friss biztonsági mentésünk, amennyiben nincs, úgy először is mentsünk le mindent a saját gépünkre, hogy később esetlegesen vissza tudjuk állítani az egyedi elemeket. Erre sajnos nincs jobb és hatékonyabb módszer, mindent el kell távolítani! Ha cPanellel rendelkezünk és a fertőzött oldal a public_html könyvtárban található fő domain, akkor szinte biztos, hogy az összes addon domain is fertőzött, mivel ezek gyökérkönyvtára mindig egy mappa, ami a public_html-en belül található. Ilyen esetben sajnos ezeket is el kell távolítani és itt is a lenti lépéseket kell követni.

A következő, amit meg kell tennünk az a jelszavak megváltoztatása! FTP, cPanel, minden, ami a weboldalunkhoz köthető. A tisztítás után természetesen meg kell változtatnunk a WordPress adminisztrátorok jelszavait is.

Tehát van mentésünk, töröltük mindent a gyökérkönyvtárból, jöhet a helyreállítás. Szerencsére a WordPress core és a pluginek visszaállítása relatíve egyszerű. Töltsük le a legfrissebb verziós WordPress telepítőt, csomagoljuk ki, majd másoljuk fel a tárhelyünk gyökerébe. Tegyünk ugyanígy a korábban használt pluginekkel is. Ha nem vagyunk biztosak benne, hogy mik is voltak aktívak, akkor puskázhatunk a biztonsági mentésünkből (wp-content/plugins). A sablonnal sincs nehéz dolgunk, kivéve ha tartalmaz egyedi módosításokat. Ha nem nyúltunk bele, akkor ebből is töltsük le a legfrissebb verziót és másoljuk fel a wp-content/themes mappába. Ezután már csak két dolog van hátra, az első az uploads mappa. Itt találhatóak a médiatárba feltöltött képeink és egyéb tartalmaink. Ezeket mindenképp vissza kell másolnunk, azonban mindenképp ellenőrizzük kézzel a mappák tartalmait, mivel előszeretettel töltenek fel ide PHP kiterjesztésű kártékony kódot tartalmazó fájlokat. Egyesével lépjünk be az évszámok/hónapok mappáiba és töröljünk minden olyan fájlt, ami PHP kiterjesztésű. Csak képek, videók és az egyéb általunk feltöltött dokumentumok lehetnek itt. Az utolsó lépés a wp-config.php és a .htaccess fájl visszaállítása. Ha tudjuk, hogy mit csinálunk, akkor nyissuk meg a wp-config.php-t és ellenőrizzük a tartalmát. Amennyiben nincs benne semmi gyanús (általában a fájlok elejére injektálnak base64 titkosított kódot), akkor ezt is visszamásolhatjuk. Mindenképp szükségünk lesz rá, mert ez tartalmazza az adatbázis kapcsolat adatait és az egyéb beállításokat. Enélkül az oldal megnyitásakor csak a WordPress telepítő fog minket fogadni. Ha kételyeink vannak a fájl eredeti tartalmát illetően, akkor puskázhatunk a wp-config-sample.php megnyitásával. A .htaccess fájl esetében is hasonlóan járjunk el. Alapesetben csak a következőket kell tartalmaznia:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Természetesen egyes pluginek is hozzáadhatnak saját szabályokat a .htaccess-hez, ha nem vagyunk biztosak benne, hogy kártékony-e a kód vagy sem, akkor inkább töröljük és hagyjuk csak meg a fenti részletet. Később csak újra el kell menteni a pluginek beállításait és ismételten létre fogják hozni a saját szabályaikat.

A fentiek végrehajtása után elviekben újra működőképes lesz az oldalunk (már ha az adatbázis ép és módosítatlan). Ebben az esetben be tudunk lépni a vezérlőpultra a régi jelszavunkkal (már, ha nem törölték a felhasználót és nem változtatták meg a jelszavát). Ha az adatbázis megsérült, akkor ezt is vissza kell állítanunk (legegyszerűbben PHPMyAdmin-on keresztül tehetjük ezt meg). Ha nincs PHPMyAdmin hozzáférés, akkor a MySQL Dumper nevű kis scriptet hívhatjuk segítségül. Amennyiben nem sikerülne belépni vagy nem működne a régi jelszavunk, úgy ez a cikk segíthet a megoldásban: [link]

Ha él az oldal és sikerült a belépés, akkor érdemes átnézni még a WordPress felhasználókat. Ha látunk gyanús adminisztrátor jogokkal rendelkező regisztrációt, akkor érdemes azonnal törölni. Jó ötlet még átnézni egyes posztok és oldalak tartalmát is a HTML nézetben, nehogy itt is megbújjanak kifelé mutató SPAM linkek vagy beágyazott kártékony Javascript kódok.

Az eddigi lépések segíthetnek helyreállítani egy átlagos WordPress honlapot, de mi van akkor, ha az oldal egyedileg módosított kóddal, sablonnal és bővítményekkel rendelkezik? Ilyen esetben nem opció a pluginek/sablon ismételt letöltése az utólag hozzáadott egyedi kód miatt. Ekkor általában a manuális ellenőrzést szoktam ajánlani, de ez sem mindig jöhet szóba a rengeteg PHP fájl és a végtelen mappaszerkezet miatt. Szerencsére van segítség.

A malware vadász

Nagyon sokszor vettem már hasznát az “Anti-Malware Security and Brute-Force Firewall” nevű pluginnek. Kis méretű, de gyors és nagyon sokoldalú eszköz, nélkülözhetetlen segítőtárs a fertőzések felderítésében. Persze nem tévedhetetlen és vannak esetek, amikor néhány fertőzött fájl átsiklik a rostán, de tapasztalataim szerint legalább 80%-os hatékonysággal fedezi fel a kártékony kódot, akár a core fájlok közé injektálva is. Használatához mindössze egy ingyenes regisztráció szükségeltetik a jobb oldalsávból, ezután a legfrissebb definíciók letöltése után már indulhat is a teljes ellenőrzés. Értelemszerűen ez a módszer csak akkor működik, ha az oldal számunkra is elérhető a weben. A manuális tisztítás és helyreállítás után is érdemes lefuttatni, mert nem kizárt, hogy érhetnek minket meglepetések. Erősen fertőzött, vagy inaktivált, esetleg manuálisan módosított oldal esetén más oldalról kell közelíteni, ilyenkor egy ideiglenes domainre telepített WordPress oldal alá telepítsük a plugint, majd a lementett (fertőzött) oldalunkat másoljuk fel az ideiglenes oldalunk mellé egy új mappába és úgy futtassuk az ellenőrzést. Így megakadályozhatjuk az eredeti domain felől érkező automatikus továbbfertőzést és egy védett környezetben futtathatjuk le az ellenőrzést. A detektált kártékony fájlokat egyesével tudjuk mi is ellenőrizni, a kijelölteket pedig automatikusan tisztítja is a plugin. Képes még felderíteni a timthumb és a htaccess sebezhetőségeket is.

Anti Malware

Ha igazán biztosra akarunk menni, akkor a fentieken túl telepítsünk és futtassunk egy WordFence ellenőrzést is, persze előtte kapcsoljuk be a beállításaiban, hogy a teljes fájlrendszert, az összes plugint, a sablonokat és a WordPress core-t is ellenőrizze.

A tisztítás befejeztével érdemes futtatni még egy Sucuri online ellenőrzést. Ha az oldalunk valóban tiszta, akkor itt is ennek kell látszódnia. Ráadásul itt arról is értesítést kaphatunk, ha esetlegesen feketelistára került a domainünk vagy az IP címünk, ilyen esetben ezek eltávolítását is kérvényeznünk kell.

Hasznos tippek

Kevesen ismerik és használják, de a cPanel egyes beépített funkciói is segíthetnek a fertőzések felderítésében. Például ott van a statisztikai adatokért felelős Webalizer vagy AwStats. Ezen eszközök segítségével azt is láthatjuk, hogy mely fájlok kapják a legtöbb lekérést a weben. Fertőzött oldal esetén mindig van egy vagy több olyan fájl, amit folyamatosan külső lekérésekkel bombáznak a folyamatos újrafertőzés vagy éppen a SPAM üzenetek kiküldése és egyéb funkciók folyamatos futtatása okán. Ezeket a fájlokat könnyen megtalálhatjuk, ha kicsit böngésszük a statisztikákat.

A hibanapló (error_log) is árulkodó lehet, ha folyamatosan hízik, akkor érdemes lehet utánanézni, hogy mi lehet ennek az oka. Előfordulhat, hogy egy PHP fájlt automatikusan módosítottak, emiatt pedig hibaüzeneteket generál.

Remélhetőleg sokak számára hasznosnak bizonyul majd ez a cikk, de természetesen bármilyen kérdésre örömmel válaszolok a lenti komment szekcióban vagy akár üzenetben is.

Ha tetszik, mutasd meg másoknak is: