netcup VPS & Root-Server absichern: SSH-Keys, Fail2ban & Docker-UFW-Bypass beheben

Inhaltsverzeichnis14 Abschnitte

Jeder neu installierte Linux-Server mit öffentlicher IP-Adresse wird bereits wenige Minuten nach dem ersten Bootvorgang von automatisierten Botnetzen gescannt und mit Brute-Force-Angriffen auf Port 22 attackiert.

Wer das initiale root-Passwort beibehält oder Datenbank-Container ungeschützt startet, riskiert binnen kürzester Zeit kompromittierte Systeme.

Dieser Leitfaden führt Sie durch eine praxiserprobte Sicherheits-Härtung für Debian 12 und Ubuntu 24.04 – inklusive der wichtigen Besonderheiten von systemd-journald und der gefährlichen Docker-UFW-Firewall-Lücke.

---

0. Grundregel vorab: So sperren Sie sich niemals selbst aus#

Beachten Sie bei allen Änderungen an der SSH-Konfiguration und der Firewall zwei goldene Regeln:

1. Schließen Sie niemals Ihr aktuelles SSH-Terminal! Behalten Sie Ihre bestehende root-Sitzung offen, bis Sie in einem zweiten, neu geöffneten Terminalfenster erfolgreich getestet haben, dass der Login mit neuem Benutzer, SSH-Key und neuem Port funktioniert.
2. Ihr Rettungsanker im Ernstfall: Sollten Sie sich durch einen Tippfehler in der Firewall doch einmal aussperren, öffnen Sie im netcup Server Control Panel (SCP) einfach den Punkt Screen (HTML5-VNC-Konsole). Dort können Sie sich wie an einem lokalen Bildschirm direkt einloggen und die Regel rückgängig machen.

---

1. System aktualisieren & dedizierten Admin-Benutzer anlegen#

Melden Sie sich mit dem initialen root-Zugang an, installieren Sie alle Sicherheitsupdates und legen Sie einen unprivilegierten Arbeitsbenutzer mit sudo-Berechtigung an:

# 1. Paketlisten aktualisieren und alle Sicherheits-Patches einspielen
apt update && apt upgrade -y

# 2. Wichtige Basis- und Sicherheitspakete installieren
apt install -y sudo curl wget ufw fail2ban

# 3. Admin-Benutzer (z. B. deploy) anlegen und zur Gruppe sudo hinzufügen
adduser deploy
usermod -aG sudo deploy

# 4. Sudo-Berechtigung kurz verifizieren
su - deploy
sudo whoami   # Muss "root" ausgeben
exit

---

2. Moderne Ed25519 SSH-Keys einrichten (Passwort-Login ersetzen)#

Verzichten Sie auf Passwörter und alte RSA-2048-Schlüssel und setzen Sie auf das moderne, auf elliptischen Kurven basierende Ed25519-Verfahren.

1. Schlüsselpaar auf Ihrem lokalen Rechner erzeugen (Linux / macOS / Windows PowerShell)#

# Ed25519-Schlüsselpaar erstellen (optional mit starker Passphrase schützen)
ssh-keygen -t ed25519 -C "[email protected]"

Dadurch entstehen unter ~/.ssh/ zwei Dateien: id_ed25519 (Ihr geheimer privater Schlüssel) und id_ed25519.pub (Ihr öffentlicher Schlüssel).

2. Öffentlichen Schlüssel auf den netcup Server übertragen#

# Auf Ihrem lokalen Rechner ausführen (hinterlegt den Key unter ~/.ssh/authorized_keys)
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@IHRE_SERVER_IP

---

3. SSH-Dienst härten & Port verlegen (sshd_config.d unter Debian 12)#

Statt die zentrale /etc/ssh/sshd_config direkt zu bearbeiten (was bei späteren System-Upgrades zu Konflikten führt), legen wir unter Debian 12 / Ubuntu 24.04 eine saubere Override-Datei im Verzeichnis /etc/ssh/sshd_config.d/ an:

cat << 'EOF' > /etc/ssh/sshd_config.d/99-security.conf
# 1. SSH-Port verlegen (stoppt 99 % aller automatisierten Port-22-Bot-Scans)
Port 22222

# 2. Direkten Root-Login über SSH verbieten
PermitRootLogin no

# 3. Passwort-Authentifizierung komplett abschalten (nur noch SSH-Keys erlauben)
PasswordAuthentication no
KbdInteractiveAuthentication no

# 4. Public-Key-Authentifizierung explizit aktivieren
PubkeyAuthentication yes

# 5. Inaktive Sitzungen nach 10 Minuten sauber trennen
ClientAliveInterval 300
ClientAliveCountMax 2

# 6. SSH-Zugriff strikt auf Ihren Admin-Benutzer beschränken
AllowUsers deploy
EOF

Konfiguration prüfen und SSH-Dienst neu starten#

# Syntax vor dem Neustart prüfen (darf keine Fehler melden)
sshd -t

# Systemd-Units neu laden und SSH neu starten
systemctl daemon-reload
systemctl restart ssh

