Ukratko: Kriptorudar na poslužitelju uglavnom se očituje trajno visokim opterećenjem CPU-a bez prepoznatljivog razloga, stranim procesima, često pod korisnikom web-poslužitelja, i odlaznim vezama prema nepoznatim odredištima. Proces ne prekidajte prenagljeno: najprije osigurajte tragove, potražite mehanizme koji ga ponovno pokreću i zatvorite ulazna vrata. Rudar znači da je netko mogao izvršavati kod na Vašem poslužitelju.
Kad je račun cloud pružatelja prvo upozorenje
Kriptorudar često ne upadne u oči zbog sigurnosnog alarma, nego usput. Web-stranica postaje troma, hoster javlja prekoračenje računalnog vremena, ventilator u vlastitom podatkovnom centru stalno radi ili obračun kod cloud pružatelja raste bez novih projekata. Za napadače je rudar jednostavan način da kompromitirani poslužitelj pretvore u novac.
Rudarenje znači koristiti računalnu snagu tuđeg sustava za stvaranje kriptovalute. Šteta se čini podnošljivom jer se podaci ne šifriraju. To vara: tko može pokrenuti rudara, može i čitati pristupne podatke, kopirati baze podataka i stvarati daljnja stražnja vrata.
Nakon PHP2Shella provjera se osobito isplati. Ranjivosti CVE-2026-109618 i CVE-2026-109619 omogućuju izvršavanje zlonamjernog koda bez prijave. Potvrđenih Indicators of Compromise nema, a rudar nije specifičan znak za te ranjivosti. Visoko opterećenje nepoznatim procesima ipak spada u opće znakove opisane u članku Jesam li već kompromitiran?.
Ispravno tumačiti znakove kriptorudara
Visoko opterećenje ima mnogo bezazlenih uzroka. Tablica pomaže pri prvom razvrstavanju:
| Opažanje | Moguće bezazleno objašnjenje | Što provjeriti |
|---|---|---|
| CPU trajno blizu punog opterećenja | sigurnosna kopija, obrada slika, izgradnja indeksa | Radi li opterećenje ujednačeno i noću i vikendom? |
| Proces s imenom poput sistemske usluge | rijetko | Nalazi li se programska datoteka na očekivanom sistemskom putu? |
Proces pod www-data, apache ili nginx koji nije PHP |
jedva | Tko ga je pokrenuo, iz kojeg direktorija? |
Program u /tmp, /var/tmp ili /dev/shm |
jedva | Otkad datoteka postoji, kome pripada? |
| Trajna odlazna veza prema nepoznatom odredištu | nadzor, ažuriranja | Pripada li odredište poznatoj usluzi? |
| Opterećenje pada čim se prijavite | rijetko | Neki zlonamjerni programi pauziraju kad rade alati za nadzor |
Što više redaka odgovara, to je nalaz vjerojatniji. Činjenica da korisnik web-poslužitelja uopće pokreće strane programe sama je po sebi jak znak upozorenja, kako pokazuje članak Web-poslužitelj pokreće ljusku.
Kako provjeriti procese i veze
Sljedeće naredbe samo čitaju. Rezultat i vrijeme zabilježite prije nego išta promijenite:
# Procesi prema potrošnji CPU-a, s korisnikom, vremenom pokretanja i punom naredbom
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Programska datoteka i radni direktorij sumnjivog procesa (umetnuti PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Odlazne veze s procesom
sudo ss -tnp state established
# Izvršne datoteke u privremenim direktorijima
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Ako /proc/PID/exe pokazuje na datoteku s dodatkom (deleted), program je izbrisan nakon pokretanja. To je tipičan pokušaj maskiranja. Proces radi dalje i dok radi, programska datoteka se još može osigurati preko /proc. To bi trebao preuzeti netko tko zna postupati sa zlonamjernim softverom; datoteku nikad ne izvršavajte.
Kako procese iznad rudara sustavno proći, opisuje članak Pronaći sumnjive procese na Linux poslužiteljima.
Zašto se rudar stalno vraća
Mnogi operateri prekinu proces, obraduju se padu opterećenja i sljedeći dan utvrde da sve počinje iznova. Rudari se gotovo uvijek instaliraju s mehanizmom ponovnog pokretanja. Tipična mjesta su:
- Cron poslovi korisnika web-poslužitelja ili na razini sustava, koji svakih nekoliko minuta provjeravaju radi li rudar i inače ga ponovno dohvaćaju.
- Sistemske usluge s neupadljivim imenima koje se pokreću pri podizanju sustava.
- Web shell u web-direktoriju preko kojeg napadač rudara može bilo kada ponovno pokrenuti.
- Izmijenjene startne skripte ili profilne datoteke korisnika.
- Strani SSH ključevi kojima se napadač izravno ponovno prijavljuje.
# Cron poslovi korisnika web-poslužitelja i unosi na razini sustava
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Nedavno izmijenjene systemd jedinice
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Tek kad su pronađeni svi mehanizmi, poslužitelj trajno ostaje miran. Ako je napadač imao root prava, ponovna izgradnja na svježem sustavu uglavnom je pouzdanija od traženja svakog skrovišta.
Pravi redoslijed nakon nalaza
Rudar djeluje kao tehnička neugodnost, ali je sigurnosni incident. Zato postupajte uredno:
- Osigurati: Popis procesa, veze, sumnjive datoteke i zapisnike kopirati s kontrolnim zbrojem prije nego se išta prekine.
- Ograničiti: Poslužitelj izolirati ili blokirati odlazne veze ako je to moguće bez gubitka podataka.
- Zatvoriti uzrok: PHP dovesti na ispravljeno stanje (8.5.12, 8.4.27, 8.3.36, 8.2.35 ili potvrđeni backport), ponovno pokrenuti sve workere, ažurirati CMS i proširenja.
- Očistiti ili ponovno izgraditi: Ukloniti rudara, mehanizme ponovnog pokretanja i stražnja vrata, u slučaju sumnje postaviti iznova.
- Provjeriti posljedice: Jesu li se mogli pročitati pristupni podaci ili osobni podaci? Tada razjasniti zaštitu podataka i po potrebi obveze prijave.
Rano uključite svog hostera ili cloud pružatelja. Mnogi pružatelji preventivno blokiraju poslužitelje s upadljivim opterećenjem ili mrežnim prometom. Tko sam obavijesti pružatelja i uskladi postupak, prije zadržava kontrolu nad trenutkom isključenja. Pritom pitajte i za mrežne zapisnike i zapisnike pristupa pružatelja, jer se nalaze izvan Vašeg poslužitelja i napadaču ih je teško mijenjati.
Za upravu je važno kratko, iskreno razvrstavanje: sam rudar troši prije svega računalno vrijeme i performanse. Stvarno pitanje glasi ipak što je napadač usto vidio. Dok se to ne razjasni, incident se ne bi smio smatrati zaključenim, čak i ako je opterećenje opet normalno.
Kriptorudar pokazuje da je na Vašem poslužitelju izvršen kod. Sve pristupne podatke koji su bili na poslužitelju smatrajte mogućim izvorom odljeva i obnovite ih nakon čišćenja.
Kako PHP SOS konkretno pomaže?
- Razvrstavamo opterećenje i razlikujemo bezazlene uzroke od stranih procesa.
- Osiguravamo procese, datoteke i veze prije nego se rudar prekine.
- Tražimo sve mehanizme ponovnog pokretanja i stražnja vrata te čistimo poslužitelj u okviru uklanjanja zlonamjernog softvera ili ga ponovno gradimo.
- Zatvaramo ulazna vrata, obnavljamo pristupe i postavljamo nadzor opterećenja koji rano javlja neobične obrasce.
Česta pitanja
Po čemu prepoznajem kriptorudar na svom poslužitelju?
Tipično je trajno visoko opterećenje CPU-a koje ne odgovara broju posjetitelja ni planiranim zadacima. Tome se pridružuju procesi s nepoznatim ili bezazleno zvučećim imenima, često pod korisnikom web-poslužitelja, i odlazne veze prema stranim adresama. Pojedino obilježje još nije dokaz.
Je li dovoljno prekinuti proces rudarenja?
Ne. Rudari se uglavnom iznova pokreću putem cron poslova, sistemskih usluga ili web shella. Tko samo prekine proces, često ga nakon kratkog vremena opet vidi. Uz to ostaju otvorena ulazna vrata kojima je rudar dospio na poslužitelj.
Je li kriptorudar bezazlen jer samo krade računalnu snagu?
Ne. Tko je mogao instalirati rudara, mogao je izvršavati kod na poslužitelju. Time su u pravilu bile dostupne i konfiguracijske datoteke, pristupni podaci i baze podataka. Rudar je vidljiv simptom provale.
Koji bezazleni uzroci mogu stajati iza visokog opterećenja poslužitelja?
Sigurnosne kopije, obrada slika, izgradnja indeksa pretraživanja, agresivni crawleri ili neispravno proširenje također mogu trošiti mnogo računalnog vremena. Ti se uzroci uglavnom mogu pridružiti poznatom procesu i rasporedu. Ako opterećenje ostane bez objašnjenja, treba pomnije provjeriti.