Vad du inte ska göra

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

Lärandemål: Efter den här lektionen känner du igen de fel som oftast leder till en hackad eller trasig server, du kan förklara varför de är farliga och du vet vad du gör i stället.

Nyckelbegrepp: root-inloggning med lösenord, svagt lösenord eller standardlösenord, öppen databas, Docker-API på port 2375, docker.sock i en container, chmod 777, curl | bash, hemligheter i Git, adminpanel utan tvåstegsverifiering, brandväggen "tillfälligt av", inga uppdateringar, ingen säkerhetskopia

Varför en lektion om fel?

De flesta servrar hackas inte av en genial angripare med en okänd sårbarhet. De hackas av botar som går igenom hela internet på jakt efter kända fel: ett lösenord som går att gissa, en databas som står öppen, ett program som saknat en uppdatering i flera månader. Undviker du felen i den här lektionen blir du ointressant för de botarna. Det är den största delen av det skydd du kan få.

För varje fel står det varför det är farligt och vad du gör i stället. Nästan allt har du lärt dig i tidigare lektioner; den här lektionen sammanfattar det.

1. Root-inloggning med lösenord

Problemet. Varje server får inloggningsförsök på root hela dagen (lektion 5.3). Kan root logga in med lösenord är det lösenordet det enda som står mellan en bot och full kontroll. Återanvända eller för korta lösenord blir förr eller senare gissade, eller finns redan i en läckt lista.

Gör så här. Logga bara in med nycklar: PasswordAuthentication no och KbdInteractiveAuthentication no, root högst med nyckel (PermitRootLogin prohibit-password) eller inte alls (no), och arbeta till vardags som vanlig användare med sudo (lektion 2.2 och 3.2). Kontrollera utifrån vilka inloggningsmetoder din server erbjuder (uppgift Z2.2).

2. En databas, cache eller sökkluster öppen mot internet

Problemet. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch eller OpenSearch (9200) och MongoDB (27017) är gjorda för betrodda program i ett betrott nätverk. Lyssnar de på 0.0.0.0 utan brandvägg hittar skannrar dem snabbt. Redis skriver i sin egen dokumentation att tjänsten inte ska exponeras mot internet och att den som har åtkomst kan radera hela datamängden; med kommandot CONFIG kan en angripare till och med skriva filer på servern. Öppna databaser och sökkluster har i många år varit en känd orsak till stora dataläckor och till "lösensummemeddelanden" i stället för dina data.

Gör så här. Låt sådana tjänster lyssna på 127.0.0.1 (lektion 5.1), håll dem bakom brandväggen (lektion 5.2) och publicera dem i Docker inte alls eller bara på 127.0.0.1 (lektion 9.3). Behöver du själv komma åt dem från din laptop: använd en SSH-tunnel (lektion 2.3). Kontrollera utifrån (uppgift Z5.1).

3. Docker-API:t öppet eller docker.sock i en container

Problemet. Den som kan styra Docker-daemonen är i praktiken root på servern: Docker-dokumentationen säger att bara betrodda användare får styra daemonen och likställer åtkomst till daemonen med root-åtkomst. Två varianter av det här felet:

• Daemonen lyssnar på en TCP-port utan TLS (vanligt är 2375). Alla som når den porten kan starta containrar med serverns disk monterad.
• En container får /var/run/docker.sock som volym ("då kan den hantera containrar själv"). Blir den containern hackad är hela servern förlorad.

Även gruppen docker är likvärdig med root (lektion 9.2): lägg bara till administratörer i den.