# Prüfen, ob sshd auf dem neuen Port 22222 lauscht
ss -tulpn | grep ssh

Wichtiger Kontrollpunkt:
Öffnen Sie jetzt auf Ihrem PC ein zweites Terminalfenster und testen Sie den Login:
ssh -p 22222 deploy@IHRE_SERVER_IP
Erst wenn der Login per SSH-Key auf Port 22222 reibungslos klappt, fahren Sie mit Schritt 4 fort!

---

4. UFW-Firewall einrichten & die „Docker umgeht UFW“-Falle lösen#

1. Basis-Regeln für UFW konfigurieren#

# Standardverhalten: Eingehend alles blockieren, ausgehend alles erlauben
ufw default deny incoming
ufw default allow outgoing

# WICHTIG: Zuerst Ihren neuen SSH-Port freigeben!
ufw allow 22222/tcp comment 'Custom SSH Port'

# Webserver-Ports (HTTP / HTTPS / HTTP3) freigeben
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw allow 443/udp comment 'HTTP/3 QUIC'

# Firewall aktivieren
ufw enable

# Aktive Regeln kontrollieren
ufw status verbose

---

2. Kritische Sicherheitsfalle: Warum Docker standardmäßig die UFW-Firewall umgeht!#

Einer der häufigsten Gründe für gehackte Datenbanken und Redis-Instanzen auf Linux-Servern ist das Zusammenspiel von Docker und iptables:

• Das technische Problem:

Docker trägt seine Port-Weiterleitungen direkt in die PREROUTING- und FORWARD-Ketten von iptables ein. Da diese Ketten im Linux-Netzwerkstack vor den INPUT-Regeln von UFW ausgewertet werden, ignoriert Docker Ihre UFW-Sperren komplett!

• Gefährliches Beispiel in der docker-compose.yml:

  ports:
    - "3306:3306"   # GEFAHR: Öffnet MySQL/MariaDB auf 0.0.0.0:3306 weltweit im Internet!
  

Obwohl ufw status anzeigt, dass Port 3306 gesperrt ist, ist Ihre Datenbank von außen für jeden Port-Scanner offen erreichbar!

Die saubere Lösung: Interne Container-Ports immer an 127.0.0.1 binden#

Binden Sie alle Datenbanken (PostgreSQL, MariaDB, Redis) und internen Backend-Dienste in Ihrer docker-compose.yml immer explizit an das lokale Loopback-Interface (127.0.0.1):

ports:
  - "127.0.0.1:3306:3306"   # SICHER: Nur lokal auf dem Host bzw. per Reverse-Proxy erreichbar

Lediglich Ihr Reverse-Proxy (Caddy, Nginx oder Traefik auf den Ports 80 und 443) darf öffentlich auf 0.0.0.0 lauschen.

---

5. Fail2ban unter Debian 12 einrichten (backend = systemd)#

In minimalen Debian-12-Images existiert die klassische Logdatei /var/log/auth.log nicht mehr, da systemd-journald die Protokollierung übernimmt. Ohne die Angabe backend = systemd startet Fail2ban nicht.

/etc/fail2ban/jail.local anlegen#

cat << 'EOF' > /etc/fail2ban/jail.local
[DEFAULT]
# Angreifer-IPs für 1 Stunde (3600 Sekunden) sperren
bantime = 3600
# Beobachtungszeitraum: 10 Minuten
findtime = 600
# Nach 3 Fehlversuchen sperren
maxretry = 3
# Pflicht unter Debian 12 / Ubuntu 24.04 für systemd-journald
backend = systemd

[sshd]
enabled = true
port = 22222
EOF

# Fail2ban neu starten und dauerhaft aktivieren
systemctl restart fail2ban
systemctl enable fail2ban

# Status des SSH-Jails prüfen
fail2ban-client status sshd

---

6. Automatische Sicherheitsupdates aktivieren (unattended-upgrades)#

Damit kritische Sicherheitslücken im Linux-Kernel oder in OpenSSL auch nachts automatisch geschlossen werden:

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

---

7. Abschluss-Checkliste vor dem Go-Live#

Prüfen Sie vor der Inbetriebnahme Ihrer Dienste kurz alle Punkte:

• [ ] System ist per apt update && apt upgrade -y auf dem neuesten Stand
• [ ] Eigener Admin-Benutzer mit sudo-Rechten ist eingerichtet
• [ ] Login per Ed25519-SSH-Key funktioniert zuverlässig
• [ ] SSH-Port wurde verlegt, PermitRootLogin no und PasswordAuthentication no sind aktiv
• [ ] UFW-Firewall ist aktiv und lässt nur SSH, 80 und 443 durch
• [ ] Alle internen Docker-Container-Ports (Datenbanken, Redis, Admin-UIs) sind an 127.0.0.1 gebunden
• [ ] fail2ban-client status sshd zeigt ein aktives Jail mit systemd-Backend
• [ ] unattended-upgrades ist für automatische Sicherheits-Patches aktiviert
• [ ] Notfall-Zugang über die SCP Screen-Konsole (VNC) ist bekannt