När något går fel

Modul 10: Håll dig säker · Lästid: 11 minuter

Lärandemål: Efter den här lektionen känner du igen tecknen på en hackad server, tar du de första stegen utan att förstöra bevis eller säkerhetskopior, väljer du mellan att rensa och att installera om, och vet du när du måste anmäla en personuppgiftsincident.

Nyckelbegrepp: incident, varningstecken, isolera, ögonblicksbild som bevis, incidentlogg, installera om, byta nycklar och lösenord, ren säkerhetskopia, anmälningsplikt för personuppgiftsincidenter (72 timmar), Integritetsskyddsmyndigheten (IMY), nödplan

Känna igen en incident

Ett intrång gör sig sällan till känna. Oftast ser du något som är "konstigt". Tecken som du ska ta på allvar:

• Hög belastning utan anledning: processorn ligger hela tiden på 100 %, till exempel på grund av en kryptominer. Kontrollera med top eller htop vilken process det är och under vilken användare den körs.
• Okända processer eller tjänster: ett program med ett konstigt namn, ofta i /tmp, /dev/shm eller /var/tmp, eller en systemd-tjänst eller timer som du inte har skapat själv.
• Utgående trafik som inte stämmer: din leverantör meddelar att din server skickar spam eller angriper andra servrar, eller nätverksgraferna i panelen visar toppar.
• Nya användare eller nycklar: en rad i ~/.ssh/authorized_keys som du inte känner igen, en användare i /etc/passwd med UID 0, en ny rad i /etc/sudoers.d/.
• Ändrade filer: okända PHP-filer på din webbplats, en ändrad crontab.
• Loggar som har försvunnit eller är tomma: angripare suddar gärna ut sina spår.

Några kommandon för att snabbt se dig omkring:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last visar vem som loggade in och när, awk-raden visar alla konton med UID 0 (det ska bara vara root), och find-raden letar efter units och cron-filer som är nyare än en fil som skapades vid installationen.

Obs: på en server som verkligen är hackad kan även de här kommandona vara förfalskade. De hjälper dig att misstänka något, inte att bevisa att allt är rent.

De första stegen: lugn, isolera, dokumentera

Det viktigaste under de första minuterna är att inte ta bort saker i panik. Arbeta i den här ordningen.

1. Börja föra en logg. Skriv på papper eller på din laptop (inte på servern) vad du ser, när och vad du gör. Det behöver du senare för att hitta orsaken, för en anmälan, en polisanmälan eller ditt försäkringsbolag. Det nederländska NCSC rekommenderar också detta.

2. Isolera servern. Förhindra att den gör mer skada (spam, attacker, skickar iväg data) utan att stänga av den:

• stäng allt i din leverantörs brandvägg (om det finns en) utom SSH från din egen adress; eller
• gör samma sak på själva servern, via konsolen;
• om det inte går på annat sätt: stäng av servern via panelen. Då förlorar du visserligen innehållet i minnet.

3. Ta en ögonblicksbild. En ögonblicksbild (snapshot) i panelen sparar tillståndet som det är just nu. Det är ditt bevis och din källa för att senare ta reda på hur angriparen tog sig in, även om du installerar om servern efteråt.

4. Säkra dina säkerhetskopior. Kontrollera att dina säkerhetskopior utanför servern fortfarande är intakta, och se till att den hackade servern inte längre kommer åt dem (till exempel genom att återkalla serverns åtkomstnyckel till lagringen för säkerhetskopior). Angripare försöker också radera eller kryptera säkerhetskopior.

Rensa eller installera om?

Det lockande svaret är: ta bort den misstänkta filen, stoppa kryptominern, klart. Men du vet inte vad en angripare har gjort mer: en andra bakdörr, ett ändrat program, en extra nyckel, en timer som återställer alltihop. En server där någon har haft root kan du inte längre lita på.

Rådet från administratörer och även från det nederländska NCSC är därför: installera om drabbade system och återställ dina data från en säkerhetskopia som inte själv är infekterad. Konkret:

1. En ny installation (installera om i panelen, eller en ny server).
2. Direkt grunderna från den här kursen: uppdateringar, vanlig användare med sudo, SSH med nya nycklar, brandvägg (modul 2 till och med 5).
3. Installera om dina applikationer från officiella källor, helst med dina compose-filer eller anteckningar (lektion 10.4).
4. Återställ data (databas, uppladdningar) från en säkerhetskopia från före incidenten. Återställ inte kod eller konfiguration i blindo: den kan innehålla bakdörren. Granska även återställda data kritiskt; en angripare kan ha varit inne längre än du tror.
5. Täpp till hålet som angriparen tog sig in genom. Annars händer det igen. Ögonblicksbilden från steg 3 hjälper dig att ta reda på det.

Byt ut allt som kan ha läckt

Utgå från att allt som fanns på servern är i angriparens händer:

