Wünsche für die netcup-Firewall

Hallo terence

vielen Dank für dein Feedback!

Wir haben deine Anregungen intern an die jeweils zuständigen Stellen weitergegeben.

Liebe Grüße
Sarah & das netcup-Team

Guten Morgen terence

ich hatte dein Feedback ja weitergegeben - zu einem Punkt gibt es nun News!

Zitat

SCP: Wenn man eine Policy ändert, erscheint beim Speichern ein Hinweis darauf, wieviele Server von der Änderung betroffen sind. Hier wäre eine Liste der Servernamen total super. Oder man zeigt die Serverliste direkt unterhalb der Policy-Regeln an - dann sieht man sie schon vorher, was sogar noch besser wäre.

Bei Editierung einer Policy werden die von der Anpassung betroffenen Server nun unten gelistet.

Ich wünsche dir noch einen schönen Tag und liebe Grüße
Sarah

Wäre auch gut 5 Templates zu haben.
Dies hilft für die ganzen Noobs immens. Wahrscheinlich machen alle irgendwelche Fehler. Für euch einmal Arbeit.

Hier als Beispiel fünf gängige Firewall-Regelwerke für verschiedene virtuelle Server-Rollen:

1. Einfacher Webserver (ohne E-Mail) Eingehend erlaubt: Port 80 (HTTP), 443 (HTTPS) und 22 (SSH, idealerweise auf die eigene IP beschränkt). Alles andere wird verworfen. Das ist das häufigste Setup für einen VPS, der eine Website oder API hostet. Ausgehend sollte DNS (53), HTTP/HTTPS (für Paketupdates) und NTP (123 für Zeitsynchronisation) erlaubt sein – alles andere blockieren.

2. Datenbankserver (nur Backend) Eingehend nur den Datenbank-Port erlauben (z. B. 3306 für MySQL, 5432 für PostgreSQL) und auf die IP(s) der Anwendungsserver beschränken. SSH nur von der Verwaltungs-IP. Sämtlicher anderer eingehender Verkehr wird blockiert, auch HTTP/HTTPS. So bleibt die Datenbank komplett vom öffentlichen Internet abgeschirmt.

3. Web- und Mailserver kombiniert Eingehend erlaubt: 80, 443, 22 (SSH) sowie die Mail-Ports: 25 (SMTP), 587 (Submission), 993 (IMAPS) und optional 110/995 (POP3/POP3S). Ausgehend muss zusätzlich Port 25 für den Mailversand freigegeben sein. Dieses Regelwerk eignet sich für einen VPS, der sowohl Webhosting als auch E-Mail übernimmt.

4. Anwendungs-/API-Server (hinter einem Load Balancer) Eingehend nur vom Load Balancer auf dem App-Port erlauben (z. B. 8080, 3000 oder was auch immer die Anwendung nutzt). SSH von der Verwaltungs-IP. Alles andere verwerfen. Da der Load Balancer den öffentlichen Verkehr übernimmt, muss dieser Server nie direkt erreichbar sein.

5. Entwicklungs-/Staging-Server (maximal abgesichert) Eingehend nur SSH (Port 22) von einem VPN oder einem bestimmten IP-Bereich erlauben. Optional einen höheren Port für eine Staging-Seite freigeben, ebenfalls IP-beschränkt. Alles andere blockieren. Das ist das restriktivste Regelwerk – der Server ist für die Öffentlichkeit praktisch unsichtbar und nur für das eigene Team erreichbar.

Zitat von friend_of_root

Wäre auch gut 5 Templates zu haben.
Dies hilft für die ganzen Noobs immens. Wahrscheinlich machen alle irgendwelche Fehler. Für euch einmal Arbeit.

Wenn man ehrlich ist, ist die UI/UX für diese Einstellungen zwar ambitioniert gedacht, in der Praxis aber eher mühsam. Man möchte schnell mal die Firewall aktivieren, muss sich für die nötigen 15 Regeln ziemlich abmühen.
Man muss sich die hundert Postings in Erinnerung rufen, wo sich die User hier gegenseitig erklärt haben wie man die Firewall bedient. In den Diskussionen ist es praktisch nie um strategische Entscheidungen hinsichtlich Einstellungen gegangen, sondern einfach wie man es endlich reingeklopft kriegt.
Die Startpunkte machen das alles fluppe. Dann hat man einen Startpunkt der gleich funkt und nur 1-2 Adaptionen nach Vorlage.

