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

Sehr schön, ich freue mich über das neue Feature! 👍

Gute Ergänzung zu den bestehenden Servern!

So nun läuft das Ganze, mal gucken. Prinzipiell begrüsse ich das Firewall-Feature aber sehr, das hat mir gefehlt!

Zitat von [netcup] Lars S.

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.

Puh, das mit DNS ist eine böse Falle. Ich musste die hier auch Eingehend VON Port 53 TCP/UDP erlauben, damit der lokale DNS wieder auflösen konnte. Klar, auf dem Papier spricht man intern mit dem DNS. Dieser fragt im Hintergrund aber nach draußen. Müsste das dann nicht alle DNS-Requests betreffen, sobald man irgendeine eingehende Regel definiert? Weil dann ja die implizierte Regeln eingehend auf DROP ANY schaltet?

Zitat von friend_of_root

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.

Ich habe auf einigen Server geoip-shell im Einsatz.

Funktioniert sehr gut.
Allerdings rate ich jedem, das nur mit Blacklisting zu betreiben. Alles blocken und nur bestimmte Länder zu erlauben kann ins Auge gehen:

Zitat von johnassel

Puh, das mit DNS ist eine böse Falle. Ich musste die hier auch Eingehend VON Port 53 TCP/UDP erlauben, damit der lokale DNS wieder auflösen konnte. Klar, auf dem Papier spricht man intern mit dem DNS. Dieser fragt im Hintergrund aber nach draußen. Müsste das dann nicht alle DNS-Requests betreffen, sobald man irgendeine eingehende Regel definiert? Weil dann ja die implizierte Regeln eingehend auf DROP ANY schaltet?

Es reicht UDP 53 IN, TCP sollte ja dank stateful funktionieren - so hab ichs gelöst. Zusätzlich hab ichs noch auf die IPs meiner beiden externen Resolver eingegerenzt.

UDP mit Port 53 als Zielport hatte ich ja, sonst könnte ich meinen DNS nicht erreichen. Aber es fehlte UDP mit Port 53 als Quelle. Ohne läuft es nicht.

Zitat von johnassel

UDP mit Port 53 als Zielport hatte ich ja, sonst könnte ich meinen DNS nicht erreichen. Aber es fehlte UDP mit Port 53 als Quelle. Ohne läuft es nicht.

Genau, hatte ich mich falsch ausgedrückt.

Zitat von aRaphael

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.

Ja, habe mittlerweile auch verstanden, wie das gemeint ist Der Hinweis "Regeln werden von oben nach unten angewendet" ist dennoch verwirrend, da die impliziten Regeln von der Reihenfolge ausgenommen sind. Ansonsten würde das "Drop All" der impliziten Regeln alle zuvor geöffneten Ports wieder schließen. In meinem Fall hat cloudflared keine Verbindung mehr zum Host aufgebaut und ich dachte erst, dass es daran liegt, dass die impliziten Regeln ganz unten stehen.

Zitat von engine

Genau, hatte ich mich falsch ausgedrückt.

Das wäre dann vielleicht auch etwas, was man in den Standardregelsatz aufnehmen könnte. Das dürfte dann ja jeden DNS-Verkehr betreffen. 🤔

Zitat von johnassel

Das wäre dann vielleicht auch etwas, was man in den Standardregelsatz aufnehmen könnte. Das dürfte dann ja jeden DNS-Verkehr betreffen. 🤔

Sehe ich auch so, denn selbst ein lokaler Resolver hat - wie du sagst - einen Upstream und der schlägt dann fehl, wenn die entsprechenden Ports nicht freigegeben sind.

Zitat von fs86

Der Hinweis "Regeln werden von oben nach unten angewendet" ist dennoch verwirrend, da die impliziten Regeln von der Reihenfolge ausgenommen sind. Ansonsten würde das "Drop All" der impliziten Regeln alle zuvor geöffneten Ports wieder schließen.

Ne der Hinweis ist genau richtig. Die Impliziten Regeln sind nicht von der Reihenfolge ausgenommen, erst wenn alle zuvor erstellten Regeln nicht zutreffen werden die Impliziten Regeln Angewendet.

Zitat von fs86

verwirrend, da die impliziten Regeln von der Reihenfolge ausgenommen sind

