Was Sie nicht tun sollten

Modul 10: Sicher bleiben · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion erkennen Sie die Fehler, die am häufigsten zu einem gehackten oder defekten Server führen, können erklären, warum sie gefährlich sind, und wissen, was Sie stattdessen tun.

Kernbegriffe: Root-Login mit Passwort, schwaches oder Standardpasswort, offene Datenbank, Docker-API auf Port 2375, docker.sock in einem Container, chmod 777, curl | bash, Geheimnisse in Git, Verwaltungsoberfläche ohne Zwei-Faktor-Authentifizierung, Firewall "kurz aus", keine Updates, kein Backup

Warum eine Lektion über Fehler?

Die meisten Server werden nicht von einem genialen Angreifer mit einer unbekannten Lücke gehackt. Sie werden von Bots gehackt, die das gesamte Internet nach bekannten Fehlern absuchen: ein Passwort, das sich erraten lässt, eine Datenbank, die offen steht, ein Programm, dem seit Monaten ein Update fehlt. Wer die Fehler aus dieser Lektion vermeidet, fällt für diese Bots aus dem Raster. Das ist der größte Teil des Schutzes, den Sie erreichen können.

Zu jedem Fehler steht, warum er gefährlich ist und was Sie stattdessen tun. Fast alles haben Sie in früheren Lektionen gelernt; diese Lektion fasst es zusammen.

1. Root-Login mit einem Passwort

Das Problem. Jeder Server erhält den ganzen Tag Anmeldeversuche auf root (Lektion 5.3). Kann sich root mit einem Passwort anmelden, ist dieses Passwort das Einzige, was zwischen einem Bot und der vollständigen Kontrolle steht. Wiederverwendete oder zu kurze Passwörter werden früher oder später erraten oder stehen bereits in einer geleakten Liste.

So geht es richtig. Anmeldung nur mit Schlüsseln: PasswordAuthentication no und KbdInteractiveAuthentication no, root höchstens mit einem Schlüssel (PermitRootLogin prohibit-password) oder gar nicht (no), im Alltag als normaler Benutzer mit sudo arbeiten (Lektion 2.2 und 3.2). Prüfen Sie von außen, welche Anmeldemethoden Ihr Server anbietet (Aufgabe Z2.2).

2. Eine Datenbank, ein Cache oder ein Suchcluster offen zum Internet

Das Problem. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch oder OpenSearch (9200) und MongoDB (27017) sind für vertrauenswürdige Programme in einem vertrauenswürdigen Netzwerk gemacht. Lauschen sie auf 0.0.0.0 ohne Firewall, finden Scanner sie schnell. Redis schreibt in seiner eigenen Dokumentation, dass es nicht dem Internet ausgesetzt werden sollte und dass jemand mit Zugriff den gesamten Datenbestand löschen kann; über den Befehl CONFIG kann ein Angreifer sogar Dateien auf den Server schreiben. Offene Datenbanken und Suchcluster sind seit Jahren eine bekannte Ursache großer Datenpannen und von "Lösegeld"-Nachrichten anstelle Ihrer Daten.

So geht es richtig. Lassen Sie solche Dienste auf 127.0.0.1 lauschen (Lektion 5.1), halten Sie sie hinter der Firewall (Lektion 5.2) und veröffentlichen Sie sie in Docker nicht oder nur auf 127.0.0.1 (Lektion 9.3). Selbst vom Laptop darauf zugreifen: mit einem SSH-Tunnel (Lektion 2.3). Prüfen Sie von außen (Aufgabe Z5.1).

3. Die Docker-API offen oder docker.sock in einem Container

Das Problem. Wer den Docker-Daemon steuern kann, ist faktisch root auf dem Server: Die Docker-Dokumentation sagt, dass nur vertrauenswürdige Benutzer den Daemon steuern dürfen, und setzt Zugriff auf den Daemon mit Root-Zugriff gleich. Zwei Varianten dieses Fehlers:

