netcup-Firewall im SCP einrichten (mit stateless-UDP-Kniff)

netcup bringt eine Firewall schon vor deinem Server mit – im Server Control Panel,
noch bevor ein Paket das Betriebssystem erreicht. Richtig gebaut ist sie ein starker
Schutzschild. Es gibt dabei aber einen Kniff, an dem viele scheitern: Die netcup-Firewall
ist bei UDP zustandslos. Dieses Tutorial zeigt dir eine saubere, wiederverwendbare
Firewall – und warum DNS und NTP sonst plötzlich klemmen.

Was bauen wir?

Wir bauen im netcup SCP eine Netzwerk-Firewall aus komponierbaren Policy-Templates:
ein Basis-Template (das jeder Server braucht), eins für SSH und eins für
Web (HTTP/HTTPS). Diese Bausteine weist du deinem Server nach Bedarf zu – ein
Webserver bekommt Basis + SSH + Web, ein Server ohne Website nur Basis + SSH. Am Ende ist
eingehend alles gesperrt außer dem, was du bewusst erlaubst.

Ein netcup-spezifisches Detail macht dabei den Unterschied: Bei UDP arbeitet die Firewall
zustandslos – weshalb Dienste wie DNS und NTP eine eigene Eingangs-Regel brauchen, sonst
klemmen sie plötzlich. Warum das so ist und wie das Basis-Template es löst, zeigt Schritt 2.

ℹ️ Netzwerk-Firewall ≠ Host-Firewall

Die netcup-Firewall arbeitet im Netzwerk vor dem Server und ersetzt nicht die
Firewall auf dem Server selbst (UFW). Beide
zusammen sind „Defense in Depth": Fällt eine Schicht aus oder ist falsch konfiguriert,
greift die andere. Richte ruhig beide ein.

Voraussetzungen

• Ein netcup-Server, z. B. dein erster VPS.
• Deine SCP-Zugangsdaten (Kundennummer + SCP-Passwort aus der netcup-Willkommensmail – andere als dein SSH-Login).
• Klarheit über deinen SSH-Port: Standard ist 22, und beim SSH-Absichern bleibt er auch dabei. Hast du ihn anderweitig geändert, nimm deinen echten Port – sonst sperrst du dich beim Aktivieren aus.

Schritt für Schritt

Schritt 1: Firewall Policys im SCP öffnen

