Det du ikke bør gjøre

Modul 10: Hold deg sikker · Lesetid: 12 minutter

Læringsmål: Etter denne leksjonen kjenner du igjen feilene som oftest fører til en hacket eller ødelagt server, du kan forklare hvorfor de er farlige, og du vet hva du gjør i stedet.

Nøkkelbegreper: root-innlogging med passord, svakt passord eller standardpassord, åpen database, Docker-API på port 2375, docker.sock i en container, chmod 777, curl | bash, hemmeligheter i Git, administrasjonspanel uten tofaktorautentisering, brannmuren «bare litt» av, ingen oppdateringer, ingen sikkerhetskopi

Hvorfor en leksjon om feil?

De fleste servere blir ikke hacket av en genial angriper med et ukjent sikkerhetshull. De blir hacket av boter som går gjennom hele internett på jakt etter kjente feil: et passord som kan gjettes, en database som står åpen, et program som har manglet en oppdatering i flere måneder. Unngår du feilene i denne leksjonen, faller du utenfor det disse botene leter etter. Det er den største delen av beskyttelsen du kan få.

For hver feil står det hvorfor den er farlig og hva du gjør i stedet. Nesten alt har du lært i tidligere leksjoner. Denne leksjonen samler det på ett sted.

1. Root-innlogging med passord

Problemet. Alle servere får innloggingsforsøk på root hele dagen (leksjon 5.3). Kan root logge inn med passord, er det passordet det eneste som står mellom en bot og full kontroll. Gjenbrukte eller for korte passord blir før eller senere gjettet, eller de står allerede i en lekket liste.

Gjør dette. Logg inn bare med nøkler: PasswordAuthentication no og KbdInteractiveAuthentication no, root høyst med nøkkel (PermitRootLogin prohibit-password) eller ikke i det hele tatt (no), og jobb til daglig som vanlig bruker med sudo (leksjon 2.2 og 3.2). Kontroller utenfra hvilke innloggingsmetoder serveren din tilbyr (oppgave Z2.2).

2. En database, cache eller søkeklynge åpen mot internett

Problemet. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch eller OpenSearch (9200) og MongoDB (27017) er laget for pålitelige programmer i et pålitelig nettverk. Lytter de på 0.0.0.0 uten brannmur, finner skannere dem raskt. Redis skriver i sin egen dokumentasjon at den ikke skal eksponeres mot internett, og at alle med tilgang kan slette hele datasettet. Med kommandoen CONFIG kan en angriper til og med skrive filer på serveren. Åpne databaser og søkeklynger har i mange år vært en kjent årsak til store datalekkasjer og til «løsepenge»-meldinger der dataene dine skulle vært.

Gjør dette. La slike tjenester lytte på 127.0.0.1 (leksjon 5.1), hold dem bak brannmuren (leksjon 5.2), og publiser dem ikke i Docker, eller bare på 127.0.0.1 (leksjon 9.3). Trenger du selv tilgang fra den bærbare PC-en: bruk en SSH-tunnel (leksjon 2.3). Kontroller utenfra (oppgave Z5.1).

3. Docker-API-et åpent eller docker.sock i en container

Problemet. Den som kan styre Docker-daemonen, er i praksis root på serveren: Docker-dokumentasjonen sier at bare pålitelige brukere skal få styre daemonen, og regner tilgang til daemonen som det samme som root-tilgang. To varianter av denne feilen:

• Daemonen lytter på en TCP-port uten TLS (vanligvis 2375). Alle som når den porten, kan starte containere med serverens disk montert inn.
• En container får /var/run/docker.sock som volum («så kan den administrere containere selv»). Blir den containeren hacket, er hele serveren tapt.

Også gruppen docker tilsvarer root (leksjon 9.2): legg bare administratorer inn i den.

