Når noe går galt

Modul 10: Hold deg sikker · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kjenner du igjen tegnene på en hacket server, tar du de første stegene uten å ødelegge bevis eller sikkerhetskopier, velger du mellom å rydde opp og å installere på nytt, og vet du når du må melde et brudd på personopplysningssikkerheten.

Nøkkelbegreper: hendelse, tegn, isolere, snapshot som bevis, logg over hendelsen, installere på nytt, bytte nøkler og passord, ren sikkerhetskopi, meldeplikt ved avvik (72 timer), Datatilsynet, beredskapsplan

Kjenne igjen en hendelse

Et innbrudd varsler sjelden om seg selv. Som regel ser du noe som er "rart". Tegn du bør ta på alvor:

• Høy belastning uten grunn: prosessoren står hele tiden på 100 %, for eksempel på grunn av en kryptominer. Bruk top eller htop for å se hvilken prosess det er, og under hvilken bruker.
• Ukjente prosesser eller tjenester: et program med et merkelig navn, ofte i /tmp, /dev/shm eller /var/tmp, eller en systemd-tjeneste eller timer som du ikke har laget selv.
• Utgående trafikk som ikke stemmer: leverandøren din melder at serveren sender spam eller angriper andre servere, eller nettverksgrafene i panelet viser topper.
• Nye brukere eller nøkler: en linje i ~/.ssh/authorized_keys som du ikke kjenner igjen, en bruker i /etc/passwd med UID 0, en ny linje i /etc/sudoers.d/.
• Endrede filer: ukjente PHP-filer på nettstedet ditt, en endret crontab.
• Logger som er borte eller tomme: angripere liker å slette sporene sine.

Noen kommandoer for å se deg raskt rundt:

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 viser hvem som logget inn og når, awk-linjen viser alle kontoer med UID 0 (det skal bare være root), og find-linjen finner units og cron-filer som er nyere enn en fil som ble laget under installasjonen.

Merk: på en server som virkelig er hacket, kan også disse kommandoene være forfalsket. De hjelper deg å mistenke noe, ikke å bevise at alt er rent.

De første stegene: ro, isoler, dokumenter

Det viktigste de første minuttene er å ikke kaste ting i panikk. Jobb i denne rekkefølgen.

1. Start en logg. Skriv ned på papir eller på den bærbare PC-en din (ikke på serveren) hva du ser, når, og hva du gjør. Det trenger du senere for å finne årsaken, for en melding, en anmeldelse eller forsikringen din. Det nederlandske NCSC anbefaler også dette.

2. Isoler serveren. Hindre at den gjør mer skade (spam, angrep, sender ut data) uten å slå den av:

• steng alt i brannmuren hos leverandøren din (hvis den finnes), unntatt SSH fra din egen adresse; eller
• gjør det samme på selve serveren, via konsollen;
• hvis det ikke går på annen måte: slå av serveren via panelet. Da mister du riktignok innholdet i minnet.

3. Ta et snapshot. Et snapshot i panelet lagrer tilstanden slik den er nå. Det er beviset ditt og kilden din når du senere skal finne ut hvordan angriperen kom inn, også om du installerer serveren på nytt etterpå.

4. Sikre sikkerhetskopiene dine. Kontroller at sikkerhetskopiene utenfor serveren fortsatt er intakte, og sørg for at den hackede serveren ikke lenger kommer til dem (for eksempel ved å trekke tilbake serverens tilgangsnøkkel til lagringen for sikkerhetskopier). Angripere prøver også å slette eller kryptere sikkerhetskopier.

Rydde opp eller installere på nytt?

Det fristende svaret er: fjern den mistenkelige filen, stopp kryptomineren, ferdig. Men du vet ikke hva en angriper ellers har gjort: en bakdør til, et endret program, en ekstra nøkkel, en timer som setter alt tilbake. En server der noen har hatt root, kan du ikke lenger stole på.

Rådet fra administratorer og også fra det nederlandske NCSC er derfor: installer berørte systemer på nytt og gjenopprett dataene dine fra en sikkerhetskopi som selv ikke er infisert. Konkret:

1. En ny installasjon (installer på nytt i panelet, eller en ny server).
2. Med en gang grunnmuren fra dette kurset: oppdateringer, vanlig bruker med sudo, SSH med nye nøkler, brannmur (modul 2 til og med 5).
3. Installer applikasjonene dine på nytt fra offisielle kilder, helst med compose-filene eller notatene dine (leksjon 10.4).
4. Gjenopprett data (database, opplastinger) fra en sikkerhetskopi fra før hendelsen. Ikke gjenopprett kode eller konfigurasjon i blinde: den kan inneholde bakdøren. Se også kritisk på gjenopprettede data; en angriper kan ha vært inne lenger enn du tror.
5. Tett hullet som angriperen kom inn gjennom. Ellers skjer det igjen. Snapshotet fra steg 3 hjelper deg å finne ut av det.

Bytt alt som kan ha lekket

Gå ut fra at alt som lå på serveren, er i hendene på angriperen:

