Feltörték a szervert, mit tegyen? Első lépések és azonnali segítség

Röviden: Érintett? Hívjon minket. Segítünk. Ha azt gyanítja, hogy feltörték a szerverét, először egy dolog számít: a nyomok megőrzése. Az első üzenettől távolról átvesszük a helyzetképet, a mentést, a megfékezést, a tisztítást és a dokumentálást, amíg az incidens le nem zárul.

Érintett? Jelek arra, hogy feltörték a szervert

Egy gyanú elég ahhoz, hogy jelentkezzen. A támadást nem kell bizonyítania. Tipikus jelek:

• A webszerver vagy a PHP-FPM olyan folyamatokat indít, mint az sh vagy a bash. Ez erős figyelmeztető jel, amelyet a A webszerver shellt indít oldalon magyarázunk el.
• A feltöltési, gyorsítótár- vagy temp-mappákban új vagy ismeretlen PHP-fájlok vannak.
• Vannak cron-feladatok, amelyeket senki sem hozott létre, vagy SSH-kulcsok, amelyeket senki sem tud hová tenni.
• A terhelés látható ok nélkül magas, vagy a szerver szokatlan kimenő kapcsolatokat épít fel.
• A szerveréről küldött levelek a spambe kerülnek, vagy elutasítják őket.
• A tárhelyszolgáltató, egy ügyfél vagy egy böngészőbeli figyelmeztetés kártékony kódot jelez.
• A CMS-ben olyan rendszergazdai fiókok jelennek meg, amelyeket senki sem hozott létre.

További jeleket itt talál: Már feltörték a rendszeremet?. Ha több pont is igaz, kezelje a szervert feltörtként, amíg az ellenkezője nem igazolódik.

Feltörték a szervert: mit tegyen azonnal

1. Maradjon nyugodt, és ne változtasson semmit. Ne töröljön fájlokat, ne végezzen „gyors javításokat”, ne telepítsen újra a régi állapot fölé.
2. Rögzítse az időpontot. Jegyezze fel, mit mikor észlelt, és ki végzett utoljára módosításokat a rendszeren.
3. Őrizze meg a naplókat. A hozzáférési, hiba- és rendszernaplók nem rotálódhatnak és nem íródhatnak felül. A PHP2Shell esetében a szakmai sajtó azt javasolja, hogy a szervernaplókat 2026. október 20-tól őrizzék meg.
4. Csökkentse a támadási felületet. Ha adatok szivároghatnak ki, vegye le a szervert a nyilvános hálózatról, vagy zárja el tűzfallal. Ne egyszerűen kapcsolja ki.
5. Gyűjtse össze a hozzáféréseket. Kinek van SSH-, panel-, FTP-, CMS- és adatbázis-hozzáférése? A jelszavakat csak egyeztetés után, és csak egy tiszta eszközről módosítsa.
6. Nevezzen meg kapcsolattartót. Legyen elérhető egy döntési jogkörrel rendelkező személy, a leállításhoz és az újraindításokhoz is.
7. Jelentkezzen most. Hívjon minket, vagy írjon WhatsAppon. Minden mást lépésről lépésre tisztázunk Önnel.

Hálózatról levenni, vagy futni hagyni?

Ez az első percek leggyakoribb kérdése, és nincs rá általános válasz. Ha fizetésekkel működő webshop vagy ügyféladatokat kezelő portál fut, többnyire az adatok védelme a döntő. Ilyenkor az átmeneti elzárás a helyes, például karbantartási oldallal vagy olyan tűzfalszabállyal, amely csak az Ön rendszergazdáit engedi be.

A kemény kikapcsolás ezzel szemben ritkán a legjobb első lépés, mert a memóriában olyan nyomok vannak, amelyeket egy újraindítás töröl. Jobb a rendszer lenyomata, például egy snapshot a tárhelyszolgáltatónál, mielőtt bármi megváltozik. A PHP2Shell-helyzetben a BSI azt javasolja, hogy a webszervereket átmenetileg le kell választani a hálózatról, ha a frissítés nem lehetséges azonnal. Ez nem jelenti azt, hogy minden lekapcsolt szervert feltörtek.

Hogy az Ön esetében elzárjuk, korlátozzuk vagy futni hagyjuk, azt Önnel együtt döntjük el, a rendszeren lévő adatok alapján.

Újratelepítés vagy tisztítás?

Sokan legszívesebben azonnal újraépítenék a szervert. Ez nem helytelen, de csak a mentés után. Különben nem derül ki, hogyan jutott be a támadó, és ugyanaz az út az új rendszer előtt is nyitva áll. A mérlegelést a Szerver újratelepítése vagy tisztítása? oldal írja le, az újjáépítés előtti mentést pedig a Őrizze meg a bizonyítékokat az újratelepítés előtt oldal.