Gjør dette. La Docker bare jobbe via den lokale socketen. Fjernadministrasjon går via SSH (docker context med ssh://), eller, hvis det virkelig må gå via TCP, med TLS på port 2376 og klientsertifikater. Monter docker.sock bare i en container du stoler fullt på og virkelig trenger, og helst skrivebeskyttet via en begrensende proxy.

4. chmod 777 for å bli kvitt en feilmelding

Problemet. «Permission denied» ved en opplasting, og et forum sier: chmod -R 777 /var/www. Etter det kan alle brukere og alle prosesser på serveren skrive hva som helst i nettstedet ditt, også en hacket plugin eller en annen konto. Kode som webserveren kan skrive til, kan via et sikkerhetshull byttes ut med en bakdør.

Gjør dette. Finn ut hvem som må skrive og hvor (leksjon 3.1): som regel bare webserverbrukeren, i én mappe for opplastinger eller cache. La koden eies av en annen bruker enn webserveren, med rettigheter 644/755, og opplastinger 750/640 eller tilsvarende.

5. curl ... | bash og programvare fra hvor som helst

Problemet. Et skript du kjører som root uten å ha lest det, kan gjøre alt: legge til kilder og nøkler, overskrive filer, åpne en tjeneste. Selv om hensikten er god, vet du etterpå ikke hva som er endret, og ved neste release-oppgradering går det i stykker (leksjon 4.3).

Gjør dette. Last ned og les skriptet. Installer heller fra pakkekilden til distribusjonen din eller den offisielle kilden fra utvikleren, med en egen nøkkel (Signed-By, leksjon 4.1). Noter hva du installerer og hvorfor.

6. Ingen oppdateringer, eller oppdateringer «senere»

Problemet. Sikkerhetshull blir tettet og deretter utnyttet, ofte i løpet av dager. En server som ikke får oppdateringer på flere måneder, eller som kjører en release uten støtte, har en liste med kjente åpninger. Containere blir ikke oppdatert av apt.

Gjør dette. Slå på automatiske sikkerhetsoppdateringer (leksjon 4.2), ha et fast tidspunkt for omstart, før sluttdatoen for releasen din inn i kalenderen (leksjon 4.3), og oppdater containere jevnlig (leksjon 9.4).

7. Ingen sikkerhetskopi, eller en sikkerhetskopi som aldri er testet

Problemet. Et øyeblikksbilde (snapshot) på samme lagring er ikke en sikkerhetskopi (leksjon 8.1). En sikkerhetskopi som ligger på selve serveren, forsvinner sammen med den ved et innbrudd eller løsepengevirus. Og en sikkerhetskopi som aldri er gjenopprettet, er et håp, ikke en garanti.

Gjør dette. Krypterte sikkerhetskopier utenfor serveren (restic, leksjon 8.2), overvåking av at de kjører, og minst én gjenopprettingstest hvert kvartal.

8. Administrasjonspaneler åpne for alle, uten tofaktorautentisering

Problemet. Et administrasjonspanel for en database (som phpMyAdmin), for Docker (som Portainer), for applikasjonen din eller for passordhvelvet ditt er et attraktivt mål: ett passord gir tilgang til alt. Standardpassord som admin/admin og registrering som blir stående åpen (Vaultwarden, leksjon 9.4), gjør det enda enklere.

Gjør dette. Ikke åpne administrasjonspaneler mot internett: nå dem via en SSH-tunnel eller bare fra en fast adresse. Må et panel likevel være offentlig: https, et sterkt og unikt passord fra passordbehandleren din, tofaktorautentisering, og stengt registrering. Endre alltid standardpassord.

9. Hemmeligheter i Git eller i compose-filen din

Problemet. Et passord, en API-nøkkel eller en privat nøkkel i en fil som havner i et Git-repository, ligger der for alltid i historikken, også om du fjerner den senere. Offentlige repositories blir gjennomsøkt av boter på jakt etter nettopp slike nøkler.

Gjør dette. Legg hemmeligheter i en egen fil med rettigheter 600 (EnvironmentFile, leksjon 6.3; .env med Docker Compose, leksjon 9.3) som står i .gitignore. Har en hemmelighet likevel lekket: bytt den ut med en gang (nytt passord, ny nøkkel). Å rydde opp i Git er ikke nok.

10. Brannmuren «bare litt» av, alt som root og ingen notater

Problemet. «Jeg slår av brannmuren et øyeblikk for å teste» blir glemt. «Jeg gjør det bare raskt som root» blir en vane. Og en server der ingen vet hva som kjører på den og hvorfor, er umulig å administrere eller gjenopprette.

Gjør dette. Test med en midlertidig, smal regel (én port, én kildeadresse) og fjern den etterpå. Jobb som vanlig bruker med sudo. Hold et kort serverdokument oppdatert: hva kjører, hvilke porter er åpne, hvor ligger sikkerhetskopiene, når er sluttdatoen for releasen (leksjon 10.4).

I praksis

Alle disse feilene kan gjøres på hvilken som helst VPS, hos WebOké like godt som hos andre leverandører: det som skjer inne på serveren din, administrerer du selv. Leverandøren kan likevel koble en server fra nettverket hvis den sender spam eller utfører angrep, fordi det rammer andre kunder. Å forebygge er derfor også viktig for din egen tilgjengelighet.

Oppsummering

• De fleste innbrudd utnytter kjente feil, ikke ukjente sikkerhetshull.
• Logg inn med nøkler og slå av passordinnlogging. Databaser, cacher og Docker-API-et skal aldri være åpne mot internett. Ingen docker.sock i containere du ikke stoler fullt på.
• Ingen chmod 777 og ingen curl | bash: vit hvem som har lov til hva, og hva du installerer.
• Automatiske oppdateringer, sikkerhetskopier utenfor serveren som er testet, administrasjonspaneler bak en tunnel eller med tofaktorautentisering.
• Hemmeligheter utenfor Git og utenfor compose-filer. Det som har lekket, skal byttes ut.

Quiz

Oppgave

Oppgave Z10.2: Hvilken feil er det? I eksempelfilen casussen-z10-2.md står det åtte korte caser om servere der noe er galt. Velg for hver case hvilken feil det er fra listen i denne leksjonen (A til og med J) og hva som er det beste første steget. Programmet sammenligner med den faste fasiten og viser deretter forklaringen for hver case.

Les mer

• Sikre VPS-en din: de første fem minuttene
• Passordbehandler og passkeys: slik sikrer du innloggingen din
• Docker-dokumentasjonen, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker-dokumentasjonen, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
• Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/