# Gyanús folyamatok keresése Linux-szervereken

> Gyanús folyamatok keresése Linuxon: törölt programfájlok, álcázott nevek és indítási helyek felismerése, a folyamatok csomaghoz rendelése és a nyomok mentése.

Forrás: https://phpsos.de/hu/blog/verdaechtige-prozesse-linux/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A gyanús folyamatokat Linux-szervereken néhány jellemzőről ismeri fel: a programfájl törölt, vagy a `/tmp`, a `/dev/shm` vagy egy webkönyvtár alatt van, a név egy rendszerfolyamatot utánoz, szokatlan a felhasználó, tartósak a hálózati kapcsolatok, vagy ok nélkül magas a terhelés. Olvasó parancsokkal ellenőrizze, hogy a programfájl egy telepített csomaghoz tartozik-e, és a találatokat mentse el, mielőtt bármit befejezne.

## Mit jelent a „gyanús” egy folyamatnál

Egy webszerveren több száz folyamat fut. A legtöbb az operációs rendszerhez, a webszerverhez, az adatbázishoz vagy a PHP-hez tartozik. Az a támadó, aki egy olyan résen keresztül, mint a PHP2Shell, kódot tudott végrehajtani, arra törekszik, hogy közöttük ne tűnjön fel. Ártalmatlan neveket választ, és a programokat ott helyezi el, ahová a webszerver-felhasználó írhat.

Az ellenőrzéshez segít ismerni a normál állapotot. Aki tudja, mely szolgáltatásoknak kell futniuk egy szerveren, mely felhasználók alatt és milyen terheléssel, az sokkal gyorsabban ismeri fel az eltéréseket. Ha ez a tudás hiányzik, érdemes összehasonlításul egy hasonló, nem gyanús szerver folyamatlistáját használni.

