Linux VPS oder Root-Server auf Netcup absichern (5-Schichten Defense-in-Depth Blueprint)

Die im Netcup Server Control Panel (servercontrolpanel.de) für alle Generationen 11/11.5/12/12.5 verfügbare SCP Stateful Firewall filtert Datenverkehr direkt am virtuellen Switch des Host-Hypervisors (tap-Interface), noch bevor Pakete Ihre virtuelle Maschine erreichen. Das bietet zwei entscheidende Sicherheitsvorteile: Erstens werden volumetrische Port-Scans (z. B. auf Port 3306, 5432, 6379 oder 27017) bereits auf dem Host-Switch verworfen, ohne CPU-SoftIRQ-Interrupts oder Conntrack-Tabelleneinträge in Ihrer VM zu verbrauchen; zweitens können Docker-Container selbst bei einem Fehlkonfigurationsfehler (-p 5432:5432) niemals ein Loch in die Hypervisor-Firewall reißen.

Im Gegensatz zu einfachen statischen Paketfiltern arbeitet die Netcup SCP Firewall zustandsbehaftet (Stateful Inspection): Sobald Ihre VM eine ausgehende Verbindung initiiert (etwa für apt update, git clone, ausgehende Webhooks oder DNS-Abfragen), merkt sich die Status-Engine des Hypervisors den Verbindungszustand (ESTABLISHED, RELATED) und lässt die zugehörigen Antwortpakete automatisch passieren, während unangeforderte eingehende Verbindungsversuche (SYN) auf nicht freigegebenen Ports mit DROP verworfen werden. Über die Funktion Firewall Policies / Templates im SCP können Sie ein Standard-Regelwerk einmalig definieren und mit einem Klick oder über die SCP-REST-API auf beliebig viele Netcup-Server anwenden.

Achten Sie beim Anlegen Ihrer Ingress-Regeln darauf, ICMP und insbesondere ICMPv6 (Typen 133 bis 136) ausdrücklich zuzulassen (ACCEPT). IPv6 benötigt die ICMPv6-Pakete *Neighbor Solicitation (Typ 135)*, *Neighbor Advertisement (Typ 136)* sowie *Packet Too Big (Typ 2)* zwingend für die Layer-2-Nachbarschaftsauflösung zum Netcup-Gateway fe80::1 und für Path MTU Discovery (PMTUD). Ein pauschales Blockieren von ICMPv6 führt unweigerlich zu eingefrorenen TLS-Handshakes und IPv6-Routing-Abbrüchen. Konfigurieren Sie unter SCP → Server auswählen → Firewall die folgende Produktions-Matrix:

Unter Ubuntu 24.04 LTS und modernen Debian 12 Installationen wird standardmäßig kein klassischer Text-Log-Daemon (rsyslog) mehr installiert – die Datei /var/log/auth.log existiert also nicht! Wenn Sie fail2ban ohne Anpassung installieren, sucht der Dienst nach /var/log/auth.log und bricht den Start entweder mit Failed during configuration: Have not found any log file for sshd jail ab oder übersieht sämtliche fehlgeschlagenen SSH-Anmeldeversuche. Durch die Installation von python3-systemd und das Setzen von backend = systemd liest Fail2ban strukturierte Ereignisse (_SYSTEMD_UNIT=ssh.service) verzögerungsfrei direkt aus dem binären systemd-journald-Index.

Gleichzeitig aktivieren wir im [sshd]-Jail die Einstellung mode = aggressive. Moderne verteilte SSH-Botnetze führen oft keinen vollständigen Passwort-Versuch mehr durch, sondern prüfen nur den SSH-Banner oder brechen den Handshake bereits in der Pre-Auth-Phase (Connection closed by authenticating user root ... [preauth]) ab, um unter dem Radar klassischer Fail2ban-Filter zu bleiben. Mit mode = aggressive erkennt Fail2ban auch diese Pre-Auth-Scanner-Abbrüche und sperrt die Quell-IP über ufw bereits nach drei Versuchen innerhalb von 15 Minuten (findtime = 15m, maxretry = 3).

Anstelle einer starren 10-Minuten-Sperre, nach deren Ablauf dasselbe Botnetz einfach weiterprobiert, schalten wir exponentiell ansteigende Sperrzeiten (bantime.increment = true) frei: Beim ersten Verstoß wird die IP für 1h gesperrt, beim zweiten Mal für 2h, danach für 4h, 8h, 16h bis hin zu einer maximalen Sperrdauer von 5 Wochen (bantime.maxtime = 5w). Tragen Sie Ihre eigene statische Büro- oder WireGuard-VPN-IP in ignoreip ein, um sich niemals versehentlich selbst auszusperren:

sudo apt update
sudo apt install -y fail2ban python3-systemd

# Gehärtete Fail2ban-Konfiguration mit systemd-Backend und exponentiellen Sperrzeiten schreiben
cat << 'EOF' | sudo tee /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 5w
findtime = 15m
maxretry = 3
backend = systemd
banaction = ufw
banaction_allports = ufw
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
mode = aggressive
port = ssh
logpath = %(sshd_log)s
backend = systemd
EOF

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed:     0
`- Actions
   |- Currently banned: 0
   `- Total banned:     0

