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

Zitat von Interessent

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

Code

To                         Action      From
--                         ------      ----
SSH-ungleich-22/tcp                  LIMIT       Anywhere
SSH-ungleich-22/tcp (v6)             LIMIT       Anywhere (v6)


10.100.x.x 80/tcp          ALLOW FWD   Anywhere                   # allow npm 80/tcp NPM
10.100.x.x 443/tcp         ALLOW FWD   Anywhere                   # allow npm 443/tcp NPM
172.19.x.x 51820/udp       ALLOW FWD   Anywhere                   # allow wireguard 51820/udp VPN
172.19.x.y 1194/udp        ALLOW FWD   Anywhere                   # allow openvpnas 1194/udp VPN
172.19.x.y 9443/tcp        ALLOW FWD   Anywhere                   # allow openvpnas 9443/tcp VPN

Alles anzeigen

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?

Brauch ich nun in der NC Firewall die privaten IPs meiner Dokercontainer?

Zitat von TBT

Ich habe keine Kunden

danke für die einordnung. klar, als alleiniger nutzer kann ich meinen server beliebig zunageln, drei hürden aufstellen und den rest vermienen. hilft dann auch nur zuhause strom und hardware investitionen zu sparen.

Mal so als Frage: Wie ist es eigentlich mit Firewall Regeln/Policys wenn man den Server überträgt?

Und der neue Empfänger die Policys bei sich nicht so erstellt hat?

Zitat von fvbor

wenn man den Server überträgt?

Ich fände es logisch, wenn alles mit Übertragen wird. Weshalb sollte es anders sein? Bisher wurde doch auch nur das komplette Produkt vom einen in den andren Account verschoben.

Die Firewall ist doch Produkt und nicht Accountbezogen.

Zitat von ASS

Die Firewall ist doch Produkt und nicht Accountbezogen.

Naja, die Firewall Policys werden schon auf Accountebene verwaltet (SCP -> Optionen -> Firewall Policys). Und auf Produktebene werden diese Policys den Servern zugeordnet (SCP -> Server -> Firewall).
Wenn die Policys bei einem Inhaberwechsel übernommen werden sollen, müssten im Account des Empfängers die Policys angelegt werden, die beim Versender dem Server zugeordnet waren. Würde mich auch mal interessieren, wie sich das am Ende verhält.

laurenz.rausche da wir bald™️(wenn die Abrechungswarteschlange und der Support gnädig sind) Server tauschen - könnten wir das ja mal testen 🤔

Bauen wir paar Policys und hängen sie an den Server vorm Transfer und berichten

Bin nicht up to date was genau Sache ist, aber jop bin dabei!

Zitat von Virinum

Naja, die Firewall Policys werden schon auf Accountebene verwaltet

Oder nur auf Accountebene zusammengefasst? Dann wirds nur kritisch, wenn 2 mal derselbe Namen benutzt wird. Vielleicht wird aber auch mit ids gearbeitet?

Meine ersten Gehversuche mit der Firewall waren zwar erfolgreich, aber das Handling im SCP ist meiner Meinung durchaus noch ein wenig verbesserungswürdig.

• Dass man bei deaktivierter Firewall nichts ändern kann, ist irgendwie nicht sehr sinnvoll, aber vielleicht gibt es dafür technische Gründe? Dadurch schöpft das neue Feature zum Deaktivieren nicht das ganze Potenzial aus.
• Beim Anlegen einer neuen Policy, werden neue Regeln gleich einmal verworfen, wenn man nicht zuvor schon einen Namen für die Policy eingetippt hat. Ich würde ja erwarten, dass das erst beim Speichern relevant ist und nicht schon bei einem Zwischenschritt.
• Wenn ich mich nicht verschaut habe, springt die Default Policy erst nach dem Speichern von ACCEPT auf DROP. Ich würde erwarten, dass das dynamisch korrekt dargestellt wird, je nachdem ob bereits Regeln vorhanden sind. Ich würde es aber sowieso begrüßen, wenn man das explizit konfigurieren kann.

Zitat von fvbor

Mal so als Frage: Wie ist es eigentlich mit Firewall Regeln/Policys wenn man den Server überträgt?

Ich würde jedenfalls nicht erwarten, dass ein Inhaberwechsel etwas an meinen Policies herumpfuscht oder diese an einen neuen Inhaber preisgibt, wenn man sie nicht vorher entfernt.

Ich persönlich würde es fast begrüßen, wenn die Firewall beim Inhaberwechsel einfach zurückgesetzt wird. Also Zuweisung der Policies entfernen und womöglich die Firewall deaktivieren. Wobei dann ein expliziter Hinweis im CCP auch nicht schaden würde, weil bei einem laufenden System plötzlich Ports offen stehen könnten. Der Inhaberwechsel kann ja auch für produktive Dienste verwendet werden, die ohne Unterbrechung weiterlaufen sollen.

