Ett intrång ser sällan ut som i filmerna. Ingen skriver något i terminalen och inga skallar dyker upp på skärmen. Det vanliga är tråkigare: servern blir långsam, hostingleverantören skickar ett brev om utgående skräppost, eller så börjar sajten skicka besökare till en främmande adress.

Nedan följer sju kontroller i den ordning som är vettig att göra dem. Alla tar tillsammans omkring tio minuter.

1. Vad äter processorn

top -c
ps aux --sort=-%cpu | head -20

Det du letar efter är en process med ett meningslöst namn som ligger på nära hundra procent processor. Kryptogrävare är den vanligaste följden av ett intrång, helt enkelt för att det är det snabbaste sättet att tjäna pengar på någon annans server.

Två saker är värda att titta närmare på. Processer som körs från /tmp, /dev/shm eller /var/tmp — därifrån startas ingenting normalt. Och namn som liknar systemprocesser men inte riktigt stämmer: kswapd0 med hög processorlast som körs från fel katalog, eller crond med stort C.

sudo ls -l /proc/<pid>/exe
sudo ls -l /proc/<pid>/cwd

Det första kommandot visar den riktiga sökvägen till den körbara filen, det andra vilken katalog processen arbetar i. Det räcker oftast för att förstå vad det handlar om.

2. Utgående anslutningar

sudo ss -tupn
sudo ss -tupn state established

En vanlig webbserver ansluter utåt sällan: till pakethanterarens speglar, till betalningsgatewayen, till e-postutskickstjänsten. Stadiga anslutningar till okända adresser på höga portar är antingen en gruvpool eller kontakt med en styrserver.

Kom ihåg att den här kontrollen är svag på egen hand: skadlig kod ansluter ofta bara enligt schema. Om du inte ser något just nu betyder det inte att inget finns.

3. Cron-jobb för alla användare

Det är här man förankrar sig så att det man rensat bort kommer tillbaka.

for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; sudo crontab -u "$u" -l 2>/dev/null; done
sudo ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
sudo cat /etc/crontab

Det som ska väcka misstanke: rader med @reboot, långa kodade kommandon, anrop av curl eller wget som skickas vidare till ett skal, allt som startar från tillfälliga kataloger.

4. SSH-nycklar och användare

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo lastlog | head -20

Varje rad i authorized_keys är någons permanenta åtkomst som överlever både lösenordsbyte och omstart. Kan du inte säga vems nyckeln är, betrakta den som främmande — kommentaren i slutet av raden är fri text och bevisar ingenting.

Det andra kommandot listar alla konton med uid 0. Där ska det bara finnas root.

5. Loggarna över inloggningar

sudo grep 'Accepted' /var/log/auth.log | tail -30
sudo last -20
who

Det viktiga är lyckade inloggningar, inte de misslyckade. Misslyckade försök är bakgrundsbrus som varenda server på internet har. En lyckad inloggning från en okänd adress vid en tidpunkt då ingen arbetade är ett konkret svar.

På Debian 12 och Ubuntu 24.04 finns filen /var/log/auth.log ofta inte alls — rsyslog installeras inte längre som standard. Läs journalen i stället:

sudo journalctl -u ssh --since '7 days ago' | grep Accepted

6. Ändrade systemfiler

På Debian och Ubuntu finns en färdig referens: varje paket bär med sig kontrollsummor för sina filer.

sudo apt install debsums
sudo debsums -c

Ändrade konfigurationsfiler i /etc är normalt — dem har du ändrat själv. Ändrade körbara filer i /usr/bin, /bin eller /usr/sbin är precis det du letade efter.

7. Ovanliga filer i webbroten

sudo find /var/www -name '*.php' -mtime -7 -ls
sudo find /var/www/uploads -name '*.php'

Det andra kommandot är viktigare än det första. En PHP-fil i katalogen för uppladdade filer har inget legitimt skäl att finnas där, och det är den vanligaste platsen för ett webbskal.

Om något faktiskt hittas

Den första impulsen är att radera fyndet direkt. Det är fel: tillsammans med filen försvinner informationen om hur den kom dit, och utan svar på den frågan upprepas allt inom några dagar.

  1. Spara en kopia av filen och dess ändringstid.
  2. Leta i webbserverns loggar efter vad som hände vid samma tidpunkt — där finns oftast ingången.
  3. Gå igenom alla sju punkterna, inte bara den där du hittade något. Bakdörrar lämnas nästan aldrig i ett enda exemplar.
  4. Först därefter städa och täppa till själva sårbarheten.

Och en ärlig avgränsning: om angriparen fick root går ingen kontroll inifrån att lita på fullt ut — verktygen själva kan vara utbytta. Vid ett djupt intrång är den enda pålitliga vägen en ny server och en genomgången återställning från säkerhetskopia.

Det som gör kontrollen svår

Den största svårigheten här är inte kommandona utan att en okänd rad inte ser misstänkt ut när man inte minns hur listan såg ut i förra veckan. På en server som någon annan satt upp går det nästan inte att skilja eget från främmande.

Därför är slutsatsen praktisk: ta en ögonblicksbild av läget medan servern är i ordning. Listan över processer, portar, cron-jobb och nycklar på en frisk maskin är den referens du senare jämför mot — och då förvandlas timmar av letande till en jämförelse av två listor. Hur det ser ut samlat på en sida visar demonstrationen nedan.