Sicherheit im Homelab: SSH, Docker & Firewall richtig absichern

Wer ein Homelab betreibt, sammelt mit der Zeit viele Dienste an: Nextcloud, WordPress, Grafana, Portainer, diverse Datenbanken. Jeder öffnet einen Port, jeder ist ein potenzielles Einfallstor. Mir wurde das letzte Woche richtig bewusst, als ich meine Application-Passwords durchging und merkte: Ich hatte noch nie systematisch über Homelab-Sicherheit nachgedacht.

Die gute Nachricht: Mit ein paar grundlegenden Maßnahmen ist ein Homelab schon deutlich sicherer – ohne dass man Security-Experte sein muss. Hier sind die Maßnahmen, die ich in den letzten Wochen umgesetzt habe.

1. SSH-Zugriff mit Schlüsseln statt Passwörtern

Das allererste und einfachste Upgrade: SSH-Passwort-Authentifizierung deaktivieren und auf Schlüssel umstellen. Ein Passwort kann erraten werden, ein privater Schlüssel (mit Passphrase) nicht.

So gehst du vor:

# Lokalen Schlüssel generieren (falls nicht vorhanden)
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

# Schlüssel auf den Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@dein-server

# Dann auf dem Server: Passwort-Login deaktivieren
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Wichtig: Vor dem Deaktivieren des Passwort-Logins immer in einem zweiten Terminal testen, ob der SSH-Key funktioniert. Sich selbst aussperren ist peinlich – und nervig.

2. Docker-Container nicht als Root laufen lassen

Ein klassischer Sicherheitsfehler: Container, die als root laufen. Wenn ein Angreifer einen solchen Container übernimmt, hat er Root-Zugriff auf dem Host (oder zumindest weitreichende Rechte).

Besser: Non-Root-User im Container verwenden. Viele Images bieten das schon von Haus aus an. Für eigene Dockerfiles oder docker-compose.ymls:

services:
  mein-dienst:
    image: mein-image:latest
    user: "1000:1000"   # Non-Root User
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # Nur die Capability, die wirklich gebraucht wird
    read_only: true
    tmpfs:
      - /tmp
      - /run

Die security_opt– und cap_drop-Zeilen entziehen dem Container alle nicht benötigten Kernel-Capabilities. read_only: true macht das Root-Filesystem des Containers schreibgeschützt – nur wenige Container brauchen wirklich Schreibzugriff.

3. Firewall: Nur das Nötigste öffnen

Wenn alle Dienste hinter einem Caddy Reverse Proxy laufen, brauchst du eigentlich nur zwei Ports offen: 80 (HTTP → Weiterleitung) und 443 (HTTPS). Alles andere bleibt innen.

Mit ufw (Uncomplicated Firewall) unter Ubuntu/Debian:

# Standard-Richtlinien
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Nur SSH und HTTP/HTTPS erlauben
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Aktivieren
sudo ufw enable

Interne Dienste wie Prometheus (:9090), Grafana (:3000) oder Portainer (:9000) sind dann nur noch über den Reverse Proxy von außen erreichbar. Wer sie trotzdem braucht, nutzt ein WireGuard-VPN ins Homelab.

4. Automatische TLS-Zertifikate mit Caddy

Jeder selbst-gehostete Dienst, der von außen erreichbar ist, sollte HTTPS verwenden. Caddy holt und erneuert Let’s-Encrypt-Zertifikate automatisch – kein manuelles Zertifikats-Management nötig.

Das Setup habe ich im Caddy-Reverse-Proxy-Beitrag detailliert beschrieben. Einmal eingerichtet, läuft es von allein.

5. Application Passwords statt Admin-Passwort für APIs

WordPress, Nextcloud und viele andere Dienste unterstützen Application Passwords – separate Passwörter für API-Zugriffe, die nicht das Haupt-Passwort gefährden. Gerade bei der Automatisierung mit Hermes Agent ein wichtiges Pattern.

Das Prinzip: Jeder automatisierte Client bekommt sein eigenes Application Password. Wird eines kompromittiert, löschst du nur dieses eine – das Hauptkonto bleibt sicher. Und anders als das Admin-Passwort funktionieren Application Passwords nicht für den Browser-Login, was die Angriffsfläche reduziert.

6. Regelmäßige Updates

Der einfachste Sicherheitshebel: Container-Images regelmäßig aktualisieren. Ein docker compose pull && docker compose up -d einmal pro Woche ist oft schon genug, um kritische Sicherheitslücken zu schließen.

Für den Docker-Host selbst hilft:

# Unattended-Upgrades aktivieren
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Und für die Container direkt: Ein Tool wie Uptime Kuma überwacht nicht nur die Verfügbarkeit, sondern auch SSL-Zertifikatsablauf und Antwortzeiten – ein guter Indikator, ob ein Dienst Probleme macht.

Sicherheits-Checkliste fürs Homelab

Maßnahme	Priorität	Aufwand
SSH-Key-Auth statt Passwort	🔴 Hoch	10 Minuten
UFW-Firewall aktivieren	🔴 Hoch	5 Minuten
Non-Root-Container	🟡 Mittel	Pro Container
Automatische Updates	🟡 Mittel	10 Minuten
Application Passwords	🟡 Mittel	Pro Dienst
Read-Only-Filesystem	🟢 Optional	Pro Container
Capabilities minimieren	🟢 Optional	Pro Container

Nicht alle Maßnahmen sind für jeden Dienst sinnvoll. Aber die ersten drei Punkte (SSH-Keys, Firewall, Non-Root-Container) sollten in jedem Homelab Standard sein – sie kosten kaum Zeit, bringen aber enorm viel Sicherheit.

Fazit

Sicherheit im Homelab ist kein Hexenwerk. Die meisten Maßnahmen sind einfach umsetzbar und brauchen nur wenige Minuten. Der größte Fehler, den ich selbst gemacht habe: Gar nicht erst anfangen, weil „das Homelab ja nur intern läuft“. Aber interne Netze werden überschätzt – ein kompromittierter Container in einem Docker-Netzwerk kann schnell zum Einfallstor für andere Dienste werden.

Starte mit SSH-Keys und der Firewall. Das ist in einer halben Stunde erledigt und macht den größten Unterschied. Der Rest kommt dann nach und nach.