• SSH-nøkler: fjern de offentlige nøklene som lå på serveren overalt, og lag nye nøkkelpar hvis det lå private nøkler på serveren.
• Passord til databaser, administrasjonspaneler og brukere av applikasjonen din.
• API-nøkler og tokens (e-post, betalinger, skylagring, lagring for sikkerhetskopier) fra .env-filer og konfigurasjon: trekk dem tilbake hos tjenesten og bytt dem ut.
• Sertifikater: den private nøkkelen til sertifikatet ditt lå på serveren. Få sertifikatet tilbakekalt og be om et nytt (med Let's Encrypt går det raskt, leksjon 7.3).

Melde: GDPR og andre

Lå det personopplysninger på serveren (kundedata, kontoer, e-postadresser), kan det være et brudd på personopplysningssikkerheten. GDPR (personvernforordningen, artikkel 33) sier at den behandlingsansvarlige skal melde bruddet til tilsynsmyndigheten uten ugrunnet opphold og om mulig innen 72 timer etter å ha fått kjennskap til det. I Norge er det Datatilsynet, og meldingen sendes via et digitalt skjema. Noen viktige punkter:

• du trenger ikke melde hvis bruddet sannsynligvis ikke medfører en risiko for de berørte; er du i tvil, melder du;
• har du ikke all informasjon ennå, meld likevel innen 72 timer og fyll ut senere;
• personene som har fått opplysningene sine lekket, informerer du hvis det er høy risiko for dem;
• alle brudd dokumenterer du i et eget register, også når du ikke trenger å melde.

Drifter du serveren for en kunde, er du som regel databehandler: da må du informere kunden (den behandlingsansvarlige) uten ugrunnet opphold, slik at kunden kan melde. Denne leksjonen er ikke juridisk rådgivning; sjekk nettstedet til Datatilsynet hvis du er i tvil.

Videre: meld misbruk som er gjort fra serveren din til leverandøren din (den har ofte allerede sett det), og ved et alvorlig angrep leverer du en anmeldelse til politiet. Er organisasjonen din omfattet av digitalsikkerhetsloven (som gjennomfører NIS1) eller av NIS2-reglene i EU, gjelder egne, kortere meldefrister.

Forberedelse: beredskapsplanen

En hendelse skjer alltid på et dårlig tidspunkt. Det du har ordnet på forhånd, sparer deg for timer:

• Vit hvordan du kommer til konsollen og snapshotknappen hos leverandøren din, og ha innloggingsdetaljene til panelet (med totrinnsverifisering) et sted utenfor serveren.
• Vit hvor sikkerhetskopiene ligger, hvordan du gjenoppretter dem, og at de fungerer (leksjon 8.2).
• Ha en liste over alle hemmeligheter som ligger på serveren, slik at du vet hva du må bytte.
• Ha en ringeliste: leverandøren din, hvem ellers som må vite noe om serveren (kunde, kollega), og kontaktinformasjonen for en avviksmelding.

I praksis

I VPS-skjermbildet hos WebOké finner du konsollen, snapshots, sikkerhetskopier og knappen for å installere på nytt; hos andre leverandører heter de omtrent det samme (console eller VNC, snapshot, rescue, reinstall). Dette kurset er selvhjelp: ingen følger med på serveren din, og ingen rydder opp etter en hendelse for deg. Nettopp derfor er en beredskapsplan som du kan gjennomføre selv, så viktig.

Oppsummering

• Tegn: uforklarlig belastning, ukjente prosesser, tjenester eller nøkler, merkelig utgående trafikk, endrede eller forsvunne filer og logger.
• Første steg: før logg, isoler serveren, ta et snapshot som bevis, sikre sikkerhetskopiene.
• En server der noen hadde root, rydder du ikke opp i, men installerer på nytt; data hentes tilbake fra en ren sikkerhetskopi, og hullet tettes.
• Bytt alle nøkler, passord, tokens og sertifikater som lå på serveren.
• Berørt personopplysninger? Et brudd melder du om mulig innen 72 timer til Datatilsynet, og du dokumenterer alle brudd.

Quiz

Oppgave

Oppgave O10.3: Beredskapsplanen din på én side. Skriv en beredskapsplan for din egen server på høyst én A4-side: hvordan kommer du inn i panelet, konsollen og snapshotene; hvor ligger sikkerhetskopiene og hvordan gjenoppretter du dem; hvilke hemmeligheter ligger på serveren; hvem må du informere (og må du melde ved et brudd på personopplysningssikkerheten); og hvilke fem første steg tar du ved mistanke om innbrudd. Oppbevar planen utenfor serveren.

Les mer

• Har du ikke lenger tilgang til VPS-en din? Dette gjør du nå
• Snapshots og backup av VPS-en din
• Koble til en egen ISO eller installer VPS-en din på nytt
• Det nederlandske NCSC, Gehackt, wat nu? (nederlandsk kilde): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Datatilsynet, melding om avvik: https://www.datatilsynet.no/
• VPS: fra første innlogging til sikker server 9.1: Utestengt: du kommer ikke lenger inn på serveren din
• VPS: fra første innlogging til sikker server 9.5: Hacket? De første stegene