netcup SCP-Firewall einrichten: Policies, Regeln und Zusammenspiel mit ufw

netcup liefert zu jedem VPS eine kostenlose, vorgelagerte Cloud-Firewall im Server Control Panel (SCP), die auf Netzwerkebene filtert, bevor Pakete den Server erreichen. Eigenheiten sind die automatische Umschaltung auf DROP ab der ersten eigenen Regel und die nötigen UDP-Regeln in beide Richtungen bei gefiltertem ausgehendem Verkehr. Diese Anleitung zeigt, wie die SCP-Firewall arbeitet, wie Sie Policies anlegen und warum eine Firewall auf dem Server trotzdem Pflicht bleibt.

Voraussetzungen

1. netcup VPS oder Root-Server ab Generation 9 (laut netcup-Helpcenter; ältere werden schrittweise nachgerüstet)
2. Zugang zum netcup Server Control Panel (SCP) unter servercontrolpanel.de
3. Ubuntu 22.04/24.04 oder Debian 12/13 (für ufw)
4. SSH-Zugang zum Server
5. Optional: REST-API des SCP für automatisierte Policy-Verwaltung

Schritt 1: Wie die SCP-Firewall intern funktioniert

Die SCP-Firewall sitzt am Netzwerk-Edge vor dem Hypervisor. Verworfene Pakete erreichen den VPS-Kernel nie, was CPU-Last bei Scans und DDoS-Angriffen spart. ufw/iptables/nftables auf dem VPS filtern danach, was durchgelassen wurde.

Zwei Konzepte:

1. Stateful TCP: Etablierte TCP-Verbindungen werden gemerkt; zu einer INGRESS-Regel für Port 443 kommen die Antworten ohne EGRESS-Regel durch.
2. Stateless UDP: Kein Connection-Tracking. Wer ausgehend filtert, braucht für UDP-Dienste wie NTP eine EGRESS-Regel (Anfrage) und eine INGRESS-Regel mit passendem Source-Port (Antwort). DNS an die netcup-Resolver erlauben die nicht editierbaren Standardregeln.

Entscheidend: Die implizite Default-Regel steht anfangs auf „ACCEPT ANY“. Sobald eine einzige eigene Regel für INGRESS oder EGRESS existiert, wechselt sie für diese Richtung auf DROP. Schon eine EGRESS-Regel blockiert also allen anderen ausgehenden Verkehr (etwa Paket-Updates), und ohne SSH in der ersten INGRESS-Regel verlieren Sie die Verbindung.

Verifizieren: Im SCP unter Firewall des Servers sind die aktuell zugewiesenen Policies sichtbar. Bei einem neu bestellten Server ist dort nur die Standard-Policy inklusive netcup Mail block eingetragen.

Schritt 2: Policy im SCP anlegen

Eine Policy ist ein benanntes Regelset, das Sie einem oder mehreren Servern zuweisen, etwa „Basis-Webserver“ für mehrere VPS.

1. Im SCP einen Server wählen und oben Firewall Policies öffnen.
2. Klicken Sie auf „Create Firewall Policy“.
3. Namen vergeben, z. B. basis-schutz-webserver, optional eine Beschreibung.
4. Bestätigen Sie das Anlegen.

Solange die Policy leer ist, gilt ACCEPT ANY.

Verifizieren: Die neue Policy erscheint in der Liste unter Firewall Policies, noch ohne Regeln.

Schritt 3: Regeln hinzufügen (Webserver-Beispiel)

Klicken Sie in der Policy auf „Add Rule“. Parameter je Regel:

Regeln für einen typischen Webserver. Sie werden nach Priorität abgearbeitet, die erste passende gilt; engere Regeln gehören nach oben:

# Reihenfolge im SCP per Drag-and-Drop festlegen
# Reihenfolge ist entscheidend: erste passende Regel gewinnt

# INGRESS TCP ACCEPT – SSH
Direction: INGRESS | Protocol: TCP | Action: ACCEPT
Source: 0.0.0.0/0 | Src-Port: (leer) | Dst-Port: 22

# INGRESS TCP ACCEPT – HTTP
Direction: INGRESS | Protocol: TCP | Action: ACCEPT
Source: 0.0.0.0/0 | Src-Port: (leer) | Dst-Port: 80

# INGRESS TCP ACCEPT – HTTPS
Direction: INGRESS | Protocol: TCP | Action: ACCEPT
Source: 0.0.0.0/0 | Src-Port: (leer) | Dst-Port: 443

# Keine EGRESS-Regeln anlegen: Ausgehend bleibt dann ACCEPT ANY.
# TCP-Antworten auf HTTP/HTTPS/SSH brauchen keine eigene
# EGRESS-Regel, TCP ist stateful.

Wer auch ausgehend filtert, muss laut netcup mindestens EGRESS TCP 80/443 (Updates), EGRESS UDP 123 plus INGRESS UDP mit Source-Port 123 (Zeit) und weitere benötigte Ports erlauben. netcup empfiehlt nur INGRESS-Regeln.