Gör så här. Låt Docker bara arbeta via den lokala socketen. Fjärrhantering sker via SSH (docker context med ssh://), eller om det verkligen måste gå via TCP, med TLS på port 2376 och klientcertifikat. Montera docker.sock bara i en container som du litar helt på och verkligen behöver, och helst skrivskyddat via en begränsande proxy.

4. chmod 777 för att bli av med ett felmeddelande

Problemet. "Permission denied" vid en uppladdning, och ett forum säger: chmod -R 777 /var/www. Efter det får varje användare och varje process på servern skriva vad som helst i din webbplats, även ett hackat tillägg eller ett annat konto. Kod som webbservern kan skriva till kan via en sårbarhet bytas ut mot en bakdörr.

Gör så här. Ta reda på vem som behöver skriva och var (lektion 3.1): oftast bara webbserveranvändaren, i en enda mapp för uppladdningar eller cache. Koden ska ha en annan ägare än webbservern, med rättigheterna 644/755, uppladdningar 750/640 eller liknande.

5. curl ... | bash och programvara från var som helst

Problemet. Ett skript som du kör som root utan att ha läst det kan göra vad som helst: lägga till källor och nycklar, skriva över filer, öppna en tjänst. Även om avsikten är god vet du efteråt inte vad som har ändrats, och vid nästa versionsuppgradering går det sönder (lektion 4.3).

Gör så här. Ladda ner och läs skriptet. Installera helst från din distributions paketkälla eller tillverkarens officiella källa, med en egen nyckel (Signed-By, lektion 4.1). Anteckna vad du installerar och varför.

6. Inga uppdateringar, eller uppdateringar "senare"

Problemet. Sårbarheter åtgärdas och utnyttjas sedan, ofta inom några dagar. En server som inte får uppdateringar på flera månader, eller som kör en version utan support, har en lista med kända öppningar. Containrar uppdateras inte av apt.

Gör så här. Slå på automatiska säkerhetsuppdateringar (lektion 4.2), bestäm en fast tid för omstarter, lägg in slutdatumet för din version i kalendern (lektion 4.3) och uppdatera containrar regelbundet (lektion 9.4).

7. Ingen säkerhetskopia, eller en säkerhetskopia som aldrig testats

Problemet. En ögonblicksbild på samma lagring är ingen säkerhetskopia (lektion 8.1). En säkerhetskopia som ligger på själva servern försvinner med den vid ett intrång eller ransomware. Och en säkerhetskopia som aldrig har återställts är ett hopp, ingen garanti.

Gör så här. Krypterade säkerhetskopior utanför servern (restic, lektion 8.2), bevakning av att de körs och ett återställningstest minst varje kvartal.

8. Adminpaneler öppna för alla, utan tvåstegsverifiering

Problemet. En adminpanel för en databas (som phpMyAdmin), för Docker (som Portainer), för din applikation eller för ditt lösenordsvalv är ett lockande mål: ett enda lösenord ger åtkomst till allt. Standardlösenord som admin/admin och registrering som lämnas öppen (Vaultwarden, lektion 9.4) gör det ännu enklare.

Gör så här. Öppna inte adminpaneler mot internet: nå dem via en SSH-tunnel eller bara från en fast adress. Måste en panel ändå vara publik: https, ett starkt unikt lösenord från din lösenordshanterare, tvåstegsverifiering och stängd registrering. Byt alltid standardlösenord.

9. Hemligheter i Git eller i din compose-fil

Problemet. Ett lösenord, en API-nyckel eller en privat nyckel i en fil som hamnar i ett Git-repository finns kvar i historiken för alltid, även om du tar bort den senare. Publika repositories genomsöks av botar efter just sådana nycklar.

Gör så här. Lägg hemligheter i en separat fil med rättigheterna 600 (EnvironmentFile, lektion 6.3; .env med Docker Compose, lektion 9.3) som står i .gitignore. Har en hemlighet ändå läckt: byt ut den direkt (ett nytt lösenord, en ny nyckel). Att bara städa i Git räcker inte.

10. Brandväggen "tillfälligt" av, allt som root och inga anteckningar

Problemet. "Jag stänger av brandväggen en stund för att testa" glöms bort. "Jag gör det snabbt som root" blir en vana. Och en server där ingen vet vad som körs och varför går inte att förvalta eller återställa.

Gör så här. Testa med en tillfällig, smal regel (en port, en källadress) och ta bort den efteråt. Arbeta som vanlig användare med sudo. För en kort serverdokumentation: vad körs, vilka portar är öppna, var finns säkerhetskopiorna, när är versionens slutdatum (lektion 10.4).

I praktiken

Alla de här felen går att göra på vilken VPS som helst, hos WebOké lika väl som hos andra leverantörer: det som händer inne på din server förvaltar du själv. Leverantören kan däremot koppla bort en server från nätverket om den skickar spam eller utför attacker, eftersom det drabbar andra kunder. Att förebygga är alltså också viktigt för din egen tillgänglighet.

Sammanfattning

• De flesta intrång utnyttjar kända fel, inte okända sårbarheter.
• Logga in med nycklar och stäng av lösenordsinloggning; databaser, cachar och Docker-API:t aldrig öppna mot internet; ingen docker.sock i containrar som du inte litar helt på.
• Ingen chmod 777 och ingen curl | bash: vet vem som får göra vad och vad du installerar.
• Automatiska uppdateringar, säkerhetskopior utanför servern och testade, adminpaneler bakom en tunnel eller med tvåstegsverifiering.
• Hemligheter utanför Git och utanför compose-filer; det som har läckt ska bytas ut.

Quiz

Uppgift

Uppgift Z10.2: Vilket fel är det? I exempelfilen casussen-z10-2.md finns åtta korta fall med servrar där något är fel. Välj för varje fall vilket fel det är från listan i den här lektionen (A till och med J) och vilket som är det bästa första steget. Programmet jämför med den fasta facit och visar sedan förklaringen för varje fall.

Läs mer

• Säkra din VPS: de första fem minuterna
• Lösenordshanterare och passkeys: så loggar du in säkert
• 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/