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 stateless-UDP-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.

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:

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 ab, im Basis-Template steht es trotzdem, damit dein Fundament auch ohne die netcup-Defaults vollständig bleibt.

grep -rE "inet6? (static|dhcp)" /etc/network/interfaces /etc/network/interfaces.d/

/etc/network/interfaces.d/50-cloud-init.cfg:iface eth0 inet static
/etc/network/interfaces.d/50-cloud-init.cfg:iface eth0 inet6 static

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 (siehe Wartung).

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, 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, wo dein Server der fragende Client ist und der Port deshalb im Quell-Port steht. Beide Richtungen existieren problemlos nebeneinander. TCP-Antworten sind davon nicht betroffen (der Firewall-Zustand spielt nur bei UDP keine Rolle); ausgehend ist ohnehin alles erlaubt.

Mailserver (mailcow & Co.)

Passt zu mailcow und Stalwart.

Zwei Dinge gehören beim Mailserver zusätzlich dazu:

• 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: ist bei netcup ab Werk gesperrt. Wie du das änderst, steht im nächsten Abschnitt.

Port 25 freischalten: „netcup Mail block" abnehmen

Ein Mailserver muss auf Port 25 ausgehend zustellen können. netcup sperrt ausgehendes SMTP – die Ports 25, 465 und 587 – als Spam-Schutz über die Default-Policy „netcup Mail block". Eine Fehlermeldung bekommst du dabei nicht: Verbindungen zu fremden Mailservern laufen einfach in einen Timeout. IMAP (993) und alle anderen Ports nach draußen sind davon nicht betroffen.

Die Sperre nimmst du dem Server selbst ab: Deaktiviere in der Zuweisung aus Schritt 4 das netcup-Template „netcup Mail block". Ein Support-Ticket brauchst du dafür nicht. Willst du nur kurz testen, ob deine Mails zugestellt werden, kannst du das Template danach wieder zuweisen.

Offener Port 25 allein reicht für eine saubere Zustellung nicht. Ohne korrekten PTR-/Reverse-DNS-Eintrag landen deine Mails im Spam – was sonst noch dazugehört, steht bei der Mail-Zustellbarkeit.

WireGuard-VPN

Passt zu WireGuard-VPN einrichten.

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.

Headscale (eigener Tailscale-Koordinationsserver)

Passt zu Headscale: das eigene Tailscale-Netz.

Oberfläche, API und der DERP-Kanal selbst laufen über den Reverse Proxy und damit über 443 (Serverküche Web). Direkt veröffentlicht wird nur UDP 3478: Darüber hilft der eingebaute DERP-Server deinen Geräten bei der NAT-Durchdringung. Eine fehlende Regel fällt erst spät auf – die Anmeldung am Koordinationsserver klappt über 443, nur die direkten Verbindungen zwischen den Geräten kommen nicht zustande.

OpenVPN

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:

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

Im Standard-Pull-Modus verbindet sich der Checkmk-Server ausgehend zu 6556 der Agenten – eingehend braucht deshalb nur der überwachte Host diesen Port. Der Checkmk-Server selbst kommt mit 80/443 (Serverküche Web) aus; 8000 und 6557 nur, wenn du Push-Modus bzw. verteiltes Monitoring nutzt. 8000 gilt dabei für die erste Site auf dem Server – eine zweite Site nutzt 8001, eine dritte 8002 und so weiter.

Coturn / TURN-Server (Nextcloud Talk, Matrix)

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.

Jitsi Meet (Videokonferenzen)

Passt zu Jitsi Meet: eigene Videokonferenzen (Tutorial folgt voraussichtlich im November).

Das ist die Policy, die am häufigsten vergessen wird, weil Jitsi ohne sie komplett normal aussieht: Die Weboberfläche kommt über 443 (Serverküche Web), die Teilnehmerliste füllt sich, und erst beim Sprechen merkt man, dass nichts ankommt. Ton und Bild laufen nicht durch den Reverse Proxy, sondern direkt auf UDP 10000 – ein fester Port, anders als bei coturn mit seiner großen Relay-Range.

Git-Server über SSH (Forgejo)

Passt zu Forgejo: der eigene Git-Server hinter Traefik.

Die Weboberfläche kommt über 443 (Serverküche Web). Forgejos eingebauter SSH-Server liegt bewusst nicht auf 22 – dort sitzt schon der SSH-Dienst des Servers –, sondern auf 2222. Nimm den Wert, den du bei SSH_LISTEN_PORT gesetzt hast. Ohne diese Regel sieht alles gesund aus: Anmelden, Repositorys anlegen und HTTPS-Klonen funktionieren, nur git clone ssh://git@DEINE_DOMAIN:2222/… läuft in einen Timeout.

Syncthing

Passt zu Syncthing: Dateien zwischen Geräten synchronisieren.

Der Sync-Verkehr läuft nicht über den Reverse Proxy, sondern direkt auf 22000 – nur die Weboberfläche kommt über 443. Beide Zeilen gehören dazu: Syncthing nimmt TCP und QUIC (UDP) auf demselben Port. Den dritten Port 21027/UDP brauchst du nicht – das ist die Geräte-Erkennung im lokalen Netz, die über das Internet ohnehin nicht trägt.

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

Diese Vorlage brauchst du nur, wenn dein DNS-Server öffentlich erreichbar sein soll. Im Serverküche-Weg bei AdGuard Home ist er das bewusst nicht: Dort lauscht AdGuard ausschließlich auf der WireGuard-Adresse, erreichbar also nur durchs VPN – dafür ist hier keine Regel nötig.

Dst 53 erlaubt hier die Anfragen fremder Clients an deinen DNS-Server – die Gegenrichtung zu Src 53 im Basis-Template.

Datenbank-Fernzugriff (nur im Notfall)

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

• Nach jeder Änderung den Zugang testen – mit zweiter offener Sitzung, wie in Schritt 4.
• Neue Dienste = neues Template. Brauchst du später einen weiteren Port, leg ein kleines eigenes Template an und weise es zusätzlich zu.
• 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 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.