Melde dich im Server Control Panel an und öffne oben
den Menüpunkt Firewall Policys. Hier legst du wiederverwendbare Regelsätze („Policys")
an – unabhängig vom einzelnen Server. Erst später weist du sie zu.

Schritt 2: Das Basis-Template bauen

Klick auf Firewall Policy erstellen, vergib den Namen Serverküche Basis und lege über
Regel hinzufügen diese vier Regeln an – alle EINGEHEND und ACCEPT:

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
DNS-Antworten (stateless)	UDP	53	beliebig
NTP-Antworten (stateless)	UDP	123	beliebig
ICMP (Ping/PMTU)	ICMP	–	–
ICMPv6 (Neighbor Discovery)	ICMPv6	–	–

Zwei Dinge, die hier den Unterschied machen:

• DNS/NTP über den Src Port, nicht den Ziel-Port. Dein Server fragt DNS/NTP an (ausgehend); die Antwort kommt von Port 53 bzw. 123 zurück. Weil UDP zustandslos ist, brauchst du diese Eingangs-Regel – sonst gibt es keine Namensauflösung und keine Zeitsynchronisation, obwohl „alles andere" zu funktionieren scheint.
• ICMPv6 nie vergessen. Ohne Neighbor Discovery bricht IPv6 komplett. ICMP (v4) dazu ist für Ping und die Pfad-MTU-Erkennung sinnvoll. netcups Default-Policy „Ping allow" deckt ICMP zwar schon ab – im Basis-Template steht es bewusst nochmal drin, damit dein Fundament auch dann vollständig bleibt, wenn du die netcup-Defaults einmal entfernst.

ℹ️ Sobald eine Regel da ist, sperrt netcup den Rest automatisch

Ein abschließendes „alles sperren" musst du nicht anlegen. Ohne zugewiesene Policy
ist eingehend alles erlaubt. Sobald du dem Server aber mindestens eine eigene Policy
zuweist, schaltet netcup den Default auf „block all" – ab dann ist eingehend alles
gesperrt, was keine deiner Regeln ausdrücklich erlaubt. Die Whitelist entsteht also von
selbst; ausgehend bleibt offen.

💡 Nutzt dein Server DHCP?

netcup-VPS sind in der Regel statisch konfiguriert (iface … inet static) – dann ist
hier nichts zu tun. netcups Netz betreibt zwar einen DHCP-Server, aber weil UDP zustandslos
ist, wird die DHCP-Antwort (Quell-Port 67) von der Whitelist verworfen. Ist dein
Server ausnahmsweise per DHCP konfiguriert, ergänze im Basis-Template
EINGEHEND · UDP · ACCEPT · Src 67 (für DHCPv6 zusätzlich Src 547) – sonst verliert er
bei der nächsten Lease-Erneuerung seine IP.

Schritt 3: Kleine Bausteine für SSH und Web

Statt eines großen Regel-Monolithen legst du atomare Templates an, die du frei
kombinierst. Erstelle nach demselben Muster zwei weitere Policys:

• Serverküche SSH – eine Regel: EINGEHEND, TCP, ACCEPT, Ziel-Port 22.
• Serverküche Web – zwei Regeln: EINGEHEND, TCP, ACCEPT, Ziel-Port 80 und 443.

Der Gewinn: Die Basis-Regeln stehen nur einmal da, nicht in jeder Policy dupliziert.
Kommt später ein Dienst dazu (z. B. ein Mailserver oder WireGuard), baust du dafür ein
weiteres kleines Template und steckst es dazu – ohne die bestehenden anzufassen.

Schritt 4: Templates dem Server zuweisen

Wechsle zu Server → deinen Server → Reiter „Firewall" und klick auf Firewall Policys
editieren. Schieb aus Verfügbare Firewall Policys die passenden nach Ausgewählte:
für einen Webserver Serverküche Basis + Serverküche SSH + Serverküche Web.

Bestätige mit Übernehmen und dann Speichern. Prüfe, dass der Schalter „Firewall
aktiv" eingeschaltet ist. Die zugewiesenen Regeln erscheinen jetzt in der Liste –
zusammen mit netcups Default-Policys (dazu unten mehr).

⚠️ Nicht aussperren

Aktiviere die Firewall nur, wenn die SSH-Regel (Port 22 bzw. dein echter Port) drin
ist. Lass während der Umstellung eine zweite SSH-Sitzung offen und öffne parallel eine
neue Verbindung, um den Zugang zu testen – erst wenn die klappt, die alte Sitzung
schließen. Kommst du gar nicht mehr rein, hilft die VNC-Konsole unter Bildschirm im SCP.

Schritt 5: Fertige Templates für gängige Dienste

Genau nach dem Muster aus Schritt 3 folgen hier fertige Vorlagen für die häufigsten
Selfhosting-Dienste. Jede ist ein eigenes kleines Template, alle Regeln sind
EINGEHEND und ACCEPT. Bau nur die, die du wirklich brauchst, und steck sie wie in
Schritt 4 zu Serverküche Basis + Serverküche SSH dazu.

ℹ️ Bei UDP-Diensten: Ziel-Port, nicht Quell-Port

Für UDP-Dienste, die du selbst anbietest (VPN, TURN, eigener DNS-Server), steht der
Port im Ziel-Port (Dst) – denn hier verbinden sich Clients zu deinem Server. Das ist
das Gegenteil der DNS/NTP-Regeln aus dem Basis-Template: Dort steht der Port im
Quell-Port (Src), weil dein Server dort der fragende Client ist, dessen Antwort
zurückkommt. TCP-Antworten sind davon nicht betroffen (der Firewall-Zustand spielt nur bei
UDP keine Rolle); ausgehend ist ohnehin alles erlaubt.

Mailserver (mailcow & Co.)

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
SMTP (Mailannahme anderer Server)	TCP	–	25
Submission (STARTTLS)	TCP	–	587
Submission (implizites TLS)	TCP	–	465
IMAP (STARTTLS)	TCP	–	143
IMAPS	TCP	–	993
POP3 (STARTTLS)	TCP	–	110
POP3S	TCP	–	995
ManageSieve (Filterregeln)	TCP	–	4190

Zwei Dinge, die beim Mailserver zusätzlich dazugehören:

• Web-UI und Zertifikate: mailcow braucht 80/443 für das Webinterface und den Let's-Encrypt-Abruf – dafür einfach das Serverküche Web-Template mit zuweisen.
• Ausgehendes SMTP freischalten: Ein Mailserver muss auf Port 25 ausgehend zustellen können. netcup sperrt das per Default-Policy „netcup Mail block" – die musst du am Server entfernen (siehe „Wenn es nicht funktioniert"). Und ohne korrekten PTR-/Reverse-DNS-Eintrag landen deine Mails im Spam.

