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

Wer einen VPS bei netcup betreibt, bekommt seit Generation 12 eine kostenlose, vorgelagerte Cloud-Firewall im Server Control Panel (SCP) mitgeliefert. Diese Firewall arbeitet auf Netzwerkebene – noch bevor Pakete den eigenen Server überhaupt erreichen. Das klingt praktisch, bringt aber einige Eigenheiten mit sich: die automatische Umschaltung auf DROP, sobald die erste eigene Regel gesetzt wird, oder die Notwendigkeit expliziter UDP-Regeln in beide Richtungen. Diese Anleitung richtet sich an KMU-Admins und erfahrene Selfhoster, die verstehen möchten, wie die SCP-Firewall intern funktioniert, wie man Policies sauber anlegt und warum eine zusätzliche Firewall auf dem Server trotzdem Pflicht bleibt.

Voraussetzungen

• netcup VPS ab Generation 12 (VPS x86, VPS ARM, Root-Server oder vGPU-Server)
• Zugang zum netcup Server Control Panel (SCP) unter servercontrolpanel.de
• Linux-Server mit Ubuntu 20.04/22.04/24.04 oder Debian 11/12 (für die ufw-Befehle)
• Bestehende SSH-Verbindung zum Server sowie ein Terminal-Client
• Optional: netcup API-Key für automatisierte Policy-Verwaltung

Schritt 1: Wie die SCP-Firewall intern funktioniert

Bevor du die erste Policy anlegst, lohnt es sich, das Grundprinzip zu verstehen – sonst läufst du direkt in die häufigste Falle.

Die SCP-Firewall sitzt am Netzwerk-Edge von netcup, also vor dem Hypervisor. Pakete, die die Firewall verwirft, erreichen den VPS-Kernel gar nicht erst. Das spart CPU-Last bei Scans und DDoS-Angriffen, weil der Traffic nie auf dem Server ankommt. Auf dem VPS läuft trotzdem ein eigener Kernel-Netfilter-Stack (ufw/iptables/nftables) – der filtert dann, was die SCP-Firewall durchgelassen hat.

Zwei Konzepte musst du verstanden haben, bevor du Regeln anlegt:

• Stateful TCP: Die SCP-Firewall merkt sich etablierte TCP-Verbindungen. Wenn du also eine INGRESS-Regel für Port 443 setzt, werden die TCP-Antwortpakete des Servers automatisch durchgelassen – ohne eigene EGRESS-Regel.
• Stateless UDP: Bei UDP gibt es kein Connection-Tracking. Für jeden UDP-Dienst (z.B. DNS-Abfragen oder NTP) brauchst du sowohl eine EGRESS-Regel (Anfrage geht raus) als auch eine INGRESS-Regel (Antwort kommt rein, erkennbar am Source-Port des DNS-Resolvers).

Und die wichtigste Eigenschaft: Die implizite Default-Regel steht initial auf „ACCEPT ANY". Sobald du eine einzige eigene Regel für INGRESS oder EGRESS erstellst, wechselt die implizite Regel dieser Richtung automatisch auf DROP. Das bedeutet: Alle Ports, die du nicht explizit freigegeben hast, sind danach gesperrt. Wer vergisst, SSH in der ersten Regel einzutragen, verliert die Verbindung zum Server.

Schritt 2: Policy im SCP anlegen

Eine Policy ist ein benanntes Regelset, das du unabhängig vom Server erstellen und dann einem oder mehreren Servern zuweisen kannst. Du kannst also eine „Basis-Webserver"-Policy bauen und sie auf mehrere VPS gleichzeitig anwenden.

1. Melde dich im SCP an und navigiere zu Firewall Policies im linken Menü.
2. Klicke auf „Create Firewall Policy".
3. Vergib einen aussagekräftigen Namen, z.B. basis-schutz-webserver, und optional eine Beschreibung.
4. Bestätige mit „Create".

Die neue Policy ist zunächst leer. Solange keine eigenen Regeln existieren, gilt die implizite ACCEPT-ANY-Regel – alle Ports sind offen. Im nächsten Schritt fügst du gezielt Regeln hinzu.

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

Klicke innerhalb der Policy auf „Add Rule". Jede Regel hat folgende Parameter:

Parameter	Mögliche Werte	Pflicht	Hinweis
Direction	INGRESS / EGRESS	Ja	INGRESS = eingehend, EGRESS = ausgehend
Protocol	TCP / UDP	Ja	ICMP nicht direkt konfigurierbar
Action	ACCEPT / DROP	Ja	REJECT nicht verfügbar – nur stilles Verwerfen
Source IP/Netz	IP oder CIDR (z.B. 0.0.0.0/0)	Nein	Leer = beliebig; max. 100 IPs pro Regel
Source Port	Einzeln (22), Bereich (1000–11000)	Nein	Leer = beliebig
Destination IP	IP oder CIDR	Nein	Leer = beliebig
Destination Port	Einzeln (443), Bereich, Liste (80,443)	Nein	Leer = beliebig

Lege für einen typischen Webserver folgende Regeln an – in genau dieser Reihenfolge (engere Regeln zuerst, da First-Match-Wins gilt):

# 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

# EGRESS UDP ACCEPT – DNS-Anfragen raus (stateless!)
Direction: EGRESS | Protocol: UDP | Action: ACCEPT
Source: (leer) | Src-Port: (leer) | Dst-Port: 53

# INGRESS UDP ACCEPT – DNS-Antworten rein (Src-Port 53!)
Direction: INGRESS | Protocol: UDP | Action: ACCEPT
Source: 0.0.0.0/0 | Src-Port: 53 | Dst-Port: (leer)

# Hinweis: TCP-Antworten auf HTTP/HTTPS/SSH brauchen
# KEINE eigene EGRESS-Regel – TCP ist stateful!

Verifizieren: Nachdem du alle Regeln gespeichert hast, sollte die Policy-Übersicht die Regeln in der richtigen Reihenfolge anzeigen. Prüfe, ob die implizite Regel jetzt „DROP (implicit)" lautet – das bestätigt, dass deine eigenen Regeln aktiv sind und alle nicht genannten Ports gesperrt werden.

Schritt 4: Policy dem Server zuweisen

Eine Policy hat erst dann Wirkung, wenn sie einem Server zugewiesen ist. Vergessen viele – und wundern sich, warum die Firewall scheinbar nichts tut.

1. Wechsle im SCP zur Server-Übersicht und wähle den gewünschten VPS aus.
2. Klicke auf den Reiter „Firewall".
3. Wähle „Edit Policies".
4. Ziehe die gewünschte Policy per Drag-and-Drop von der linken Spalte (verfügbare Policies) in die rechte Spalte (zugewiesene Policies).
5. Klicke auf „Apply" und anschließend auf „Save".

Änderungen greifen sofort – kein Server-Neustart nötig. Bereits bestehende TCP-Verbindungen (z.B. deine aktuelle SSH-Session) bleiben dabei aktiv und werden nicht neu geprüft. Erst neue Verbindungsversuche unterliegen den geänderten Regeln.

Verifizieren: Öffne im SCP den Firewall-Reiter des Servers. Dort sollte die Policy jetzt als „aktiv" aufgeführt sein. Teste 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.

Schritt 5: ufw auf dem VPS einrichten

Die SCP-Firewall ist nicht genug allein – und das ist keine Meinung, sondern eine offizielle Empfehlung von netcup. Die SCP-Firewall filtert nur öffentlichen Internet-Traffic. Kommunikation zwischen eigenen Servern im selben vLAN läuft komplett an ihr vorbei. Nur ufw (oder nftables) auf dem Kernel des VPS erfasst diesen internen Traffic.

Außerdem: Wenn die SCP-Firewall durch eine Fehlkonfiguration deaktiviert wird oder ein Port versehentlich offenbleibt, ist ufw die letzte Verteidigungslinie. Defense-in-depth bedeutet genau das: mehrere unabhängige Schichten, die sich gegenseitig absichern.

Installiere und konfiguriere ufw auf Ubuntu/Debian so:

# 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 – VOR dem Aktivieren eintragen!
sudo ufw allow in 22/tcp
sudo ufw allow out 22/tcp comment 'SSH outbound established'

# 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

# SSH-Brute-Force-Schutz (Rate Limiting)
sudo ufw limit 22/tcp

# Firewall aktivieren
sudo ufw enable

# Status und Regeln prüfen
sudo ufw status verbose