Verifizieren: Nach dem Speichern zeigt die Policy die drei Regeln in der gewünschten Reihenfolge, und die implizite INGRESS-Regel steht auf DROP.

Schritt 4: Policy dem Server zuweisen

Erst die Zuweisung an einen Server macht die Policy wirksam; das wird oft vergessen.

1. Server im SCP wählen.
2. Menüpunkt „Firewall“ öffnen.
3. „Edit Policies“ klicken.
4. Policy von der linken (verfügbar) in die rechte Spalte (zugewiesen) ziehen.
5. „Apply“ und „Save“.

Änderungen greifen sofort ohne Neustart; bestehende Verbindungen (z. B. die laufende SSH-Sitzung) bleiben aktiv.

Verifizieren: Unter Firewall des Servers steht die Policy jetzt bei den zugewiesenen Policies. Testen Sie von einem externen Rechner aus, ob SSH (Port 22) erreichbar ist und ob ein nicht freigegebener Port (z.B. 8080) einen Timeout liefert (kein RST, da DROP das Paket still verwirft), zum Beispiel mit nc -vz -w 5 SERVER-IP 8080.

Schritt 5: ufw auf dem VPS einrichten

netcup empfiehlt ausdrücklich eine zusätzliche Host-Firewall: Die SCP-Firewall filtert nur öffentlichen Internet-Traffic, Verkehr zwischen eigenen Servern im selben vLAN läuft an ihr vorbei. Nur ufw (oder nftables) auf dem VPS erfasst ihn.

Zudem ist ufw die letzte Verteidigungslinie, falls die SCP-Firewall durch Fehlkonfiguration aus ist oder ein Port offen bleibt (defense-in-depth).

Installation und Konfiguration auf Ubuntu/Debian:

# ufw installieren (meist schon vorhanden)
sudo apt install ufw

# Standardmäßig alles sperren
sudo ufw default deny incoming
sudo ufw default deny outgoing

# SSH erlauben (mit Rate Limiting gegen Brute Force) – VOR dem Aktivieren!
sudo ufw limit 22/tcp

# Ausgehendes SSH, z. B. für git oder Backups per SSH
sudo ufw allow out 22/tcp

# HTTP und HTTPS eingehend
sudo ufw allow in 80/tcp
sudo ufw allow in 443/tcp

# DNS-Auflösung ausgehend (UDP und TCP)
sudo ufw allow out 53/udp
sudo ufw allow out 53/tcp

# NTP für Zeitsynchronisation
sudo ufw allow out 123/udp

# APT-Updates (HTTP/HTTPS ausgehend)
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp

# Firewall aktivieren
sudo ufw enable

# Status und Regeln prüfen
sudo ufw status verbose

Die Regel ufw limit ersetzt ein zusätzliches allow für Port 22: ufw wertet die erste passende Regel aus, ein vorangestelltes allow würde das Rate Limiting aushebeln.

Verifizieren: Der Befehl sudo ufw status verbose listet alle Regeln auf und zeigt „Status: active“ sowie Default: deny (incoming), deny (outgoing). Testen Sie die SSH-Verbindung aus einer neuen Terminal-Sitzung, bevor Sie die alte schließen, und prüfen Sie mit sudo apt update, dass ausgehende Verbindungen funktionieren.

Schritt 6: SSH-Härtung in sshd_config

Passwort-Logins und Root-Zugriff werden deaktiviert:

# /etc/ssh/sshd_config – relevante Zeilen anpassen
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

# Optional: SSH auf eigenen Port verschieben
# Dann auch in SCP-Firewall UND ufw den neuen Port freigeben,
# BEVOR Port 22 gesperrt wird!
# Port 2222
# Nach Änderungen Syntax prüfen und SSH neu starten
sudo sshd -t
sudo systemctl restart ssh

Für einen SSH-Portwechsel gilt strikt: neuen Port in SCP-Firewall und ufw freigeben, sshd neu starten, neue Verbindung testen, erst dann Port 22 in beiden Firewalls sperren. Sonst kann der Server unerreichbar werden. Unter Ubuntu 24.04 (Socket-Aktivierung) greift der Portwechsel erst nach sudo systemctl daemon-reload und sudo systemctl restart ssh.socket.

Verifizieren: sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin' zeigt passwordauthentication no und permitrootlogin no, und ein Login-Versuch mit ssh -o PubkeyAuthentication=no BENUTZER@SERVER-IP wird abgewiesen.

Wer sich mit SSH-Keys noch nicht beschäftigt hat, findet eine detaillierte Anleitung unter SSH-Key-Authentifizierung einrichten.

SCP-Firewall vs. ufw: Vergleich beider Ebenen

Eingehender Traffic läuft stets Internet → SCP-Firewall → ufw → Dienst. Ein Dienst ist nur erreichbar, wenn beide Ebenen den Port freigeben; prüfen Sie bei Problemen immer beide.

Für den grundlegenden Einstieg in das Absichern eines VPS mit ufw und fail2ban empfiehlt sich die Anleitung VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban.

Troubleshooting / Typische Fehler