Mein Wunsch wäre:

Macht die Firewall komplett Stateful.

Ich kann mir nicht vorstellen, dass das derzeit eine Hardwareeinschränkung ist, sondern lediglich Konfigurationssache seitens Netcup (!?).

Das ist (je nach Umfang der betriebenen Services) derzeit nicht nur absoluter "Pain-in-the-Ass", sondern schreckt auch nicht so Versierte ab....wenn selbst gestandene ITler hier im Forum über Seiten hinweg sich austauschen wie/was/wo noch an Ports dazu muss, dazu müssen könnte und sollte und überhaupt.

Ich würde es toll finden, wenn nach der Editierung einer Policy nicht nur die Vertragsnummern der jeweiligen Server da stehen würden, sondern die Spitznamen.

Leude. Wir sind IT Admins. Wir sollten eine Firewall Konfiguration mit den gegebenen Mitteln hinbekommen. Jeder Server ist unterschiedlich, daher baut Euch doch bitte Euere eigenen Regelpakete. Kein Template sollte Euch die Beschäftigung damit, welche Ports in welche Richtung und ob TCP oder UDP offen sein sollen, abnehmen. Denn das würde bedeuten, dass Ihr nicht komplett verstanden oder drüber nachgedacht habt, was genau passiert, sondern einfach "hirnlos" ein Template ausgewählt habt.

Zitat von TBT

Leude. Wir sind IT Admins. Wir sollten eine Firewall Konfiguration mit den gegebenen Mitteln hinbekommen. Jeder Server ist unterschiedlich, daher baut Euch doch bitte Euere eigenen Regelpakete. Kein Template sollte Euch die Beschäftigung damit, welche Ports in welche Richtung und ob TCP oder UDP offen sein sollen, abnehmen. Denn das würde bedeuten, dass Ihr nicht komplett verstanden oder drüber nachgedacht habt, was genau passiert, sondern einfach "hirnlos" ein Template ausgewählt habt.

Ne, da sind 1000de Server von Leuten, die keine Ahnung haben und keine IT Admins sind.

Zitat von friend_of_root

Ne, da sind 1000de Server von Leuten, die keine Ahnung haben und keine IT Admins sind.

Dann müssen sie durch Beschäftigung mit der Materie dazu gezwungen werden, sich mit der Sicherheit ihres Servers auseinanderzusetzen. Die Richtung "mach alles so, dass es selbst absolute Laien verstehen" ist falsch und nicht hilfreich. Nicht mal für die Personen selbst. Insbesondere wenn so viel Schaden angerichtet werden kann wie mit einem Server.

Zitat von TBT

Dann müssen sie durch Beschäftigung mit der Materie dazu gezwungen werden, sich mit der Sicherheit ihres Servers auseinanderzusetzen. Die Richtung "mach alles so, dass es selbst absolute Laien verstehen" ist falsch und nicht hilfreich. Nicht mal für die Personen selbst. Insbesondere wenn so viel Schaden angerichtet werden kann wie mit einem Server.

Es kann sich auch jeder einen Mailserver oder ein CMS bauen.. sollten aber 99,999% nicht.
Am besten alles professionalisieren bei dem eine Person leicht Fehler machen kann. Für Netcup sehe ich da noch ein Riesenpotential bei Backups.

Zitat von -Manu-

Macht die Firewall komplett Stateful.

Auch wenn das technisch wahrscheinlich nur eine Einstellungsänderung ist, hat sich Netcup sicherlich bewusst und fundiert dagegen entschieden, denn diese Konfiguration ist ja doch für die meisten unerwartet. Das Problem mit UDP Tracking ist, dass es keinen offiziellen Verbindungszustand gibt. Jedes UDP Paket steht für sich. Verbindungen sind in UDP einfach nur die Information, dass in den letzten x Sekunden ein Paket mit dieser Portkombination gesehen wurde. Clients beenden die "Verbindung" nicht sondern senden einfach keine weiteren Pakete. Man kann die Tupel aber nicht schnell rausschmeißen, weil so Protokolle wie SIP oft nur im Abstand mehrerer Minuten Keepalive-Pakete senden, wenn überhaupt. Viele UDP Protokolle verwenden aus Sicherheitsgründen ständig neue Sourceports (um Spoofing zu erschweren) und nutzen sehr kurzlebige "Verbindungen", z.B. im Fall von DNS regelmäßig nur ein Fragepaket und ein Antwortpaket, die dann in der Trackingtabelle rumlungern. Das ist schon unter normalen Bedingungen ein großer Resourcenverbrauch, aber vor allem ist es ein Scheunentor für Denial-of-Service Angriffe. UDP Pakete sind trivial fälschbar, weil es keinen Handshake gibt, bei dem der Initiator das Antwortpaket des Servers sehen muss, um die "Verbindung" herzustellen. Methoden dagegen gibt es, aber die sind nicht allgemein für UDP spezifiziert sondern spezifisch für Anwendungsprotokolle. Man könnte also simpelst die Trackingtabelle fluten.

