Docker Engine auf einem Netcup VPS oder Root-Server installieren (inkl. Fix für den UFW-Firewall-Bypass)

Entfernen Sie zunächst eventuell vorhandene Container-Pakete der Distribution (docker.io, podman-docker, containerd) und stellen Sie sicher, dass kein docker-Snap-Paket installiert ist. Die in den Standard-Repositories von Ubuntu und Debian gepflegten docker.io-Pakete hinken den offiziellen Upstream-Releases oft um mehrere Monate hinterher, teilen Buildx und Compose v2 in abweichende Paketnamen auf und erhalten wichtige runc- oder containerd-Sicherheitsfixes teilweise verzögert.

Noch problematischer auf produktiven KVM-Servern ist das Ubuntu-snap-Paket für Docker: Da Snap den Docker-Daemon in einer eigenen AppArmor- und Mount-Namespace-Sandbox kapselt, kommt es regelmäßig zu Berechtigungsfehlern beim Einbinden von Bind-Mounts außerhalb von /home, zu verzögerten Daemon-Starts beim Booten sowie zu unerwünschten automatischen Neustarts laufender Datenbank-Container während eines Snap-Auto-Refreshs. Für produktive Server auf Netcup ist das offizielle APT-Repository von Docker (download.docker.com) daher der einzig empfehlenswerte Standard.

Wir legen den öffentlichen GPG-Schlüssel von Docker im Verzeichnis /etc/apt/keyrings/docker.asc ab und verknüpfen ihn über das Attribut signed-by=/etc/apt/keyrings/docker.asc direkt in der /etc/apt/sources.list.d/docker.list. Im Gegensatz zum veralteten Befehl apt-key add, der Schlüssel global für sämtliche Paketquellen des Systems freigab, vertraut apt diesem Schlüssel ausschließlich für Pakete aus dem offiziellen Docker-Repository.

Durch das Auslesen von /etc/os-release ($ID und $VERSION_CODENAME) erkennt das folgende Installationsskript vollautomatisch, ob Ihr Netcup-Server unter Ubuntu 24.04 LTS (noble) oder Debian 12 (bookworm) läuft, und installiert docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin sowie docker-compose-plugin (Compose v2 als natives Go-Plugin docker compose).

# 1. Eventuell vorhandene Distributionspakete sauber entfernen
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y $pkg 2>/dev/null || true
done

# 2. Voraussetzungen installieren und offiziellen GPG-Schlüssel von Docker hinterlegen
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
. /etc/os-release
sudo curl -fsSL "https://download.docker.com/linux/${ID}/gpg" -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3. Offizielles Docker APT-Repository einbinden
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. Docker Engine, CLI, containerd, Buildx und Compose v2 installieren
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker --version && docker compose version

Docker version 27.3.1, build ce12230
Docker Compose version v2.29.7

Standardmäßig speichert Dockers json-file-Logging-Treiber jede Zeile auf stdout/stderr unbegrenzt auf der Festplatte. Auf einem produktiven Nginx-, Traefik- oder Node.js-Container auf einem Netcup VPS 1000 G12.5 oder RS 1000 G12.5 können unrotierte Container-Logs unter /var/lib/docker/containers/<id>/<id>-json.log im Laufe weniger Monate unbemerkt 40 GB bis 80 GB NVMe-Speicher verschlingen – bis PostgreSQL oder MariaDB plötzlich mit ENOSPC (No space left on device) abstürzt. Mit "max-size": "10m" und "max-file": "3" begrenzen wir das Log-Volumen jedes einzelnen Containers strikt auf maximal 30 MB.

Ebenso wichtig für hohe Verfügbarkeit ist "live-restore": true. In der Standardeinstellung beendet der dockerd-Daemon beim Stoppen oder Neustarten alle laufenden Container-Prozesse. Wenn unattended-upgrades ein Sicherheitsupdate für docker-ce einspielt, führt das ohne Live-Restore jedes Mal zu einem kurzen Ausfall Ihrer gesamten Web- und Datenbank-Stacks. Ist "live-restore": true gesetzt, bleiben die Container unter der Kontrolle von containerd-shim unterbrechungsfrei aktiv, während der Management-Daemon dockerd im Hintergrund neu startet.

Zusätzlich setzen wir "userland-proxy": false. Standardmäßig startet Docker für jeden veröffentlichten Port einen eigenen Userspace-Prozess namens docker-proxy, der Pakete zwischen Host- und Container-Socket im Arbeitsspeicher hin- und herkopiert. Wird dieser deaktiviert, übernimmt der Linux-Kernel die Weiterleitung vollständig über native Netfilter/iptables-NAT-Regeln (inklusive Hairpin-NAT), was den RAM-Verbrauch senkt und zusätzliche Kontextwechsel zwischen Kernel- und Userspace vermeidet.

Schließlich definieren wir über "default-address-pools" eindeutige /24-Bridge-Subnetze aus dem Bereich 172.20.0.0/14. Ohne diese Vorgabe vergibt Docker Compose für jedes neue Projekt ein komplettes /16-Netz (172.18.0.0/16, 172.19.0.0/16 usw.), sodass bereits nach rund 30 Compose-Netzwerken der private Adressraum erschöpft ist oder es zu Routing-Konflikten mit internen WireGuard-, Tailscale- oder OpenVPN-Tunneln kommt. Mit /24-Blöcken (je 254 Container-IPs pro Projekt) stehen Ihnen über 1.000 konfliktfreie Docker-Netzwerke zur Verfügung.