Implicit-Drop-Falle: SSH gesperrt nach erster Regel

Ist SSH (Port 22) bei der ersten INGRESS-Regel nicht als ACCEPT eingetragen, ist der Server per SSH nicht mehr erreichbar. Lösung: Im SCP (per Browser weiter erreichbar) unter Firewall die Policy per Edit Policies entfernen oder Firewall active deaktivieren und speichern, dann die Regeln mit SSH an erster Stelle neu anlegen. „Restore Default Policies“ hilft nicht: Es stellt nur die Standard-Policies wieder her und lässt eigene unverändert.

UDP-DNS kommt nicht durch

Symptom: Nach EGRESS-Regeln sind fremde DNS-Resolver nicht mehr erreichbar, weil ausgehend alles auf DROP steht und UDP-Antworten nicht automatisch zugelassen werden (netcup-Resolver bleiben über die Standardregeln erreichbar). Lösung: auf EGRESS-Regeln verzichten oder EGRESS UDP Ziel-Port 53 plus INGRESS UDP Source-Port 53 anlegen.

Policy angelegt, aber keine Wirkung

Ohne Zuweisung an den Server (Edit Policies → Drag & Drop → Save) ist keine Firewall aktiv. Prüfen Sie im Firewall-Reiter des Servers, ob die Policy zugewiesen ist.

SSH-Port wechseln und ausgesperrt

Reihenfolge aus Schritt 6 einhalten; Port 22 nie sperren, bevor die neue Verbindung bestätigt ist.

Mail-Block-Policy entfernt, kein Ersatz gesetzt

Die Standard-Policy „netcup Mail block“ sperrt SMTP gegen Spam. Entfernen Sie sie nur für einen sauber konfigurierten Mailserver (kein offenes Relay, SPF, DKIM, Reverse-DNS).

Doppelte Freigabe vergessen

Ein Port muss in SCP-Firewall und ufw freigegeben sein. Prüfen Sie sudo ufw status verbose auf dem Server und die Policy im SCP.

vLAN-Traffic nicht gefiltert

Verkehr zwischen eigenen Servern im selben netcup Cloud-vLAN umgeht die SCP-Firewall; dafür ist ufw/nftables auf dem VPS zuständig.

Häufige Fragen

Brauche ich ufw noch, wenn die SCP-Firewall aktiv ist?

Ja. Die SCP-Firewall filtert keinen vLAN-Traffic und ersetzt keine Host-Kontrolle; netcup empfiehlt beide Ebenen (Schritt 5).

Warum kommt mein DNS nicht durch, obwohl EGRESS UDP Port 53 erlaubt ist?

UDP-Antworten werden nicht automatisch zugelassen: Zusätzlich zur EGRESS-Regel braucht es INGRESS mit Source-Port 53. Gleiches gilt für NTP (UDP 123). Einfacher: keine EGRESS-Regeln, wie netcup empfiehlt.

Gilt die SCP-Firewall für IPv4 und IPv6?

Ja. Die Helpcenter-Beispiele enthalten IPv4 und IPv6 in derselben Regel (etwa 198.51.100.10/32 und 2001:db8::cafe/128); eine leere Quelle gilt für beide. Für ufw sollte in /etc/default/ufw IPV6=yes stehen (Standard).

Wie verhindere ich, mich beim Einrichten auszusperren?

SSH (Port 22 oder eigener Port) als erste INGRESS-TCP-ACCEPT-Regel eintragen. Notfall: Policy im SCP entfernen oder Firewall active deaktivieren.

Kann ich die SCP-Firewall per API automatisieren?

netcup bietet für das SCP eine REST-API. Welche Firewall-Funktionen sie abdeckt, beschreibt das netcup Helpcenter im Bereich REST API (Server Control Panel).

Was passiert, wenn ich die Firewall im SCP deaktiviere?

Policies und Regeln bleiben erhalten, werden aber nicht angewendet. ufw auf dem VPS filtert weiter.

Fazit

Die netcup SCP-Firewall schützt den VPS kostenlos auf Netzwerkebene. Die drei häufigsten Stolpersteine: DROP ab der ersten eigenen Regel, stateless UDP und die vergessene Zuweisung der Policy an den Server.

Sie ersetzt ufw nicht: Die Cloud-Firewall hält öffentliche Scans vom Server fern, ufw deckt vLAN-Traffic ab und ist die Rückfallebene. Zusammen mit SSH-Keys und Updates ergibt das ein mehrschichtiges Sicherheitskonzept.

Weiterführende Anleitungen und Quellen

1. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban (Hetzner/Netcup)
2. SSH-Keys im netcup SCP speichern und bei Image-Installationen automatisch einbinden
3. Das netcup Server Control Panel (SCP) erklärt: Alle Funktionen im Überblick
4. SSH-Hardening Deep-Dive: sshd_config, Match-Blöcke und ssh-audit für KMU-Server
5. netcup Helpcenter: Firewall (offizielle Dokumentation)
6. netcup Blog: New firewall for netcup vServer
7. netcup Community Tutorial: First steps to protect your Linux server