Nagut, FW geht nicht, aber ich denke, da liegt noch ein Problem in der Firewall.
Sobald ich die meine Regeln einstelle, funktioniert dies 5 Minuten, danach wird alle geschlossen und ich kann nichts mehr machen.
Ich muss dann die Default FW-Regeln aktivieren.
Das erklärt auch mein Problem. Es wäre schön, wenn sich mal jemand aus dem Support zu Wort meldet.
Wir sind keine Betatester, da dürfen die sich also auch gerne an einem Sonntag melden.
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.
Klar das wäre toll, bietet aber out of the box niemand so an. Wäre auch ein zu hoher Aufwand für einen Hoster.
Kostenlos VLAN, den 2€ VPS und Basteln. Alternativ bei Cloudflare die Länder sperren, geht dann aber halt nicht auf IP Ebene.
Mal eine dumme frage:
Kann man hier nachträglich auch Beträge mergen? Wollte nicht "spamen". - Fehler in den Beiträgen gefunden.
Implizite Regeln -> ändern sich vonn allow zu drop. Netcup ganz ehrlich: Löscht wenigstens euer tam tam auf der Webseite. Die Firewall ist somit Alpha und nicht Beta.
Implizite Regeln -> ändern sich vonn allow zu drop.
Na, das ist ja sicher auch so gewollt.
Hat man keine Policy, ist zunächst alles offen und wenn man dann eigene Regeln anlegt, macht die Firewall alles dicht, außer diesen Regeln.
Ist doch eigentlich ganz praktisch.
Ist doch eigentlich ganz praktisch.
Und unerlässlich...
Ja, verstehe ich. Aber wenn ich den Traffic generell nach außen öffnen würde, dann müsste man extra eine Regel erstellen, die vor den implizierten Regeln greift.
Ich habe mich gestern auch gewundert, warum die implizierten Regel nach außen von allow zu Drop gewechselt ist.
Alle meine Firewalls hatten als oberste Priorität mich auszuschliessen und nicht wieder ins Haus zu lassen - anders kenne ich das nicht.
Na, das ist ja sicher auch so gewollt.
Hat man keine Policy, ist zunächst alles offen und wenn man dann eigene Regeln anlegt, macht die Firewall alles dicht, außer diesen Regeln.
Ist doch eigentlich ganz praktisch.
Gehe ich mit. Ich muss heute mal etwas herumexperimentieren. 
Euch einen schönen dritten Advent.
Alles anzeigenKlar das wäre toll, bietet aber out of the box niemand so an. Wäre auch ein zu hoher Aufwand für einen Hoster.
Kostenlos VLAN, den 2€ VPS und Basteln. Alternativ bei Cloudflare die Länder sperren, geht dann aber halt nicht auf IP Ebene.Mal eine dumme frage:
Kann man hier nachträglich auch Beträge mergen? Wollte nicht "spamen". - Fehler in den Beiträgen gefunden.
Implizite Regeln -> ändern sich vonn allow zu drop. Netcup ganz ehrlich: Löscht wenigstens euer tam tam auf der Webseite. Die Firewall ist somit Alpha und nicht Beta.
Es ist so, dass man die Blocklisten (IP-> Länderzuordnung, sowie Bad-Actor IPs) aktualisiert lizensieren kann. Dies kostet aber einiges wenn das jeder selbst macht. Ein Hoster könnte dies als API (integriert in die Firewall oder seperat) zur Verfügung stellen und damit einen hohen Benefit schaffen.
Es ist so, dass man die Blocklisten (IP-> Länderzuordnung, sowie Bad-Actor IPs) aktualisiert lizensieren kann. Dies kostet aber einiges wenn das jeder selbst macht. Ein Hoster könnte dies als API (integriert in die Firewall oder seperat) zur Verfügung stellen und damit einen hohen Benefit schaffen.
Mag sein, momentan wäre Netcup aber zunächst damit bedient, dass die FW überhaupt läuft.
Das sind meine derzeitigen Settings, mit dem Ergebnis:
Zugriff auf nichts...weder auf SSH, HTTP(S), Cloudflare Tunnel. Auch wenn bei TCP angeblich keine ausgehenden Regeln notwendig sind, so habe sie trotzdem mal testweise gesetzt.
Nachtrag:
Ich habe das Gefühl, dass die implizierten Regeln, höher gewertet werden und die Gewichtung entgegen des „Hinweises“ so nicht mehr von oben nach unten erfolgt. Irgendwo in "dieser Richtung" muss ein Bug vorliegen.
Das würde zumindest das gegenwärtige Verhalten erklären.
Ich persönlich kann derzeit keinem empfehlen, die Firewall in produktiv (kritischen) Umgebungen scharf zu schalten....irgendwas ist das einfach buggy.
Ich hab mich mit echt wirklich simplen Regeln beschäftigt, eigentlich derzeit nur eingehend HTTP(S) und SSH sowie ICMP....ausgehend fasse ich derzeit nicht an.
Damit steht/stand die Firewall simpelst auf:
ALLOW INCOMING HTTP/HTTPS/SSH/ICMP(v6) ohne das mit Source und Destination einzuschränken.
Der Rest wird folglich INCOMING bei der (Default) impliziten Regel geblockt und OUTGOING steht komplett auf ALLOW.
Ich stelle im und/oder-Prinzip fest:
Für mich ist die Firewall damit derzeit nicht vertrauenswürdig. Mir hat es gelangt, dass ich mit einem funktionalen Regelwerk 5 Stunden später ins Bett bin und am nächsten Tag absolut gar nichts mehr ging. Mir konnte nicht einmal mein Monitoring eine Statusmeldung schicken, weil Mails nicht mehr raus gegangen sind (obwohl ausgehend alles erlaubt war).
Alles etwas strange derzeit (zumindest bei mir)
Ich persönlich kann derzeit keinem empfehlen, die Firewall in produktiv (kritischen) Umgebungen scharf zu schalten....irgendwas ist das einfach buggy.
Ich hab mich mit echt wirklich simplen Regeln beschäftigt, eigentlich derzeit nur eingehend HTTP(S) und SSH sowie ICMP....ausgehend fasse ich derzeit nicht an.
Ich vermute eine Überbewertung der Implizite Regeln. Das würde zumindest bei uns alles erklären. Das mit der teilweise Zeitlichen Verzögerung konnte ich beobachten. Allerdings war es bei max. 1 Minute in der Nacht.
Ist aber normal bei vorgeschalteten Firewalls, bzw. kenne ich so von Mitbewerbern auch.
Für mich ist die Firewall damit derzeit nicht vertrauenswürdig. Mir hat es gelangt, dass ich mit einem funktionalen Regelwerk 5 Stunden später ins Bett bin und am nächsten Tag absolut gar nichts mehr ging. Mir konnte nicht einmal mein Monitoring eine Statusmeldung schicken, weil Mails nicht mehr raus gegangen sind (obwohl ausgehend alles erlaubt war).
Könnte das evtl. an dem UDP Traffic liegen (u.a. DNS)? Es gab hier im Thread ja schon ein paar Mal Erwähnungen, dass man hier besonders aufpassen muss, weil die Verbindungen stateless sind. Das ist sicher für viele verwirrend, weil man das so nicht von anderen Anbietern/Lösungen kennt. Ich will es nur erwähnen, weil DNS Probleme generell manchmal erst nach einer gewissen Zeit auftreten (nach dem die TTL aufgelaufen ist und der Cache nicht mehr greift).
Also ich habe es nochmal getestet.
Die Regeln werden mal angewendet, mal nicht. Und wenn die nicht angewendet werden, steht alles. SSH, WebServer und auch Wireguard.
Ich werde die FW erstmal auf Durchzug schalten und mir das später nochmal anschauen.
/Edit:
Ich habe auch eine Regel, vor den Implizierten erstellt, dass diese nach Außen TCP und UDP freigeben soll. Geht mal oder mal nicht.
Gem. Anlage würde das bspw. bei mir so aussehen...mit dem genannten Verhalten.
Absolut simpelst. Es werden eingehend nur die eingetragenen Kommunikationsbeziehungen zugelassen, ausgehend ist alles erlaubt.
Screenshot 2025-12-14 12.22.17.png
EDIT: Und außer den genannten, eingehend Regeln erwarte ich keinerlei andere, eingehende Anfragen an das System.
Und wenn ich mit diesem simpelsten Regelwerk *random* dann nicht einmal mehr per SSH auf den Server komme....kann mMn ja irgendwas nicht stimmen.
nach einer gewissen Zeit
Eine andere denkbare Ursache für erst später greifende Firewalls ist, dass trackende Firewalls nur die ersten Pakete der Verbindungen filtern. Alle weiteren Pakete werden als zur bestehenden Verbindung gehörend erkannt und genau so behandelt wie das erste Paket der Verbindung. Damit bleibt eine getrackte Verbindung auch nach einer Regeländerung bestehen, die die Verbindung verbieten würde. Erst wenn die Verbindung beendet ist und neu aufgebaut wird, geht sie dann nicht mehr durch. Man kann sich z.B. "problemlos" über eine SSH-Verbindung den SSH-Port sperren und trotzdem über SSH verbunden bleiben. Auch eine Neuverbindung vom selben Client kann mit SSH Multiplexing während der bestehenden Verbindung noch funktionieren, aber wenn die TCP-Verbindung beendet wird, kommt man nicht mehr rein.
(Vielleicht spinnt aber auch die Firewall. Nur ein Hinweis zu allgemeinen Fallstricken von Firewalls.)
Gem. Anlage würde das bspw. bei mir so aussehen...mit dem genannten Verhalten.
Absolut simpelst. Es werden eingehend nur die eingetragenen Kommunikationsbeziehungen zugelassen, ausgehend ist alles erlaubt.
Screenshot 2025-12-14 12.22.17.png
EDIT: Und außer den genannten, eingehend Regeln erwarte ich keinerlei andere, eingehende Anfragen an das System.
Und wenn ich mit diesem simpelsten Regelwerk *random* dann nicht einmal mehr per SSH auf den Server komme....kann mMn ja irgendwas nicht stimmen.
Genau das gleiche Bild habe ich auch.
Spannend bei dir zu sehen ist, das deine implizierte Regel für "Ausgehend" auf Accept steht. Sobald ich eine eigene Regel hinzufüge, wird diese auf Drop gesetzt.
Ich habe soeben testweise alles komplett auf gemacht, "aufer" gehts nicht....nach dem speichern ist instant alles komplett dicht....wo ist mein Denkfehler.....oder doch buggy
EDIT: Und außer den genannten, eingehend Regeln erwarte ich keinerlei andere, eingehende Anfragen an das System.
Und wenn ich mit diesem simpelsten Regelwerk *random* dann nicht einmal mehr per SSH auf den Server komme....kann mMn ja irgendwas nicht stimmen.
Im Prinzip hast du auch recht. Das würde man normalerweise auch erwarten. Das Problem ist nur die Art und Weise wie die (Netcup) Firewall arbeitet. Wenn du von ausgehenden Verbindungen sprichst, meinst du ja Verbindungen/Anfragen, die auch eine Antwort von der Gegenstelle erwarten. Wenn du einen DNS Request machst, dann siehst du das ja als ausgehenden Traffic. In Wahrheit kommt aber auch Traffic wieder zurück (die DNS Antwort). In einer stateful Firewall merkt sich die Firewall die ausgehende Verbindung und lässt die eingehende Antwort automatisch rein. In einer stateless Firewall (wie jetzt hier bei Netcup) ist das aber bei UDP nicht der Fall. Sprich der Request geht raus, die Antwort darf aber nicht zu dir rein, weil du ja alles blockst, was rein kommen will (außer https und ssh, aber das deckt halt nicht die DNS Antwort ab).
Ich will nicht ausschließen, dass da wirklich was kaputt ist (ich habe die FW selbst noch nicht getestet), es wäre aber gut, wenn du den gleichen Test nochmal machen könntest, aber eine zusätzliche Regel einbaust, die den eingehenden UDP Traffic erlaubt um zumindest das Problem ausschließen zu können.
Ach Mist, ich hab bei meiner Testregel Copy+Paste bei ICMP einen Fehler gemacht (ist auf TCP und nicht ICMP)....ich prüfe nochmal
EDIT: Mit korrigertem "voll auf" keine Änderung des Verhaltens. Nach dem Speichern habe ich wie ein Irrer meine SSH-Session wiederholt reconnected....nach ca. 15 Sekunden alles dicht.
Da bin ich aber beruhigt, dass ich nicht der einzige bin, der die Firewall für buggy hält.
Habe ebenfalls eine Policy erstellt, die nur drei Ports/TCP und alles UDP erlaubt.
Das Ergebnis war dann, dass der Server zuerst nicht mehr nach Außen kommunizieren konnte und kurze Zeit später konnte ich auch keine SSH Verbindung aufbauen. Das sind auch keine Kinderkrankheiten, muss ich sagen.
Tolles Feature, netcup, aber bitte beim nächsten Mal ordentlich testen, oder ggf. mit einer Testgruppe verifizieren - da finden sich sicherlich einige Early Adopters hier.
Ich habe nun meine Policy gelöscht und der Cluster ist wieder erreichbar, was auch keinen Sinn macht, denn nun sollte theoretisch die DROP ALL Regel greifen, die sich aber wieder zurück in eine ACCEPT ALL Regel geändert hat.
