Et indbrud ligner sjældent det, man ser i film. Ingen skriver noget i terminalen, og der dukker ikke dødningehoveder op på skærmen. Det sædvanlige er kedeligere: serveren bliver langsom, hostingudbyderen sender et brev om udgående spam, eller hjemmesiden begynder at sende besøgende til en fremmed adresse.

Nedenfor følger syv kontroller i den rækkefølge, det giver mening at udføre dem. Tilsammen tager de omkring ti minutter.

1. Hvad æder processoren

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

Det, du leder efter, er en proces med et meningsløst navn, der ligger på næsten hundrede procent processor. Kryptominere er den hyppigste følge af et indbrud, ganske enkelt fordi det er den hurtigste måde at tjene penge på andres server.

To ting er værd at se nærmere på. Processer, der kører fra /tmp, /dev/shm eller /var/tmp — derfra startes intet normalt. Og navne, der ligner systemprocesser uden helt at passe: kswapd0 med høj processorbelastning kørende fra den forkerte mappe, eller crond med stort C.

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

Den første kommando viser den virkelige sti til den eksekverbare fil, den anden hvilken mappe processen arbejder i. Det er som regel nok til at forstå, hvad det drejer sig om.

2. Udgående forbindelser

sudo ss -tupn
sudo ss -tupn state established

En almindelig webserver forbinder sjældent udad: til pakkehåndteringens spejle, til betalingsgatewayen, til e-mailudsendelsestjenesten. Vedvarende forbindelser til ukendte adresser på høje porte er enten en mining-pool eller kontakt med en styringsserver.

Husk, at denne kontrol er svag alene: skadelig software forbinder ofte kun efter en tidsplan. At du ikke ser noget lige nu, betyder ikke, at der intet er.

3. Cron-job for alle brugere

Det er her, man forankrer sig, så det, du har ryddet væk, kommer tilbage.

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, der skal vække mistanke: linjer med @reboot, lange kodede kommandoer, kald af curl eller wget, der sendes videre til en skal, alt hvad der starter fra midlertidige mapper.

4. SSH-nøgler og brugere

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

Hver linje i authorized_keys er nogens permanente adgang, som overlever både adgangskodeskift og genstart. Kan du ikke sige, hvis nøglen er, betragter du den som fremmed — kommentaren i slutningen af linjen er fri tekst og beviser ingenting.

Den anden kommando viser alle konti med uid 0. Der skal kun stå root.

5. Loginlogfilerne

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

Det vigtige er de vellykkede logins, ikke de mislykkede. Mislykkede forsøg er baggrundsstøj, som enhver server på internettet har. Et vellykket login fra en ukendt adresse på et tidspunkt, hvor ingen arbejdede, er et konkret svar.

På Debian 12 og Ubuntu 24.04 findes filen /var/log/auth.log ofte slet ikke — rsyslog installeres ikke længere som standard. Læs journalen i stedet:

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

6. Ændrede systemfiler

På Debian og Ubuntu findes der en færdig reference: hver pakke bærer kontrolsummer for sine filer.

sudo apt install debsums
sudo debsums -c

Ændrede konfigurationsfiler i /etc er normalt — dem har du selv ændret. Ændrede eksekverbare filer i /usr/bin, /bin eller /usr/sbin er præcis det, du ledte efter.

7. Usædvanlige filer i webroden

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

Den anden kommando er vigtigere end den første. En PHP-fil i mappen med uploadede filer har ingen legitim grund til at være der, og det er det hyppigste sted for en webshell.

Hvis der rent faktisk findes noget

Den første impuls er at slette fundet med det samme. Det er forkert: sammen med filen forsvinder oplysningen om, hvordan den kom derhen, og uden svar på det spørgsmål gentager alt sig i løbet af nogle dage.

  1. Gem en kopi af filen og dens ændringstidspunkt.
  2. Led i webserverens logfiler efter, hvad der skete på samme tidspunkt — der ligger som regel indgangen.
  3. Gennemgå alle syv punkter, ikke kun det, hvor du fandt noget. Bagdøre efterlades næsten aldrig i ét enkelt eksemplar.
  4. Først derefter rydder du op og lukker selve sårbarheden.

Og en ærlig afgrænsning: fik angriberen root, kan ingen kontrol indefra stoles helt på — værktøjerne selv kan være skiftet ud. Ved et dybt indbrud er den eneste pålidelige vej en ny server og en gennemgået gendannelse fra sikkerhedskopi.

Det, der gør kontrollen svær

Den største vanskelighed her er ikke kommandoerne, men at en ukendt linje ikke ser mistænkelig ud, når man ikke husker, hvordan listen så ud i sidste uge. På en server, som en anden har sat op, er det næsten umuligt at skelne eget fra fremmed.

Derfor er konklusionen praktisk: tag et øjebliksbillede af tilstanden, mens serveren er i orden. Listen over processer, porte, cron-job og nøgler på en rask maskine er den reference, du senere sammenligner med — og så bliver timers ledearbejde til en sammenligning af to lister. Hvordan det ser ud samlet på én side, viser demonstrationen nedenfor.