Wünsche für die netcup-Firewall

Quote from darkstar

Ich brauche normalerweise keine externe Firewall wenn ich einen Debian-Server selber voll unter Kontrolle habe.

Das passiert aber alles auf OS Ebene. Als Vorfilter ist die NC Firewall schon sinnvoll.

Quote from Hille

Das passiert aber alles auf OS Ebene. Als Vorfilter ist die NC Firewall schon sinnvoll.

Ich denke, es gibt 2 Ebenen:

a) die Protokoll/Port-Ebene - das kann ich mit der NC-Firewall machen - oderbauch mit Tools lokalen Tools wie ufw - in dieser Hinsicht aber Vorteil NC-Firewall, weil dieser Traffic garnicht erst beim Server landet. Im Prinzip tut es aber auch eine gute Konfiguration der Services mit Prüfung was da so läuft, also ss -tulpn

Wenn Die NC-Firewall hat da dann einen Sinn, wenn die Konfiguration nicht fertig ist und über irgendwelche vorkonfigurierten Automatismen plötzlich und unerwartet ein Dienst hochkommt, der auf 0.0.0.0 hört und das direkt Probleme machen kann. Hatte neulich ein strongswan was ein dhcp automatisch mitbrachte…

b) die Ebene der Zugriffsversuche auf durchaus gewollte Dienste, d.h. da wo z.B. fail2ban arbeitet. Da hat die NC-Firewall derzeit keine Funktion… Es sei denn man baut einen REST-API-Client. Die Frage ist dann nur, ob es nicht Sinn macht, dass dann jeder seine Config selber pflegt oder ob man nicht auch eine gemeinsame Blocklist pflegen kann. Wenn ich mir anschauen, wie sehr systematisch aus bestimmten Netzen wie 2:57.120/121/122.* allein ssh gescannt wird, mit postfix-sasl geht es dann weiter usw.

Wenn man unsicher ist, ob man so legitimen Traffic blockt kann man sich auch ein paar vserver lite als honeypot hinpacken, die dann eine Reihe offene Ports mit gängigen Diensten darstellen, ohne dass etwas dahinter wäre bzw. z.B. ein Postfix überhaupt senden könnte…

Quote from darkstar

Ich brauche normalerweise keine externe Firewall wenn ich einen Debian-Server selber voll unter Kontrolle habe.

Wenn, ja wenn. Wenn der Server nicht mehr voll unter Kontrolle ist (weil gehackt), ist er eben nicht mehr voll unter Kontrolle. Und der User weiß ggfalls nichts davon.

Quote from darkstar

Und für nervende Gäste gibt es Fail2ban. Allerdings ist für viele die Konfiguration nicht so einfach - und wann man dann noch Abuse-Reports schicken möchte sind viele inhaltlich oder zeitlich überfordert.

Aber wieso F2B überhaupt benötigen/verwenden, wenn man schlicht auch - noch sicherer - SSH Zugang von außen mit der Firewall und einer VPN Lösung komplett unterbinden kann? Ich sag nicht, dass die NC Firewall alles abfangen kann (sie ist keine WAF), aber zumindest für SSH ist sie - für mich - eine feine Sache.

Quote from TBT

Wenn, ja wenn. Wenn der Server nicht mehr voll unter Kontrolle ist (weil gehackt), ist er eben nicht mehr voll unter Kontrolle. Und der User weiß ggfalls nichts davon.

Argument verstanden… soll ja User geben die sich einen vserver mieten - noch vor dem Internet-Führerschein

Quote from TBT

Aber wieso F2B überhaupt benötigen/verwenden, wenn man schlicht auch - noch sicherer - SSH Zugang von außen mit der Firewall und einer VPN Lösung komplett unterbinden kann? Ich sag nicht, dass die NC Firewall alles abfangen kann (sie ist keine WAF), aber zumindest für SSH ist sie - für mich - eine feine Sache.

Es ist ja nicht nur SSH, es gibt ja jede Menge Anmeldeversuche per Postfix/Dovecot etc. - irgendwelche Rootkit/Wordpress-Plugin-Suchen (ich will hier jetzt kein error.log ausbreiten) - kurz auf jeden verdammten Port der da irgendwo im Netz steht. Und dummerweise sind die Ports auch für legitimen Traffic (absichtlich!) da.

