Att skaffa sig åtkomst är halva saken; den andra halvan är att inte förlora den. Därför ser så gott som all automatiserad skadlig kod först och främst till att kunna starta igen: efter en omstart, efter att filen raderats, efter ett lösenordsbyte. Därav den typiska historien — ”vi städade, och två dagar senare var det tillbaka”.

Ställena där man ordnar det är inte så många, och alla går att kontrollera på några minuter. Nedan följer hela rundan i tur och ordning.

1. SSH-nycklar

Det enklaste sättet att komma tillbaka: en rad i authorized_keys överlever lösenordsbyte, systemuppdatering och omstart.

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

Varje rad är någons permanenta åtkomst. Kan du inte säga vems, betrakta den som främmande. Lägg också märke till kommentaren i radens slut: den är fri text, och att den stämmer med ditt namn bevisar ingenting.

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

Det räcker inte att titta 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 ska lägga märke till: rader med @reboot, långa kodade kommandon, anrop av curl eller wget som skickas vidare till ett skal, allt som startar från /tmp, /dev/shm eller /var/tmp. Från de katalogerna startar ingenting normalt.

3. systemd-timers och tjänster

Den moderna motsvarigheten till cron, och den kontrolleras märkbart mer sällan:

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

Särskilt användartjänster, som körs utan root-rättigheter och inte hamnar i den allmänna listan:

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

Ytterligare en detalj: påslagen sessionsvarighet för en användare (loginctl enable-linger) låter deras tjänster köra utan en aktiv session. Det kontrolleras med loginctl list-users.

4. Skalets startfiler

Kod som lagts till i slutet av skalets startfil körs vid varje inloggning:

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

Titta just i filens slut — det är där man lägger till för att det inte ska synas vid en snabb genomläsning.

5. ld.so.preload

En fil som tvingar systemet att läsa in ett angivet bibliotek i varje process som startas. Under normala förhållanden uppstår den aldrig:

ls -l /etc/ld.so.preload

Att den finns är praktiskt taget ett entydigt tecken på en allvarlig kompromettering, och ett sådant bibliotek döljer vanligen både filer, processer och nätverksanslutningar. Ingenting du ser därefter på den maskinen förtjänar tillit.

6. Pakethanterarens hooks

En metod man sällan tänker på: apt kan köra kommandon före och efter varje paketoperation.

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örs vid varje installation av uppdateringar — alltså regelbundet och med root-rättigheter.

7. Dagens meddelande i Ubuntu

Katalogen /etc/update-motd.d/ innehåller körbara skript som startas vid varje SSH-inloggning och sätter ihop hälsningstexten. Platsen är bekväm just för att den ser systemmässig ut:

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

8. Uppskjutna at-jobb

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

En gammal och sällan använd mekanism, och därför den som kontrolleras mest sällan av alla.

Ordningen om något hittas

Den första impulsen är att genast radera fyndet. Det är ett misstag: med det försvinner informationen om hur det hamnade där, och utan svar på den frågan upprepas allt.

  1. Spara en kopia av filen eller jobbet och dess ändringstid.
  2. Kontrollera i webbserverns loggar och i auth.log vad som hände under samma minut. Där finns vanligen ingången.
  3. Gå igenom alla åtta ställena på listan, inte bara det 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.

Att veta hur det normala ser ut

Den stora svårigheten med den här kontrollen är inte kommandona utan att en okänd rad i jobblistan inte ser misstänkt ut om man inte minns hur listan såg ut tidigare. På en server som satts upp av någon annan, eller som sattes upp för ett år sedan, går det nästan inte att skilja eget från främmande.

Därav den praktiska slutsatsen: ta en ögonblicksbild av läget ”som det är” i dag, medan servern är i ordning. Listan över cron-jobb, timers, nycklar och tjänster på en frisk maskin är den referens du senare jämför mot. Insamlad och sparad med historik förvandlar den letandet efter en bakdörr från ett arbete på flera timmar till en jämförelse av två listor. Hur det ser ut visar demonstrationssidorna nedan.