Röviden: A CMS cseréje egy feltörés után csak akkor segít, ha maga a régi rendszer volt az ok, például mert a gyártó nem szállít több biztonsági frissítést, vagy fontos bővítményeket nem gondoznak. Ha az ok elavult bővítményekben, gyenge hozzáférésekben vagy egy olyan résben volt, mint a PHP2Shell az alatta lévő PHP-ban, a váltás csak áthelyezi a ráfordítást. Mindenesetre érvényes: a tartalmakat előbb ellenőrizni, azután költöztetni, különben a kártékony kód is vándorol.
Ha elveszett a bizalom
Egy behatolás után a hangulat gyakran egyértelmű: „ezzel a rendszerrel soha többé.” Ez érthető. A weboldal látogatókat irányított át idegen oldalakra, a Google figyelmeztetett, az ügyfelek rákérdeztek. Egy új CMS újrakezdésnek érződik.
A PHP2Shell körüli helyzet azonban megmutatja, miért vezethet félre ez a reflex. A rés a PHP-értelmezőben van, nem a WordPressben, a TYPO3-ban, a Shopwareben vagy más rendszerben. A WordPress.org a drweb.de szerint ezért nem tervez saját frissítést ellene. Aki most egy PHP-s CMS-ről egy másik PHP-s CMS-re vált, a végén ugyanazzal a függőséggel rendelkezik, csak más logóval. Hogy mely rendszerek futnak PHP-n, azt a Mely CMS-ek és webshoprendszerek futnak PHP-n áttekintés mutatja.
Az dönt, mi volt az ok
Mielőtt a váltáson gondolkodik, tisztázni kell a behatolás okát. Tipikus belépési pontok az elavult bővítmények, többször használt vagy gyenge jelszavak, a hiányzó kétfaktoros bejelentkezés, egy javítatlan szerver vagy elfelejtett tesztinstallációk. E okok egyike sem kötődik egy bizonyos CMS-hez.
Aki nem ismeri az okot, azt kockáztatja, hogy átviszi az új rendszerbe. Az a csapat, amely eddig halogatta a frissítéseket, az új CMS-ben is ezt fogja tenni. Az az ügynökség, amely közös admin-fiókokat használt, megismétli ezt, ha senki sem változtat a folyamaton. A kérdés tehát kevésbé „melyik CMS?”, hanem „melyik folyamat?”.
CMS-váltás feltörés után: a mérlegelés
| Szempont | A meglévő CMS-nél maradni és keményíteni | Másik CMS-re váltani |
|---|---|---|
| A behatolás oka | Ismert és megszüntethető, például elavult bővítmény | Magában a rendszerben van, például hiányzó gyártói frissítések |
| Gyártói gondozás | A biztonsági frissítéseket szállítják | A gyártó megszüntette a gondozást |
| Függőség a bővítményektől | Kevés, gondozott bővítmény | Sok bővítmény aktív gondozás nélkül |
| Ráfordítás | Tisztítás, keményítés, folyamatváltoztatás | Újjáépítés, migráció, képzés, gyakran új arculat |
| Idő a biztonságos weboldalig | Rövidebb | Hosszabb, átmeneti megoldás szükséges |
| Védelem PHP-rések ellen | Nincs változás, a PHP-t javítani kell | Nincs változás, amíg az új rendszer PHP-t használ |
| Hosszú távú haszon | Magas, ha a folyamatok javulnak | Magas, ha a régi rendszer amúgy is a végén volt |
Ha az Ön helyzetében a legtöbb sor a bal oldalra esik, a váltás aligha éri meg. A maradás, a tisztítás, a keményítés és a karbantartási folyamat javítása kevesebb pénzért több biztonságot hoz. A WordPress-üzemeltetők számára a WordPress és a PHP2Shell összefoglalja a legfontosabb lépéseket.
Ehhez a döntéshez nem mindig van szüksége szolgáltatóra. Ha az ok egyértelmű volt, például egy ismert bővítmény közzétett réssel, és az ügynökség vagy az admin rendesen újratelepítette a weboldalt, maga is dönthet. Külső segítség akkor éri meg, ha az ok tisztázatlan marad, vagy személyes adatok érintettek lehetnek.
Ha vált: a kártékony kódot ne vigye magával
Ha a váltás mellett döntenek, maga a migráció is biztonsági kockázat. A támadók nyomokat nemcsak a fájlokban, hanem az adatbázisban is hagynak. Ezek a lépések segítenek tisztán költözni:
- A régi rendszert rögzíteni és elszigetelni: Teljes mentés bizonyítékként, azután a régi rendszert levenni a hálózatról, vagy már csak belsőleg elérhetővé tenni.
- A tartalmakat célzottan exportálni: Szövegek, oldalstruktúra és média, nem a teljes adatbázis. A felhasználói fiókokat nem átvenni, hanem újra létrehozni.
- A tartalmakat ellenőrizni: A szövegeket átnézni bejuttatott szkriptek, rejtett linkek és idegen átirányítások szempontjából. Hogyan megy ez, azt a Az adatbázis ellenőrzése bejuttatott kódra írja le.
- A médiát szűrni: Csak várt fájltípusokat átvenni, a kettős kiterjesztésű vagy szkripttartalmú fájlokat kiválogatni.
- Az új rendszert tisztán felállítani: A gyártó eredeti forrásából, javított PHP-jú szerveren, új hozzáférési adatokkal és kétfaktoros bejelentkezéssel.
- Az átirányításokat megtervezni: A régi címeket az újakra irányítani, hogy a keresőmotorok és a látogatók megérkezzenek, anélkül hogy régi útvonalak nyitva maradnának.
A CMS-váltás nem pótolja a régi szerver tisztítását. Ha a régi rendszer tovább fut, például elfelejtett másolatként egy aldomainen, a hátsó ajtó nyitva marad.
Az alternatíva, amelyet gyakran figyelmen kívül hagynak
Egyes vállalkozások egy feltörés után megállapítják, hogy egy nagy CMS funkciói egyáltalán nem kellenek nekik. Egy kevés oldalból álló, ritkán módosított cégweboldal PHP nélkül is megvan a szerveren. A statikus oldalak generátora kész HTML-fájlokat állít elő, amelyek már nem igényelnek szerveroldali programlogikát. Hogy ennek milyen előnyei és hátrányai vannak, azt a Statikus weboldalak: kevesebb PHP, kisebb támadási felület írja le.
Fordítva ez webshopoknál, portáloknál vagy sok szerkesztővel rendelkező weboldalaknál többnyire nem lehetőség. Itt egy dinamikus rendszer marad az értelmes, és a biztonság gondozásból, keményítésből és felügyeletből jön létre.
Aki bizonytalan, hogy a régi WordPressben nincsenek-e még rejtett hozzáférések, a Hátsó ajtók keresése a WordPressben cikkben megtalálja a tipikus lelőhelyeket. Ez abban is segít, hogy eldöntse, reális-e a tisztítás.
Hogyan segít konkrétan a PHP SOS?
- Először tisztázzuk a behatolás okát, és megmondjuk, hogy a CMS-ben, a folyamatban vagy a szerverben van-e.
- A meglévő rendszert a kártevő-eltávolítás keretében megtisztítjuk, vagy bizonyítékként előkészítjük egy újjáépítéshez.
- Váltásnál az átveendő tartalmakat és médiát kártékony kód szempontjából ellenőrizzük, mielőtt az új rendszerbe kerülnének.
- Az új szervert javított PHP-vel és keményített konfigurációval állítjuk fel.
Összegzés
Egy CMS-váltás feltörés után ritkán a megoldás, de néha a helyes alkalom. Ha a régi rendszert már nem gondozzák, megéri az újrakezdés. Ha az ok a folyamatokban vagy a szerverben volt, a folyamaton végzett munka többet hoz, mint egy új logó. Mindkét esetben érvényes: előbb ellenőrizni, azután költöztetni.
Gyakori kérdések
Segít a CMS-váltás a PHP2Shell ellen?
Nem, amíg az új CMS is PHP-n fut. A PHP2Shell a PHP-értelmezőben van, nem a CMS-ben. A döntő a PHP javítási állapota a szerveren, nem a fölötte lévő rendszer.
A WordPress kevésbé biztonságos, mint más CMS-ek?
Általánosságban ezt nem lehet megmondani. Sok behatolás elavult bővítményekből, gyenge hozzáférésekből vagy hiányzó frissítésekből ered, és ezek az okok minden rendszerben megvannak. Az elterjedtség azonban gyakoribb célponttá teszi a CMS-t az automatizált szkenneléseknél.
Egyszerűen exportálhatom a tartalmakat a feltört CMS-ből?
Csak ellenőrzés után. Az adatbázis tartalmazhat bejuttatott szkripteket, rejtett linkeket vagy idegen admin-fiókokat. A feltöltött fájlok kártékony kódot álcázhatnak. A tartalmakat célzottan exportálja, és importálás előtt ellenőrizze őket.
Mikor valóban értelmes a CMS-váltás?
Ha a gyártó nem szállít több biztonsági frissítést, ha a weboldal olyan bővítményekre van utalva, amelyeket már nem gondoznak, vagy ha a rendszer a mai követelményekhez egyszerűen már nem illik. A feltörés ilyenkor az alkalom, nem az ok.