Kostenvergleich Apps Preise Blog Termin buchen

Docker-Server härten: Security-Checkliste für Self-Hosted-Infrastruktur

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-proxy beschrä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.

Bereit für eigene Infrastruktur?

15 Minuten Call – wir klären ob Self-Hosting für euch passt.

Termin buchen