WireGuard-VPN

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
WireGuard	UDP	–	51820

51820 ist der übliche Standard – nimm den Wert aus deinem ListenPort. Nur diese eine
eingehende Regel ist nötig; die Antworten an die Clients gehen ausgehend raus.

OpenVPN

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
OpenVPN (UDP, Standard)	UDP	–	1194
OpenVPN (TCP-Fallback)	TCP	–	1194

Standard ist UDP 1194. Die TCP-Regel nur, wenn du OpenVPN bewusst über TCP betreibst
(manche legen es zusätzlich auf TCP 443, um durch restriktive fremde Netze zu kommen) –
sonst weglassen.

Zabbix-Monitoring

Hier kommt es auf die Rolle des Servers an:

Rolle	Beschreibung	Protokoll	Ziel-Port (Dst)
Überwachter Host (Zabbix-Agent)	passive Checks vom Server	TCP	10050
Zabbix-Server	Trapper (aktive Agenten/Proxies)	TCP	10051

Der Zabbix-Server braucht zusätzlich 80/443 fürs Web-Frontend (Serverküche Web).
Betreibst du aktive Checks, verbindet sich der Agent ausgehend zum Server auf 10051 –
dafür ist am Agenten-Host keine eingehende Regel nötig.

Checkmk

Rolle	Beschreibung	Protokoll	Ziel-Port (Dst)
Überwachter Host (Agent)	Agent-Controller, Pull-Modus	TCP	6556
Checkmk-Server (optional)	Agent-Receiver (Push/Registrierung)	TCP	8000
Checkmk-Server (optional)	Livestatus (verteiltes Monitoring)	TCP	6557

Im Standard-Pull-Modus holt der Checkmk-Server die Daten aktiv ab – er verbindet sich
also ausgehend zu 6556 der Agenten. Eingehend braucht deshalb nur der überwachte Host
den Port 6556. Der Checkmk-Server selbst kommt mit 80/443 (Serverküche Web) aus;
8000 und 6557 nur, wenn du Push-Modus bzw. verteiltes Monitoring nutzt.

Coturn / TURN-Server (Nextcloud Talk, Matrix)

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
STUN/TURN	TCP	–	3478
STUN/TURN	UDP	–	3478
STUN/TURN über TLS	TCP	–	5349
STUN/TURN über TLS	UDP	–	5349
Medien-Relay (Audio/Video)	UDP	–	49152–65535

Die große UDP-Relay-Range ist der Standard – über sie laufen die eigentlichen
Audio-/Video-Streams. Du kannst sie in der coturn-Konfiguration (min-port/max-port)
enger fassen und die Firewall-Regel dann auf denselben, kleineren Bereich setzen.

Eigener DNS-Server (AdGuard Home, Pi-hole, Unbound)

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
DNS-Anfragen	UDP	–	53
DNS-Anfragen (große Antworten/TCP)	TCP	–	53
DNS-over-TLS (DoT)	TCP	–	853

Achtung, das ist genau die Gegenrichtung zum Basis-Template: Dort erlaubt Src 53 die
Antworten auf deine eigenen DNS-Anfragen; hier erlaubt Dst 53 die Anfragen fremder
Clients an deinen DNS-Server. Beides existiert problemlos nebeneinander.

⚠️ Kein offener Resolver

Ein weltweit offener rekursiver DNS-Server wird für DNS-Amplification-Angriffe
missbraucht. Beschränke den Zugriff auf deine eigenen Netze (Quell-Adresse in der Regel
setzen) oder biete DNS ausschließlich verschlüsselt (DoT/DoH) für angemeldete Clients an –
öffne 53 nie „mal eben" für die ganze Welt.

Datenbank-Fernzugriff (nur im Notfall)

