Ab sofort: Firewall für netcup vServer verfügbar

    Quote from ASS

    Wie denn z.B.? Und was genau ist "das"?

    Ich fühle mich nach wie vor ausreichend kommuniziert.

    Das es "Probleme" mit der Freigabe von UDP Ports gibt.

    Man kann nicht einfach Port X in UDP Freigeben auch wenn es so suggeriert wird.

    Ich wäre kläglich gescheitert, wenn hier nicht intensiv diskutiert worden wäre.

    Bis heute weiß ich nicht, wie die Firewall implementiert wurde.

    Habe nur mit iptables Erfahrung.

    Quote from Marschi

    Das es "Probleme" mit der Freigabe von UDP Ports gibt.

    Ähm, gibt es die?

    Quote from Marschi

    auch wenn es so suggeriert wird.

    Hm, wo denn?

    Stand nicht direkt im Announce, dass sie UDP Stateless ist?

    Ist halt für den Normaluser nicht so optimal, aber wenn es technisch bedingt ist...

    Quote from Marschi

    Bis heute weiß ich nicht, wie die Firewall implementiert wurde.

    Das wissen wir alle nicht, steht aber auch schon auf meinem Block für die "Frangen an die Technik" fürs nächste Community Event.

    Quote from Marschi

    Habe nur mit iptables Erfahrung.

    Ja, da muss man ein klein wenig umdenken...

    Ich denke dass die stateless Firewall von Netcup wohl auf dem Switchport als Funktion des Switch OS implementiert ist. Alternativ könnte es auch eine Funktion der Virtualisierungslösung sein, auf der alle unsere Server laufen.

    So nutze ich die Netcup FW:

    - Als letzte Regel: Eingehend DROP all, Ausgehend ACCEPT all. Damit werden Anfragen von außen geblockt, es sei denn sie werden weiter oben erlaubt, der Server kann jedoch raus und z.B. Updates ziehen, DNS abfragen etc.

    - Ich erstelle mir im SCP unter Optionen des Accounts Firewall Policies als Paket für einen Anwendungszweck. Dabei separiert wenn nötig (z.B. HTTP und HTTPS sind zwei getrennte Policies) und zusammen wenn sinnvoll (z.B. für eine Anwendung, die mehrere eingehende Ports oder Portranges braucht.

    - Dann werden beim jeweiligen Server nur die Policies aktiviert, die nötig sind.

    - Ich nutze als VPN https://tailscale.com/ , das ist auch auf jedem Server drauf. Nach der Einrichtung eines solchen VPN ist es z.B. ohne weiteres möglich, die SSH Policy zu deaktivieren, dann geht SSH nur mehr über das VPN. Wie viele 24/7 "Anklopfversuche" man sich damit ersparen kann, brauche ich wohl nicht weiter ausführen.

    - Die Firewall kann zudem Verwaltungsoberflächen, die eigentlich nicht über das Internet erreichbar sein müssen, schlicht wegblocken (da braucht man gar nichts spezifisches machen). So ist z.B. der Verwaltungsport für https://dockhand.pro/ , meiner Dockerverwaltung auch nur übers Tailscale VPN erreichbar, nicht jedoch übers Internet. Das war vorher nur bedingt möglich ohne Gefahr sich selbst auszusperren. Auch das Verwaltungsinterface von https://nginxproxymanager.com/ auf Port 81 braucht nicht im Internet sein. Zudem ist es damit relativ egal, ob solch ein Interface HTTP oder HTTPS ist.

    Firewalls korrekt zu konfigurieren hat schon immer grundlegendes Verständnis von Netzwerken erfordert. Ein solches zu entwickeln wird nicht nur für einen Netcup Server nützlich sein, sondern für jegliches Netzwerkgeschehen. Die Regeln, die die Netcup Firewall bietet sind absoluter Standard, das ist bei so ziemlich jeder FW so.

    RS 2000 G12 Pro BW25 (8C EPYC 9645, 16GB, 1TB) | RS 500 G12 BW25 (2C EPYC 9645, 4GB, 128GB) | RS Cyber Quack (1C,2GB,40GB)

    Edited once, last by TBT (January 31, 2026 at 6:41 PM).

    Spickzettel für die Netcup vServer- & Root-Server Firewall im SCP

    Eigentlich ist die Sache ja im Wiki https://helpcenter.netcup.com/de/wiki/server/firewall ausreichend erklärt. Aber ich muss gestehen, ich bin jetzt beim Erst-Versuch auch drüber gestolpert, und wenn ich mir diese Diskussion hier so durchlese hab ich den Eindruck: Es stolpern auch andere darüber.

    Da die Meisten vermutlich ihre Server mit diesen abschließenden Default Regeln betreiben ("Accept all | AUSGEHEND") müsste man sich ja eigentlich nur um Server-Dienste kümmern:

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    Drop all EINGEHEND DROP ANY * * * *
    Accept all AUSGEHEND ACCEPT ANY * * * *


    Die Firewall ist für TCP-Verbindungen stateful, das heißt man muss KEINE Regel für die Antworten konfigurieren.

    Einfache TCP-Server-Dienste sind daher hiermit abgedeckt:

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    http EINGEHEND ACCEPT TCP * * * 80
    https EINGEHEND ACCEPT TCP * * * 443
    ssh EINGEHEND ACCEPT TCP * * * 22
    smtp EINGEHEND ACCEPT TCP * * * 25
    smtps EINGEHEND ACCEPT TCP * * * 465
    submission EINGEHEND ACCEPT TCP * * * 587
    pop3 EINGEHEND ACCEPT TCP * * * 110
    pop3s EINGEHEND ACCEPT TCP * * * 995
    imap EINGEHEND ACCEPT TCP * * * 143
    imaps EINGEHEND ACCEPT TCP * * * 993

    Wer einen DNS-Server betreibt: denkt daran, dass DNS sowohl UDP als auch TCP nutzt:

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    dns-server-tcp EINGEHEND ACCEPT TCP * * * 53
    dns-server-udp EINGEHEND ACCEPT UDP * * * 53

    Was ist mit den DNS-UDP-Antworten? ... Die sind bei einem DNS-Server ja ausgehend und mit der "Impliziten Regel / Ausgehend" bereits abgedeckt.


    ABER: Die Firewall ist in Bezug auf UDP vollkommen stateless, das bedeutet man muss z.B. für ausgehendes DNS, NTP, DHCP eine Regel für Antworten konfigurieren!

    Das betrifft: Antworten auf DNS-Queries, also DNS-Responses, NTP-Responses und DHCP-Responses: auch wenn man selbst keinen solchen Server betreibt sondern diese Dienste lediglich konsumiert!

    Also denkt daran, folgendes zu ergänzen, UDP Regeln mit Source Ports für:

    Beschreibung Typ Aktion Protokoll Source(s) (IPs / Netzwerke) Source Port(s) Destination(s) (IPs / Netzwerke) Destination Port(s)
    DNS response stateless-udp EINGEHEND ACCEPT UDP * 53 * *
    DHCP response stateless-udp EINGEHEND ACCEPT UDP * 68 * *
    NTP response stateless-udp EINGEHEND ACCEPT UDP * 123 * *

    Anmerkung: Wer ausschließlich die Netcup eigenen DNS-Server nutzt muss gemäß Netcup-Firewall-Wiki keine UDP-Source-Port-53 Regel anlegen, da diese automatisch immer erlaubt sein dürften.

    Edited 3 times, last by gunnarh (January 31, 2026 at 8:00 PM).

    Ich möchte auf einem Server die NC FW aktivieren, weil mir die ständigen Loginversuche der blöden Chinesen auf meinem Nicht SSH Port auf den Nerv gehen.

    Die UFW bleibt weiterhin aktiv.

    Welche Regeln brauche ich unbedingt?

    Das ist mein Bedarf:

    Nginx mit nextcloud auf 443
    Port 80 eingehend nötig?
    Tailscale Netz, eingehende Regeln nötig?

    Outgoing rsync im Tailscale Netz
    SSH Port, der soll nur noch aus meinem Adressebereich vom 1&1 DSL Netz möglich sein
    Geoblocking möglich ?

    Danke

    Quote from Interessent

    Tailscale Netz, eingehende Regeln nötig?

    Outgoing rsync im Tailscale Netz

    Ich habe auch Tailscale auf meinem Server hinter der NC FW. Alles was über den Tunnel geht, kann so betrachtet werden als gäbe es keine Firewall. D.h. alle Ports (über die Tailscale IP) sind ohne weitere Maßnahmen erreichbar (z.B. irgendein Port für irgendeine Weboberfläche zur Verwaltung), dazu zählt auch SSH. Sobald Tailscale installiert ist, kann man also m.E. den eingehenden SSH Zugang unterbinden und spart sich damit viele "Anklopfversuche" und erhöht die Sicherheit.

    RS 2000 G12 Pro BW25 (8C EPYC 9645, 16GB, 1TB) | RS 500 G12 BW25 (2C EPYC 9645, 4GB, 128GB) | RS Cyber Quack (1C,2GB,40GB)

    Quote from TBT

    Ich denke dass die stateless Firewall von Netcup wohl auf dem Switchport als Funktion des Switch OS implementiert ist. Alternativ könnte es auch eine Funktion der Virtualisierungslösung sein, auf der alle unsere Server laufen.

    Ja, wie man sowas implementieren könnte, ist wohl uns allen hier klar.

    Interessant ist es ja, WIE NC es wirklich gemacht hat...

    Quote from Marschi

    Ich kann mich aber ganz dunkel erinnern, dass Netcup so ein Feature schon mal hatte....

    Das war aber lange bevor ich Kunde war.

    Aber nur bei Linux-VServer, nicht bei KVM-Produkten. Dort war es auch noch wichtiger, weil man iptables u.ä. durch den Shared Kernel nicht nutzen konnte. Das war somit die einzige Möglichkeit für Firewallregeln.

    So vergleichsweise mächtig wie die jetzige Firewall war sie damals definitiv nicht. Und extrem langsam in der Konfiguration im VCP, wenn man mehr als ~10 Regeln hatte. :D

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 3 times, last by KB19 (February 1, 2026 at 7:12 AM).

    Ich habe freilich auch keinerlei Einblick wie Netcup die Lösung realisiert. Aber meine Vermutung wäre, dass das KVM/Libvirt Feature nwfilter genutzt wird. Da montiert man eine XML-Policy direkt am Interface der KVM-VM. Meiner Einschätzung nach wird aus der zusammengeklickten Policy genau so ein XML-File erstellt und der VM als Konfiguration mit nwfilter-define angefügt.

    Mir ist beim Testen der Firewall ne Sache aufgefallen, dir mir nicht ganz klar ist


    Code
    DNS response-stateless-udp          EINGEHEND    ACCEPT    UDP    *    53       *    *
icmp4                               EINGEHEND    ACCEPT    ICMP   *    *        *    *
icmp6                               EINGEHEND    ACCEPT    ICMPv6 *    *        *    *
wireguard-vpn                       EINGEHEND    ACCEPT    UDP    *    *        *    51820
wireguard-vpn-response-stateless    EINGEHEND    ACCEPT    UDP    *    51820    *    *
ntp-udp                             EINGEHEND    ACCEPT    UDP    *    *        *    123
ntp-udp-response-stateless          EINGEHEND    ACCEPT    UDP    *    123      *    *
ntp-nts                             EINGEHEND    ACCEPT    TCP    *    *        *    4460
Drop all                            EINGEHEND    DROP      ANY    *    *        *    *
Accept all                          AUSGEHEND    ACCEPT    ANY    *    *        *    *


    So funktioniert es problemlos



    Durch das Hinzufügen der Regel 1-3 ist keine Wireguard Verbindung mehr möglich. Warum ist das so?.

    Edited once, last by Hille (February 1, 2026 at 12:46 PM).

    Quote from Zierleiste

    ...UDP 53 nicht erforderlich ist, wenn die DNS-Server von netcup verwendet werden...

    Danke für den Hinweis! Da hatte es bei mir nicht geklickt als ich das gelesen habe. Ich habe die DNS-Regeln daher gleich wieder bei mir rausgeschmissen. :)

    Meiner Meinung nach könnte man das noch klarer machen, indem man den ersten Satz im u. g. Abschnitt "Standard Policys" in einen eigenen Abschnitt "Feste Regeln" verlagert. Dort könnte dann auch erklärt werden, was es sonst noch für unsichtbare Regeln gibt. So gäbe es dann eine klare Trennung zwischen Standard-Policys, die man löschen und wiederherstellen kann und den festen Regeln, die man nicht verändern kann.

    Quote

    Standard-Policys

    Die Standard-Firewall enthält nicht bearbeitbare Regeln, die obligatorischen Traffic erlauben. So ist zum Beispiel der DNS-Traffic zu den netcup DNS-Servern immer erlaubt. Außerdem sind standardmäßig Regeln eingestellt, die beispielsweise E-Mail-Spamming verhindern sollen. Diese kannst du jedoch einsehen und bei Bedarf entfernen.

    ...

    Willst du deine Standard-Policys wiederherstellen, klicke unter Firewall auf Default Policys wiederherstellen...

    [Suche] RS Piccolo gesucht