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

    Quote from Hille

    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?.

    Denk daran sobald du eine Ausgehende Regel Hinzufügst wird die Implizite Regel für ausgehend auf Drop gesetzt!
    Bei deinem 2. Beispiel sollte die Letzte Regel also so aussehen:

    Code
    Drop all                          AUSGEHEND    DROP    ANY    *    *        *    *

    Also am Besten vor der Impliziten Regel für die Protokolle Ausgehend ein AUSGEHEND ACCEPT <PROTOKOLL> * * * * einstellen.

    Edited 2 times, last by philw95 (February 1, 2026 at 5:07 PM).

    Hille Ich möchte der Frage von philw95 gerne noch weitere Fragen hinzufügen, dabei beziehe ich mich auf deine zweite Tabelle mit 13 Regeln:

    Stammen die Regeln 1 bis 3 von Dir oder ist das die netcup Mail block (Default policy)?

    Stammen die Regeln 12 und 13 von Dir oder sind das Implizite Regeln von netcup?

    Willst Du die WireGuard-VPN-Verbindung von extern zu deinem Server aufbauen oder soll der Server selbst eine VPN-Verbindung aufbauen?

    Bis auf die beiden letzten Regeln, sind es komplett eigene Regeln. Regel 12-13 (letztes Beispiel) sind Implizite Regeln. Und die stehen für ausgehend auf Accept any. Deshalb war mir auch nicht klar, warum Wireguard ausgehend geblockt wird. Allerdings habe ich die anderen Ports noch nicht getestet, ob diese auch geblockt werden, vermutlich aber ja.

    Wenn Du eingehend alles blockierst, wirst Du es brauchen. Deine eigene Firewall ist höchstwahrscheinlich Stateful, die im SCP (bei UDP) jedoch Stateless.

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

    Edited once, last by KB19 (February 1, 2026 at 11:48 PM).

    Quote from Interessent

    Brauch ich NTP in der NC Firewall überhaupt?

    Ja (wie KB19 schon schrieb), weil die netcup-Firewall bei UDP stateless ist. Wenn Du ausgehend allen Traffic erlaubt hast, benötigst Du eingehend eine Regel, die Antworten auf deine NTP-Anfragen durchlässt. Daher muss Source Port 123 für UDP eingehend erlaubt werden.

    Linux hingegen hat einen Timer, der für 30 Sekunden UDP-Antworten automatisch durchlässt, der genaue Wert kann mit cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout ausgelesen werden, Quelle hier: https://serverfault.com/questions/8359…-udp-right-away

    Edited once, last by Zierleiste: Protokoll UDP ergänzt for "stateless". (February 2, 2026 at 8:54 AM).

    Hille Du müsstest nochmals Regel #13 prüfen, ob Du sie richtig notiert hast. Wenn es die implizite Regel von netcup ist, dann sollte sie gemäß Doku eigentlich von Accept all auf Drop all wechseln, weil Du andere ausgehende Regeln (1-3) definiert hast.

    Die Frage hast Du leider noch nicht beantwortet:

    Quote from Zierleiste

    Willst Du die WireGuard-VPN-Verbindung von extern zu deinem Server aufbauen oder soll der Server selbst eine VPN-Verbindung aufbauen?

    Auch bei NTP ist mir nicht klar, warum Du so viele Regeln hast. Betreibst Du einen eigenen NTP-Server, der von außen angesprochen werden soll oder nur einen lokalen Dämon, der sich mit öffentlichen Zeitservern synchronisieren können soll?

    Quote from Zierleiste

    weil die netcup-Firewall stateless ist.

    Korrektur, nur damit es hier richtig steht.
    TCP ist Statefull
    UDP ist Stateless

    https://helpcenter.netcup.com/de/wiki/server/firewall

    Quote

    Die Firewall ist stateful. Das bedeutet, dass sie sich Verbindungen merkt, die von deinem Server ausgehen, und den Rückverkehr automatisch annimmt. Dies gilt jedoch nur für TCP-Traffic. Um UDP-Traffic auf die Whitelist zu setzen, musst du sowohl eine INGRESS- als auch eine EGRESS-Regel in deiner Policy anlegen:

    Quote from Zierleiste

    Ja (wie KB19 schon schrieb), weil die netcup-Firewall bei UDP stateless ist. Wenn Du ausgehend allen Traffic erlaubt hast, benötigst Du eingehend eine Regel, die Antworten auf deine NTP-Anfragen durchlässt. Daher muss Source Port 123 für UDP eingehend erlaubt werden.

    Linux hingegen hat einen Timer, der für 30 Sekunden UDP-Antworten automatisch durchlässt, der genaue Wert kann mit cat /proc/sys/net/netfilter/nf_conntrack_udp_timeout ausgelesen werden, Quelle hier: https://serverfault.com/questions/8359…-udp-right-away

    Danke, das wäre dann so, oder?


    pasted-from-clipboard.png

    Kurze Frage zu einem anderen Server. Das sind meine UFW Regeln:

    Regeln 3-7 beziehen sich auf Docker.

    D.h. ich brauche für UDP von Wireguard und OpenVPN jeweils 2 Regeln, eine eingehende und eine ausgehende?

    Gebe ich die internen Docker IPs in der NC FW auch als Target IP mit an?

    Quote from Interessent

    Danke, das wäre dann so, oder?

    Ja. Benutzt Du chronyd? Dann kannst Du mit chronyc tracking prüfen, ob die Zeit erfolgreich synchronisiert werden konnte.

    Regeln 3 - 7 oder meinst Du Regeln 7 - 11? Das sind ja private IP-Adressen, die sollte die SCP-Firewall gar nicht sehen.

    Ich betreibe beispielsweise auf einem Server ebenfalls OpenVPN und dafür habe ich in der SCP-Firewall nur eine eingehende Regel für Destination Port 1194 angelegt, weil bei mir ausgehend auch alle Verbindungen erlaubt sind.

    Was Du in der SCP-Firewall eintragen musst, hängt also davon ab, ob dein Server nur von extern angesprochen wird oder ob er selbst VPN-Tunnel zu anderen Servern aufbauen können soll.

    Quote from hoedlmoser

    heißt aber auch ich kann mit src port 53 alle deine udp services nutzen.

    Ja. Alle Nameserver die der eigene Resolver abfragen könnte als Source-IP-Adressen in der Firewall einzutragen ist nicht bewerkstelligbar. Den Aufwand das auf einzelne IP-Adressen zu beschränken kann man sich aber machen, wenn man nur well-known-resolver verwendet (z.B. 1.1.1.1, 8.8.8.8, ...) aber selbst keinen Resolver der interatives Lookup durchführt betreibt.

    Quote from hoedlmoser

    heißt aber auch ich kann mit src port 53 alle deine udp services nutzen.

    So viel oder wenig wie vor der Einführung der neuen Firewall. Dahinter kommt ja (hoffentlich!) auch weiterhin noch eine Firewall auf dem Server (ufw, iptables, nftables), die das entweder schon vorher nicht geblockt hat oder es jetzt immer noch tut. Die neue netcup Firewall sehe ich nur als ein eher grobes Sieb vor dem Server. Immerhin, jede Verbindung die sie blockt, ist eine weniger die mein Server bearbeiten bzw blocken muss.

    Quote from hoedlmoser

    wie kommen Deine kunden zb auf ihr webroot?

    Ich habe keine Kunden und betreibe den nur für mich selbst.

    Wenn ich Kunden hätte, würde ich sie wohl dazu auffordern, sich einen kostenfreien Tailscale Account anzulegen und dann den Server an diese Accounts sharen. Oder ich würde es gar nicht so machen.

    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)