Röviden: A webshellt új vagy módosított PHP-fájlokról ismeri fel szokatlan helyeken, a webszerver-felhasználó idegen folyamatairól és szokatlan kapcsolatokról. Mentse le a nyomokat, mielőtt bármit törölne, és a kódot tiszta forrásból állítsa helyre. Egy javítás önmagában nem távolít el hátsó ajtót.
Miért téma a webshell a PHP2Shell után
A magában a PHP-ban lévő CVE-2026-109618 és CVE-2026-109619 rések lehetővé teszik kártékony kód távoli futtatását bejelentkezés nélkül. Egy sikeres támadás után kézenfekvő cél a tartós hátsó ajtó, vagyis egy webshell. Ez akkor is megmarad, ha a PHP-t időközben frissítették.
Médiabeszámolók szerint az első támadási kísérletet már 2026. 10. 17-én megfigyelték, a javítások 10. 21-én követték. Akinek a rendszere ebben az időszakban sebezhető volt, annak célzottan utána kell néznie. Megerősített Indicators of Compromise eddig nincsenek közzétéve. A keresés ezért a viselkedés feltűnő jeleire támaszkodik, nem kész listára.
Ha ügyféladatokat tároló szerveren webshellt talál: ne töröljön semmit kapkodva. Először mentse a bizonyítékokat, utána különítse el a szervert, és tervezze meg a további kezelést.
Hogyan ismeri fel a webshellt: fájlok vizsgálata
A legtöbb webshell PHP-fájl a webkönyvtárban. Feltűnőek a 10. 17. után keletkezett vagy módosított fájlok, a feltöltési és gyorsítótár-mappákban lévő PHP-fájlok, valamint az elfedett kódú fájlok. A következő parancsok nem változtatnak semmin, csak listáznak:
# A 2026. 10. 17. óta módosított PHP-fájlok
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# PHP-fájlok feltöltési, gyorsítótár- vagy tmp-mappákban
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Tipikus elfedés: eval dekódolással kombinálva
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# A szokatlanul hosszú sorok gyakran tömörített kódra utalnak
grep -rlE ".{3000,}" /var/www --include="*.php"
A találatok jelzések, nem bizonyítékok. Egyes bővítmények jogosan használnak kódolt kódot. Vesse össze a gyanús fájlokat a gyártó eredeti csomagjával. A legmegbízhatóbb az ellenőrző összegekkel vagy egy olyan verziókezelő rendszerrel való összevetés, mint a Git:
# Eltérések az utolsó ismert állapottól a Git-tárolóban
git -C /var/www/projekt status --porcelain
Az időbélyeg hamisítható. Ezért ne támaszkodjon kizárólag egy fájl módosítási dátumára.
Mely jegyek teszik gyanússá a fájlt
| Jegy | Miért feltűnő |
|---|---|
| PHP-fájl egy feltöltési vagy képmappában | Ott csak médiafájloknak szabadna lenniük |
Dupla kiterjesztés, például .jpg.php vagy .php.png |
Ártalmatlan fájlnak álcázás |
| Nagyon hosszú, tördelés nélküli sorok | Tömörített vagy titkosított kódra jellemző |
| A fájlnév egy alapfájléhoz hasonlít, de nincs az eredeti csomagban | Álcázás az ismert környezetben |
| A tulajdonos vagy a jogok eltérnek a szomszédos fájlokétól | A fájlt más úton hozták létre |
Minél több jegy esik egybe, annál nagyobb a találat valószínűsége. A gyanús fájlokat csak szövegként nyissa meg, soha nem a böngészőn keresztül, mert a weboldalon át való meghívás futtatná a kódot.
Folyamatok, kapcsolatok és cron-feladatok ellenőrzése
Egy aktív webshell gyakran a fájlrendszeren kívül is hagy nyomokat. A webszerver-felhasználó, például a www-data, az apache vagy az nginx, normális esetben nem indít shelleket, hálózati eszközöket vagy fordítókat.
# A tipikus webszerver-felhasználók folyamatai
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Nyitott hálózati kapcsolatok a hozzájuk tartozó folyamattal
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# A webszerver-felhasználó ütemezett feladatai
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Feltűnőek a tartós kimenő kapcsolatok ismeretlen célok felé, a rejtélyes nevű folyamatok és az olyan cron-feladatok, amelyek fájlokat töltenek le az internetről. Ellenőrizze emellett a hozzáférési naplókat azokra a kérésekre, amelyek korábban nem létező fájlokra irányulnak. Hogyan működik ez, azt a Webszerver-naplók kiértékelése egy támadás után útmutató írja le.
Nyomok mentése az eltávolítás előtt
Aki előbb töröl, elveszíti a legfontosabb kérdések válaszát: hogyan jutott be a támadó, mit látott, mely adatok érintettek? Ezekre a válaszokra szüksége van egy esetleges GDPR szerinti bejelentéshez, a biztosítókhoz, és annak eldöntéséhez, hogy veszélyben vannak-e további rendszerek.
Célszerű sorrend:
- Dokumentálja az állapotot: folyamatlista, hálózati kapcsolatok, bejelentkezett felhasználók.
- Másolja le a gyanús fájlokat és naplókat ellenőrző összeggel, anélkül hogy megnyitná vagy futtatná őket.
- Ha lehetséges, készítsen a rendszerről lemezképet vagy a virtuális gépről pillanatképet (snapshot).
- Vegye le a szervert a hálózatról, vagy erősen korlátozza a hozzáférést.
Érzékeny adatokat tartalmazó vagy lehetséges jogvitával érintett rendszereknél a mentést forenzikailag szabályosan kell végezni. A háttérről a IT-forenzika egy webszerver-támadás után oldalon olvashat.
Webshellek szakszerű eltávolítása
Egyetlen fájl törlése ritkán jelenti a végét. A támadók gyakran több hozzáférést hoznak létre: további fájlokat rejtett helyeken, bejegyzéseket konfigurációs fájlokban, például a .htaccess-ben vagy a .user.ini-ben, új rendszergazdai fiókokat az alkalmazásban, vagy cron-feladatokat. A megbízható megtisztítás ezeket a lépéseket követi:
- Vigye a PHP-t javított állapotba (8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy igazolt backport), és indítsa újra az összes PHP-folyamatot.
- Az alkalmazáskódot tiszta forrásból telepítse újra, ahelyett hogy egyes fájlokat javítana.
- Csak ellenőrzött tartalmakat vegyen át, például a feltöltéseket és az adatbázist, és ott célzottan keresse a bejuttatott kódot.
- Cserélje le az összes hozzáférési adatot: adatbázis, SSH, FTP, rendszergazdai fiókok, API-kulcsok.
- Korlátozza a webszerver írási jogait a legszükségesebbre, és tiltsa a PHP-végrehajtást a feltöltési mappákban.
A WordPress-nek megvannak a saját tipikus rejtekhelyei, amelyeket a Hátsó ajtók keresése a WordPressben útmutató ír le. Ezután a weboldalt egy ideig szorosabban érdemes figyelni, hogy egy ismételt hozzáférést időben észrevegyenek.
Hogyan segít konkrétan a PHP SOS?
- Követhető módon lementjük a naplókat, fájlokat és a rendszerállapotot, mielőtt bármit megváltoztatnánk.
- Hátsó ajtókat keresünk a fájlokban, az adatbázisban, a cron-feladatokban és a konfigurációban, és besoroljuk a találatokat.
- Az alkalmazást tiszta forrásból újra felállítjuk, lecseréljük a hozzáféréseket és megerősítjük a szervert.
- Az incidenst a lezárásáig dokumentáljuk, bejelentések és biztosítók számára alapként.
A megtisztítás menetét a Kártevők és webshellek eltávolíttatása szolgáltatás írja le.
Gyakori kérdések
Mi az a webshell?
A webshell egy bejuttatott fájl, többnyire PHP, amelyen keresztül a támadók távolról irányíthatják a szervert. Gyakran ártalmatlan fájlnak álcázza magát jelentéktelen névvel, és egy frissítés után is aktív marad.
Minden webshellt megtalál egy vírusirtó?
Nem. A szkennerek az ismert mintákat ismerik fel, az új vagy erősen elfedett változatok átcsúsznak. A PHP2Shell-hez ráadásul nincsenek közzétett, megerősített Indicators of Compromise, ezért a viselkedéselemzés fontosabb egy aláírás-listánál.
Elég törölni a megtalált fájlt?
Többnyire nem. A támadók gyakran több hozzáférést hoznak létre, például további fájlokat, cron-feladatokat vagy új rendszergazdai fiókokat. Az ok elemzése és az összes hozzáférési adat cseréje nélkül a megismételt hozzáférés valószínű.
Be kell jelentenem valamit, ha webshellt találtam?
Ha személyes adatok érintettek lehetnek, a GDPR alapján bejelentési kötelezettség állhat fenn, általában 72 órán belül. Tisztázza az adatvédelmi felelősével vagy egy ügyvéddel; ez nem jogi tanácsadás.