Det skal du ikke gøre

Modul 10: Forbliv sikker · Læsetid: 12 minutter

Læringsmål: Efter denne lektion genkender du de fejl, der oftest fører til en hacket eller ødelagt server, du kan forklare, hvorfor de er farlige, og du ved, hvad du gør i stedet.

Centrale begreber: root-login med adgangskode, svag adgangskode eller standardadgangskode, åben database, Docker-API på port 2375, docker.sock i en container, chmod 777, curl | bash, hemmeligheder i Git, administrationspanel uden totrinsbekræftelse, firewall "lige slået fra", ingen opdateringer, ingen backup

Hvorfor en lektion om fejl?

De fleste servere bliver ikke hacket af en genial angriber med et ukendt hul. De bliver hacket af bots, der gennemsøger hele internettet efter kendte fejl: en adgangskode, der kan gættes, en database, der står åben, et program, der har manglet en opdatering i flere måneder. Undgår du fejlene i denne lektion, falder du uden for de bots' rækkevidde. Det er størstedelen af den beskyttelse, du kan få.

Ved hver fejl står der, hvorfor den er farlig, og hvad du gør i stedet. Næsten alt har du lært i tidligere lektioner; denne lektion samler det.

1. Root-login med adgangskode

Problemet. Alle servere får loginforsøg på root hele dagen (lektion 5.3). Kan root logge ind med adgangskode, er den adgangskode det eneste, der står mellem en bot og fuld kontrol. Genbrugte eller for korte adgangskoder bliver før eller siden gættet eller står allerede på en lækket liste.

Gør dette. Log kun ind med nøgler: PasswordAuthentication no og KbdInteractiveAuthentication no, root højst med en nøgle (PermitRootLogin prohibit-password) eller slet ikke (no), og arbejd til daglig som almindelig bruger med sudo (lektion 2.2 og 3.2). Kontrollér udefra, hvilke loginmetoder din server tilbyder (opgave Z2.2).

2. En database, cache eller søgeklynge åben mod internettet

Problemet. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch eller OpenSearch (9200) og MongoDB (27017) er lavet til betroede programmer i et betroet netværk. Lytter de på 0.0.0.0 uden firewall, finder scannere dem hurtigt. Redis skriver i sin egen dokumentation, at den ikke bør eksponeres mod internettet, og at enhver med adgang kan slette hele datasættet; via kommandoen CONFIG kan en angriber endda skrive filer på serveren. Åbne databaser og søgeklynger har i årevis været en kendt årsag til store datalæk og til "løsesums"-beskeder i stedet for dine data.

Gør dette. Lad den slags tjenester lytte på 127.0.0.1 (lektion 5.1), hold dem bag firewallen (lektion 5.2), og publicér dem i Docker slet ikke eller kun på 127.0.0.1 (lektion 9.3). Skal du selv ind fra din laptop: brug en SSH-tunnel (lektion 2.3). Kontrollér udefra (opgave Z5.1).

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

Problemet. Den, der kan styre Docker-daemonen, er reelt root på serveren: Docker-dokumentationen siger, at kun betroede brugere må styre daemonen, og sidestiller adgang til daemonen med root-adgang. To varianter af denne fejl:

• Daemonen lytter på en TCP-port uden TLS (typisk 2375). Alle, der kan nå den port, kan starte containere med din servers disk monteret.
• En container får /var/run/docker.sock med som volume ("så kan den selv styre containere"). Bliver den container hacket, er hele serveren tabt.

Også gruppen docker svarer til root (lektion 9.2): sæt kun administratorer i den.