Fontos: egy PHP-frissítés önmagában nem oldja meg a problémát. Lezárja a rést, de nem távolítja el a már bejuttatott kártékony szoftvert. Hogyan találhatók meg a nyomok a naplókban, azt a Webszerver-naplók elemzése egy támadás után oldalon találja. És számoljon azzal, hogy a konfigurációs fájlokból hozzáférési adatokat is kiolvastak: az adatbázis-, levelezési és API-hozzáféréseknek is rajta kell lenniük a megújítandó titkok listáján.

Hogyan segít konkrétan a PHP SOS?

1. Helyzetfelmérés: Önnel együtt tisztázzuk, mit észleltek, mely rendszerek lehetnek érintettek, és milyen adatok vannak rajtuk.
2. Mentés és lezárás: Mentjük a fájlokat, az adatbázist és a naplókat, mielőtt bármi megváltozna. Utána megfékezzük a támadást, és lezárjuk a bejáratot, PHP2Shell esetén javítással és az összes PHP-folyamat újraindításával.
3. Vizsgálat és tisztítás: Webshelleket, hátsó ajtókat, cron-feladatokat és idegen hozzáféréseket keresünk, és eltávolítjuk őket. A részletek itt vannak: Kártevők és webshellek eltávolíttatása.
4. Keményítés és jelentés: Dokumentációt kap idővonallal, lelőhelyekkel és ajánlásokkal. Ha az incidens egy szerveren túlra terjed, strukturált Incident Response eljárásba lépünk.

Mit ne tegyen

Stresszhelyzetben elkerülhető hibák történnek. Ne töröljön „gyanús” fájlokat pusztán gyanú alapján úgy, hogy előtte nem mentette őket. Ne futtasson fórumokból származó parancsokat, amelyeket nem ért. És ne telepítsen biztonsági bővítményeket olyan szerverre, amely esetleg már kompromittálódott: a kártékony kód becsaphatja a szkennereket, az eredmény pedig hamis biztonságérzetbe ringat. Óvatosan bánjon azokkal a tanácsokkal is, amelyek szerint egy bizonyos munkamenet-azonosítót tartalmazó összes kérést blokkolni kell; a szakírók a PHP2Shellel kapcsolatos ilyen tanácsokat kifejezetten elutasítják. A saját verzióját biztonságosan ellenőrizheti a php -v paranccsal és a disztribúciója csomag-changelogjának átnézésével, mert a backportok gyakran ugyanazon a verziószámon hagyják a rendszert.

Mit érdemes elküldenie nekünk

• rövid leírás: mi tűnt fel, mióta, mit módosítottak utoljára
• a rendszer típusa: saját szerver, vServer, menedzselt szerver vagy tárhelycsomag
• SSH- vagy paneles hozzáférés, vagy engedély arra, hogy beszéljünk a tárhelyszolgáltatójával
• információ a meglévő mentésekről és azok koráról
• a tárhelyszolgáltató, a böngésző vagy az ügyfelek figyelmeztető üzenetei szó szerint

Ha ezek közül valami hiányzik, jelentkezzen így is. A hiányokat a beszélgetés során pótoljuk.

Miért a PHP SOS

A munkánk Made in Germany, és a kiberbiztonsági szakemberekből álló partnerhálózatunkkal több mint 25 éve az informatikai biztonságra szakosodtunk. Egy kapcsolattartója van, távolról dolgozunk, kiszállás nélkül, egész Németországban és Európában. Minden lépést dokumentálunk, és nyíltan elválasztjuk a bizonyítottat, a valószínűt és az ismeretlent. Olyan ígéreteket, amelyeket senki sem tarthat be, nem teszünk. A további teendők áttekintése a Feltörés utáni ellenőrzőlistában áll, a teljes vészhelyzeti segítség pedig itt: Feltörték a weboldalt? Vészhelyzeti segítség távolról. Az adatvédelmi incidensek bejelentési kötelezettségéről olvassa el a 72 órás szabályt; a jogi értékelés az adatvédelmi felelősöknél és az ügyvédeknél marad.

Érintett? Hívjon minket. Segítünk.

Ne várjon, amíg a gyanúból nagyobb kár lesz. Az első üzenettől átvesszük az ügyet, és addig maradunk, amíg az incidens le nem zárul, és dokumentált nem lesz. Vészhelyzet bejelentése most.

Gyakori kérdések

Források

• BSI: Szövetségi Információbiztonsági Hivatal (Németország)
• GDPR 33. cikk: bejelentés a felügyeleti hatóságnak
• OWASP Cheat Sheets