Röviden: Aki biztonsági incidens után tárhelyszolgáltatót szeretne váltani, először mentse a bizonyítékokat és tisztázza az incidenst, azután csak ellenőrzött adatokat vigyen át egy újonnan felépített rendszerre, és csak ezután szüntesse meg a régi szerződést. Az új szolgáltatót biztonsági szempontok szerint válassza ki: igazolható javítási folyamatok, az ügyfelek elválasztása, hozzáférés a naplókhoz, mentések és egyértelmű kapcsolattartók. A szolgáltatóváltás akkor értelmes, ha hiányzik a bizalom vagy a teljesítmény, de nem helyettesíti a tisztítást.
Ha elveszett a bizalom
A PHP2Shell után sok vállalat először él át nyomás alatt a tárhelyszolgáltatójával. Egyesek gyorsan egyértelmű tájékoztatást kaptak a javítási állapotról. Mások napokig vártak válaszra, csak általános frázisokat kaptak, vagy kiderült, hogy a weboldaluk elavult PHP-verzión futott. Ha ehhez még egy incidens is társul, érthető a váltás szándéka.
A tárhelyszolgáltató cseréje azonban nem az incidens kezelésének lépése, hanem az utána következő újrafelállításé. Aki rossz sorrendben csinálja, a legrosszabb esetben a támadót is magával viszi, és egyidejűleg elveszíti azokat a nyomokat, amelyek megmutatják, mi történt.
A váltás helyes sorrendje
- Mentse a nyomokat, amíg megvannak. A régi rendszer naplóit, fájljait és adatbázisát mentse el, mielőtt bármit törölnének vagy felmondanának. Kérdezze meg kifejezetten a régi tárhelyszolgáltatót a 2026. október 20-tól készült hozzáférési és hibanaplókról és azok megőrzési idejéről. A Bizonyítékok mentése az újratelepítés előtt cikk leírja, hogyan járjon el.
- Határolja be az incidenst. Mely rendszerek érintettek, mely hozzáféréseket használták, mely adatok voltak elérhetők? Ettől függnek a bejelentési kötelezettségek és az, hogy mit vihet át.
- Vizsgálja meg a bejelentési kötelezettségeket. Ha személyes adatok érintettek lehetnek, a lehetséges GDPR-bejelentés határideje az incidensről való tudomásszerzéssel kezdődik, nem a költözéssel. A háttér a GDPR-bejelentési kötelezettség: 72 óra oldalon olvasható.
- Építse fel tisztán az új rendszert. Támogatott PHP-verzió, friss csomagok, megerősített konfiguráció, még az első fájl átvitele előtt.
- Csak ellenőrzött tartalmat vigyen át. Kód tiszta forrásból, adatbázis és médiafájlok ellenőrzés után.
- Cserélje ki az összes hozzáférési adatot. Adatbázis, admin-fiókok, SSH, FTP, API-kulcsok, azokat is, amelyek konfigurációs fájlokban vannak.
- Kapcsoljon át és figyeljen. DNS-átállítás, utána egy ideig szorosabb felügyelet.
- Szüntesse meg a régi szerződést. Csak ha a naplók és a mentések biztonságban vannak, és az új üzemeltetés stabilan fut.
Ne mondja fel a régi szerződést, mielőtt a naplók és a mentések a kezében nem lennének. A szerződés megszűntével a szolgáltatónál olyan adatok is törlődhetnek, amelyekre a biztosítóhoz, hatóságokhoz vagy a saját kivizsgáláshoz szüksége van.
Mit ne vigyen magával
Kényelmes lenne a teljes webkönyvtárat vagy a szerver egy képét egyszerűen átmásolni. Incidens után éppen ez a kockázatos. A webshellek ártalmatlan fájloknak álcázzák magukat, a hátsó kapuk konfigurációs fájlokban bújnak meg, például a .htaccess vagy a .user.ini fájlban, és a beszúrt kód adatbázis-tartalmakban is lehet.
Az alkalmazáskódot ezért tiszta forrásból vigye át, például a megfelelő verziójú gyártói csomagból vagy a verziókezelő rendszerből. A médiafájlokat végrehajtható fájlok nélkül vegye át, az adatbázist pedig feltűnő tartalmak és új rendszergazdai fiókok ellenőrzése után. Amit a régi rendszeren találtak, segít ebben az ellenőrzésben.
Gondoljon mindarra is, ami a weboldal mellett a régi szolgáltatónál van. Az e-mail-postafiókok, a DNS-bejegyzések, a tanúsítványok és az átirányítások könnyen kimaradnak a költözésből. Csökkentse a DNS-bejegyzések érvényességi idejét néhány nappal az átállás előtt, hogy a változás gyorsan eljusson a látogatókhoz. Ha az e-mailek is költöznek, a postafiókok váltását tervezze külön, mert ott is érintettek lehetnek a hozzáférési adatok egy incidens után.
Az új szolgáltató kiválasztása biztonság szerint
Az ár és a tárhely minden ajánlatban szerepel. A döntő biztonsági kérdéseket többnyire Önnek kell feltennie. Az alábbi lista segít az összehasonlításban:
| Szempont | Kérdés a szolgáltatóhoz | Miért számít |
|---|---|---|
| Javítási folyamat | Hogyan és milyen keretek között telepítik és indítják újra a PHP-biztonsági frissítéseket? | A PHP2Shell megmutatta, mennyire fontos az igazolható folyamat |
| Igazolás | Kérésre kapok írásos megerősítést a javítási állapotról? | Alap a saját dokumentációjához |
| PHP-verziók | Mely ágakat kínálják, és meddig? | A frissítés nélküli régi ágak tartós kockázatot jelentenek |
| Elválasztás | Minden weboldal saját felhasználóval és saját PHP-folyamattal fut? | Korlátozza a kárt, ha egy szomszédot támadnak meg |
| Naplók | Hozzáférek a hozzáférési és hibanaplókhoz, és meddig őrzik meg őket? | Napló nélkül nincs kivizsgálás |
| Mentések | Milyen gyakran, meddig, a webszervertől elkülönítve, visszaállítási teszttel? | Visszaállítás incidens után |
| Vészhelyzeti kapcsolat | Hogyan érek el szakértő személyt egy incidens esetén? | Éles helyzetben az idő a legszűkösebb tényező |
| Adatfeldolgozás | Van GDPR szerinti szerződés és alvállalkozói lista? | Személyes adatoknál kötelező |
A javítási állapotra vonatkozó kérdéshez mintát kínál a Kérdezze meg a tárhelyszolgáltatót a javítási állapotról útmutató. Alkalmas arra is, hogy a szerződéskötés előtt összehasonlítsa a szolgáltatókat.
Jobb válasz lehet egy másik üzemeltetési modell?
Néha a probléma kevésbé a tárhelyszolgáltatónál van, mint az üzemeltetési modellben. Aki rendszeres karbantartás nélkül üzemeltet saját szervert, gyakran jobb helyen van egy jól támogatott menedzselt ajánlatnál. Fordítva, egy saját IT-vel rendelkező vállalat több kontrollt nyerhet a javítási időpontok fölött, ha maga üzemeltet. A mérlegelést a Menedzselt tárhely vagy saját szerver? cikk írja le.
A modelltől függetlenül érvényes: rögzítse írásban a feladatmegosztást. Ki telepíti a PHP-frissítéseket, ki indít újra, ki ellenőrzi az alkalmazást, ki kinek jelez vészhelyzetben? A PHP2Shell esetében sok késedelem éppen itt keletkezett, mert mindkét fél azt hitte, hogy a másik gondoskodik a dologról.
Hogyan segít konkrétan a PHP SOS?
- Mentjük a régi rendszer naplóit és adatait, és tisztázzuk, mi történt az incidens során.
- Megerősítve építjük fel az új rendszert, és csak ellenőrzött tartalmat viszünk át tiszta forrásokból.
- Az új szolgáltatók ajánlatait biztonsági szempontok szerint vizsgáljuk, és feltesszük a megfelelő kérdéseket.
- Folyamatban lévő incidens esetén az Incident Response szolgáltatásunk keretében dolgozunk, amíg az incidens le nem zárul és dokumentálva nem lesz.
Gyakori kérdések
Azonnal tárhelyszolgáltatót kell váltanom egy feltörés után?
Nem azonnal. Előbb nyomokat kell menteni, az incidenst be kell határolni, és az okot tisztázni. Egy elhamarkodott költözés a kártékony kódot is magával viheti, és a régi szolgáltatónál megsemmisítheti a bizonyítékokat.
A tárhelyszolgáltató hibája volt, ha a weboldalamat a PHP2Shellen keresztül támadták meg?
Ez a szerződéstől és az időponttól függ. Megosztott tárhelyen a PHP-frissítésekért többnyire a tárhelyszolgáltató felel, saját szervernél az üzemeltető. A javítások 2026. október 21-én jelentek meg; hogy felkerültek-e, és mikor, azt csak bizonyítékokkal lehet tisztázni. Felelősségi kérdésekben kérjen jogi tanácsot.
Milyen adatokat vihetek át az új tárhelyszolgáltatóhoz?
Csak ellenőrzött tartalmat: az adatbázist a beszúrt kód ellenőrzése után, a médiafájlokat végrehajtható fájlok nélkül, a kódot pedig tiszta forrásból, például a gyártói csomagból vagy a verziókezelő rendszerből. Teljes szerverképeket vagy webkönyvtárakat az megfertőzött rendszerről ne vigyen át ellenőrzés nélkül.
Be kell vonnom az adatvédelmet egy incidens után?
Ha személyes adatok érintettek lehetnek, a GDPR szerinti bejelentési kötelezettség állhat fenn, általában 72 órán belül. Az új tárhelyszolgáltatóval ezenkívül adatfeldolgozási szerződésre is szüksége van. Egyeztessen az adatvédelmi felelősével; ez nem jogi tanácsadás.