Gør dette. Lad kun Docker arbejde via den lokale socket. Fjernadministration foregår via SSH (docker context med ssh://), eller hvis det virkelig skal være via TCP, med TLS på port 2376 og klientcertifikater. Montér kun docker.sock i en container, du stoler fuldt på og virkelig har brug for, og helst skrivebeskyttet via en begrænsende proxy.

4. chmod 777 for at slippe af med en fejlmeddelelse

Problemet. "Permission denied" ved en upload, og et forum siger: chmod -R 777 /var/www. Derefter må alle brugere og alle processer på serveren skrive alt i dit website, også et hacket plugin eller en anden konto. Kode, som webserveren kan skrive i, kan via et hul blive udskiftet med en bagdør.

Gør dette. Find ud af, hvem der skal skrive, og hvor (lektion 3.1): som regel kun webserverbrugeren i én mappe til uploads eller cache. Kode ejes af en anden end webserveren, med rettighederne 644/755, uploads 750/640 eller lignende.

5. curl ... | bash og software alle vegne fra

Problemet. Et script, du kører som root uden at have set det, kan alt: tilføje kilder og nøgler, overskrive filer, åbne en tjeneste. Selv om hensigten er god, ved du bagefter ikke, hvad der er ændret, og ved næste release-opgradering går det i stykker (lektion 4.3).

Gør dette. Download og læs scriptet. Installér hellere fra din distributions pakkekilde eller producentens officielle kilde med en egen nøgle (Signed-By, lektion 4.1). Notér, hvad du installerer, og hvorfor.

6. Ingen opdateringer, eller opdateringer "senere"

Problemet. Huller bliver lukket og derefter udnyttet, ofte inden for få dage. En server, der ikke får opdateringer i flere måneder, eller som kører på en release uden support, har en liste over kendte åbninger. Containere bliver ikke opdateret af apt.

Gør dette. Slå automatiske sikkerhedsopdateringer til (lektion 4.2), hav et fast tidspunkt til genstart, skriv din releases slutdato i kalenderen (lektion 4.3), og opdatér containere jævnligt (lektion 9.4).

7. Ingen backup, eller en backup, der aldrig er testet

Problemet. Et snapshot på samme lager er ikke en backup (lektion 8.1). En backup, der ligger på selve serveren, forsvinder med ved et hack eller ransomware. Og en backup, der aldrig er blevet gendannet, er et håb, ikke en sikkerhed.

Gør dette. Krypterede backups uden for serveren (restic, lektion 8.2), overvågning af, at de kører, og mindst en gendannelsestest hvert kvartal.

8. Administrationspaneler åbne for alle, uden totrinsbekræftelse

Problemet. Et administrationspanel til en database (som phpMyAdmin), til Docker (som Portainer), til din applikation eller til din adgangskodeboks er et attraktivt mål: én adgangskode giver adgang til alt. Standardadgangskoder som admin/admin og registrering, der bliver stående åben (Vaultwarden, lektion 9.4), gør det endnu lettere.

Gør dette. Åbn ikke administrationspaneler mod internettet: nå dem via en SSH-tunnel eller kun fra en fast adresse. Skal et panel alligevel være offentligt: https, en stærk unik adgangskode fra din adgangskodemanager, totrinsbekræftelse og lukket registrering. Skift altid standardadgangskoder.

9. Hemmeligheder i Git eller i din compose-fil

Problemet. En adgangskode, API-nøgle eller privat nøgle i en fil, der havner i et Git-repository, ligger for altid i historikken, også selv om du fjerner den senere. Offentlige repositories gennemsøges af bots efter netop den slags nøgler.

Gør dette. Hemmeligheder i en separat fil med rettighederne 600 (EnvironmentFile, lektion 6.3; .env ved Docker Compose, lektion 9.3), som står i .gitignore. Er en hemmelighed alligevel lækket: udskift den med det samme (ny adgangskode, ny nøgle); det er ikke nok kun at rydde op i Git.

10. Firewallen "lige" slået fra, alt som root og ingen noter

Problemet. "Jeg slår lige firewallen fra for at teste" bliver glemt. "Jeg gør det lige som root" bliver en vane. Og en server, hvor ingen ved, hvad der kører på den og hvorfor, kan hverken administreres eller gendannes.

Gør dette. Test med en midlertidig, snæver regel (én port, én kildeadresse), og fjern den bagefter. Arbejd som almindelig bruger med sudo. Før en kort servermappe: hvad kører der, hvilke porte er åbne, hvor ligger backupperne, hvornår er releasens slutdato (lektion 10.4).

I praksis

Alle disse fejl kan begås på enhver VPS, hos WebOké lige så vel som hos andre udbydere: hvad der sker inde i din server, administrerer du selv. Udbyderen kan dog tage en server af netværket, hvis den sender spam eller udfører angreb, fordi det rammer andre kunder. Forebyggelse er altså også vigtig for din egen tilgængelighed.

Opsummering

• De fleste hacks udnytter kendte fejl, ikke ukendte huller.
• Log ind med nøgler, slå login med adgangskode fra; databaser, caches og Docker-API'et aldrig åbne mod internettet; ingen docker.sock i containere, du ikke stoler fuldt på.
• Ingen chmod 777 og ingen curl | bash: vid, hvem der må hvad, og hvad du installerer.
• Automatiske opdateringer, backups uden for serveren og testet, administrationspaneler bag en tunnel eller med totrinsbekræftelse.
• Hemmeligheder uden for Git og uden for compose-filer; lækket betyder udskiftet.

Quiz

Opgave

Opgave Z10.2: Hvilken fejl er det? I eksempelfilen casussen-z10-2.md står otte korte cases med servere, hvor noget er galt. Vælg for hver case, hvilken fejl det er fra listen i denne lektion (A til og med J), og hvad det bedste første skridt er. Programmet sammenligner med den faste nøgle og viser derefter forklaringen for hver case.

Læs mere

• Sikr din VPS: de første fem minutter
• Password manager og passkeys: sådan logger du sikkert ind
• Docker-dokumentationen, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker-dokumentationen, 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/