cat << 'EOF' | sudo tee /etc/docker/daemon.json
{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  },
  "live-restore": true,
  "userland-proxy": false,
  "default-address-pools": [
    {
      "base": "172.20.0.0/14",
      "size": 24
    }
  ]
}
EOF

# systemd neu laden und Docker-Daemon mit den neuen Einstellungen starten
sudo systemctl daemon-reload
sudo systemctl restart docker
sudo docker info | grep -E "Storage Driver|Logging Driver|Live Restore"

 Storage Driver: overlay2
 Logging Driver: json-file
 Live Restore Enabled: true

Dies ist das am häufigsten übersehene Sicherheitsrisiko auf selbstverwalteten Linux-Servern: Wenn Sie ufw aktivieren (ufw default deny incoming) und anschließend einen Container mit ports: - "5432:5432" oder - "8080:8080" starten, ändert Docker die PREROUTING-NAT-Tabelle des Kernels, noch bevor die ufw-before-input-Filterkette überhaupt ausgewertet wird. Dadurch steht Port 5432 oder 8080 weltweit offen im Internet, obwohl ufw status lediglich die Ports 22, 80 und 443 als geöffnet anzeigt!

Um zu verstehen, warum das passiert, muss man den Weg eines Netzwerkpakets durch den Linux-Netfilter-Stack betrachten: Wenn ein Paket von außen auf Port 5432 Ihrer öffentlichen Netcup-IPv4-Adresse eintrifft, durchläuft es zuerst die Kette nat PREROUTING. Dort greift Dockers DNAT-Regel und schreibt die Ziel-IP von Ihrer Server-IP auf die interne Container-IP (172.20.0.2:5432) um. Da die Zieladresse nun nicht mehr der Host selbst ist, sondern ein geroutetes Bridge-Subnetz (br-xxxx), biegt der Kernel am Routing-Entscheidungspunkt in die Kette filter FORWARD statt in filter INPUT ab. Sämtliche ufw deny-Standardregeln befinden sich jedoch in der INPUT-Kette (ufw-before-input), während Docker in der FORWARD-Kette ganz oben seine eigene DOCKER-Kette einhängt und das Paket direkt an den Container durchlässt.

Aus genau diesem Grund reserviert die Docker Engine am Anfang der FORWARD-Kette eine spezielle Kette namens DOCKER-USER, die immer vor den automatisch generierten DOCKER-Regeln ausgewertet wird und bei einem Neustart von dockerd erhalten bleibt. Noch wirkungsvoller auf einem Netcup VPS oder Root-Server ist die Kombination aus drei Verteidigungsschichten: Binden Sie interne Container-Ports strikt an das Loopback-Interface (127.0.0.1:5432:5432), aktivieren Sie die zustandsbehaftete Netcup SCP Hypervisor-Firewall (die außerhalb Ihrer VM direkt am Host-Switch filtert) und härten Sie optional die DOCKER-USER-Kette.

Kontrollieren Sie nach jedem Deployment mit sudo ss -tulnp, welche Prozesse und Container tatsächlich an wildcard-fähigen Adressen (0.0.0.0 oder [::]) lauschen. Auf einem sauber konfigurierten Produktionsserver sollten auf 0.0.0.0 ausschließlich sshd (Port 22) und Ihr Reverse-Proxy (nginx, caddy oder traefik auf Port 80/443) erscheinen, während alle Datenbank-, Redis- und Applikations-Container entweder gar keinen Host-Port veröffentlichen (Zugriff über ein gemeinsames Docker-Bridge-Netzwerk) oder strikt an 127.0.0.1 gebunden sind:

• ▪ Schicht 1 — Explizites Loopback-Binding in der compose.yaml: Schreiben Sie immer 127.0.0.1:8080:8080 statt 8080:8080 für Backend-Dienste, die über einen lokalen Nginx/Caddy-Reverse-Proxy angesprochen werden.
• ▪ Schicht 2 — Zustandsbehaftete Netcup SCP Hypervisor-Firewall: Erlauben Sie im Netcup Server Control Panel (servercontrolpanel.de → Network → Firewall) eingehend nur TCP 22, 80, 443 sowie UDP 443 und setzen Sie die Standard-Ingress-Policy auf DROP. Da die SCP-Firewall außerhalb der VM auf dem Host-Switch arbeitet, können Dockers iptables-Regeln sie unmöglich umgehen!
• ▪ Schicht 3 — DOCKER-USER-Kette in /etc/ufw/after.rules absichern: Fügen Sie explizite Drop-Regeln in die DOCKER-USER-Netfilter-Kette für Pakete ein, die über das öffentliche Interface (eth0/ens3) an private RFC1918-Container-Subnetze adressiert sind.

# Interne Anwendungs- und Datenbank-Ports immer strikt an 127.0.0.1 binden:
docker run -d --name test-redis --restart unless-stopped -p 127.0.0.1:6379:6379 redis:7-alpine

# Alle lauschenden TCP/UDP-Sockets auf Ihrem Netcup-Server überprüfen:
# Auf 0.0.0.0 bzw. [::] dürfen nur sshd (22) und Ihr Reverse-Proxy (80/443) lauschen
sudo ss -tulnp

tcp   LISTEN 0      4096       127.0.0.1:6379      0.0.0.0:*    users:(("dockerd",pid=1120,fd=14))