Når en server er kompromitteret, er det første instinkt at genstarte den eller slette det mistænkelige. Begge dele gør skaden større. De første minutter afgør, om I har et overblik bagefter, eller om I gætter.

Denne guide er til jer, der står med mistanken lige nu, og til jer, der vil være forberedt. Den første del er til ledelsen og ejeren. Den tekniske del til sidst er til IT-ansvarlige.

Minut 0: To ting I ikke må gøre

Genstart ikke serveren. Angriberens kørende processer, åbne forbindelser og indlæst kode findes i hukommelsen. En genstart sletter netop de spor, der viser, hvad der er sket. Samtidig overlever angriberens bagdør som regel genstarten, så maskinen kommer op igen stadig kompromitteret.

Slet ikke noget. Fjerner I en ondsindet fil, ved angriberen, at I har opdaget dem. I mister tidslinjen, og I finder sjældent det hele i første forsøg. Imens står den dør åben, de kom ind ad.

Gør i stedet tre ting: Sig det til nogen. Notér klokkeslættet. Og begynd at skrive ned, hvad I gør, og hvornår.

Rækkefølgen I skal følge

Har jeres virksomhed en beredskabsplan, så følg den. Har I ikke, er denne rækkefølge et forsvarligt sted at starte:

Isolér (minut 0-2). Afskær serveren fra netværket, men lad den køre.
Sikr beviser (minut 2-6). Gem det, der forsvinder, når maskinen stopper.
Vurdér (minut 6-10 og de næste timer). Hvad er ramt, og hvordan kom de ind?
Underret. Internt først, og derefter som loven kræver. Det kører parallelt med det tekniske.
Genopbyg (dage). Byg en ny server i stedet for at rense den gamle.
Lær (ugen efter). Luk indgangen og det hul, der gjorde, at I ikke så det.

Isolér, uden at slukke

Den bedste isolering sker uden for selve serveren: i firewallen, på switchen, hos hostingudbyderen eller i cloud-konsollen. Så kører maskinen videre, men den kan ikke nå noget. Kører serveren virtuelt eller i skyen, så tag et snapshot af disken med det samme. Det tager sekunder, ødelægger intet og er forskellen på en undersøgelse og et gæt.

Gå ud fra, at angriberen kan se, hvad I gør på maskinen. Og drøft ikke hændelsen i en mail- eller chatkonto, der kan være kompromitteret.

Sikr beviserne, før de forsvinder

Hukommelse, netværksforbindelser og kørende processer forsvinder, når maskinen stopper. Det skal gemmes først, i en fil, og kopieres væk fra serveren med det samme. En kompromitteret disk er ikke et sikkert sted at opbevare beviser. Skriv klokkeslættet for hver kommando ned. Den log bliver jeres hændelsesrapport.

Find ud af, hvordan de kom ind

Svarene findes typisk i loginlogs, webserverens adgangslog og filer, der er ændret for nylig. Klassiske tegn er et vellykket login fra en ukendt adresse eller på et underligt tidspunkt, mange fejlede logins efterfulgt af ét, der lykkes, en ny brugerkonto, eller en ekstra SSH-nøgle på en eksisterende bruger.

Husk dog: Alt, I tjekker på selve serveren, kører på en maskine, angriberen måske styrer. En angriber med fulde rettigheder kan rette i logfilerne og skjule sig for netop de kommandoer, I bruger. Resultaterne hjælper jer med at indkredse problemet, men de kan aldrig bevise, at maskinen er ren. Kun logs, der løbende sendes til et andet system, kan I stole på bagefter.

Derfor genopbygger man i stedet for at rense

Det er her, mange vil diskutere, og det er her, det ender med at koste dobbelt. I finder det, I er i stand til at finde. Bagdøre er billige at lægge flere steder, og "det ser rent ud nu" er ikke en sikkerhedsvurdering. Den eneste forsvarlige vej efter et angreb med fulde rettigheder er en ny server:

Byg den nye server fra et kendt, rent udgangspunkt, uden forbindelse til internettet.
Opdatér den fuldt og luk det hul, angriberen brugte.
Genskab data (ikke programmer og opsætning) fra en backup taget før angrebet, og kontrollér den. En backup kan også indeholde angriberens filer.
Giv alt nye adgangskoder og nøgler.
Tjek, at der ikke er ukendte brugere, åbne porte eller planlagte opgaver, I ikke kender.
Først derefter: tilbage på netværket, under skærpet overvågning.

Kan I ikke finde indgangen, så gå ud fra, at den stadig er der. Og gem den kompromitterede disk, indtil sagen er lukket.

Skift alle hemmeligheder, ikke kun de oplagte