Verifizieren: Der Befehl sudo ufw status verbose sollte alle Regeln auflisten und „Status: active" anzeigen. Teste die SSH-Verbindung aus einer neuen Terminal-Session, bevor du die alte schließt – so stellst du sicher, dass du dich nicht ausgesperrt hast.

Schritt 6: SSH-Härtung in sshd_config

Die Firewall-Konfiguration ist sinnlos, wenn SSH selbst unsicher konfiguriert ist. Deaktiviere Passwort-Logins und Root-Zugriff:

# /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 sshd neu starten
sudo systemctl restart sshd

Wer den SSH-Port wechseln möchte, muss die Reihenfolge strikt einhalten: Erst den neuen Port in der SCP-Firewall und in ufw freigeben, dann sshd neu starten, die neue Verbindung testen – und danach erst Port 22 in beiden Firewalls sperren. Jede Abweichung von dieser Reihenfolge kann den Server unerreichbar machen.

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

Merkmal	netcup SCP-Firewall	ufw (Linux OS-Firewall)
Ebene	Netzwerk (vorgelagert, vor dem VPS)	Host (Kernel/netfilter auf dem VPS)
Kosten	Kostenlos	Kostenlos (im OS enthalten)
Stateful TCP	Ja	Ja
Stateless UDP	Ja – explizite Regeln für beide Richtungen	Ja – explizite Regeln für beide Richtungen
Schützt VPS-CPU vor Scan-Last	Ja – Traffic kommt nie an	Nein – Pakete erreichen den VPS-Kernel
vLAN-internen Traffic filtern	Nein	Ja
Verwaltung	SCP-GUI + API	CLI (sudo ufw ...) + Konfigurationsdateien
Ab Generation verfügbar	Ab Gen. 12	Alle Linux-Server
REJECT-Aktion	Nicht verfügbar (nur DROP)	Verfügbar (ufw reject)
Log-Sichtbarkeit	Über SCP (begrenzt)	/var/log/ufw.log (vollständig)

Der Datenweg bei eingehendem Traffic lautet stets: Internet → SCP-Firewall → ufw → Dienst. Wird ein Port in der SCP-Firewall geblockt, kommt er nie bei ufw an. Beide müssen einen Port freigeben, damit ein Dienst erreichbar ist. Das ist auch die häufigste Debugging-Falle: Ein Port ist in der SCP-Firewall offen, aber ufw sperrt ihn – oder umgekehrt. Immer beide Ebenen prüfen.

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

Sobald die erste eigene INGRESS-Regel angelegt wird, wechselt die implizite Regel für INGRESS automatisch auf DROP. Wenn SSH (Port 22) in diesem Moment nicht als ACCEPT-Regel eingetragen ist, ist der Server per SSH nicht mehr erreichbar. Lösung: Im SCP gibt es eine „Restore Default Policies"-Funktion, die alle eigenen Regeln entfernt und die implizite ACCEPT-ANY-Regel wiederherstellt. Danach die Regeln mit SSH an erster Stelle neu anlegen.

UDP-DNS kommt nicht durch

Symptom: Der Server kann keine Hostnamen auflösen, obwohl EGRESS UDP Port 53 freigegeben ist. Ursache: UDP ist stateless – die Antwort des DNS-Resolvers wird nicht automatisch zugelassen. Lösung: Zusätzlich eine INGRESS-Regel für UDP mit Source-Port 53 anlegen. Erst beide Regeln zusammen ergeben funktionierende DNS-Auflösung.

Policy angelegt, aber keine Wirkung

Wer eine Policy erstellt und Regeln hinzufügt, aber vergisst, die Policy dem Server zuzuweisen (Edit Policies → Drag & Drop → Save), hat effektiv keine Firewall aktiv. Immer im SCP-Firewall-Reiter des Servers prüfen, ob die Policy dort als zugewiesen aufgeführt ist.

SSH-Port wechseln und ausgesperrt

Reihenfolge einhalten: Erst neuen Port in SCP-Firewall und ufw freigeben, dann sshd neustarten, neue Verbindung erfolgreich testen – danach erst Port 22 in beiden Systemen sperren. Nie Port 22 sperren, bevor die neue Verbindung bestätigt wurde.

Mail-Block-Policy entfernt, kein Ersatz gesetzt

