Docker-Server härten: Security-Checkliste für Self-Hosted-Infrastruktur
Ein Docker-Server im Internet ist ein attraktives Ziel. Container isolieren Anwendungen — aber der Host darunter muss genauso abgesichert sein. Die häufigsten Angriffsvektoren: offene Ports durch Docker-iptables-Konflikte, exponierte Docker-Sockets und fehlende SSH-Härtung. In diesem Artikel gehen wir die wichtigsten Maßnahmen durch.
Diese Checkliste ergänzt unsere Artikel über Monitoring für Docker-Stacks und Backup-Strategien. Zusammen bilden sie das Fundament für sicheren Self-Hosting-Betrieb.
1. SSH härten: Die erste Verteidigungslinie
SSH ist der Hauptzugang zu Ihrem Server — und das primäre Ziel automatisierter Brute-Force-Angriffe. Die wichtigste Einzelmaßnahme:
Key-Only Authentication
# SSH-Key generieren (Ed25519 empfohlen)
ssh-keygen -t ed25519 -C "admin@example.com"
# Key auf den Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
# ERST testen, DANN Passwort-Login deaktivieren!
# In /etc/ssh/sshd_config:
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
PubkeyAuthentication yes
Achtung: Deaktivieren Sie Passwort-Login erst, nachdem Sie den Key-basierten Login erfolgreich getestet haben. Sonst sperren Sie sich selbst aus.
SSH-Port ändern
Standard-Port 22 ist das Ziel automatisierter Scans. Ein anderer Port (z. B. 2222 oder ein zufälliger Port oberhalb 1024) reduziert Log-Noise erheblich — ist aber keine echte Sicherheitsmaßnahme, sondern Defense in Depth.
# In /etc/ssh/sshd_config:
Port 2222
2. UFW und Docker: Der iptables-Konflikt
Das ist die häufigste Sicherheitsfalle bei Docker-Servern: Docker umgeht UFW komplett.
Docker manipuliert iptables direkt und erstellt eigene Chains (DOCKER, DOCKER-USER, DOCKER-ISOLATION), die vor UFWs Regeln ausgewertet werden. Das Ergebnis: Sie konfigurieren UFW sorgfältig, aber Container-Ports sind trotzdem von außen erreichbar.
Die Lösung: DOCKER-USER Chain
Docker garantiert, die DOCKER-USER-Chain nie zu überschreiben. Nutzen Sie diese für Ihre Firewall-Regeln. Fügen Sie in /etc/ufw/after.rules hinzu:
*filter
:DOCKER-USER - [0:0]
# Bestehende Verbindungen erlauben
-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Return-Traffic für private Netze erlauben
-A DOCKER-USER -s 10.0.0.0/8 -j RETURN
-A DOCKER-USER -s 172.16.0.0/12 -j RETURN
-A DOCKER-USER -s 192.168.0.0/16 -j RETURN
# Alles andere blockieren
-A DOCKER-USER -j DROP
COMMIT
Danach sudo ufw reload. Jetzt müssen Sie explizit freigeben, welche Container-Ports von außen erreichbar sein sollen.
Alternative: ufw-docker Tool
Das Tool ufw-docker automatisiert diese Konfiguration:
# Installation
sudo wget -O /usr/local/bin/ufw-docker
https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
# iptables-Regeln installieren
sudo ufw-docker install
# Container gezielt freigeben
sudo ufw-docker allow traefik 443/tcp
sudo ufw-docker allow traefik 80/tcp
Nicht empfohlen: --iptables=false im Docker-Daemon. Damit verlieren Container ihre externe Netzwerkkonnektivität.
3. Docker Socket Security
Der Docker-Socket (/var/run/docker.sock) ist gleichbedeutend mit Root-Zugriff auf den Host. Ein kompromittierter Container mit Socket-Zugriff kann:
- Andere Container starten, stoppen und löschen
- Images erstellen und ausführen
- Auf das Host-Dateisystem zugreifen (via Volume-Mounts)
- Privilegierte Container starten → vollständiger Host-Zugriff
Maßnahmen
- Socket nicht in Container mounten — wenn irgendwie vermeidbar
- Read-only Mount hilft kaum — macht Exploitation schwieriger, verhindert sie aber nicht
- Socket-Proxy verwenden:
tecnativa/docker-socket-proxybeschränkt den API-Zugriff auf einzelne Endpoints
services:
docker-proxy:
image: tecnativa/docker-socket-proxy
environment:
- CONTAINERS=1 # Nur Container-Liste erlauben
- SERVICES=0
- TASKS=0
- NETWORKS=0
- VOLUMES=0
- POST=0 # Keine schreibenden Operationen
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
networks:
- proxy-net
traefik:
# ... Traefik nutzt den Proxy statt den echten Socket
environment:
- DOCKER_HOST=tcp://docker-proxy:2375
networks:
- proxy-net
4. Container-Security: Angriffsfläche minimieren
Jeder Container sollte mit minimalen Rechten laufen. Die wichtigsten Einstellungen:
services:
app:
image: myapp:latest
security_opt:
- no-new-privileges:true # Privilege Escalation verhindern
read_only: true # Dateisystem read-only
tmpfs:
- /tmp # Temporäres Verzeichnis im RAM
user: "1000:1000" # Nicht als root laufen
cap_drop:
- ALL # Alle Capabilities entfernen
cap_add:
- NET_BIND_SERVICE # Nur was nötig ist, hinzufügen
Erklärung der Einstellungen
- no-new-privileges: Verhindert, dass Prozesse über setuid/setgid höhere Rechte erlangen
- read_only: Container-Dateisystem ist unveränderbar — Malware kann sich nicht einnisten
- user: Container läuft als unprivilegierter Nutzer, nicht als root
- cap_drop: ALL + cap_add: Nur die tatsächlich benötigten Linux-Capabilities vergeben
5. Fail2Ban für Docker-Dienste
Fail2Ban überwacht Log-Dateien und bannt IPs nach zu vielen fehlgeschlagenen Versuchen. Für Docker-Dienste:
services:
fail2ban:
image: lscr.io/linuxserver/fail2ban
container_name: fail2ban
cap_add:
- NET_ADMIN
- NET_RAW
network_mode: host
environment:
- TZ=Europe/Berlin
volumes:
- fail2ban-data:/config
- /var/log:/var/log:ro
- ./remotelogs:/remotelogs:ro # Logs der Docker-Apps
restart: unless-stopped
volumes:
fail2ban-data:
Wichtig: Für Docker-Container nutzt Fail2Ban die Chain DOCKER-USER statt INPUT. Mounten Sie Log-Verzeichnisse der Apps unter /remotelogs — keine einzelnen Dateien, sondern ganze Verzeichnisse.
6. Automatische Sicherheitsupdates
Ungepatchte Systeme sind das größte Risiko. Konfigurieren Sie unattended-upgrades für automatische Sicherheitsupdates:
# Installation
sudo apt install unattended-upgrades
# Konfiguration in /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
# Aktivieren
sudo dpkg-reconfigure -plow unattended-upgrades
Für Docker-Images empfehlen wir Watchtower oder manuelle Updates mit einem festen Update-Zyklus (z. B. monatlich).
7. Rootless Docker (optional)
Docker kann seit Version 20.10 komplett ohne root-Rechte betrieben werden. Der Docker-Daemon läuft als unprivilegierter User. Vorteile: Selbst bei einem Container-Ausbruch hat der Angreifer keine root-Rechte auf dem Host.
Nachteile: Einige Features funktionieren eingeschränkt (z. B. Ports unter 1024, bestimmte Storage-Treiber). Für die meisten Setups mit einem Reverse Proxy wie Traefik ist das kein Problem, da Traefik auf den privilegierten Ports läuft und intern weiterleitet.
Security-Checkliste (Zusammenfassung)
| Maßnahme | Priorität | Aufwand |
|---|---|---|
| SSH Key-Only + Root-Login deaktivieren | Kritisch | 10 Min. |
| UFW + DOCKER-USER Chain konfigurieren | Kritisch | 15 Min. |
| Docker-Socket nicht in Container mounten | Hoch | Variabel |
| Container mit no-new-privileges + non-root User | Hoch | 5 Min./Container |
| Fail2Ban für SSH und Docker-Dienste | Hoch | 20 Min. |
| Automatische Sicherheitsupdates | Hoch | 5 Min. |
| SSH-Port ändern | Mittel | 2 Min. |
| Docker-Socket-Proxy einrichten | Mittel | 15 Min. |
| Rootless Docker | Optional | 30+ Min. |
Managed Security: Wir härten Ihren Server
Server-Härtung ist kein einmaliger Vorgang — es ist ein fortlaufender Prozess. Neue CVEs, Docker-Updates, sich ändernde Best Practices. Bei netzspitze.tech ist Security-Hardening Teil jedes Managed-Pakets:
- SSH-Härtung und Key-Management
- UFW + Docker-Firewall-Konfiguration
- Fail2Ban für alle exponierten Dienste
- Automatische Sicherheitsupdates
- Regelmäßige Security-Reviews
- Container-Hardening nach CIS Docker Benchmark
Jetzt Beratungstermin buchen — wir machen Ihren Docker-Server sicher.