Nichts ist ausgenommen, aber die Verarbeitung stoppt beim ersten Treffer. Damit ist das Paket entsprechend der ersten zutreffenden Regel erlaubt oder verboten und alle weiteren Regeln spielen für dieses Paket keine Rolle mehr. Das ist eine sehr übliche Semantik solcher Regelsätze.

[netcup] Sarah G. Zum Thema DNS:

Bei Verwendung der netcup-DNS-Server werden keine Firewall-Regeln für DNS benötigt, richtig?

Beantworte ich mal selbst: Steht bereits in der Hilfe drin, dass das zutrifft.

Das Beispiel in der Hilfe dient für den Betrieb eines eigenen DNS-Servers und nicht für die Verwendung externer DNS-Server wie beispielsweise 1.1.1.1?

Beides sollte man vielleicht in der Hilfe erläutern.

Edit: Antwort erste Frage nachgetragen.

Zitat von Zierleiste

[netcup] Sarah G. Zum Thema DNS:

Bei Verwendung der netcup-DNS-Server werden keine Firewall-Regeln für DNS benötigt, richtig?

Das Beispiel in der Hilfe dient für den Betrieb eines eigenen DNS-Servers und nicht für die Verwendung externer DNS-Server wie beispielsweise 1.1.1.1?

Beides sollte man vielleicht in der Hilfe erläutern.

Doch, auch für 1.1.1.1 oder ähnliches brauchst du entsprechende Firewall-Regeln. Wie es mit den internen aussieht kann ich dir nicht beantworten.

Zitat von engine

Es reicht UDP 53 IN, TCP sollte ja dank stateful funktionieren - so hab ichs gelöst. Zusätzlich hab ichs noch auf die IPs meiner beiden externen Resolver eingegerenzt.

Diese Auflösung funktioniert wahrscheinlich in den meisten Fällen auch ohne die UDP 53 IN Regel, weil der Resolver dann auf TCP umschaltet. Deswegen fällt es vielleicht erst durch den Performanceverlust auf, dass man diese Regel braucht. Dass die UDP-Regeln stateless sind, führt allerdings die UDP-Firewall fast ad absurdum, weil ein Angreifer nur einen dann praktisch immer freizugebenden Source Port wie DNS verwenden muss, um beliebige UDP-Ports auf dem Server erreichen zu können. (Man kann die Regeln auf den Portbereich einschränken, der für abgehende "Verbindungen" verwendet wird, aber wer macht das schon.)

engine Das war nicht meine Frage, dass man die Regeln braucht, ist klar (hat man ja hier schon lesen können).

Meine Frage war, wie das Beispiel in der Hilfe gemeint ist (Kapitel 1. Über die Firewall).

Zitat von NaN

Diese Auflösung funktioniert wahrscheinlich in den meisten Fällen auch ohne die UDP 53 IN Regel, weil der Resolver dann auf TCP umschaltet. Deswegen fällt es vielleicht erst durch den Performanceverlust auf, dass man diese Regel braucht. Dass die UDP-Regeln stateless sind, führt allerdings die UDP-Firewall fast ad absurdum, weil ein Angreifer nur einen dann praktisch immer freizugebenden Source Port wie DNS verwenden muss, um beliebige UDP-Ports auf dem Server erreichen zu können. (Man kann die Regeln auf den Portbereich einschränken, der für abgehende "Verbindungen" verwendet wird, aber wer macht das schon.)

Oder auf die Source-IP filtern, sofern man nur externe Nameserver verwendet. Dann müsste der Angreifer auch die IP spoofen.

Zitat von NaN

Nichts ist ausgenommen, aber die Verarbeitung stoppt beim ersten Treffer. Damit ist das Paket entsprechend der ersten zutreffenden Regel erlaubt oder verboten und alle weiteren Regeln spielen für dieses Paket keine Rolle mehr. Das ist eine sehr übliche Semantik solcher Regelsätze.

Kann man so interpretieren. Ich kenne es aber so, dass die Regeln, die hier unter "implizite Regeln" stehen, oben stehen.

Bei allen Firewalls, die ich kenne, ist die erste zutreffende Regel entscheidend. Alles nachfolgende wird dann ignoriert und implizite Regeln, die den Rest erledigen stehen am Ende.