Gå ud fra, at alt, der lå på serveren, nu er offentligt. Det gælder SSH-nøgler (også dem, serveren har adgang til andre steder), API-nøgler til cloud, overvågning og betalingsløsninger, databaseadgangskoder, brugeradgangskoder, TLS-certifikater (genudsted og tilbagekald de gamle) og alt, der ligger i konfigurationsfiler. De kommer igen med den nøgle, I glemte.

Hvem skal have besked, og hvornår?

Det tekniske er kun halvdelen. Den anden halvdel har frister, og uret starter, når I bliver opmærksomme på bruddet. "Vi var stadig ved at undersøge det" forlænger ikke fristen.

Internt

Ledelsen og den, der ejer den berørte løsning.
Jeres DPO eller den, der står for databeskyttelse, hvis der er persondata involveret.
Én person fører tidslinjen, én person træffer beslutningerne.

Eksternt

Datatilsynet (GDPR art. 33): Er der persondata involveret, skal bruddet anmeldes uden unødig forsinkelse og så vidt muligt senest 72 timer efter, at I fik kendskab til det. Fristen løber også i weekenden. Anmeldelse er ikke nødvendig, hvis bruddet sandsynligvis ikke indebærer en risiko for de berørte personer, men alle brud skal dokumenteres internt.
De berørte personer (GDPR art. 34): Skal underrettes uden unødig forsinkelse, hvis bruddet sandsynligvis indebærer en høj risiko for dem.
NIS2: Er jeres virksomhed omfattet af NIS2-loven, skal en væsentlig hændelse varsles senest 24 timer efter, at I fik kendskab til den, underrettes senest efter 72 timer, og der skal sendes en endelig rapport senest en måned efter underretningen.
Forsikring og kunder: Cyberforsikringer og kundekontrakter har ofte deres egne krav om underretning.

Artiklen er generel vejledning og ikke juridisk rådgivning.

Tjeklisten: Det, der gør næste gang til en dårlig dag i stedet for en dårlig måned

Hændelseshåndtering handler mest om det arbejde, der er gjort i forvejen. Kan I sætte flueben ved disse punkter?

Logs sendes løbende til et andet system.
Backup med flere måneders historik, og genskabelse er testet.
Vi har en oversigt over, hvad hver server kører, og hvad den bør lytte på.
Firewallen tillader kun det nødvendige.
SSH kræver nøgle, og root kan ikke logge direkte ind.
Adgangskoder og nøgler deles ikke mellem maskiner.
Mere end én person har adgang til hosting- eller cloud-konsollen.
Vi har en skriftlig plan for, hvem der beslutter, dokumenterer og underretter.
Vi kender de frister, der gælder for os.
Vi har prøvet at genopbygge en server mindst én gang.

Til IT-ansvarlige: kommandoerne

Eksemplerne er til Linux. Kør dem helst fra en konsol uden for maskinen, og send output væk fra serveren.

Sikr flygtige data

date -u > /tmp/ir.txt
ps auxwwf >> /tmp/ir.txt # processer som træ
ss -tunap >> /tmp/ir.txt # forbindelser med proces
who; w; last -n 20 >> /tmp/ir.txt # sessioner
lsof -nP +L1 >> /tmp/ir.txt # slettede filer, der stadig er åbne
ip a; ip route >> /tmp/ir.txt
scp /tmp/ir.txt bruger@andet-system:

Triage

lastb | head -20 # fejlede logins
find /etc /usr/local /opt -mtime -7 -ls # ændret seneste 7 dage
awk -F: '$3>=1000' /etc/passwd # brugerkonti
cat /etc/sudoers.d/* ~/.ssh/authorized_keys
crontab -l; ls /etc/cron.*; systemctl list-timers

Logs og pakkekontrol

journalctl -u ssh --since '7 days ago' | grep -i 'accepted\|failed'
grep -i accepted /var/log/auth.log # Debian/Ubuntu (RHEL: /var/log/secure)
debsums -c # Debian/Ubuntu: ændrede binære filer
rpm -Va | grep '^..5' # RHEL: checksum-afvigelser

Typiske gemmesteder for bagdøre: authorized_keys, cron, systemd-tjenester og timere, .bashrc og /etc/profile.d, web-shells i webroden, udskiftede programmer som ps, ls og sshd, LD_PRELOAD og kernemoduler. Huller i logfilerne er i sig selv et fund.

Få hjælp, før det sker

BestSecurity hjælper danske virksomheder med beredskabsplaner, backup der ligger adskilt fra jeres netværk, test af genskabelse og løbende overvågning. Ring på 82 82 82 95, så tager vi en snak om, hvor I står i dag.

Jeres server er hacket. Det gør I de første 10 minutter