Kort sagt: Misstänkta processer på Linux-servrar känner ni igen på få kännetecken: programfilen raderad eller i /tmp, /dev/shm eller en webbkatalog, namnet härmar en systemprocess, ovanlig användare, varaktiga nätverksanslutningar eller hög belastning utan skäl. Kontrollera med läsande kommandon om programfilen tillhör ett installerat paket, och säkra fynd innan ni avslutar något.
Vad ”misstänkt” betyder för en process
På en webbserver körs hundratals processer. De flesta hör till operativsystemet, webbservern, databasen eller PHP. En angripare som har kunnat köra kod via en sårbarhet som PHP2Shell försöker inte stå ut bland dem. Han väljer anonyma namn och lägger program där webbserveranvändaren får skriva.
För kontrollen hjälper det att känna till normaltillståndet. Den som vet vilka tjänster som ska köras på en server, under vilka användare och med vilken belastning, upptäcker avvikelser mycket snabbare. Saknas den kunskapen lönar det sig att använda processlistan från en likadan, icke misstänkt server som jämförelse.
Ett enskilt kännetecken är inget bevis. Avgörande är samspelet. En process med namnet på en kärntråd, som körs under www-data, startades från /dev/shm och håller en anslutning utomlands, är ett tydligt fall. Hur ni kontrollerar specialfallet med ett skal under webbservern beskrivs i Varningssignal: webbservern startar ett skal.
Första överblick med fem kommandon
Alla kommandon läser bara. Kör dem som root så att ni ser alla processer, och spara utskrifterna i en fil utanför webbkatalogen.
# 1. Alla processer med användare, förälder-PID, starttid, CPU och kommandorad
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processer vars programfil har raderats
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processer som körs från temporära kataloger eller webbkataloger
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processer med nätverksanslutningar
ss -tunap
# 5. Webbserveranvändarnas processer i överblick
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Användarnamn skiljer sig per distribution och panel; Plesk och andra paneler kör PHP ofta under respektive kunds användare. Anpassa listan till er miljö.
Läs utskrifterna med blick på starttiden. Processer som har körts sedan serverns senaste omstart hör oftast till systemet. Processer som startades mitt i natten eller dagarna efter den 17 oktober och inte passar till någon tjänst förtjänar uppmärksamhet. Jämför också antalet PHP-processer med vad er poolkonfiguration tillåter; klart fler processer under en webbserveranvändare är en fingervisning.
Misstänkta processer i Linux: typiska kännetecken
| Kännetecken | Varför det sticker ut | Möjlig ofarlig förklaring? |
|---|---|---|
| Programfil ”(deleted)” | Angripare raderar filer efter starten | ja, efter paketuppdateringar fram till omstart |
Startplats /tmp, /dev/shm, uppladdningsmapp |
där får alla eller webbservern skriva | sällan |
Namn inom hakparenteser som [kworker] |
härmar kärntrådar | nej, om en programfil ligger bakom |
| Varaktigt hög CPU-belastning utan anledning | typiskt för kryptominers | ja, vid batchjobb eller indexering |
| Föräldraprocess 1 och webbserveranvändare | lösgjord från webbservern, fortsätter på egen hand | sällan |
| Anslutning till okänt mål | styrning eller dataläckage | ja, vid uppdateringar och API:er |
Äkta kärntrådar har ingen programfil; ls -l /proc/PID/exe ger för dem ingen sökväg. Pekar en process med kärnnamn på en fil är den maskerad. Vid hög belastning utan synlig orsak hjälper inlägget Kryptominers på webbservern vidare.
Motkontroll: tillhör programfilen ett paket?
Nästan alla legitima program på en server kommer från pakethanteringen. En programfil som inte tillhör något paket är inte automatiskt illasinnad, men förtjänar en noggrann titt.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: vilket paket tillhör filen?
rpm -qf "$EXE" # RHEL-familjen
sha256sum /proc/$PID/exe # Kontrollsumma, fungerar även vid raderad fil
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # Miljövariabler
Är programfilen raderad läser sha256sum /proc/$PID/exe den ändå ur den körande processen. Den kontrollsumman hör hemma i dokumentationen. En kopia av filen bör bara skapas av någon som vet hur den förvaras säkert.
Kontrollens gränser på det körande systemet
Alla kommandon ovan litar på det system ni just kontrollerar. Vid ett vanligt intrång via webbplatsen med webbserveranvändarens rättigheter är det försvarbart. Har en angripare fått root-rättigheter kan han dölja processer och förfalska utskrifter. Då visar servern bara det angriparen tillåter.
Tecken på det är motsägelser: belastning utan synlig process, anslutningar som brandväggen ser men ss inte gör, eller förändrade systemprogram. I sådana fall hör kontrollen hemma på en säkrad avbild. Vid körande system tillkommer ofta en säkring av arbetsminnet, eftersom vissa skadeprogram bara finns där och knappast lämnar spår på hårddisken. Den säkringen måste ske före en omstart och kräver lämpliga verktyg och erfarenhet. Varför ni bör göra detta före en nyinstallation förklaras i Säkra bevis innan ni sätter upp på nytt.
Avsluta inte misstänkta processer som första steg. Ofta startar ett cronjobb eller en tjänst om dem, och med processen försvinner kommandorad, anslutningar och den raderade programfilen ur minnet.
Kontrollera autostart och nästa steg
En skadlig process som skulle vara borta efter en omstart vore värdelös för angripare. Därför hör till varje processfynd frågan vad som startar den. Vid sidan av cronjobb kommer framför allt systemd-tjänster i fråga, som en angripare med root-rättigheter kan skapa. Uppseendeväckande är tjänster med generiska namn vars programfil ligger i en ovanlig katalog, och unit-filer som har tillkommit efter den 17 oktober.
# Körande tjänster och nyligen ändrade 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
# Injiceras ett bibliotek i varje process? Filen finns normalt inte.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
En post i /etc/ld.so.preload är sällsynt på vanliga webbservrar och ett starkt tecken på manipulation med root-rättigheter. Hur ni kontrollerar schemalagda uppgifter fullständigt beskrivs i Känn igen dolda cronjobb som bakdörr.
Därefter följer nästa steg i den här ordningen:
- Säkra utskrifter och kontrollsummor med klockslag.
- Sök persistens: cronjobb, systemd-tjänster och timers, SSH-nycklar.
- Klargör ursprunget: loggar från och med den 20 oktober, nya filer i webbkatalogen.
- Isolera servern och planera sanering eller nyuppbyggnad.
En översikt över alla typiska tecken efter PHP2Shell ger Är jag redan komprometterad?.
Hur hjälper PHP SOS konkret?
- Bedöma processer: Vi granskar processlista, programfiler och anslutningar och placerar varje fynd.
- Säkra rättssäkert: Med IT-forensiken säkrar vi arbetsminne och lagringsmedier innan något ändras.
- Hitta persistens: Vi söker efter mekanismer som startar om skadliga processer.
- Avsluta: Vi sanerar eller bygger upp på nytt och dokumenterar incidenten till avslutet.
Vanliga frågor
Hur känner jag igen en misstänkt process i Linux?
Typiska kännetecken är en raderad programfil, en startplats i /tmp eller /dev/shm, ett namn som härmar en systemprocess, en ovanlig användare och varaktiga nätverksanslutningar. Enskilda kännetecken är fingervisningar, flera tillsammans en allvarlig misstanke.
Vad betyder ”(deleted)” vid /proc/PID/exe?
Processens programfil raderades efter starten. Det sker legitimt efter paketuppdateringar tills tjänsten startar om. Hos processer från temporära mappar eller under webbserveranvändaren är det ett typiskt maskeringsbeteende.
Kan jag lita på utskriften från ps?
Vid ett vanligt intrång oftast ja. Har en angripare däremot fått root-rättigheter kan han manipulera verktyg och utskrifter. Då är en kontroll utifrån, till exempel på en säkrad avbild, mer tillförlitlig.
Ska jag avsluta en misstänkt process med kill?
Inte som det första. Säkra först kommandorad, programfil, anslutningar och starttid. En avslutad process avslöjar ingenting längre, och ofta startar ett cronjobb eller en tjänst om den ändå.