Ich könnte mir vorstellen, dass es da fertige Hostinglösungen für diese stateless Firewalls gibt, eine solche hat Straaaat0 auch schon seit langem.

Zitat von friend_of_root

Es kann sich auch jeder einen Mailserver oder ein CMS bauen.. sollten aber 99,999% nicht.
Am besten alles professionalisieren bei dem eine Person leicht Fehler machen kann. Für Netcup sehe ich da noch ein Riesenpotential bei Backups.

Stimmt!

Hier ist die Mailkuh das beste Beispiel. 2-3 Befehle kopieren, docker nimmt dir die Arbeit ab.

alles ist fertig und läuft. Der Mailserver ist jetzt sicher, aber was ist mit dem Linux da drunter?

Ich bin auch kein Freund davon, dass sich jeder einen vServer nimmt und "Server-Admin" ist.

Aber warum denen, die keine Ahnung haben, dann nicht wenigstens eine FW an die Hand zu geben, die deren Wissenstand

entspricht. Es wird uns danach allen besser gehen. Am Ende fragen die noch eine KI wie man eine Server absichert.

Zitat von extremmichi

Am Ende fragen die noch eine KI wie man eine Server absichert.

Unpopular opinion: richtig eingesetzt können agentische Systeme (z.B. Claude Code) m.E. sehr bei der Verwaltung von IT Infrastrukturen helfen. Eine kritische Analyse der eigenen Docker Compose Files oder sonstiger Projekte kann sehr helfen.

Zitat von TBT

Unpopular opinion: richtig eingesetzt können agentische Systeme (z.B. Claude Code) m.E. sehr bei der Verwaltung von IT Infrastrukturen helfen. Eine kritische Analyse der eigenen Docker Compose Files oder sonstiger Projekte kann sehr helfen.

Das unterschreibe ich mehr oder weniger gern. Aber es erfordert dann eben jemanden, der in der Lage ist, die Vorschläge einer KI zu prüfen und zu beurteilen. Wenn das allerdings nicht (mehr...) gegeben ist, dann bewegt man sich m.E. auf sehr dünnem Eis.

Das gilt allerdings erst recht, wenn man keine KI einsetzt und selbst auch keine Ahnung hat oder nicht einmal die Notwendigkeit einer zumindest grundlegenden Absicherung sieht. Da mache ich mir nichts vor, die Mehrheit der vServer im Internet ist wenig bis gar nicht gesichert. Das mag hier im Forum einen anderen Anschein vermitteln, weil diejenigen, die hier im Forum zu dem Thema nachfragen, diejenigen sind, die immerhin die Notwendigkeit einer Absicherung erkannt haben.

Ich brauche normalerweise keine externe Firewall wenn ich einen Debian-Server selber voll unter Kontrolle habe.
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.

Derzeit bekommen alle eigenen Server per banaction mitgeteilt wenn bei einem der eigenen Server ein Gast auffällig wurde und an blocklist.de fürs Abuse arbeite ich derzeit. Es ist nämlich gefühlt echt viel im Netcup-Netzen.

Es wäre z.B. schick, auch der Firewall direkt Nachricht zu geben und nicht erst auf Server-Ebene zu blocken…

Das geht zwar prinzipiell schon per REST-API, mich würde aber auch dafür eine Art Schwarmintelligenz interessieren - d.h. viele Server lassen Fail2ban reporten an eine Blocklist und die Firewall bindet dann so eine Blocklist ein, z.B. erst wenn x verschiedene Server den gleichen nervenden Gast gemeldet haben die IP >nul-routed…

Ich hoffe, die Idee wurde deutlich…