Quote from darkstar

Es ist ja nicht nur SSH, es gibt ja jede Menge Anmeldeversuche per Postfix/Dovecot etc. - irgendwelche Rootkit/Wordpress-Plugin-Suchen (ich will hier jetzt kein error.log ausbreiten) - kurz auf jeden verdammten Port der da irgendwo im Netz steht. Und dummerweise sind die Ports auch für legitimen Traffic (absichtlich!) da.

Das stimmt, aber ja doch vor allem SSH. Ja, Mailserver werden auch permanent angebaggert, hab ich auf meinem eigenen Mailserver gesehen. Hier kann man mit f2b in der Tat was machen.

Spätestens bei dem Wordpress Thema bräuchte es aber dann schon eine WAF. Und eine solche ist ja doch etwas selten. Bin da gerade auf https://github.com/bunkerity/bunkerweb gestoßen, evtl mal ansehen und die eigene Umgebung noch besser absichern.

Quote from TBT

Das stimmt, aber ja doch vor allem SSH. Ja, Mailserver werden auch permanent angebaggert, hab ich auf meinem eigenen Mailserver gesehen. Hier kann man mit f2b in der Tat was machen.

Spätestens bei dem Wordpress Thema bräuchte es aber dann schon eine WAF. Und eine solche ist ja doch etwas selten. Bin da gerade auf https://github.com/bunkerity/bunkerweb gestoßen, evtl mal ansehen und die eigene Umgebung noch besser absichern.