Zitat von ASS

Oder nur auf Accountebene zusammengefasst? Dann wirds nur kritisch, wenn 2 mal derselbe Namen benutzt wird. Vielleicht wird aber auch mit ids gearbeitet?

Nein, die definiert man schon auf Accountebene. Man kann ja Policys anlegen, ohne diese einem Server zuzuordnen. Auch der API-Pfad klingt für mich stark nach Accountebene: /api/v1/users/{userId}/firewall-policies

Die Policys haben IDs und doppelte Namen sind kein Problem (Rückgabe der API):

[
    {
        "description": "",
        "id": 41244,
        "name": "Drop all"
    },
    {
        "description": "Test doppelter Name",
        "id": 41527,
        "name": "Drop all"
    }
]

Zitat von KB19

Der Inhaberwechsel kann ja auch für produktive Dienste verwendet werden, die ohne Unterbrechung weiterlaufen sollen.

Aber auch für Server, die nicht ohne Grund durch eine Firewall geschützt werden...

Zitat von ASS

Aber auch für Server, die nicht ohne Grund durch eine Firewall geschützt werden...

Legitimer Einwand. Perfekt wäre ja, wenn beide Seiten im CCP auswählen können, was beim Inhaberwechsel passiert:

• Alter Kunde: Firewallregeln mit übertragen Ja/Nein
• Neuer Kunde: Firewallregeln akzeptieren Ja/Nein

Aber der Entwicklungsaufwand sprengt dann wohl alles für die 5-10 Maxerl, die das nachher wirklich brauchen.

Bevor wir uns weiter den Kopf zerbrechen, wäre es interessant, wie es aktuell im CCP/SCP gelöst ist. Irgendwie muss das neue Feature beim Inhaberwechsel bedacht worden sein, wenn es nicht in einer Exception enden soll. Vielleicht kann uns da ein netcup Engelchen erleuchten?

Zitat von KB19

Perfekt wäre ja, wenn beide Seiten im CCP auswählen können, was beim Inhaberwechsel passiert:

Für mich würde es einfach genügen, wenn Server nur im ausgeschalteten Zustand übertragen würden.

Zitat von KB19

das Handling im SCP ist meiner Meinung durchaus noch ein wenig verbesserungswürdig.

Füge Deine Vorschläge gerne meinem Wunschzettel hinzu. Hatte ich vergessen, dazuzuschreiben, dass wir das als Sammel-Thread verwenden können.

https://forum.netcup.de/netcup-anwendungen/scp-server-control-panel/netcup-firewall/21639-wünsche-für-die-netcup-firewall/

Zitat von fvbor

Mal so als Frage: Wie ist es eigentlich mit Firewall Regeln/Policys wenn man den Server überträgt?

Und der neue Empfänger die Policys bei sich nicht so erstellt hat?

Also als managed Cloud Cluster-Kunde sieht man eine Warnung vorm Verschieben des Servers zwischen Kunden:

pasted-from-clipboard.png

Ich würde erwarten, dass das beim Inhaberwechsel dann genauso ist

Zitat von fvbor

Mal so als Frage: Wie ist es eigentlich mit Firewall Regeln/Policys wenn man den Server überträgt?

Und der neue Empfänger die Policys bei sich nicht so erstellt hat?

So, heute ist endlich bei uns beiden die Rechnung per SEPA abgebucht wurden und wir konnten die Server austauschen.
Bei uns beiden ist die Firewall auf Default.

Es gab aber auch keinen Hinweis in der GUI. Aber in der E-Mail stand:

"der Server "v2ID" wurde Ihrem Benutzer zugewiesen. User Firewall Policys des vorherigen Benutzers wurden entfernt."

Danke noch mal für den Server und den Test laurenz.rausche

Danke dir! Hoffe konnte mit dem Test was beitragen!

Zitat von [netcup] Sarah G.

Guten Morgen zusammen,

wir melden uns mit einem weiteren Update zur schrittweisen Ausrollung der Firewall auf ältere vServer-Generationen.

Das Sicherheitsfeature ist nun auch für vServer der Generationen 7, 8 sowie Legacy verfügbar.

Ich wünsche euch allen einen guten Start in den Tag!

Liebe Grüße
Sarah & das netcup-Team

Es freut mich wirklich sehr, daß man nicht gezwungen wird, von einer älteren Generation wie G7 aufzurüsten und diese weiter betrieben und auch ausgebessert werden. Vielen Dank!

Ich würde auch mal dafür plädieren, wenigstens zu Anschauungszwecken eingehendes NTP in die Default Policies aufzunehmen. Im Gegensatz zu Ping ist das im Zweifel geschäftskritisch. Ich habe schon Firewalls von mindestens vier verschiedenen Herstellern konfiguriert und auch wenn die UDP-Problematik in der Anleitung erklärt wird, finde ich es nicht wirklich intuitiv und musste auch noch mal nachbessern.