Na kratko: Sumljive procese na strežnikih Linux prepoznate po nekaj značilnostih: programska datoteka je izbrisana ali v /tmp, /dev/shm ali spletnem imeniku, ime posnema sistemski proces, nenavaden uporabnik, trajne omrežne povezave ali visoka obremenitev brez razloga. Z ukazi za branje preverite, ali programska datoteka sodi k nameščenemu paketu, najdbe pa zavarujte, preden karkoli končate.
Kaj pri procesu pomeni „sumljivo“
Na spletnem strežniku teče na stotine procesov. Večina jih sodi k operacijskemu sistemu, spletnemu strežniku, podatkovni bazi ali PHP. Napadalec, ki je prek ranljivosti, kot je PHP2Shell, lahko izvedel kodo, se poskuša vmes ne izpostavljati. Izbere neopazna imena in programe odloži tam, kamor sme uporabnik spletnega strežnika pisati.
Pri preverjanju pomaga poznavanje običajnega stanja. Kdor ve, katere storitve naj na strežniku tečejo, pod katerimi uporabniki in s kakšno obremenitvijo, odstopanja opazi veliko hitreje. Če tega znanja ni, se splača za primerjavo uporabiti seznam procesov podobnega, nesumljivega strežnika.
Posamezna značilnost še ni dokaz. Odločilno je sovpadanje. Proces z imenom niti jedra, ki teče pod www-data, je bil zagnan iz /dev/shm in drži povezavo v tujino, je jasen primer. Kako preverite poseben primer lupine pod spletnim strežnikom, opisuje Opozorilni znak: spletni strežnik zažene lupino.
Prvi pregled s petimi ukazi
Vsi ukazi samo berejo. Izvedite jih kot root, da vidite vse procese, izpise pa shranite v datoteko zunaj spletnega imenika.
# 1. Vsi procesi z uporabnikom, nadrejenim PID, časom zagona, CPU in ukazno vrstico
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Procesi, katerih programska datoteka je bila izbrisana
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Procesi, ki tečejo iz začasnih ali spletnih imenikov
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Procesi z omrežnimi povezavami
ss -tunap
# 5. Pregled procesov uporabnikov spletnega strežnika
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Uporabniška imena se razlikujejo glede na distribucijo in nadzorno ploščo; Plesk in druge nadzorne plošče PHP pogosto izvajajo pod uporabnikom posamezne stranke. Seznam prilagodite svojemu okolju.
Izpise berite s pogledom na čas zagona. Procesi, ki tečejo od zadnjega ponovnega zagona strežnika, večinoma sodijo k sistemu. Pozornost si zaslužijo procesi, zagnani sredi noči ali v dneh po 17. oktobru, ki ne ustrezajo nobeni storitvi. Primerjajte tudi število procesov PHP s tem, kar dopušča konfiguracija poola; bistveno več procesov pod uporabnikom spletnega strežnika je namig.
Sumljivi procesi v Linuxu: tipične značilnosti
| Značilnost | Zakaj je opazna | Je možna neškodljiva razlaga? |
|---|---|---|
| Programska datoteka „(deleted)“ | Napadalci datoteke po zagonu izbrišejo | da, po posodobitvah paketov do ponovnega zagona |
Kraj zagona /tmp, /dev/shm, imenik za nalaganje |
tam sme pisati vsak ali spletni strežnik | redko |
Ime v oglatih oklepajih, kot je [kworker] |
posnema niti jedra | ne, če za njim stoji programska datoteka |
| Trajno visoka obremenitev CPU brez povoda | tipično za kriptorudarje | da, pri paketnih opravilih ali indeksiranju |
| Nadrejeni proces 1 in uporabnik spletnega strežnika | ločen od spletnega strežnika, teče samostojno naprej | redko |
| Povezava z neznanim ciljem | upravljanje ali odtekanje podatkov | da, pri posodobitvah in API-jih |
Prave niti jedra nimajo programske datoteke; ls -l /proc/PID/exe pri njih ne vrne poti. Če proces z imenom jedra kaže na datoteko, je prikrit. Pri visoki obremenitvi brez prepoznavnega razloga pomaga prispevek Kriptorudarji na spletnem strežniku.
Navzkrižno preverjanje: ali programska datoteka sodi k paketu?
Skoraj vsi legitimni programi na strežniku izvirajo iz upravljanja paketov. Programska datoteka, ki ne pripada nobenemu paketu, ni samodejno zlonamerna, a si zasluži natančen pogled.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: kateremu paketu pripada datoteka?
rpm -qf "$EXE" # družina RHEL
sha256sum /proc/$PID/exe # kontrolna vsota, deluje tudi pri izbrisani datoteki
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # spremenljivke okolja
Če je programska datoteka izbrisana, jo sha256sum /proc/$PID/exe vseeno prebere iz tekočega procesa. Ta kontrolna vsota sodi v dokumentacijo. Kopijo datoteke naj naredi le tisti, ki ve, kako jo varno hraniti.
Meje preverjanja na tekočem sistemu
Vsi zgornji ukazi zaupajo sistemu, ki ga ravno preverjate. Pri običajnem vdoru prek spletne strani s pravicami uporabnika spletnega strežnika je to sprejemljivo. Če je napadalec dobil pravice root, lahko procese skrije in izpise ponaredi. Tedaj strežnik pokaže samo to, kar napadalec dopusti.
Namigi na to so protislovja: obremenitev brez vidnega procesa, povezave, ki jih vidi požarni zid, ss pa ne, ali spremenjeni sistemski programi. V takih primerih preverjanje sodi na zavarovano sliko. Pri tekočih sistemih se pogosto doda zavarovanje delovnega pomnilnika, saj nekateri škodljivi programi obstajajo samo tam in na trdem disku komaj puščajo sledi. To zavarovanje mora biti pred ponovnim zagonom in zahteva primerna orodja in izkušnje. Zakaj naj ga naredite pred novo namestitvijo, pojasnjuje Zavarujte dokaze, preden začnete znova.
Sumljivih procesov ne končajte kot prvi korak. Pogosto jih cronjob ali storitev znova zažene, s procesom pa iz pomnilnika izginejo ukazna vrstica, povezave in izbrisana programska datoteka.
Preverite samodejne zagone in naslednji koraki
Škodljiv proces, ki bi po ponovnem zagonu izginil, bi bil za napadalce brez vrednosti. Zato k vsaki najdbi procesa sodi vprašanje, kaj ga zaganja. Poleg cronjobov pridejo v poštev predvsem storitve systemd, ki jih napadalec s pravicami root lahko ustvari. Opazne so storitve s splošnimi imeni, katerih programska datoteka leži v nenavadnem imeniku, in datoteke enot, nastale po 17. oktobru.
# Tekoče storitve in nedavno spremenjene datoteke enot
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
# Ali se knjižnica vnaša v vsak proces? Datoteka običajno ne obstaja.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Vnos v /etc/ld.so.preload je na običajnih spletnih strežnikih redek in močan znak manipulacije s pravicami root. Kako načrtovana opravila preverite v celoti, opisuje Prepoznavanje skritih cronjobov kot stranskih vrat.
Nato sledijo naslednji koraki v tem vrstnem redu:
- Izpise in kontrolne vsote shranite s časom.
- Poiščite obstojnost: cronjobi, storitve in časovniki systemd, ključi SSH.
- Razjasnite izvor: dnevniki od 20. oktobra, nove datoteke v spletnem imeniku.
- Strežnik izolirajte in načrtujte čiščenje ali novo postavitev.
Pregled vseh tipičnih znakov po PHP2Shell daje Ali smo že ogroženi?.
Kako PHP SOS pomaga konkretno?
- Ocena procesov: Preverimo seznam procesov, programske datoteke in povezave ter vsako najdbo razvrstimo.
- Dokazno zavarovanje: Z IT-forenziko zavarujemo delovni pomnilnik in nosilce podatkov, preden se karkoli spremeni.
- Iskanje obstojnosti: Iščemo mehanizme, ki škodljive procese znova zaženejo.
- Zaključek: Očistimo ali zgradimo znova in incident dokumentiramo do zaključka.
Pogosta vprašanja
Po čem prepoznam sumljiv proces v Linuxu?
Tipične značilnosti so izbrisana programska datoteka, kraj zagona v /tmp ali /dev/shm, ime, ki posnema sistemski proces, nenavaden uporabnik in trajne omrežne povezave. Posamezne značilnosti so namigi, več skupaj resen sum.
Kaj pomeni „(deleted)“ pri /proc/PID/exe?
Programska datoteka procesa je bila po zagonu izbrisana. To je legitimno po posodobitvah paketov, dokler se storitev ne zažene znova. Pri procesih iz začasnih imenikov ali pod uporabnikom spletnega strežnika je to tipično prikrivanje.
Ali se lahko zanesem na izpis ps?
Pri običajnem vdoru večinoma da. Če pa je napadalec dobil pravice root, lahko orodja in izpise ponaredi. Tedaj je zanesljivejše preverjanje od zunaj, na primer na zavarovani sliki.
Ali naj sumljivi proces končam s kill?
Ne najprej. Najprej zavarujte ukazno vrstico, programsko datoteko, povezave in čas zagona. Končan proces ne pove ničesar več, pogosto pa ga cronjob ali storitev tako ali tako znova zažene.