# Fallbeispiele zur Aufgabe Z10.2 (Kurs VPS und Linux-Serververwaltung)

Wählen Sie für jedes Fallbeispiel, um welchen Fehler es sich handelt und was der beste erste Schritt ist. Alle Namen und Adressen sind Beispiele.

**Fehler (aus Lektion 10.2):**
A. Root-Login mit einem Passwort
B. Eine Datenbank, ein Cache oder ein Suchcluster offen zum Internet
C. Die Docker-API offen oder `docker.sock` in einem Container
D. `chmod 777`, um eine Fehlermeldung loszuwerden
E. `curl ... | bash` und Software von überall
F. Keine Updates oder Updates "später"
G. Kein Backup oder ein Backup, das nie getestet wurde
H. Verwaltungsoberfläche offen für alle, ohne Zwei-Faktor-Authentifizierung
I. Geheimnisse in Git oder in Ihrer Compose-Datei
J. "Kurz" die Firewall aus, alles als root, keine Notizen

---

**Fallbeispiel 1.** Auf `web1.example.com` steht in `compose.yaml` beim Dienst `redis`: `ports: - "6379:6379"`. `ufw status` zeigt nur 22, 80 und 443. Ein Scan von außen findet 6379 offen.
Erster Schritt: (a) ufw neu starten (b) die Portregel entfernen oder in `"127.0.0.1:6379:6379"` ändern und erneut `docker compose up -d` (c) Redis eine andere Portnummer geben (d) den Server neu starten

**Fallbeispiel 2.** Der Entwickler einer Webanwendung auf `app.example.net` meldet, dass die Uploads nicht funktionierten. Er hat das Problem "gelöst", und jetzt stehen alle Dateien in `/var/www/app` auf `-rwxrwxrwx`.
Erster Schritt: (a) so lassen, es funktioniert jetzt (b) dem Webserver-Benutzer nur Schreibrechte auf den Upload-Ordner geben, den Rest zurück auf 644/755 mit einem anderen Eigentümer (c) den Webserver als root laufen lassen (d) AppArmor deaktivieren

**Fallbeispiel 3.** Ein öffentliches Repository enthält seit gestern eine Datei `.env` mit `MAIL_API_KEY=...` des Servers `web2.example.org`.
Erster Schritt: (a) die Datei aus dem Repository löschen (b) den Schlüssel beim Maildienst widerrufen und einen neuen erstellen, und `.env` in `.gitignore` eintragen (c) das Repository umbenennen (d) nichts tun

**Fallbeispiel 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` ergibt `permitrootlogin yes` und `passwordauthentication yes`. Im Journal stehen jede Minute Anmeldeversuche auf root.
Erster Schritt: (a) fail2ban installieren und sonst nichts (b) einen Schlüssel für einen normalen Administrator mit sudo hinterlegen, testen und dann die Passwortanmeldung und den Root-Login mit Passwort deaktivieren (c) SSH auf Port 2222 legen (d) das Root-Passwort in einer Textdatei aufbewahren

**Fallbeispiel 5.** `cat /etc/os-release` zeigt ein Ubuntu-Release, dessen Standardsupport vor drei Jahren ausgelaufen ist, ohne ESM. `apt list --upgradable` ist leer.
Erster Schritt: (a) sich freuen, es gibt keine Updates (b) ein Upgrade oder einen neuen Server auf eine unterstützte LTS planen, mit Snapshot und Backup (c) unattended-upgrades neu installieren (d) den Server neu starten

**Fallbeispiel 6.** Ein Container `portainer` hat das Volume `/var/run/docker.sock:/var/run/docker.sock` und ist unter `https://beheer.example.com` mit dem Passwort `admin123` erreichbar, ohne Zwei-Faktor-Authentifizierung.
Wählen Sie den Fehler, der den größten Schaden ermöglicht, wenn das Passwort erraten wird. Erster Schritt: (a) die Oberfläche hinter einen SSH-Tunnel oder eine feste Adresse legen und ein starkes Passwort mit Zwei-Faktor-Authentifizierung einrichten (b) den Container neu starten (c) eine andere Subdomain wählen (d) Docker neu installieren

**Fallbeispiel 7.** Nach einem fehlgeschlagenen Update der Datenbank stellt sich heraus, dass das einzige Backup ein zwei Monate alter Snapshot ist, auf demselben Speicher wie der Server. Niemand hat jemals eine Wiederherstellung ausprobiert.
Erster Schritt für die Zukunft: (a) mehr Snapshots erstellen (b) verschlüsselte Backups außerhalb des Servers einrichten (zum Beispiel restic), mit Überwachung und einem Wiederherstellungstest (c) die Datenbank nie wieder aktualisieren (d) eine zweite Festplatte im selben Server

**Fallbeispiel 8.** Auf dem Server befinden sich `/usr/local/bin/tool` und eine unbekannte Paketquelle `extra.list` mit der Option `[trusted=yes]`. Niemand weiß, woher sie stammen; der vorherige Administrator installierte "alles mit einer Zeile von einer Website".
Erster Schritt: (a) stehen lassen, es funktioniert (b) herausfinden, was die Quelle und das Programm sind, die Quelle mit `trusted=yes` deaktivieren und nur noch aus der Distribution oder der offiziellen Quelle des Herstellers mit `Signed-By` installieren (c) den Server neu starten (d) alle Pakete entfernen

Tragen Sie für jedes Fallbeispiel ein: Fehler (A-J) und erster Schritt (a-d).