• SSH-nycklar: ta bort de publika nycklar som fanns på servern överallt, och skapa nya nyckelpar om det fanns privata nycklar på servern.
• Lösenord till databaser, administrationspaneler och användare i din applikation.
• API-nycklar och tokens (e-post, betalningar, molnlagring, lagring för säkerhetskopior) från .env-filer och konfiguration: återkalla dem hos tjänsten och ersätt dem.
• Certifikat: den privata nyckeln till ditt certifikat låg på servern. Låt återkalla certifikatet och begär ett nytt (med Let's Encrypt går det snabbt, lektion 7.3).

Anmäla: GDPR och andra

Fanns det personuppgifter på servern (kunduppgifter, konton, e-postadresser), då kan det vara en personuppgiftsincident. GDPR (dataskyddsförordningen, artikel 33) säger att den personuppgiftsansvarige ska anmäla en personuppgiftsincident till tillsynsmyndigheten utan onödigt dröjsmål och om möjligt inom 72 timmar efter att ha fått kännedom om den. I Sverige är det Integritetsskyddsmyndigheten (IMY), och anmälan görs via IMY:s e-tjänst. Några viktiga punkter:

• du behöver inte anmäla om incidenten sannolikt inte medför någon risk för de berörda; är du osäker, anmäl;
• har du ännu inte all information, anmäl ändå inom 72 timmar och komplettera senare;
• de personer vars uppgifter har läckt informerar du om det finns en hög risk för dem;
• varje personuppgiftsincident dokumenterar du i ett eget register, även om du inte behöver anmäla den.

Sköter du servern åt en kund är du oftast personuppgiftsbiträde: då måste du informera kunden (den personuppgiftsansvarige) utan onödigt dröjsmål, så att kunden kan anmäla. Den här lektionen är inte juridisk rådgivning; titta på IMY:s webbplats om du är osäker.

Dessutom: anmäl missbruk som har gjorts från din server till din leverantör (som ofta redan har sett det), och gör vid en allvarlig attack en polisanmälan till Polisen. Omfattas din organisation av cybersäkerhetslagen (2025:1506), det nationella genomförandet av NIS2, gäller särskilda, kortare tidsfrister för rapportering.

Förbered dig: nödplanen

En incident inträffar alltid vid ett dåligt tillfälle. Det du har ordnat i förväg sparar timmar:

• Vet hur du når din leverantörs konsol och knapp för ögonblicksbilder, och ha inloggningsuppgifterna till panelen (med tvåstegsverifiering) någonstans utanför servern.
• Vet var dina säkerhetskopior finns, hur du återställer dem och att de fungerar (lektion 8.2).
• Håll en lista över alla hemligheter som finns på servern, så att du vet vad du måste byta ut.
• Håll en ringlista: din leverantör, vem mer som behöver veta något om servern (kund, kollega), och kontaktuppgifterna för en anmälan av en personuppgiftsincident.

I praktiken

I VPS-vyn hos WebOké hittar du konsolen, ögonblicksbilder, säkerhetskopior och knappen för att installera om; hos andra leverantörer heter de ungefär likadant (console eller VNC, snapshot, rescue, reinstall). Den här kursen är självhjälp: ingen tittar på din server och ingen städar upp en incident åt dig. Just därför är en nödplan som du kan genomföra själv så viktig.

Sammanfattning

• Tecken: oförklarlig belastning, okända processer, tjänster eller nycklar, konstig utgående trafik, ändrade eller försvunna filer och loggar.
• Första stegen: för en logg, isolera servern, ta en ögonblicksbild som bevis, säkra säkerhetskopiorna.
• En server där någon har haft root rensar du inte, utan installerar om; data tillbaka från en ren säkerhetskopia, och täpp till hålet.
• Byt ut alla nycklar, lösenord, tokens och certifikat som fanns på servern.
• Berörs personuppgifter? En personuppgiftsincident anmäler du om möjligt inom 72 timmar till IMY, och du dokumenterar varje incident.

Quiz

Uppgift

Uppgift O10.3: Din nödplan på en sida. Skriv en nödplan för din egen server på högst en A4-sida: hur kommer du in i panelen, konsolen och ögonblicksbilderna; var finns dina säkerhetskopior och hur återställer du dem; vilka hemligheter finns på servern; vem måste du informera (och måste du anmäla vid en personuppgiftsincident); och vilka fem första steg tar du om du misstänker ett intrång. Förvara planen utanför servern.

Läs mer

• Ingen åtkomst till din VPS längre: vad gör du nu?
• Snapshots och backuper av din VPS
• Montera en egen ISO eller installera om din VPS
• Det nederländska NCSC, Gehackt, wat nu? (nederländsk källa, på nederländska): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Integritetsskyddsmyndigheten (IMY), anmälan av personuppgiftsincident: https://www.imy.se/