• Der Daemon lauscht ohne TLS auf einem TCP-Port (üblich ist 2375). Jeder, der diesen Port erreicht, kann Container starten, in die die Festplatte Ihres Servers eingebunden ist.
• Ein Container bekommt /var/run/docker.sock als Volume mit ("dann kann er selbst Container verwalten"). Wird dieser Container gehackt, ist der ganze Server verloren.

Auch die Gruppe docker ist root-gleich (Lektion 9.2): Nehmen Sie nur Administratoren darin auf.

So geht es richtig. Lassen Sie Docker nur über den lokalen Socket arbeiten. Die Fernverwaltung läuft über SSH (docker context mit ssh://) oder, wenn es wirklich über TCP sein muss, mit TLS auf Port 2376 und Client-Zertifikaten. Binden Sie docker.sock nur in einen Container ein, dem Sie vollständig vertrauen und den Sie wirklich brauchen, und dann am besten nur lesend über einen einschränkenden Proxy.

4. chmod 777, um eine Fehlermeldung loszuwerden

Das Problem. "Permission denied" (Zugriff verweigert) bei einem Upload, und ein Forum rät: chmod -R 777 /var/www. Danach darf jeder Benutzer und jeder Prozess auf dem Server alles in Ihre Website schreiben, auch ein gehacktes Plugin oder ein anderes Konto. Code, der für den Webserver beschreibbar ist, kann über eine Lücke durch eine Hintertür ersetzt werden.

So geht es richtig. Finden Sie heraus, wer schreiben muss und wo (Lektion 3.1): meist nur der Webserver-Benutzer in einem einzigen Ordner für Uploads oder Cache. Code gehört einem anderen Eigentümer als dem Webserver, Rechte 644/755, Uploads 750/640 oder Vergleichbares.

5. curl ... | bash und Software von überall

Das Problem. Ein Skript, das Sie ungesehen als root ausführen, kann alles: Paketquellen und Schlüssel hinzufügen, Dateien überschreiben, einen Dienst öffnen. Selbst wenn die Absicht gut ist, wissen Sie danach nicht, was geändert wurde, und beim nächsten Release-Upgrade geht es kaputt (Lektion 4.3).

So geht es richtig. Laden Sie das Skript herunter und lesen Sie es. Installieren Sie lieber aus der Paketquelle Ihrer Distribution oder aus der offiziellen Quelle des Herstellers, mit eigenem Schlüssel (Signed-By, Lektion 4.1). Notieren Sie, was Sie installieren und warum.

6. Keine Updates oder Updates "später"

Das Problem. Lücken werden geschlossen und danach ausgenutzt, oft innerhalb weniger Tage. Ein Server, der monatelang keine Updates erhält oder auf einem Release ohne Support läuft, hat eine Liste bekannter Einfallstore. Container werden durch apt nicht aktualisiert.

So geht es richtig. Automatische Sicherheitsupdates aktivieren (Lektion 4.2), ein fester Zeitpunkt für Neustarts, das Supportende Ihres Releases im Kalender (Lektion 4.3) und Container regelmäßig aktualisieren (Lektion 9.4).

7. Kein Backup oder ein Backup, das nie getestet wurde

Das Problem. Ein Snapshot auf demselben Speicher ist kein Backup (Lektion 8.1). Ein Backup, das auf dem Server selbst liegt, verschwindet bei einem Hack oder bei Ransomware mit. Und ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, keine Gewissheit.

So geht es richtig. Verschlüsselte Backups außerhalb des Servers (restic, Lektion 8.2), eine Überwachung, dass sie laufen, und mindestens einmal pro Quartal ein Wiederherstellungstest.

8. Verwaltungsoberflächen offen für alle, ohne Zwei-Faktor-Authentifizierung

Das Problem. Eine Verwaltungsoberfläche für eine Datenbank (etwa phpMyAdmin), für Docker (etwa Portainer), für Ihre Anwendung oder für Ihren Passworttresor ist ein attraktives Ziel: Ein einziges Passwort öffnet den Zugang zu allem. Standardpasswörter wie admin/admin und eine Registrierung, die offen bleibt (Vaultwarden, Lektion 9.4), machen es noch leichter.

So geht es richtig. Machen Sie Verwaltungsoberflächen nicht aus dem Internet erreichbar: Greifen Sie über einen SSH-Tunnel oder nur von einer festen Adresse darauf zu. Muss eine Oberfläche doch öffentlich sein: https, ein starkes, einzigartiges Passwort aus Ihrem Passwortmanager, Zwei-Faktor-Authentifizierung und eine geschlossene Registrierung. Ändern Sie Standardpasswörter immer.

9. Geheimnisse in Git oder in Ihrer Compose-Datei

Das Problem. Ein Passwort, ein API-Schlüssel oder ein privater Schlüssel in einer Datei, die in einem Git-Repository landet, steht dort für immer in der Historie, auch wenn Sie ihn später entfernen. Öffentliche Repositories werden von Bots gezielt nach solchen Schlüsseln durchsucht.

So geht es richtig. Geheimnisse gehören in eine separate Datei mit den Rechten 600 (EnvironmentFile, Lektion 6.3; .env bei Docker Compose, Lektion 9.3), die in .gitignore steht. Ist doch ein Geheimnis geleakt: Ersetzen Sie es sofort (ein neues Passwort, ein neuer Schlüssel); nur in Git aufzuräumen reicht nicht.

10. "Kurz" die Firewall aus, alles als root und keine Notizen

Das Problem. "Ich schalte die Firewall kurz zum Testen aus" wird vergessen. "Ich mache das schnell als root" wird zur Gewohnheit. Und ein Server, bei dem niemand weiß, was darauf läuft und warum, lässt sich weder verwalten noch wiederherstellen.

So geht es richtig. Testen Sie mit einer vorübergehenden, eng gefassten Regel (ein Port, eine Quelladresse) und entfernen Sie sie danach wieder. Arbeiten Sie als normaler Benutzer mit sudo. Führen Sie eine kurze Serverakte: Was läuft, welche Ports sind offen, wo liegen die Backups, wann endet der Support des Releases (Lektion 10.4).

In der Praxis

All diese Fehler lassen sich auf jedem VPS machen, bei WebOké genauso wie bei anderen Anbietern: Was innerhalb Ihres Servers geschieht, verwalten Sie selbst. Der Anbieter kann einen Server allerdings vom Netz nehmen, wenn er Spam versendet oder Angriffe ausführt, weil das andere Kunden betrifft. Vorbeugen ist also auch für Ihre eigene Erreichbarkeit wichtig.

Zusammenfassung

• Die meisten Hacks nutzen bekannte Fehler, keine unbekannten Lücken.
• Anmeldung mit Schlüsseln, Passwort-Login aus; Datenbanken, Caches und die Docker-API nie offen zum Internet; kein docker.sock in Containern, denen Sie nicht vollständig vertrauen.
• Kein chmod 777 und kein curl | bash: Wissen Sie, wer was darf und was Sie installieren.
• Updates automatisch, Backups außerhalb des Servers und getestet, Verwaltungsoberflächen hinter einem Tunnel oder mit Zwei-Faktor-Authentifizierung.
• Geheimnisse außerhalb von Git und außerhalb von Compose-Dateien; was geleakt ist, wird ersetzt.

Quiz

Aufgabe

Aufgabe Z10.2: Welcher Fehler ist es? In der Beispieldatei casussen-z10-2.md stehen acht kurze Fälle von Servern, bei denen etwas nicht stimmt. Wählen Sie für jeden Fall, um welchen Fehler aus der Liste dieser Lektion (A bis J) es sich handelt und was der beste erste Schritt ist. Das Programm vergleicht mit dem festen Lösungsschlüssel und zeigt anschließend für jeden Fall die Erklärung.

Weiterführende Informationen

• Ihren VPS absichern: die ersten fünf Minuten
• Passwortmanager und Passkeys: So regeln Sie Ihre Anmeldung sicher
• Docker-Dokumentation, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker-Dokumentation, 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/