Wat je niet moet doen
Module 10: Veilig blijven · Leestijd: 12 minuten
Leerdoel: Na deze les herken je de fouten die het vaakst tot een gehackte of kapotte server leiden, kun je uitleggen waarom ze gevaarlijk zijn, en weet je wat je in plaats daarvan doet.
Kernbegrippen: root-login met wachtwoord, zwak of standaardwachtwoord, open database, Docker-API op poort 2375, docker.sock in een container, chmod 777, curl | bash, geheimen in Git, beheerpaneel zonder tweestapsverificatie, firewall "even uit", geen updates, geen back-up
Waarom een les over fouten?
De meeste servers worden niet gehackt door een geniale aanvaller met een onbekend lek. Ze worden gehackt door bots die het hele internet afgaan op zoek naar bekende fouten: een wachtwoord dat te raden is, een database die openstaat, een programma dat al maanden een update mist. Wie de fouten in deze les vermijdt, valt voor die bots af. Dat is het grootste deel van de bescherming die je kunt krijgen.
Bij elke fout staat waarom hij gevaarlijk is en wat je in plaats daarvan doet. Bijna alles heb je in eerdere lessen geleerd; deze les zet het op een rij.
1. Root-login met een wachtwoord
Het probleem. Iedere server krijgt de hele dag inlogpogingen op root (les 5.3). Kan root inloggen met een wachtwoord, dan is dat wachtwoord het enige wat tussen een bot en volledige controle staat. Hergebruikte of te korte wachtwoorden worden vroeg of laat geraden of staan al in een gelekte lijst.
Doe dit. Inloggen alleen met sleutels: PasswordAuthentication no en KbdInteractiveAuthentication no, root hoogstens met een sleutel (PermitRootLogin prohibit-password) of helemaal niet (no), dagelijks werken als gewone gebruiker met sudo (les 2.2 en 3.2). Controleer van buitenaf welke inlogmethoden je server aanbiedt (opdracht Z2.2).
2. Een database, cache of zoekcluster open naar internet
Het probleem. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch of OpenSearch (9200) en MongoDB (27017) zijn gemaakt voor vertrouwde programma's in een vertrouwd netwerk. Staan ze op 0.0.0.0 zonder firewall, dan vinden scanners ze snel. Redis zegt in zijn eigen documentatie dat het niet aan internet blootgesteld hoort te worden en dat iemand met toegang de hele dataset kan wissen; via het commando CONFIG kan een aanvaller zelfs bestanden op de server schrijven. Open databases en zoekclusters zijn al jaren een bekende oorzaak van grote datalekken en van "losgeld"-berichten in plaats van je gegevens.
Doe dit. Laat zulke diensten op 127.0.0.1 luisteren (les 5.1), houd ze achter de firewall (les 5.2), en publiceer ze in Docker niet of alleen op 127.0.0.1 (les 9.3). Zelf erbij vanaf je laptop: een SSH-tunnel (les 2.3). Controleer van buitenaf (opdracht Z5.1).
3. De Docker-API open of docker.sock in een container
Het probleem. Wie de Docker-daemon kan besturen, is in feite root op de server: de Docker-documentatie zegt dat alleen vertrouwde gebruikers de daemon mogen besturen en noemt toegang tot de daemon gelijk aan root-toegang. Twee varianten van deze fout:
- De daemon luistert op een TCP-poort zonder TLS (gebruikelijk is 2375). Iedereen die die poort bereikt, kan containers starten met de schijf van je server erin.
- Een container krijgt
/var/run/docker.sockmee als volume ("dan kan hij zelf containers beheren"). Wordt die container gehackt, dan is de hele server over.
Ook de groep docker is root-gelijk (les 9.2): zet er alleen beheerders in.
Doe dit. Laat Docker alleen via de lokale socket werken. Beheer op afstand gaat via SSH (docker context met ssh://), of als het echt via TCP moet, met TLS op poort 2376 en clientcertificaten. Mount docker.sock alleen in een container die je volledig vertrouwt en echt nodig hebt, en liever alleen-lezen via een beperkende proxy.
4. chmod 777 om een foutmelding weg te krijgen
Het probleem. "Permission denied" bij een upload, en een forum zegt: chmod -R 777 /var/www. Daarna mag iedere gebruiker en ieder proces op de server alles in je website schrijven, ook een gehackte plugin of een ander account. Code die schrijfbaar is voor de webserver, kan door een lek worden vervangen door een backdoor.
Doe dit. Zoek uit wie moet schrijven en waar (les 3.1): meestal alleen de webservergebruiker in één map voor uploads of cache. Code van een andere eigenaar dan de webserver, rechten 644/755, uploads 750/640 of vergelijkbaar.
5. curl ... | bash en software van overal
Het probleem. Een script dat je ongezien als root uitvoert, kan alles: bronnen en sleutels toevoegen, bestanden overschrijven, een dienst openzetten. Ook als de bedoeling goed is, weet je daarna niet wat er veranderd is, en bij de volgende release-upgrade breekt het (les 4.3).
Doe dit. Download en lees het script. Installeer liever uit de pakketbron van je distributie of de officiële bron van de maker, met een eigen sleutel (Signed-By, les 4.1). Noteer wat je installeert en waarom.
6. Geen updates, of updates "later"
Het probleem. Lekken worden gerepareerd en daarna misbruikt, vaak binnen dagen. Een server die maanden geen updates krijgt, of die op een release zonder ondersteuning draait, heeft een lijst met bekende openingen. Containers worden door apt niet bijgewerkt.
Doe dit. Automatische beveiligingsupdates aan (les 4.2), een vast moment voor herstarten, de einddatum van je release in je agenda (les 4.3), en containers regelmatig bijwerken (les 9.4).
7. Geen back-up, of een back-up die nooit getest is
Het probleem. Een snapshot op dezelfde opslag is geen back-up (les 8.1). Een back-up die op de server zelf staat, verdwijnt mee bij een hack of ransomware. En een back-up die nooit is teruggezet, is een hoop, geen zekerheid.
Doe dit. Versleutelde back-ups buiten de server (restic, les 8.2), bewaking dat ze lopen, en minstens elk kwartaal een terugzettest.
8. Beheerpanelen open voor iedereen, zonder tweestapsverificatie
Het probleem. Een beheerpaneel van een database (zoals phpMyAdmin), van Docker (zoals Portainer), van je applicatie of van je wachtwoordkluis is een aantrekkelijk doelwit: één wachtwoord geeft toegang tot alles. Standaardwachtwoorden als admin/admin en registratie die open blijft staan (Vaultwarden, les 9.4) maken het nog makkelijker.
Doe dit. Zet beheerpanelen niet open naar internet: bereik ze via een SSH-tunnel of alleen vanaf een vast adres. Moet een paneel toch publiek zijn: https, een sterk uniek wachtwoord uit je wachtwoordmanager, tweestapsverificatie, en registratie dicht. Verander altijd standaardwachtwoorden.
9. Geheimen in Git of in je compose-bestand
Het probleem. Een wachtwoord, API-sleutel of private key in een bestand dat in een Git-repository terechtkomt, staat daar voor altijd in de geschiedenis, ook als je het later weghaalt. Openbare repositories worden door bots doorzocht op precies zulke sleutels.
Doe dit. Geheimen in een apart bestand met rechten 600 (EnvironmentFile, les 6.3; .env bij Docker Compose, les 9.3), dat in .gitignore staat. Is er toch een geheim gelekt: vervang het meteen (een nieuw wachtwoord, een nieuwe sleutel), opruimen in Git alleen is niet genoeg.
10. "Even" de firewall uit, alles als root, en geen notities
Het probleem. "Ik zet de firewall even uit om te testen" wordt vergeten. "Ik doe het even als root" wordt een gewoonte. En een server waarvan niemand weet wat erop draait en waarom, is niet te beheren of te herstellen.
Doe dit. Test met een tijdelijke, smalle regel (één poort, één bronadres) en haal hem daarna weg. Werk als gewone gebruiker met sudo. Houd een kort serverdossier bij: wat draait er, welke poorten staan open, waar staan de back-ups, wanneer is de einddatum van de release (les 10.4).
In de praktijk
Al deze fouten zijn op elke VPS te maken, bij WebOké net zo goed als bij andere aanbieders: wat er binnen je server gebeurt, beheer je zelf. De aanbieder kan een server wel van het netwerk halen als hij spam verstuurt of aanvallen uitvoert, omdat dat andere klanten raakt. Voorkomen is dus ook voor je eigen bereikbaarheid belangrijk.
Samenvatting
- De meeste hacks gebruiken bekende fouten, geen onbekende lekken.
- Inloggen met sleutels, wachtwoordlogin uit; databases, caches en de Docker-API nooit open naar internet; geen
docker.sockin containers die je niet volledig vertrouwt. - Geen
chmod 777en geencurl | bash: weet wie wat mag en wat je installeert. - Updates automatisch, back-ups buiten de server en getest, beheerpanelen achter een tunnel of met tweestapsverificatie.
- Geheimen buiten Git en buiten compose-bestanden; gelekt is vervangen.
Quiz
Opdracht
Opdracht Z10.2: Welke fout is het? In het voorbeeldbestand casussen-z10-2.md staan acht korte casussen van servers die iets mis hebben. Kies per casus welke fout het is uit de lijst van deze les (A tot en met J) en wat de beste eerste stap is. Het programma vergelijkt met de vaste sleutel en toont daarna per casus de uitleg.
Verder lezen
- Je VPS beveiligen: de eerste vijf minuten
- Wachtwoordmanager en passkeys: zo regel je je inloggen veilig
- Docker-documentatie, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
- Docker-documentatie, 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/