Kort sagt: Mistænkelige processer på Linux-servere genkender I på få kendetegn: programfil slettet eller i /tmp, /dev/shm eller en webmappe, navn efterligner en systemproces, usædvanlig bruger, vedvarende netværksforbindelser eller høj belastning uden grund. Kontrollér med læsende kommandoer, om programfilen hører til en installeret pakke, og sikr fund, før I afslutter noget.
Hvad „mistænkelig“ betyder for en proces
På en webserver kører der hundreder af processer. De fleste hører til operativsystemet, webserveren, databasen eller PHP. En angriber, der kunne udføre kode via en sårbarhed som PHP2Shell, forsøger ikke at skille sig ud iblandt dem. Han vælger upåfaldende navne og lægger programmer dér, hvor webserverbrugeren må skrive.
Til kontrollen hjælper det at kende normaltilstanden. Den, der ved, hvilke tjenester der skal køre på en server, under hvilke brugere og med hvilken belastning, genkender afvigelser meget hurtigere. Mangler denne viden, er det umagen værd at bruge procesliste fra en tilsvarende, uskyldig server til sammenligning.
Et enkelt kendetegn er endnu intet bevis. Afgørende er samspillet. En proces med navnet på en kernel-tråd, der kører under www-data, blev startet fra /dev/shm og holder en forbindelse til udlandet, er et klart tilfælde. Hvordan I kontrollerer særtilfældet med en shell under webserveren, beskriver Advarselstegn: Webserveren starter en shell.
Første overblik i fem kommandoer
Alle kommandoer læser kun. Kør dem som root, så I ser alle processer, og gem output i en fil uden for webmappen.
# 1. Alle processer med bruger, forælder-PID, starttidspunkt, CPU og kommandolinje
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processer, hvis programfil er slettet
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processer, der kører fra midlertidige mapper eller webmapper
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processer med netværksforbindelser
ss -tunap
# 5. Webserverbrugernes processer i overblik
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Brugernavne afviger efter distribution og panel; Plesk og andre paneler kører ofte PHP under den pågældende kundes bruger. Tilpas listen til jeres miljø.
Læs output med blik for starttidspunktet. Processer, der har kørt siden serverens seneste genstart, hører som regel til systemet. Processer, der blev startet midt om natten eller i dagene efter den 17. oktober og ikke passer til nogen tjeneste, fortjener opmærksomhed. Sammenlign også antallet af PHP-processer med det, jeres pool-konfiguration tillader; tydeligt flere processer under en webserverbruger er et fingerpeg.
Mistænkelige processer under Linux: typiske kendetegn
| Kendetegn | Hvorfor det falder i øjnene | Harmløs forklaring mulig? |
|---|---|---|
| Programfil „(deleted)“ | Angribere sletter filer efter starten | ja, efter pakkeopdateringer indtil genstarten |
Startsted /tmp, /dev/shm, upload-mappe |
dér må enhver eller webserveren skrive | sjældent |
Navn i kantede parenteser som [kworker] |
efterligner kernel-tråde | nej, hvis en programfil står bag |
| Vedvarende høj CPU-belastning uden anledning | typisk for kryptominere | ja, ved batchjobs eller indeksering |
| Forælderproces 1 og webserverbruger | løsrevet fra webserveren, kører selvstændigt videre | sjældent |
| Forbindelse til ukendt mål | styring eller dataudsivning | ja, ved opdateringer og API'er |
Ægte kernel-tråde har ingen programfil; ls -l /proc/PID/exe giver ved dem ingen sti. Peger en proces med kernel-navn på en fil, er den camoufleret. Ved høj belastning uden synlig grund hjælper indlægget Kryptominer på webserveren videre.
Modprøve: Hører programfilen til en pakke?
Næsten alle legitime programmer på en server stammer fra pakkehåndteringen. En programfil, der ikke tilhører nogen pakke, er ikke automatisk ondsindet, men fortjener et nøjere kig.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: hvilken pakke hører filen til?
rpm -qf "$EXE" # RHEL-familien
sha256sum /proc/$PID/exe # kontrolsum, virker også ved slettet fil
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # miljøvariabler
Er programfilen slettet, læser sha256sum /proc/$PID/exe den alligevel ud fra den kørende proces. Denne kontrolsum hører med i dokumentationen. En kopi af filen bør kun oprettes af en, der ved, hvordan den opbevares sikkert.
Grænser for kontrollen på det kørende system
Alle kommandoerne ovenfor stoler på det system, I lige kontrollerer. Ved et almindeligt indbrud via websitet med webserverbrugerens rettigheder er det forsvarligt. Har en angriber fået root-rettigheder, kan han skjule processer og forfalske output. Så viser serveren kun det, angriberen tillader.
Fingerpeg herom er modsigelser: belastning uden synlig proces, forbindelser, som firewallen ser, men ss ikke, eller ændrede systemprogrammer. I sådanne tilfælde hører kontrollen hjemme på et sikret aftryk. Ved kørende systemer kommer der ofte en sikring af arbejdshukommelsen til, for nogle skadelige programmer findes kun dér og efterlader næsten ingen spor på harddisken. Denne sikring skal ske før en genstart og kræver passende værktøjer og erfaring. Hvorfor I bør oprette den før en nyinstallation, forklarer Sikr beviser, før I sætter op på ny.
Afslut ikke mistænkelige processer som første skridt. Ofte genstarter et cronjob eller en tjeneste dem, og med processen forsvinder kommandolinje, forbindelser og den slettede programfil fra hukommelsen.
Kontrollér autostarter og næste skridt
En skadelig proces, der ville forsvinde efter en genstart, ville være værdiløs for angribere. Derfor hører spørgsmålet om, hvad der starter den, med til ethvert procesfund. Ud over cronjobs kommer især systemd-tjenester i betragtning, som en angriber med root-rettigheder kan oprette. Påfaldende er tjenester med generiske navne, hvis programfil ligger i en usædvanlig mappe, og unit-filer, der er opstået efter den 17. oktober.
# Kørende tjenester og for nylig ændrede unit-filer
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
# Indsmugles et bibliotek i hver proces? Filen findes normalt ikke.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
En post i /etc/ld.so.preload er sjælden på normale webservere og et stærkt indicium på manipulation med root-rettigheder. Hvordan I kontrollerer planlagte opgaver fuldstændigt, beskriver Genkend skjulte cronjobs som bagdør.
Derefter følger de næste skridt i denne rækkefølge:
- Sikr output og kontrolsummer med klokkeslæt.
- Søg persistens: cronjobs, systemd-tjenester og timere, SSH-nøgler.
- Afklar oprindelsen: logs fra og med den 20. oktober, nye filer i webmappen.
- Isolér serveren, og planlæg oprydning eller nyopbygning.
Et overblik over alle typiske tegn efter PHP2Shell giver Er jeg allerede kompromitteret?.
Hvordan hjælper PHP SOS konkret?
- Vurdér processer: Vi kontrollerer procesliste, programfiler og forbindelser og vurderer hvert fund.
- Sikr retsgyldigt: Med it-forensik sikrer vi arbejdshukommelse og datamedier, før noget ændres.
- Find persistens: Vi søger efter mekanismer, der genstarter skadelige processer.
- Afslut: Vi renser op eller bygger op på ny og dokumenterer hændelsen frem til afslutningen.
Ofte stillede spørgsmål
Hvordan genkender jeg en mistænkelig proces under Linux?
Typiske kendetegn er en slettet programfil, et startsted i /tmp eller /dev/shm, et navn, der efterligner en systemproces, en usædvanlig bruger og vedvarende netværksforbindelser. Enkelte kendetegn er fingerpeg, flere sammen en alvorlig mistanke.
Hvad betyder „(deleted)“ ved /proc/PID/exe?
Processens programfil blev slettet efter starten. Det sker legitimt efter pakkeopdateringer, indtil tjenesten genstarter. Ved processer fra midlertidige mapper eller under webserverbrugeren er det en typisk camouflageadfærd.
Kan jeg stole på output fra ps?
Ved et almindeligt indbrud som regel ja. Har en angriber dog fået root-rettigheder, kan han manipulere værktøjer og output. Så er en kontrol udefra, f.eks. på et sikret aftryk, mere pålidelig.
Skal jeg afslutte en mistænkelig proces med kill?
Ikke først. Sikr først kommandolinje, programfil, forbindelser og starttidspunkt. En afsluttet proces afslører ikke mere, og ofte genstarter et cronjob eller en tjeneste den alligevel.