Å skaffe seg tilgang er halve saken; den andre halvparten er å ikke miste den. Derfor sørger så godt som all automatisert skadevare først og fremst for å kunne starte igjen: etter en omstart, etter at filen er slettet, etter et passordbytte. Derav den typiske historien — «vi ryddet opp, og to dager senere var det tilbake».

Stedene man ordner det på, er ikke så mange, og alle lar seg kontrollere på noen minutter. Nedenfor følger hele runden i tur og orden.

1. SSH-nøkler

Den enkleste måten å komme tilbake på: en linje i authorized_keys overlever passordbytte, systemoppdatering og omstart.

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;

Hver linje er noens permanente tilgang. Kan du ikke si hvem sin, regner du den som fremmed. Legg også merke til kommentaren på slutten av linjen: den er fri tekst, og at den stemmer med navnet ditt, beviser ingenting.

2. Cron-jobber for alle brukere

Det holder ikke å se i sin egen crontab:

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.hourly/ /etc/cron.daily/
sudo cat /etc/crontab

Det du skal legge merke til: linjer med @reboot, lange kodede kommandoer, kall på curl eller wget som sendes videre til et skall, alt som starter fra /tmp, /dev/shm eller /var/tmp. Fra de katalogene starter ingenting normalt.

3. systemd-timere og tjenester

Den moderne motstykket til cron, og det kontrolleres merkbart sjeldnere:

systemctl list-timers --all
systemctl list-units --type=service --state=running
sudo ls -la /etc/systemd/system/ /run/systemd/system/

Særlig brukertjenester, som kjører uten root-rettigheter og ikke havner i den alminnelige listen:

systemctl --user list-units --type=service
sudo ls -la /home/*/.config/systemd/user/

Enda en detalj: påslått øktvarighet for en bruker (loginctl enable-linger) lar tjenestene deres kjøre uten en aktiv økt. Det kontrolleres med loginctl list-users.

4. Skallets oppstartsfiler

Kode lagt til på slutten av skallets oppstartsfil kjøres ved hver innlogging:

sudo tail -5 /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile
sudo ls -la /etc/profile.d/

Se nettopp på slutten av filen — det er der man legger til for at det ikke skal synes ved en rask gjennomlesing.

5. ld.so.preload

En fil som tvinger systemet til å laste inn et angitt bibliotek i hver prosess som startes. Under normale forhold oppstår den aldri:

ls -l /etc/ld.so.preload

At den finnes, er praktisk talt et entydig tegn på en alvorlig kompromittering, og et slikt bibliotek skjuler som regel både filer, prosesser og nettverksforbindelser. Ingenting du ser deretter på den maskinen, fortjener tillit.

6. Pakkebehandlerens hooks

En metode man sjelden tenker på: apt kan kjøre kommandoer før og etter hver pakkeoperasjon.

sudo ls -la /etc/apt/apt.conf.d/
sudo grep -r 'DPkg::Pre-Invoke\|DPkg::Post-Invoke\|APT::Update' /etc/apt/apt.conf.d/

En slik hook kjøres ved hver installasjon av oppdateringer — altså jevnlig og med root-rettigheter.

7. Dagens melding i Ubuntu

Katalogen /etc/update-motd.d/ inneholder kjørbare skript som startes ved hver SSH-innlogging og setter sammen velkomstteksten. Stedet er praktisk nettopp fordi det ser systemmessig ut:

sudo ls -la /etc/update-motd.d/

8. Utsatte at-jobber

sudo atq
sudo ls -la /var/spool/cron/atjobs/ 2>/dev/null

En gammel og sjelden brukt mekanisme, og derfor den som kontrolleres sjeldnest av alle.

Rekkefølgen hvis noe blir funnet

Den første impulsen er å slette funnet med en gang. Det er en feil: med det forsvinner informasjonen om hvordan det havnet der, og uten svar på det spørsmålet gjentar alt seg.

  1. Ta vare på en kopi av filen eller jobben og endringstidspunktet.
  2. Kontroller i webserverens logger og i auth.log hva som skjedde i samme minutt. Der ligger som regel inngangen.
  3. Gå gjennom alle åtte stedene på listen, 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.

Å vite hvordan det normale ser ut

Den store vanskeligheten med denne kontrollen er ikke kommandoene, men at en ukjent linje i jobblisten ikke ser mistenkelig ut hvis du ikke husker hvordan listen så ut tidligere. På en server satt opp av noen andre, eller satt opp for et år siden, er det nesten umulig å skille eget fra fremmed.

Derav den praktiske slutningen: ta et øyeblikksbilde av tilstanden «slik den er» i dag, mens serveren er i orden. Listen over cron-jobber, timere, nøkler og tjenester på en frisk maskin er referansen du senere sammenligner mot. Samlet inn og lagret med historikk gjør den letingen etter en bakdør om fra et arbeid på flere timer til en sammenligning av to lister. Hvordan det ser ut, viser demonstrasjonssidene nedenfor.