At skaffe sig adgang er halvdelen af sagen; den anden halvdel er ikke at miste den. Derfor sørger så godt som al automatiseret skadesoftware først og fremmest for at kunne starte igen: efter en genstart, efter at filen er slettet, efter et adgangskodeskift. Deraf den typiske historie — »vi ryddede op, og to dage senere var det tilbage«.

Stederne, man ordner det på, er ikke så mange, og alle kan kontrolleres på nogle minutter. Nedenfor følger hele runden i rækkefølge.

1. SSH-nøgler

Den enkleste måde at komme tilbage på: en linje i authorized_keys overlever adgangskodeskift, systemopdatering og genstart.

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

Hver linje er nogens permanente adgang. Kan du ikke sige, hvis den er, betragter du den som fremmed. Læg også mærke til kommentaren i slutningen af linjen: den er fri tekst, og at den stemmer med dit navn, beviser ingenting.

2. Cron-job for alle brugere

Det rækker ikke at 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 lægge mærke til: linjer med @reboot, lange kodede kommandoer, kald af curl eller wget, der sendes videre til en skal, alt hvad der starter fra /tmp, /dev/shm eller /var/tmp. Fra de mapper starter intet normalt.

3. systemd-timere og tjenester

Den moderne modstykke til cron, og det kontrolleres mærkbart sjældnere:

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

Især brugertjenester, som kører uden root-rettigheder og ikke havner på den almindelige liste:

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

Endnu en detalje: slået til sessionsvarighed for en bruger (loginctl enable-linger) lader deres tjenester køre uden en aktiv session. Det kontrolleres med loginctl list-users.

4. Skallens opstartsfiler

Kode tilføjet i slutningen af skallens opstartsfil køres ved hvert login:

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

Se netop i slutningen af filen — det er der, man tilføjer, for at det ikke skal ses ved en hurtig gennemlæsning.

5. ld.so.preload

En fil, der tvinger systemet til at indlæse et angivet bibliotek i hver proces, der startes. Under normale forhold opstår den aldrig:

ls -l /etc/ld.so.preload

At den findes, er praktisk talt et entydigt tegn på en alvorlig kompromittering, og et sådant bibliotek skjuler som regel både filer, processer og netværksforbindelser. Intet, du ser derefter på den maskine, fortjener tillid.

6. Pakkehåndteringens hooks

En metode, man sjældent tænker på: apt kan køre kommandoer før og efter hver pakkeoperation.

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 sådan hook køres ved hver installation af opdateringer — altså jævnligt og med root-rettigheder.

7. Dagens meddelelse i Ubuntu

Mappen /etc/update-motd.d/ indeholder eksekverbare scripts, der startes ved hvert SSH-login og sætter velkomstteksten sammen. Stedet er praktisk netop, fordi det ser systemmæssigt ud:

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

8. Udskudte at-job

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

En gammel og sjældent brugt mekanisme, og derfor den, der kontrolleres sjældnest af alle.

Rækkefølgen hvis der findes noget

Den første impuls er at slette fundet med det samme. Det er en fejl: med det forsvinder oplysningen om, hvordan det havnede der, og uden svar på det spørgsmål gentager alt sig.

  1. Gem en kopi af filen eller jobbet og dets ændringstidspunkt.
  2. Kontrollér i webserverens logfiler og i auth.log, hvad der skete i samme minut. Der ligger som regel indgangen.
  3. Gennemgå alle otte steder på listen, 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.

At vide hvordan det normale ser ud

Den store vanskelighed ved denne kontrol er ikke kommandoerne, men at en ukendt linje på joblisten ikke ser mistænkelig ud, hvis du ikke husker, hvordan listen så ud tidligere. På en server sat op af en anden, eller sat op for et år siden, er det næsten umuligt at skelne eget fra fremmed.

Deraf den praktiske slutning: tag et øjebliksbillede af tilstanden »som den er« i dag, mens serveren er i orden. Listen over cron-job, timere, nøgler og tjenester på en rask maskine er den reference, du senere sammenligner med. Indsamlet og gemt med historik gør den ledearbejdet efter en bagdør om fra et arbejde på flere timer til en sammenligning af to lister. Hvordan det ser ud, viser demonstrationssiderne nedenfor.