Die Standard-Policy „netcup Mail block" sperrt ausgehenden SMTP-Traffic auf Port 25 zum Schutz vor Spam. Wer sie entfernt, ohne eine eigene Port-25-Regel zu setzen, öffnet den Server als potenzielles Spam-Relay. Nur entfernen, wenn bewusst ein eigener Mailserver betrieben wird und eine alternative Absicherung vorhanden ist.

Doppelte Freigabe vergessen

Ein Port muss sowohl in der SCP-Firewall als auch in ufw freigegeben sein. „SCP offen, ufw sperrt" oder „ufw offen, SCP sperrt" – beide Varianten führen dazu, dass der Dienst nicht erreichbar ist. Bei Debugging-Problemen immer zuerst sudo ufw status verbose auf dem Server prüfen und gleichzeitig die Policy im SCP kontrollieren.

vLAN-Traffic nicht gefiltert

Die SCP-Firewall filtert ausschließlich öffentlichen Internet-Traffic auf dem öffentlichen Netzwerkinterface. Kommunikation zwischen eigenen Servern im selben netcup Cloud-vLAN geht komplett an der SCP-Firewall vorbei. Für diesen Traffic ist ufw/nftables auf dem jeweiligen VPS zuständig.

Häufige Fragen

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

Ja, unbedingt. Die SCP-Firewall schützt auf Netzwerkebene, filtert aber keinen internen vLAN-Traffic und ersetzt nicht die feinkörnige Host-Kontrolle. netcup empfiehlt ausdrücklich beide Ebenen zu betreiben. Außerdem greift ufw auch bei Fehlkonfigurationen der SCP-Firewall als Rückfallebene – klassische defense-in-depth.

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

Weil UDP stateless ist und die Antwort aktiv erlaubt werden muss. Zusätzlich zur EGRESS-Regel (Anfrage raus) braucht es eine INGRESS-Regel mit Source-Port 53 (Antwort rein). TCP ist stateful – dort genügt eine Richtung. Dasselbe gilt für NTP (UDP Port 123).

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

Die offizielle Dokumentation behandelt primär IPv4-CIDR-Notation. IPv6-Unterstützung sollte im SCP direkt geprüft werden. ufw unterstützt IPv6 nativ – stelle sicher, dass in /etc/default/ufw der Wert IPV6=yes gesetzt ist.

Wie verhindere ich, mich beim Einrichten auszusperren?

Vor dem Erstellen der ersten Regel sicherstellen, dass SSH (Port 22 oder der Custom-Port) als INGRESS TCP ACCEPT-Regel bereits eingetragen ist. Erst danach weitere Regeln hinzufügen. Als Notfalloption gibt es im SCP die Funktion „Restore Default Policies", die alle eigenen Regeln entfernt und wieder auf ACCEPT ANY zurücksetzt.

Kann ich die SCP-Firewall per API automatisieren?

Ja. netcup bietet eine vollständige API für die Firewall-Verwaltung: Policies erstellen, Regeln hinzufügen, Servern zuweisen – alles programmatisch möglich. Die Dokumentation findet sich im netcup Helpcenter unter dem Bereich SCP Webservice.

Was passiert, wenn ich die Firewall im SCP deaktiviere?

Die konfigurierten Policies und Regeln bleiben vollständig erhalten, werden aber nicht mehr angewendet. Aller Traffic ist dann ungefiltert auf Netzwerkebene – ufw auf dem VPS arbeitet jedoch weiterhin als zweite Schicht.

Fazit

Die netcup SCP-Firewall ist ein mächtiges und kostenloses Werkzeug, das den VPS auf Netzwerkebene schützt – aber sie hat klare Eigenheiten, die man verstanden haben muss. Die automatische Umschaltung auf DROP beim Anlegen der ersten Regel, das stateless Verhalten von UDP und die Notwendigkeit, die Policy explizit dem Server zuzuweisen, sind die drei häufigsten Stolpersteine. Wer diese kennt, kann sauber arbeiten.

Noch wichtiger: Die SCP-Firewall ersetzt ufw nicht. Beide Ebenen schützen unterschiedliche Angriffsvektoren – die Cloud-Firewall nimmt die Last öffentlicher Scans vom Server fern, ufw schützt vor internem vLAN-Traffic und bildet die letzte Rückfallebene. Zusammen ergibt sich ein solides, mehrschichtiges Sicherheitskonzept, das für KMU-Server vollkommen ausreicht.

Weiterführende Anleitungen und Quellen

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