Firewall für vServer durch Netcup

  • Hallo,


    ist geplant für VPS / RS wieder eine Firewall von Netcup Seite anzubieten? Früher gab es das anscheinend schon mal und der Betreiber Eures Rechenzentrums in Nürnberg bietet das neuerdings auch an. Eine sehr sinnvolle Funktion... Was sagt Netcup dazu?

  • Was verstehst du da unter Firewall? Den DDOS-Schutz? Den hat netcup ja auch.

    Naja, was eine Firewall für VPS/RS ist, ist doch ziemlich klar...
    Du könntest damit z.B. im SCP pro Server Firewall Regeln definieren, einzelne Ports freigeben, IP-Ranges freigeben, alle Ports sperren etc. In meinen Augen auch ein sehr sinnvolles Feature, da es unabhängig vom OS des Servers ist, weil es auf Providerseite „vor“ dem VPS/RS sitzt. Die Funktion würde z.B. verhindern, dass Docker mal wieder ungefragt Ports öffnet. Es würde auch die „Spezialisten“ schützen, die meinen Windows 10 auf ihren VPS installieren zu müssen.


    Der große Buchhändler bietet das für seine EC2 Instanzen an, die bunte Suchmaschine ebenfalls für die compute instances und der OS Hersteller der seit neuestem auch kleine Chips in Spritzen produziert bietet das auch an.


    Von mir ein klares +1

  • Genau. Eine Firewall ist eine Firewall:)

    Und um genau solche Szenarien wie zb Docker gehts. Außerdem könnte man trotz aller Absicherung dann in der Provider Firewall seinen SSH Port sperren. Wenn man dann auf den Server will lockt man sich vorher im Provider Menü ein und macht die Regel auf.


    Viele kleine Anbieter haben das, warum Netcup als Schwergewicht nicht??!!

  • Kenne das von der Konkurrenz auch. Per default sind dort alle incoming Ports dicht und es müssen gezielt die Wunschports geöffnet werden. Würde zumindest sicherlich dafür sorgen, dass der eine oder andere ungewollte Port wirklich zu bleibt. Aber im gleichen Atemzug ergäben sich dadurch sicher auch vermehrt Supportanfragen - die sich aber mit einem gut strukturierten Wiki/FAQ schnell lösen ließen.


    Letztendlich finde ich das System aber auch gut und sinnvoll. daher:

    +1

  • es ist zwar schon einiges dazu gesagt worden, aber ich gebe zu bedenken:

    jede Firewall, egal was sie macht und wie sie es macht erhöht die Latenzzeiten zum einem

    und zum anderen der Datendurchsatz wird dadurch auch geschmälert;


    ich würde eher meinen, dass sich die Kunden selbst um deren Firewalls auf den VPS/RSen kümmern sollten,

    und nicht dies zu lasten aller gehen soll;


    was ich aber durchaus f. snnvoll erachten würde - angesichts der doch kontroversen Diskussionen um DNS-Blacklists,

    dass Port 25 ausgehend nur per Supportticket nach draußen geöffnet werden sollte, um nicht reinen Webservern die

    "Chance" zu geben zu SPAM-Schleudern zu mutieren;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • bzgl. Port 25 stimme ich dir zu. Ist bei der Konkurrenz beispielsweise auch so gelöst: alle Ports bis auf 25 kannst musst du selbst in der GUI freigeben, Port 25 jedoch nur über den Support.


    Und ja, ich bin prinzipiell auch der Meinung, dass jeder selbst in der Lage sein sollte ne Firewall auf dem Server zu konfigurieren, aber die Realität sieht anders aus und was ist dann leider oftmals die Lösung? -> sudo systemctl disable firewalld, sudo ufw disable, etc. ;P

  • Kenne das von der Konkurrenz auch.

    Bevor hier eine mehrstellige Anzahl von Bestandskunden allerdings zu Supportanfragen bzgl. erneuter Freischaltung gedrängt wird, sollte man das aber besser ausschließlich als Buchungsoption (gegen entsprechenden Aufpreis) anbieten. Oder potenzielle Neukunden müssen eben zu besagter Konkurrenz wechseln (die das sicherlich auch entsprechend ein-/bepreist).


    Da die überwiegende Mehrheit der VPS-/RS-Nutzer sicherlich absichtlich Dienste auf verschiedenen Ports anbietet und eine regelmäßige (Selbst-)Kontrolle der laufenden Dienste implementiert haben sollte (entsprechende Standardhilfswerkzeuge/-dienste sind seit Jahren Bestandteil jeder Linux-Distribution), sehe ich persönlich keinen Nutzen einer externen Firewall und würde entsprechende Angebote explizit meiden. Wer sich einen zusätzlichen Schutz dadurch verspricht, der sollte zudem bedenken, dass viele/genügend Attacken (ein- und von infizierten Systemen insbesondere ausgehend) über Standardports abgewickelt werden.


    Die Funktion würde z.B. verhindern, dass Docker mal wieder ungefragt Ports öffnet.

    Und um genau solche Szenarien wie zb Docker gehts. Außerdem könnte man trotz aller Absicherung dann in der Provider Firewall seinen SSH Port sperren. Wenn man dann auf den Server will lockt man sich vorher im Provider Menü ein und macht die Regel auf.

    Wenn Docker mal wieder(!!!) ungefragt(!) Ports öffnen kann, die von außen ansprechbar sind, dann ist das ein grundlegendes Konfigurationsproblem, welches ich mit dem Betrieb eines offenen E-Mail-Relays gleichsetzen würde (deutlich formuliert: grobe Fahrlässigkeit des Betreibers). Solange ich Anwendungen nicht hinreichend vertrauen kann, gehören sie gar nicht installiert oder hilfsweise in einen unprivilegierten Container, dessen Ein- und Ausgaben überwacht werden. Und spätestens(!) sobald die Alternative Podman (weniger "Docker rootless") scheinbar(!) keine Option ist, gehört eine Docker-basierte Installation ihrerseits in einen wirklich unprivilegierten Container.


    Gerade einen SSH-Port würde man in der Praxis entweder nur via VPN (inklusive Zugriffsadressen-/Schlüsselkontrolle, -rotation, usw.) oder über knock o.ä. öffentlich verfügbar machen oder überhaupt erst "on demand" über die existierende virtuelle Konsole starten.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Wenn Docker mal wieder(!!!) ungefragt(!) Ports öffnen kann, die von außen ansprechbar sind, dann ist das ein grundlegendes Konfigurationsproblem, welches ich mit dem Betrieb eines offenen E-Mail-Relays gleichsetzen würde (deutlich formuliert: grobe Fahrlässigkeit des Betreibers). Solange ich Anwendungen nicht hinreichend vertrauen kann, gehören sie gar nicht installiert oder hilfsweise in einen unprivilegierten Container, dessen Ein- und Ausgaben überwacht werden. Und spätestens(!) sobald die Alternative Podman (weniger "Docker rootless") scheinbar(!) keine Option ist, gehört eine Docker-basierte Installation ihrerseits in einen wirklich unprivilegierten Container.

    +1

    It's me, only me, pure michi 🦆

    RS 1000 SAS G8 | Cyber Quack

    VPS: 50 G7 |B Ostern 2017|200 | Karneval | piko

    WH: SmallEi | Adv17 Family |4000 SE|1000 SE