Egyetlen jellemző még nem bizonyíték. A döntő az együttes hatás. Egy kernel-szál nevét viselő folyamat, amely a `www-data` alatt fut, a `/dev/shm` mappából indították, és külföldre tart fenn kapcsolatot, egyértelmű eset. Hogyan ellenőrzi a webszerver alatti shell különleges esetét, azt a [Figyelmeztető jel: a webszerver shellt indít](https://phpsos.de/hu/blog/webserver-startet-shell/) írja le.

## Első áttekintés öt paranccsal

Minden parancs csak olvas. Futtassa őket rootként, hogy minden folyamatot lásson, és a kimeneteket mentse el a webkönyvtáron kívüli fájlba.

```bash
# 1. Az összes folyamat felhasználóval, szülő-PID-del, indulási idővel, CPU-val és parancssorral
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40

# 2. Folyamatok, amelyeknek a programfájlját törölték
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"

# 3. Ideiglenes vagy webkönyvtárakból futó folyamatok
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"

# 4. Hálózati kapcsolatokkal rendelkező folyamatok
ss -tunap

# 5. A webszerver-felhasználók folyamatainak áttekintése
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
```

A felhasználónevek disztribúciónként és panelenként eltérnek; a Plesk és más panelek a PHP-t gyakran az adott ügyfél felhasználója alatt futtatják. Igazítsa a listát a környezetéhez.

A kimeneteket az indulási idő szempontjából olvassa. Azok a folyamatok, amelyek a szerver utolsó újraindítása óta futnak, többnyire a rendszerhez tartoznak. Azok, amelyeket az éjszaka közepén vagy az október 17. utáni napokban indítottak, és egyetlen szolgáltatáshoz sem illenek, figyelmet érdemelnek. Hasonlítsa össze a PHP-folyamatok számát azzal is, amit a pool-konfigurációja megenged; egy webszerver-felhasználó alatt észrevehetően több folyamat jelzés.

## Gyanús folyamatok Linuxon: tipikus jellemzők

| Jellemző | Miért tűnik fel | Lehetséges ártalmatlan magyarázat? |
|---|---|---|
| A programfájl „(deleted)” | a támadók az indítás után törlik a fájlokat | igen, csomagfrissítések után az újraindításig |
| Indítási hely `/tmp`, `/dev/shm`, feltöltési mappa | oda bárki vagy a webszerver írhat | ritkán |
| Szögletes zárójeles név, például `[kworker]` | kernel-szálakat utánoz | nem, ha mögötte programfájl áll |
| Tartósan magas CPU-terhelés ok nélkül | a kriptobányászokra tipikus | igen, kötegelt feladatoknál vagy indexelésnél |
| 1-es szülőfolyamat és webszerver-felhasználó | leválasztották a webszerverről, önállóan fut tovább | ritkán |
| Kapcsolat ismeretlen célhoz | irányítás vagy adatszivárgás | igen, frissítéseknél és API-knál |

Az igazi kernel-szálaknak nincs programfájljuk; az `ls -l /proc/PID/exe` náluk nem ad útvonalat. Ha egy kernel-nevű folyamat egy fájlra mutat, álcázott. Ha ok nélkül magas a terhelés, a [Kriptobányász a webszerveren](https://phpsos.de/hu/blog/kryptominer-auf-dem-server/) cikk segít tovább.

## Ellenpróba: a programfájl egy csomaghoz tartozik?

A szerveren szinte minden jogos program a csomagkezelőből származik. Az a programfájl, amely egyetlen csomaghoz sem tartozik, nem automatikusan kártékony, de alapos vizsgálatot érdemel.

```bash
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE"        # Debian/Ubuntu: melyik csomaghoz tartozik a fájl?
rpm -qf "$EXE"        # RHEL-család
sha256sum /proc/$PID/exe   # ellenőrző összeg, törölt fájlnál is működik
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo   # környezeti változók
```

Ha a programfájl törölt, a `sha256sum /proc/$PID/exe` ennek ellenére kiolvassa a futó folyamatból. Ez az ellenőrző összeg a dokumentációba tartozik. A fájl másolatát csak az készítse el, aki tudja, hogyan kell biztonságosan megőrizni.

## Az ellenőrzés korlátai a futó rendszeren

A fenti parancsok mind megbíznak abban a rendszerben, amelyet éppen ellenőriz. Egy szokásos, a webszerver-felhasználó jogaival a weboldalon keresztül végrehajtott behatolásnál ez vállalható. Ha a támadó root jogosultságot szerzett, elrejtheti a folyamatokat, és meghamisíthatja a kimeneteket. Ekkor a szerver csak azt mutatja, amit a támadó megenged.

Erre ellentmondások utalnak: terhelés látható folyamat nélkül, kapcsolatok, amelyeket a tűzfal lát, az `ss` viszont nem, vagy módosított rendszerprogramok. Ilyen esetekben az ellenőrzés egy biztosított lemezképre tartozik. Futó rendszereknél gyakran a memória mentése is hozzájön, mert egyes kártevők csak ott léteznek, és a merevlemezen alig hagynak nyomot. Ezt a mentést az újraindítás előtt kell elvégezni, és megfelelő eszközöket és tapasztalatot igényel. Hogy miért érdemes ezt az újratelepítés előtt elkészíteni, azt a [Bizonyítékok mentése az újratelepítés előtt](https://phpsos.de/hu/blog/beweise-sichern-vor-neuinstallation/) magyarázza.

> **Fontos:**
> A gyanús folyamatokat ne első lépésként fejezze be. Gyakran egy cron-feladat vagy egy szolgáltatás újraindítja őket, és a folyamattal együtt eltűnik a memóriából a parancssor, a kapcsolatok és a törölt programfájl.

## Az automatikus indítások ellenőrzése és a következő lépések

Egy olyan kártékony folyamat, amely az újraindítás után eltűnne, értéktelen lenne a támadóknak. Ezért minden folyamatleletnél felmerül a kérdés, mi indítja. A cron-feladatok mellett elsősorban a systemd-szolgáltatások jöhetnek szóba, amelyeket egy root jogú támadó létrehozhat. Feltűnőek az általános nevű szolgáltatások, amelyek programfájlja szokatlan könyvtárban van, és az október 17. után keletkezett unit-fájlok.

```bash
# Futó szolgáltatások és a nemrég módosított unit-fájlok
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null

# Bejut egy könyvtár minden folyamatba? A fájl normálisan nem létezik.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
```

Az `/etc/ld.so.preload` bejegyzése normális webszervereken ritka, és a root jogosultsággal végzett manipuláció erős jele. Hogyan ellenőrzi teljesen az ütemezett feladatokat, azt a [Rejtett cron-feladatok felismerése hátsó kapuként](https://phpsos.de/hu/blog/cronjobs-als-hintertuer/) írja le.

Ezután a következő lépések következnek ebben a sorrendben:

1. A kimenetek és az ellenőrző összegek mentése időponttal.
2. A perzisztencia keresése: cron-feladatok, systemd-szolgáltatások és időzítők, SSH-kulcsok.
3. Az eredet tisztázása: naplók 2026. október 20-tól, új fájlok a webkönyvtárban.
4. A szerver elkülönítése, a tisztítás vagy az újjáépítés megtervezése.

A PHP2Shell utáni összes tipikus jelről áttekintést ad a [Megfertőzték már a rendszeremet?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal.

## Hogyan segít konkrétan a PHP SOS?

- **A folyamatok értékelése:** Ellenőrizzük a folyamatlistát, a programfájlokat és a kapcsolatokat, és besoroljuk az összes leletet.
- **Bírósági felhasználásra alkalmas mentés:** Az [IT-forenzikával](https://phpsos.de/hu/leistungen/it-forensik/) mentjük a memóriát és az adathordozókat, mielőtt bármit megváltoztatnánk.
- **A perzisztencia megkeresése:** Olyan mechanizmusokat keresünk, amelyek újraindítják a kártékony folyamatokat.
- **Lezárás:** Megtisztítunk vagy újjáépítünk, és az incidenst a lezárásig dokumentáljuk.


## Gyakori kérdések

**Miről ismerek fel egy gyanús folyamatot Linuxon?**  
Tipikus jellemzők: törölt programfájl, indítási hely a /tmp vagy /dev/shm alatt, egy rendszerfolyamatot utánzó név, szokatlan felhasználó és tartós hálózati kapcsolatok. Az egyes jellemzők csak jelzések, több együtt komoly gyanú.

**Mit jelent a „(deleted)” a /proc/PID/exe mellett?**  
A folyamat programfájlját az indítás után törölték. Ez jogosan megtörténik csomagfrissítések után, amíg a szolgáltatás újra nem indul. Ideiglenes mappákból indított vagy a webszerver-felhasználó alatt futó folyamatoknál tipikus álcázó viselkedés.

**Megbízhatok a ps kimenetében?**  
Egy szokásos behatolásnál többnyire igen. Ha a támadó azonban root jogosultságot szerzett, eszközöket és kimeneteket manipulálhat. Ilyenkor megbízhatóbb a kívülről végzett ellenőrzés, például egy biztosított lemezképen.

**Be kell fejeznem egy gyanús folyamatot a kill paranccsal?**  
Nem elsőként. Először mentse a parancssort, a programfájlt, a kapcsolatokat és az indulási időt. Egy befejezett folyamat már semmit sem árul el, és gyakran egy cron-feladat vagy szolgáltatás amúgy is újraindítja.

## Források

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: a német szövetségi információbiztonsági hivatal](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)