Röviden: A kriptobányász a szerveren többnyire ok nélkül tartósan magas CPU-terheléssel, idegen folyamatokkal, gyakran a webszerver-felhasználó alatt, és ismeretlen célokra irányuló kimenő kapcsolatokkal mutatkozik meg. Ne fejezze be elhamarkodottan a folyamatot: először mentse a nyomokat, keresse meg az újraindító mechanizmusokat, és zárja le a bejutási pontot. A bányász azt jelenti, hogy valaki kódot tudott végrehajtani az Ön szerverén.
Ha a felhőszolgáltató számlája az első figyelmeztetés
A kriptobányász gyakran nem biztonsági riasztással tűnik fel, hanem mellékesen. A weboldal lassú lesz, a tárhelyszolgáltató számítási idő túllépést jelez, a saját adatközpontban folyamatosan fut a ventilátor, vagy a felhőszolgáltatónál emelkedik a számla új projektek nélkül. A támadók számára a bányász egyszerű mód arra, hogy egy feltört szerverből pénzt csináljanak.
A bányászat azt jelenti, hogy egy idegen rendszer számítási teljesítményét használják kriptovaluta előállítására. A kár áttekinthetőnek látszik, mert adatokat nem titkosítanak. Ez megtévesztő: aki egy bányászt el tud indítani, az hozzáférési adatokat is tud olvasni, adatbázisokat másolni és további hátsó kapukat létrehozni.
A PHP2Shell után az ellenőrzés különösen megéri. A CVE-2026-109618 és a CVE-2026-109619 rések bejelentkezés nélkül lehetővé teszik kártékony kód végrehajtását. Megerősített Indicators of Compromise nincsenek, és a bányász nem sajátos jele ezeknek a réseknek. Az ismeretlen folyamatok okozta magas terhelés viszont azok az általános jelek közé tartozik, amelyeket a Megfertőzték már a rendszeremet? ír le.
A kriptobányász jeleinek helyes értelmezése
A magas terhelésnek sok ártalmatlan oka van. A táblázat az első besorolásban segít:
| Megfigyelés | Lehetséges ártalmatlan magyarázat | Mit ellenőrizzen |
|---|---|---|
| A CPU tartósan közel teljes kihasználtságon | mentés, képfeldolgozás, indexépítés | A terhelés éjszaka és hétvégén is egyenletes? |
| Rendszerszolgáltatás nevét viselő folyamat | ritkán | A programfájl a várt rendszerútvonalon van? |
www-data, apache vagy nginx alatti folyamat, amely nem PHP |
alig | Ki indította, melyik mappából? |
Program a /tmp, a /var/tmp vagy a /dev/shm alatt |
alig | Mióta létezik a fájl, kié? |
| Tartós kimenő kapcsolat ismeretlen célhoz | monitoring, frissítések | A cél egy ismert szolgáltatáshoz tartozik? |
| A terhelés csökken, amint bejelentkezik | ritkán | Egyes kártevők szüneteltetik magukat, ha felügyeleti eszközök futnak |
Minél több sor érvényes, annál valószínűbb a lelet. Hogy a webszerver-felhasználó egyáltalán idegen programokat indít, az önmagában erős figyelmeztető jel, ahogyan a A webszerver shellt indít cikk mutatja.
Így ellenőrzi a folyamatokat és a kapcsolatokat
A következő parancsok csak olvasnak. Jegyezze fel az eredményt és az időpontot, mielőtt bármit megváltoztatna:
# Folyamatok CPU-fogyasztás szerint, felhasználóval, indulási idővel és teljes paranccsal
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Egy gyanús folyamat programfájlja és munkakönyvtára (a PID behelyettesítendő)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Kimenő kapcsolatok folyamattal
sudo ss -tnp state established
# Végrehajtható fájlok az ideiglenes mappákban
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Ha az /proc/PID/exe egy (deleted) kiegészítésű fájlra mutat, a programot az indítás után törölték. Ez tipikus álcázási kísérlet. A folyamat tovább fut, és amíg fut, a programfájl még menthető a /proc-on keresztül. Ezt olyasvalakinek kell átvennie, aki tud bánni a kártevőkkel; a fájlt soha ne hajtsa végre.
Hogyan veszi végig szisztematikusan a folyamatokat a bányászon túl, azt a Gyanús folyamatok keresése Linux-szervereken írja le.
Miért tér vissza mindig a bányász
Sok üzemeltető befejezi a folyamatot, örül a csökkenő terhelésnek, és másnap azt állapítja meg, hogy minden elölről kezdődik. A bányászokat szinte mindig újraindító mechanizmussal telepítik. Tipikus helyek:
- Cron-feladatok a webszerver-felhasználónál vagy rendszerszinten, amelyek néhány percenként ellenőrzik, fut-e a bányász, és különben újra letöltik.
- Rendszerszolgáltatások feltűnésmentes nevekkel, amelyek bootoláskor indulnak.
- Egy webshell a webkönyvtárban, amelyen keresztül a támadó bármikor újraindíthatja a bányászt.
- Módosított indítási szkriptek vagy felhasználói profilfájlok.
- Idegen SSH-kulcsok, amelyekkel a támadó közvetlenül újra bejelentkezik.
# A webszerver-felhasználó cron-feladatai és rendszerszintű bejegyzések
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Utoljára módosított systemd-unitok
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Csak ha az összes mechanizmust megtalálták, marad tartósan nyugodt a szerver. Ha a támadó root jogosultságot szerzett, egy friss rendszeren való újjáépítés többnyire megbízhatóbb, mint minden búvóhely keresése.
A helyes sorrend a lelet után
A bányász technikai bosszúságnak látszik, de biztonsági incidens. Járjon el ezért rendezetten:
- Mentés: Másolja le a folyamatlistát, a kapcsolatokat, a gyanús fájlokat és a naplókat ellenőrző összeggel, mielőtt bármit befejeznének.
- Megfékezés: Különítse el a szervert, vagy zárolja a kimenő kapcsolatokat, ha ez adatvesztés nélkül lehetséges.
- Az ok lezárása: Hozza a PHP-t kijavított állapotba (8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy megerősített backport), indítsa újra az összes workert, frissítse a CMS-t és a bővítményeket.
- Tisztítás vagy újjáépítés: Távolítsa el a bányászt, az újraindító mechanizmusokat és a hátsó kapukat, kétség esetén telepítse újra.
- A következmények vizsgálata: Olvashattak hozzáférési adatokat vagy személyes adatokat? Akkor tisztázza az adatvédelmet és adott esetben a bejelentési kötelezettségeket.
Vonja be korán a tárhelyszolgáltatóját vagy a felhőszolgáltatóját. Sok szolgáltató elővigyázatosságból zárolja a feltűnő terhelésű vagy feltűnő hálózati forgalmú szervereket. Aki maga tájékoztatja a szolgáltatót, és egyezteti az eljárást, nagyobb eséllyel megtartja a kontrollt a lekapcsolás időpontja felett. Kérdezzen közben a szolgáltató hálózati és hozzáférési naplóiról is, mert ezek a szerverén kívül vannak, és a támadó számára nehezen módosíthatók.
A vezetőség számára fontos egy rövid, őszinte besorolás: maga a bányász főként számítási időt és teljesítményt visz el. Az igazi kérdés azonban az, hogy a támadó mit látott még. Amíg ez nincs tisztázva, az incidenst nem szabad lezártnak tekinteni, még ha a terhelés újra normális is.
A kriptobányász azt mutatja, hogy kódot hajtottak végre az Ön szerverén. Minden, a szerveren lévő hozzáférési adatot tekintsen esetleg kiszivárgottnak, és a tisztítás után újítsa meg őket.
Hogyan segít konkrétan a PHP SOS?
- Besoroljuk a terhelést, és különbséget teszünk az ártalmatlan okok és az idegen folyamatok között.
- A folyamatokat, fájlokat és kapcsolatokat mentjük, mielőtt a bányászt befejeznék.
- Megkeresünk minden újraindító mechanizmust és hátsó kaput, és a kártevő-eltávolítás keretében megtisztítjuk a szervert, vagy újjáépítjük.
- Lezárjuk a bejutási pontot, megújítjuk a hozzáféréseket, és beállítunk egy terhelésfigyelést, amely korán jelzi a szokatlan mintákat.
Gyakori kérdések
Miről ismerem fel a kriptobányászt a szerveremen?
Tipikus a tartósan magas CPU-terhelés, amely nem illik a látogatószámokhoz vagy az ütemezett feladatokhoz. Ehhez jönnek az ismeretlen vagy ártalmatlanul hangzó nevű folyamatok, gyakran a webszerver-felhasználó alatt, és az idegen címekre irányuló kimenő kapcsolatok. Egyetlen jellemző még nem bizonyíték.
Elég a bányászfolyamatot befejezni?
Nem. A bányászokat többnyire cron-feladatok, rendszerszolgáltatások vagy egy webshell indítja újra és újra. Aki csak a folyamatot fejezi be, rövid idő múlva gyakran újra látja. Ráadásul nyitva marad a bejutási pont, amelyen át a bányász a szerverre került.
Ártalmatlan a kriptobányász, mert csak számítási teljesítményt lop?
Nem. Aki bányászt tudott telepíteni, kódot tudott végrehajtani a szerveren. Ezzel általában a konfigurációs fájlok, a hozzáférési adatok és az adatbázisok is elérhetők voltak. A bányász egy behatolás látható tünete.
Milyen ártalmatlan okai lehetnek a magas szerverterhelésnek?
A mentések, a képfeldolgozás, a keresőindex felépítése, az agresszív crawlerek vagy egy hibás bővítmény is sok számítási időt emészthet fel. Ezek az okok többnyire egy ismert folyamathoz és ütemtervhez rendelhetők. Ha a terhelés magyarázat nélkül marad, alaposabban ellenőrizze.