Na kratko: Kriptorudar na strežniku se običajno pokaže s stalno visoko obremenitvijo CPU brez prepoznavnega razloga, s tujimi procesi, pogosto pod uporabnikom spletnega strežnika, in z odhodnimi povezavami do neznanih ciljev. Procesa ne končajte prenagljeno: najprej zavarujte sledi, poiščite mehanizme, ki ga znova zaženejo, in zaprite vstopno točko. Rudar pomeni, da je nekdo lahko izvajal kodo na vašem strežniku.
Ko je prvo opozorilo račun ponudnika oblaka
Kriptorudar pogosto ne pade v oči z varnostnim alarmom, ampak mimogrede. Spletna stran postane počasna, ponudnik gostovanja javi preseganje računskega časa, ventilator v lastnem podatkovnem centru stalno teče ali pa obračun pri ponudniku oblaka naraste brez novih projektov. Za napadalce je rudar preprosta pot, da iz ogroženega strežnika naredijo denar.
Rudarjenje pomeni uporabo računske moči tujega sistema za ustvarjanje kriptovalute. Škoda se zdi obvladljiva, ker se nobeni podatki ne šifrirajo. To zavaja: kdor lahko zažene rudarja, lahko bere tudi dostopna gesla, kopira podatkovne baze in ustvari nadaljnja stranska vrata.
Po PHP2Shell se preverjanje še posebej splača. Ranljivosti CVE-2026-109618 in CVE-2026-109619 omogočata izvajanje škodljive kode brez prijave. Potrjenih indikatorjev ogroženosti (Indicators of Compromise) ni in rudar ni specifičen znak teh ranljivosti. Visoka obremenitev zaradi neznanih procesov pa sodi med splošne znake, opisane pod Ali smo že ogroženi?.
Pravilna razlaga znakov kriptorudarja
Visoka obremenitev ima veliko neškodljivih vzrokov. Tabela pomaga pri prvi razvrstitvi:
| Opazovanje | Možna neškodljiva razlaga | Kaj preverite |
|---|---|---|
| CPU stalno blizu polne zasedenosti | varnostna kopija, obdelava slik, gradnja indeksa | Ali obremenitev enakomerno traja tudi ponoči in ob koncu tedna? |
| Proces z imenom, podobnim sistemski storitvi | redko | Ali je programska datoteka na pričakovani sistemski poti? |
Proces pod www-data, apache ali nginx, ki ni PHP |
komaj | Kdo ga je zagnal, iz katerega imenika? |
Program v /tmp, /var/tmp ali /dev/shm |
komaj | Od kdaj datoteka obstaja, komu pripada? |
| Trajna odhodna povezava z neznanim ciljem | nadzor, posodobitve | Ali cilj sodi k znani storitvi? |
| Obremenitev pade, takoj ko se prijavite | redko | Nekateri škodljivi programi se ustavijo, ko tečejo nadzorna orodja |
Čim več vrstic velja, tem verjetnejša je najdba. Da uporabnik spletnega strežnika sploh zaganja tuje programe, je že samo po sebi močan opozorilni znak, kot kaže prispevek Spletni strežnik zažene lupino.
Kako preverite procese in povezave
Naslednji ukazi samo berejo. Rezultat in čas zabeležite, preden karkoli spremenite:
# Procesi po porabi CPU, z uporabnikom, časom zagona in polnim ukazom
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Programska datoteka in delovni imenik sumljivega procesa (vstavite PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Odhodne povezave s procesom
sudo ss -tnp state established
# Izvršljive datoteke v začasnih imenikih
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Če /proc/PID/exe kaže na datoteko z dodatkom (deleted), je bil program po zagonu izbrisan. To je tipičen poskus prikrivanja. Proces teče naprej in dokler teče, je programsko datoteko še mogoče zavarovati prek /proc. To naj prevzame nekdo, ki zna ravnati s škodljivo programsko opremo; datoteke nikoli ne izvajajte.
Kako procese preverite sistematično čez rudarja, opisuje Iskanje sumljivih procesov na strežnikih Linux.
Zakaj se rudar vedno vrne
Mnogi upravljavci proces končajo, se razveselijo padle obremenitve in naslednji dan ugotovijo, da se vse začne znova. Rudarji se skoraj vedno namestijo z mehanizmom ponovnega zagona. Tipična mesta so:
- Cronjobi uporabnika spletnega strežnika ali sistemski, ki vsakih nekaj minut preverjajo, ali rudar teče, in ga sicer naložijo znova.
- Sistemske storitve z neopaznimi imeni, ki se zaženejo ob zagonu.
- Webshell v spletnem imeniku, prek katere napadalec rudarja kadarkoli znova zažene.
- Spremenjeni zagonski skripti ali profilne datoteke uporabnikov.
- Tuji ključi SSH, s katerimi se napadalec neposredno znova prijavi.
# Cronjobi uporabnika spletnega strežnika in sistemski vnosi
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Nazadnje spremenjene enote systemd
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Šele ko so najdeni vsi mehanizmi, strežnik trajno ostane miren. Če je imel napadalec pravice root, je nova postavitev na svežem sistemu praviloma zanesljivejša od iskanja vsakega skrivališča.
Pravilen vrstni red po najdbi
Rudar deluje kot tehnična nadloga, a je varnostni incident. Zato ukrepajte urejeno:
- Zavarujte: Seznam procesov, povezave, sumljive datoteke in dnevnike kopirajte s kontrolno vsoto, preden se karkoli konča.
- Zajezite: Strežnik izolirajte ali odhodne povezave zaprite, če je to mogoče brez izgube podatkov.
- Zaprite vzrok: PHP spravite na odpravljeno stanje (8.5.12, 8.4.27, 8.3.36, 8.2.35 ali potrjen backport), znova zaženite vse workerje, posodobite CMS in razširitve.
- Očistite ali zgradite znova: Odstranite rudarja, mehanizme ponovnega zagona in stranska vrata, ob dvomu postavite znova.
- Preverite posledice: Ali so bila dostopna gesla ali osebni podatki lahko prebrani? Tedaj razjasnite varstvo podatkov in morebitne obveznosti prijave.
Zgodaj vključite svojega ponudnika gostovanja ali oblaka. Mnogi ponudniki strežnike z opazno obremenitvijo ali opaznim omrežnim prometom previdnostno zaprejo. Kdor ponudnika obvesti sam in uskladi postopek, laže obdrži nadzor nad časom izklopa. Vprašajte tudi po omrežnih zapisih in zapisih dostopov ponudnika, saj ležijo zunaj vašega strežnika in jih napadalec težko spremeni.
Za vodstvo je pomembna kratka, poštena razvrstitev: rudar sam stane predvsem računski čas in zmogljivost. Pravo vprašanje pa je, kaj je napadalec poleg tega videl. Dokler to ni razjasnjeno, incident ne sme veljati za rešenega, tudi če je obremenitev spet običajna.
Kriptorudar kaže, da je bila na vašem strežniku izvedena koda. Vsa dostopna gesla, ki so bila na strežniku, obravnavajte kot morda odtekla in jih po čiščenju obnovite.
Kako PHP SOS pomaga konkretno?
- Obremenitev razvrstimo in ločimo neškodljive vzroke od tujih procesov.
- Procese, datoteke in povezave zavarujemo, preden se rudar konča.
- Poiščemo vse mehanizme ponovnega zagona in stranska vrata ter strežnik očistimo v okviru odstranjevanja škodljive programske opreme ali ga postavimo znova.
- Zapremo vstopno točko, obnovimo dostope in vzpostavimo nadzor obremenitve, ki nenavadne vzorce javi zgodaj.
Pogosta vprašanja
Po čem prepoznam kriptorudarja na svojem strežniku?
Tipična je stalno visoka obremenitev CPU, ki ne ustreza številu obiskovalcev ali načrtovanim opravilom. Zraven pridejo procesi z neznanimi ali neškodljivo zvenečimi imeni, pogosto pod uporabnikom spletnega strežnika, in odhodne povezave do tujih naslovov. Posamezna značilnost še ni dokaz.
Ali zadošča, da proces rudarjenja končam?
Ne. Rudarje večinoma znova in znova zaganjajo cronjobi, sistemske storitve ali webshell. Kdor proces samo konča, ga pogosto čez kratek čas spet vidi. Poleg tega ostane odprta vstopna točka, prek katere je rudar prišel na strežnik.
Ali je kriptorudar neškodljiv, ker samo krade računsko moč?
Ne. Kdor je lahko namestil rudarja, je lahko na strežniku izvajal kodo. S tem so bile praviloma dosegljive tudi konfiguracijske datoteke, dostopna gesla in podatkovne baze. Rudar je vidni simptom vdora.
Katere neškodljive vzroke ima lahko visoka obremenitev strežnika?
Veliko računskega časa lahko porabijo tudi varnostne kopije, obdelava slik, gradnja iskalnega indeksa, agresivni iskalni roboti ali napačna razširitev. Te vzroke je večinoma mogoče pripisati znanemu procesu in urniku. Če obremenitev ostane brez razlage, preverite natančneje.