Beschreibung	Protokoll	Quell-Port (Src)	Ziel-Port (Dst)
PostgreSQL	TCP	–	5432
MySQL / MariaDB	TCP	–	3306

🛑 Datenbanken gehören nicht ins offene Internet

Eine direkt erreichbare Datenbank ist ein bevorzugtes Angriffsziel. Der richtige Weg
ist, den Port gar nicht zu öffnen und stattdessen über einen
WireGuard-Tunnel oder einen SSH-Tunnel
(ssh -L 5432:localhost:5432 …) zuzugreifen. Musst du den Port trotzdem freigeben, dann
nur mit einer auf deine feste Admin-IP eingeschränkten Quell-Adresse in der
netcup-Regel – niemals für alle.

Wenn es nicht funktioniert

Symptom: Nach dem Aktivieren geht keine Namensauflösung mehr (apt update hängt,
ping domain.de scheitert, aber ping 1.1.1.1 geht).

Ursache & Lösung: Die DNS-Antworten werden geblockt. Prüfe im Basis-Template die
Regel EINGEHEND UDP ACCEPT, Src-Port 53. Wichtig: Quell-Port, nicht Ziel-Port.

Symptom: Die Uhr driftet, oder TLS-Zertifikate werden wegen falscher Zeit abgelehnt.

Ursache & Lösung: Die NTP-Antworten fehlen. Ergänze EINGEHEND UDP ACCEPT, Src-Port 123.

Symptom: IPv6 funktioniert nicht mehr (v4 schon).

Ursache & Lösung: Es fehlt die ICMPv6-Regel. Ohne Neighbor Discovery kann der
Server über IPv6 nicht einmal seinen Nachbarn (Router) finden.

Symptom: Du kommst nach dem Aktivieren nicht mehr per SSH rein.

Ursache & Lösung: Die SSH-Regel fehlt oder nennt den falschen Port. Über die
VNC-Konsole (SCP → Bildschirm) kommst du trotzdem auf den Server; korrigiere die Policy
und speichere neu. Genau dagegen hilft die „zweite Sitzung offen lassen"-Regel oben.

Symptom: Der Server kann keine E-Mails versenden (Port 25 raus geht nicht).

Ursache & Lösung: Das ist kein Fehler deiner Policy, sondern netcups
Default-Policy „netcup Mail block" – sie sperrt ausgehendes SMTP (Port 25/465/587) als
Spam-Schutz. Für einen echten Mailversand musst du dieses netcup-Template am Server deaktivieren.

Symptom: Der Server läuft zunächst normal und ist nach ein bis zwei Wochen plötzlich
offline.

Ursache & Lösung: Nutzt der Server DHCP, wird die Lease-Erneuerung von der Whitelist
geblockt – die DHCP-Antwort kommt von UDP-Quell-Port 67, den keine Regel erlaubt, und
UDP ist zustandslos. Ergänze EINGEHEND · UDP · ACCEPT · Src 67 im Basis-Template.
Statisch konfigurierte netcup-VPS (der Standard) sind davon nicht betroffen.

Wartung & Backups

• Nach jeder Änderung den Zugang testen. Firewall-Regeln sind der klassische Weg, sich selbst auszusperren. Zweite Sitzung offen halten, neue Verbindung prüfen, erst dann fertig.
• Neue Dienste = neues Template. Brauchst du später einen weiteren Port (Game-Server, WireGuard-VPN über UDP, Datenbank), leg ein kleines eigenes Template an und weise es zusätzlich zu. Die bestehenden Bausteine bleiben unberührt.
• Reihenfolge beachten. netcup wertet die Regeln von oben nach unten aus; die erste zutreffende Regel greift. Bei reinen ACCEPT-Regeln ist das egal – sobald du aber eigene DROP-Regeln einsetzt, achte auf die Reihenfolge relativ zu den ACCEPTs.
• netcups Default-Policys kennen. „netcup Mail block" (ausgehendes SMTP auf Port 25/465/587 gesperrt) und „netcup Ping allow" sind vorgegeben. Über Default Policys wiederherstellen kommst du im Notfall auf einen bekannten, funktionierenden Grundzustand zurück, falls du dich mit eigenen Regeln ausgesperrt hast – zusammen mit der VNC-Konsole dein zweites Sicherheitsnetz.

---

Dieser Beitrag erschien zuerst auf serverkueche.de.