WAF ist aber nach meinem Verständnis rein http/https… das wäre noch ein weiterer Ansatz. Die kritischen Sachen sind hier eher geknackte Mailaccounts (also smtp/imap/pop3 und das zugehörige SASL - also wenn das jemand schafft.

ich hatte mal plötzlich ne Mailqueue bis sonstwo bloß weil jemand lange genug auf einem Useraccount rumprobiert hat. Und jede Menge Probleme mit der Reputation - erstmal finden/beheben/mailq aufräumen und dann erstmal über eine andere IP senden… brauch ich nicht wirklich

F2B schickt nun bei mir so einen Bot Minimum 3h auf die Bank, im Wiederholungsfall verdoppelt sich die Zeitstrafe automatisch auf bis zu 5 Wochen…

Webseiten sind hier zwar durchaus in php - aber kein WP etc. - das meiste ist eher hausgemacht. Insofern können die rootkit-Kameraden auch gleich ohne Antwort bleiben…

ssh lässt sich gut über geoip filtern.

da wird schonmal 90% weggefiltert.

https://tecadmin.net/allow-server-access-based-on-country/

Quote from extremmichi

ssh lässt sich gut über geoip filtern.

da wird schonmal 90% weggefiltert.

https://tecadmin.net/allow-server-access-based-on-country/

Ist ne Idee (ich vermute aus Perspektive eines flächenmäßig sehr großen Landes), führt aber IMHO nur bei sehr speziell eingeschränkter Anwesenheit der ssh-Nutzer (bzw. des ssh-Nutzers) zum Ziel. So sehr bin ich nun doch nicht in Deutschland verwurzelt, dass ich mit GeoIP aller Sorgen ledig wäre…

Hier mal eine Auswertung der IP-Adressen aus einer aktuellen Blockliste für ssh nach GeoIP (die letzten 24 h eines einzelnen Servers, auf dem noch keine Daten liegen):

1. Nix (bis auf Senegal und Ecuador), wo ich noch nicht war.

2. Wenn ich die Prozentzahlen der Länder addiere, wo ich selbst noch in diesem Monat sein werde, so bin ich bei ca. 30%. Da ist pauschales GeoIP-Blocking keine gute Idee.

3. Auffällig sind Rumänien und Niederlande (es riecht nach der Cloud eines großen französischen Anbieters), das lässt sich aber auf wenige IP-Netze eingrenzen, dazu China und Russland - und dann bin ich in Summe knapp über der 50%-Schwelle.

4. die mit 1,59%/1 testende IP pro Land nehme ich nicht wirklich so wichtig.

Quote from darkstar

Ist ne Idee (ich vermute aus Perspektive eines flächenmäßig sehr großen Landes), führt aber IMHO nur bei sehr speziell eingeschränkter Anwesenheit der ssh-Nutzer (bzw. des ssh-Nutzers) zum Ziel. So sehr bin ich nun doch nicht in Deutschland verwurzelt, dass ich mit GeoIP aller Sorgen ledig wäre…

Für deinen Sonderfall, wird das nicht helfen. Da hast du Recht.

Aber du bist da eher die Ausnahme , anstatt der Regelfall.

Die wenigsten hier müssen sich aus 30 verschiedenen Ländern

im Monat auf ihren Server einloggen

Quote from terence

Für SSH verwende ich eine zufallsgenerierte IPv6-Adresse, die ausschließlich dafür verwendet wird. IPv6-Adressen hat man ja im Überfluss.

Wobei das auch interressant klingt

Auch von mir einen Wunsch für die netcup Firewall im SCP.

Es wäre schön wäre schön wenn es für die von netcup vordefinierten Firewall-Regeln hinter jedem Port einen Button gäbe um diesen zu editieren.

Denn so könnte man z. B. die vordefinierte und aktivierte netcup Firewall (für Server ab der Einführung der netcup SCP Firewall) manuell editieren.

• z. B. einen von netcup vordefinierten Port der DROP steht freigeben wenn man ihn doch benötigt.

Denn so wie es aktuell vorkonfiguriert und aktiviert ist muss man manch Blöcke löschen und danach sich abmühen die restlichen Positionen wieder einzufügen.

In dem besagten Block den ich meine stehen die Ports 25 / 465 / 587 auf DROP. Da ist man gezwungen den Block mit allen 3 zu löschen wenn man nur einen wieder freigeben möchte und man muss hinterher die restlichen zwei Ports wieder auf DROP hinzufügen oder die SCP Firewall deaktivieren.

Daher wäre es sehr schön wenn wenn in der Auflistung der vorkonfigurierten Ports jeweils rechts hinter jedem Port eine Editierfunktion gebe.

Meine Empfehlung wäre, eigene Policys anzulegen. Die kannst du dann nach deinem Wünschen anlegen und konfigurieren.

Ich modularisiere alle "Pakete" rechts oben im SCP bei "Optionen - Firewall Policies" so:

image.png

dabei kann das mitunter ein Port oder auch eine Sammlung von mehreren UDP/TCP Ports sein und dann kann man sie bei

Pulldownbox Serverauswahl - Ausgewählter Server - Firewall - (unten rechts) Policies editieren

schlicht von links nach rechts oder rechts nach links bugsieren, ohne sich beim Server selbst nochmal Gedanken machen zu müssen.

D.h. für "eMail Outgoing" erstellt man eine "Mail outgoing" Policy in den allgemeinen Einstellungen und bugsiert sie dann beim betreffenden Server nach rechts, wenn man sie aktiv haben will. Finde ich eigentlich sehr übersichtlich und praktisch.

Ich hätte auch noch ein paar Wünsche:

Es ist aktuell nicht möglich ein IP-Protokoll zu erlauben (beispielsweise GRE). Es wäre praktisch, wenn man die IP-Protokollnummer einfach angeben könnte. Da ich aktiv GRE verwende kann ich somit die Firewall nicht nutzen.

Des Weiteren gibt es keine Möglichkeit selber "any protocol" zu machen (beispielsweise für ausgehenden Traffic). Das finde ich etwas schade.

Quote from mark22k

Es ist aktuell nicht möglich ein IP-Protokoll zu erlauben (beispielsweise GRE). Es wäre praktisch, wenn man die IP-Protokollnummer einfach angeben könnte. Da ich aktiv GRE verwende kann ich somit die Firewall nicht nutzen.

Es handelt sich bei der https://www.netcup.com/de/helpcenter/…server/firewall um eine "einfache" Firewall, die "Basisschutz" erlaubt. Dazu gehört GRE jetzt nicht unbedingt.

Welche Anwendung braucht denn zwingend GRE? Ich kenne das nur für VPN. Wieso kommen hierfür nicht auch andere VPN Optionen (Wireguard, Zerotier, Tailscale u.v.m.) in Frage? Diese funktionieren ohne weiteres mit der NC Firewall.

Man kann zwar nicht "any protocol" erlauben, aber m.E. ist auch kein Protokoll explizit mit den catch-all Regeln verboten.