In der dritten Verteidigungsschicht härten wir den TCP/IP-Stack des Linux-Kernels direkt über /etc/sysctl.d/99-netcup-security.conf ab. Mit net.ipv4.tcp_syncookies = 1 schützt sich der Kernel vor TCP-SYN-Flood-Angriffen: Sobald die SYN-Backlog-Warteschlange voll läuft, lagert der Kernel den Verbindungszustand kryptografisch signiert in die Initial Sequence Number (ISN) des SYN-ACK-Pakets aus, ohne vor Abschluss des Handshakes Kernel-RAM zu verbrauchen. Ergänzend sorgt net.ipv4.tcp_rfc1337 = 1 für Schutz vor TIME_WAIT-Assassination-Attacken, während rp_filter = 1 (Strict Reverse Path Filtering) Pakete mit gefälschten Quell-IPs verwirft.

Darüber hinaus deaktivieren wir sowohl für IPv4 als auch für IPv6 das Akzeptieren und Versenden von ICMP-Redirects (accept_redirects = 0, send_redirects = 0) sowie Source-Routed-Pakete (accept_source_route = 0). Damit kann kein kompromittierter Nachbarknoten im selben Subnetz Ihren Gast-Kernel durch manipulierte ICMP-Redirect-Nachrichten dazu bringen, ausgehenden Datenverkehr über ein fremdes Gateway umzuleiten.

Auf Betriebssystem- und Speicherebene verhindern kernel.kptr_restrict = 2 und kernel.dmesg_restrict = 1, dass ein unprivilegierter Prozess (z. B. ein kompromittierter Web-Container) Kernel-Speicheradressen aus /proc/kallsyms oder dem Kernel-Ringpuffer auslesen kann, um KASLR (Kernel Address Space Layout Randomization) zu umgehen. Mit kernel.yama.ptrace_scope = 1 unterbinden wir zudem, dass ein Prozess mittels ptrace (gdb, strace) den Arbeitsspeicher anderer Prozesse desselben Benutzers ausliest, während fs.protected_hardlinks = 1 und fs.protected_symlinks = 1 klassische Privilegieneskalationen über manipulierte Symlinks in /tmp abwehren:

cat << 'EOF' | sudo tee /etc/sysctl.d/99-netcup-security.conf
# Schutz vor TCP-SYN-Floods & IP-Spoofing
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Annahme von ICMP-Redirects & Source-Routing deaktivieren (IPv4 & IPv6)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Kernel-Pointer-, dmesg- & ptrace-Absicherung
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.yama.ptrace_scope = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF

sudo sysctl --system

* Applying /etc/sysctl.d/99-netcup-security.conf ...

Selbst die beste Firewall hilft nicht, wenn ein öffentlich erreichbarer Dienst eine bekannte Sicherheitslücke (CVE) aufweist. Wenn das Ubuntu- oder Debian-Sicherheitsteam einen kritischen Patch für libssl3, libc6 (glibc), expat oder openssh-server veröffentlicht, lädt unattended-upgrades das aktualisierte .deb-Paket automatisch herunter und ersetzt die Bibliotheksdatei auf der NVMe-SSD.

Dabei übersehen viele Administratoren jedoch ein entscheidendes Detail des Linux-Speichermanagements: Solange ein bereits laufender Daemon wie nginx, postfix, php-fpm oder postgresql nicht neu gestartet wird, behält er die alte, ungepatchte Version der Shared Library (.so) über gelöschte Inodes (DEL-Mapping in /proc/<pid>/maps) weiterhin aktiv im Arbeitsspeicher! Ihr Server glaubt laut dpkg -l, er sei gepatcht, führt aber im RAM nach wie vor den verwundbaren Code aus.

Das Werkzeug needrestart schließt genau diese Lücke: Nach jedem apt- oder unattended-upgrades-Lauf scannt needrestart sämtliche Prozess-Speicherabbilder auf veraltete Shared-Library-Mappings. Durch die Konfiguration $nrconf{restart} = 'a'; in /etc/needrestart/conf.d/99-netcup-auto.conf startet needrestart betroffene Systemd-Dienste vollautomatisch neu, ohne auf eine interaktive Eingabe zu warten. Für Compliance-Anforderungen können Sie dieses Setup optional um auditd ergänzen (sudo apt install -y auditd), um Schreibzugriffe auf /etc/passwd, /etc/shadow und /etc/ssh/sshd_config.d/ revisionssicher aufzuzeichnen:

sudo apt install -y unattended-upgrades needrestart

# needrestart so konfigurieren, dass Dienste nach Shared-Library-Updates automatisch neu starten
sudo mkdir -p /etc/needrestart/conf.d
cat << 'EOF' | sudo tee /etc/needrestart/conf.d/99-netcup-auto.conf
# Dienste automatisch ('a') statt nach interaktiver Rückfrage ('i') neu starten
$nrconf{restart} = 'a';
EOF

# Unattended-Upgrades per Dry-Run überprüfen
sudo unattended-upgrade --dry-run --debug | tail -n 10