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

    Zitat von [netcup] Sarah G.

    Der HelpCenter-Artikel mit einem Überblick,

    Zitat
    Beachte, dass die Aktion REJECT (Verwerfen des Traffics und Rückmeldung an den Absender) nicht unterstützt wird. Implementiere für erweiterte Funktionen wie diese eine eigene Firewall-Lösung.

    kein reject, schade. aber gibts bei H3tzn3r auch nicht.

    Zitat

    Beispiel 1: SSH erlauben

    INGRESS, TCP, destination port 22, accept

    EGRESS, TCP, source port 22, accept (Definiere EGRESS nur, wenn du auch extra EGRESS Regeln für Client-Traffic konfiguriert hast, sonst wird dieser Traffic blockiert (siehe Beispiel 5)).

    falsch! auch bei EGRESS ist für ssh der destination port 22. da ist hier ja schon jemand im thread drübergestolpert. ;)

    selber fehler in 'Beispiel 2' und 'Beispiel 4'. in 'Beispiel 5' wirds dann hingegen richtig dargestellt.

    Zitat von AccountSuspended

    "Cloudflared" also den Tunnel? Es könnte sein, wenn du nicht selbst HTTP2 eingestellt hast, daß deine Verbindung über QUIC und somit UDP statt TCP läuft.

    https://developers.cloudflare.com/cloudflare-one…-with-firewall/

    Danke, das war es. mit http2 läuft es wieder :)
    Trotzdem ist es etwas komisch, da ja bei ausgehendem Traffic "Accept All" eingestellt war.

    Einmal editiert, zuletzt von fs86 (9. Dezember 2025 um 12:29)

    Ich hätte zu der Firewall auch noch mal eine Frage:

    Es wird ja empfohlen, dass neben der neuen Firewall auch weiterhin eine auf den Servern eingesetzt wird.

    Das leuchtet mir dann ein, wenn Beispielsweise ein TCP Port geöffnet werden soll, dann aber zusätzliche Einschränkungen für diesen Port konfiguriert werden sollen (Zugriff nur für IPs aus einem VPN Netz z.B.).

    Im Grunde muss ich doch aber davon ausgehen, dass die neue Firewall trotzdem sicher ist oder?

    Bedeutet, wenn ich z.B. den SSH Port von draußen Sperre und SSH nur über ein eigenes VPN nutzen möchte, sollte es doch reichen, dies an der neuen Firewall einzustellen und nicht noch zusätzlich die gleiche Firewall Regel auf dem Server einzustellen.

    Ansonsten baue ich mir mit zwei Firewall doch nur unnütze Komplexität auf für eine Sperre, die theoretisch bei der ersten Firewall schon greifen sollte.

    Ich halte es ebenfalls für ausreichend und als die bestmögliche Lösung, da der Traffic schon vor dem Server gefiltert wird und nicht erst sobald dieser am Server angekommen ist. Ich denke damit wollen die sich einfach nur absichern, falls deren Firewall mal ausfällt o.ä. (Ich weiß es aber nicht)

    Geht bei euch die DNS-Auflösung noch mit externen Nameservern? Bei mir geht z.B. 1.1.1.1 nicht mehr, time out. Vermutlich ist das eine stateless Firewall und man muss den eingehenden Traffic von 1.1.1.1 auf UDP & TCP Port 53 zulassen?

    EDIT: Ich hatte recht, wenn man externe Nameserver verwendet (am Beispiel von Cloudflare) muss man Source IP 1.1.1.1/32, Source Port 53 UDP & TCP auf Any zulassen, sonst funktioniert die Namensauflösung nicht...

    Hallo engine,

    beachte dazu bitte folgende Information aus unserem Help Center:

    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.

    Zitat von fs86

    Mm.. bei mir lässt es sich auf diesem Weg leider nicht lösen :(

    Ich konnte nun auch nachvollziehen, warum es zunächst bei mir nicht ging:

    Defaultmäßig sind (als letzte Regel) outgoing und income auf "allow any" gesetzt.

    Raus und rein geht also zunächst alles.

    Wenn man aber in der eigenen Policy z.B. nur eine einzige allow-Regel für einen ausgehenden Port erstellt, so springt outgoing um auf "deny any" (Und lässt sich nicht manuell ändern) Alle anderen (die zunächst alle offen waren) werden dann also gesperrt und ausgehend ist nur noch dieser eine Port offen. Und dann geht natürlich nicht mehr viel. (Das war bei mir der Fall)

    Das gleiche gilt eingehend. Man muss also entweder alle nötigen oder gar keine Ports öffnen. Sobald man einen Port in eine Richtung öffnet, macht das System alle anderen zu.

    Also ich werde meine statischen Firewall-Regeln nach und nach in die neue Firewall übernehmen. Auch die Vollsperung für einige Subnetze aus RU und CN, aus denen ein erheblicher Anteil der IPs Attacken auf meine Server gefahren haben und aus denen ich zudem nach menschlichem Ermessen keine erwünschten Zugriffe erwarte. Die Firewall auf dem Server brauche ich dann aber immer noch, z.B für fail2ban, allerdings hat sie dann eben nicht mehr so viel zu tun wie bisher.

    Zitat von engine

    Geht bei euch die DNS-Auflösung noch mit externen Nameservern? Bei mir geht z.B. 1.1.1.1 nicht mehr, time out. Vermutlich ist das eine stateless Firewall und man muss den eingehenden Traffic von 1.1.1.1 auf UDP & TCP Port 53 zulassen?

    Spannend, gerade getestet, bei mir geht es noch. Sowohl meine eigenen Resolver über das Cloud VLAN als auch 1.1.1.1. Hast du die "impliziten Regeln" rausgenommen?

    Einmal editiert, zuletzt von tab (9. Dezember 2025 um 14:03)

    Naja, die Regeln werden von oben nach unten abgearbeitet. Sowie eine Regel greift, werden die restlichen nicht mehr ausgewertet. Das was du eingehend explizit erlauben willst, müsste dann vor den impliziten Regeln stehen?!? Oder interpretiere ich das falsch?

    Zitat von m_ueberall

    Danke dafür, der Advent(s)kalender ist wieder da. :D

    Na wenn der aRaphael auch eine Regel einbaut die alles blockt von jeder IP zu jeder IP, dann ist ja klar, dass das gesamte Internet jetzt tot ist! :D

    Zitat von tab

    Naja, die Regeln werden von oben nach unten abgearbeitet. Sowie eine Regel greift, werden die restlichen nicht mehr ausgewertet. Das was du eingehend explizit erlauben willst, müsste dann vor den impliziten Regeln stehen?!? Oder interpretiere ich das falsch?

    Na wenn der aRaphael auch eine Regel einbaut die alles blockt von jeder IP zu jeder IP, dann ist ja klar, dass das gesamte Internet jetzt tot ist! :D

    Na, passt schon. Das Problem lag am UDP, das das explizit erlaubt werden muss (für DNS)

    Die Firewall ist wirklich ein sehr gutes Feature bravo!

    Featurewunsch (bisschen off topic):     Länder komplett blockieren
    Dafür einmal die IP-Länder Zuordnungslisten lizensieren und den Serverkunden die Möglichkeit geben Länder pro Server zu blockieren.

    ..würde m.E. auf den Servern wo es zum Einsatz kommt 90% Traffic und CPU Cycles sparen, Spam und Hacking um 99% reduzieren.

    Puh, jetzt hat der Adventskalender mich doch kurz etwas erschreckt. Unter dem Hinweis mit der neuen, kostenlosen Firewall steht da noch "0,00 € für den ersten Monat, ab dem zweiten Monat 6,84 €". Für einen Moment dachte ich, ich habe die Firewall bei meinem bestehenden Server jetzt für 6,84€ pro Monat aktiviert. :D ;(