Et innbrudd ser sjelden ut som på film. Ingen skriver noe i terminalen, og det dukker ikke opp hodeskaller på skjermen. Det vanlige er kjedeligere: serveren blir treg, hostingleverandøren sender et brev om utgående søppelpost, eller nettstedet begynner å sende besøkende til en fremmed adresse.

Nedenfor følger sju kontroller i den rekkefølgen det er fornuftig å gjøre dem. Til sammen tar de omtrent ti minutter.

1. Hva spiser prosessoren

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

Det du leter etter, er en prosess med et meningsløst navn som ligger på nær hundre prosent prosessor. Kryptogravere er den vanligste følgen av et innbrudd, rett og slett fordi det er den raskeste måten å tjene penger på andres server.

To ting er verdt et nærmere blikk. Prosesser som kjører fra /tmp, /dev/shm eller /var/tmp — derfra startes ingenting normalt. Og navn som ligner på systemprosesser uten å stemme helt: kswapd0 med høy prosessorlast som kjører fra feil katalog, eller crond med stor C.

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

Den første kommandoen viser den virkelige stien til den kjørbare filen, den andre hvilken katalog prosessen arbeider i. Det holder som regel for å forstå hva det dreier seg om.

2. Utgående forbindelser

sudo ss -tupn
sudo ss -tupn state established

En vanlig webserver kobler seg sjelden utover: til pakkebehandlerens speil, til betalingsgatewayen, til e-postutsendingstjenesten. Stabile forbindelser til ukjente adresser på høye porter er enten en gravepool eller kontakt med en styringsserver.

Husk at denne kontrollen er svak alene: skadevare kobler seg ofte opp bare etter en tidsplan. At du ikke ser noe akkurat nå, betyr ikke at det ikke finnes noe.

3. Cron-jobber for alle brukere

Det er her man forankrer seg, slik at det du har ryddet vekk kommer tilbake.

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 skal vekke mistanke: linjer med @reboot, lange kodede kommandoer, kall på curl eller wget som sendes videre til et skall, alt som starter fra midlertidige kataloger.

4. SSH-nøkler og brukere

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 noens permanente tilgang som overlever både passordbytte og omstart. Kan du ikke si hvem nøkkelen tilhører, regner du den som fremmed — kommentaren på slutten av linjen er fri tekst og beviser ingenting.

Den andre kommandoen lister alle kontoer med uid 0. Der skal bare root stå.

5. Innloggingsloggene

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

Det viktige er de vellykkede innloggingene, ikke de mislykkede. Mislykkede forsøk er bakgrunnsstøy som enhver server på internett har. En vellykket innlogging fra en ukjent adresse på et tidspunkt da ingen arbeidet, er et konkret svar.

På Debian 12 og Ubuntu 24.04 finnes filen /var/log/auth.log ofte ikke i det hele tatt — rsyslog installeres ikke lenger som standard. Les journalen i stedet:

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

6. Endrede systemfiler

På Debian og Ubuntu finnes det en ferdig referanse: hver pakke bærer med seg kontrollsummer for filene sine.

sudo apt install debsums
sudo debsums -c

Endrede konfigurasjonsfiler i /etc er normalt — dem har du endret selv. Endrede kjørbare filer i /usr/bin, /bin eller /usr/sbin er nettopp det du lette etter.

7. Uvanlige filer i webroten

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

Den andre kommandoen er viktigere enn den første. En PHP-fil i katalogen for opplastede filer har ingen legitim grunn til å være der, og det er det vanligste stedet for et webskall.

Hvis noe faktisk blir funnet

Den første impulsen er å slette funnet med en gang. Det er feil: sammen med filen forsvinner informasjonen om hvordan den kom dit, og uten svar på det spørsmålet gjentar alt seg i løpet av noen dager.

  1. Ta vare på en kopi av filen og endringstidspunktet.
  2. Let i webserverens logger etter hva som skjedde på samme tidspunkt — der ligger som regel inngangen.
  3. Gå gjennom alle sju punktene, ikke bare det der du fant noe. Bakdører legges nesten aldri igjen i ett eneste eksemplar.
  4. Først deretter rydder du opp og tetter selve sårbarheten.

Og en ærlig avgrensning: fikk angriperen root, kan ingen kontroll innenfra stoles helt på — verktøyene selv kan være byttet ut. Ved et dypt innbrudd er den eneste pålitelige veien en ny server og en gjennomgått gjenoppretting fra sikkerhetskopi.

Det som gjør kontrollen vanskelig

Den største vanskeligheten her er ikke kommandoene, men at en ukjent linje ikke ser mistenkelig ut når du ikke husker hvordan listen så ut forrige uke. På en server noen andre har satt opp, er det nesten umulig å skille eget fra fremmed.

Derfor er konklusjonen praktisk: ta et øyeblikksbilde av tilstanden mens serveren er i orden. Listen over prosesser, porter, cron-jobber og nøkler på en frisk maskin er referansen du senere sammenligner mot — og da blir timevis med leting til en sammenligning av to lister. Hvordan det ser ut samlet på én side, viser demonstrasjonen nedenfor.