Umfrage zur vorgeschalteten Firewall vor dem eigenen Server

  • Firewall vor dem eigenen Server gewünscht? 100

    1. Ja (21) 21%
    2. Ja, aber nur optional (57) 57%
    3. Nein (22) 22%

    Da es mittlerweile sehr viele Mitbewerber gibt, die ihren Kunden auch ohne weitere Kosten eine Firewall vor dem eigenen Server schalten, die sie bei Bedarf auch selber administrieren dürfen, hier mal diese Umfrage.

  • Ich brauch das zwar nicht, fände die aber aber prinzipiell gut solange ich das nicht mitfinanzieren muss :D Vllt könnte ja das ja ein zubuchbares Extra werden.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.mfnalex.de

    Discord: discord.jeff-media.com

  • Ich bin der Uwe und ich bin auch dabei...


    Ne Spaß beiseite. Wäre dafür, weil:

    - dann weniger angreifbare Server von Ahnungslosen offen sind.

    - dadurch der AS seltener in Blacklists landet

    - die Absicherung außerhalb des OS erfolgt

    - die Verwaltung einfacher ist

    - jeder halbwegs klar denkende Mensch in einer kritischen Netzwerkumgebung eine Firewall einsetzen würde

  • „Jeder halbwegs klar denkende Mensch“ braucht aber eigentlich keine Firewall weil er selber kontrolliert welche Ports nach außen offen sind und was darauf läuft, und auch nicht unbedingt Lust hat bei jeder Änderung sich irgendwo einzuloggen um das freizuschalten.


    Insbesondere wenn iptables bei praktisch JEDER Distribution dabei ist.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.mfnalex.de

    Discord: discord.jeff-media.com

  • - dann weniger angreifbare Server von Ahnungslosen offen sind.

    - dadurch der AS seltener in Blacklists landet

    Dazu müsste man aber standardmäßig bereits Ports sperren. Ich bin da eher skeptisch, ob der Nutzen (mir ist eh nur ein wenig seriöse Blacklist bekannt, die AS blockt) größer ist als der zusätzliche Support-Aufwand.

    - die Verwaltung einfacher ist

    Inwiefern?

    - jeder halbwegs klar denkende Mensch in einer kritischen Netzwerkumgebung eine Firewall einsetzen würde

    Wer interne Dienste ungeschützt nach außen öffnet und keine Firewall verwendet, wird auch keine externe Firewall korrekt konfigurieren.

  • Wo ist den technisch der Vorteil einer externen Firewall?

    ohne einer internen Firewall gibt es gar keinen Vorteil;


    hingegen hat man eine ordentliches Firewall am vServer ( mfnalex hats ja erwähnt, z.B. IPtables ),

    und ist diese auch sauber konfiguriert, dann hat eine externe zusätzliche Firewall gewisse zusätzliche Sicherheitsaspekte;


    eine Schadsoftware welche man sich einfängt kann die Firewall am Host sehr schnell etwas 'optimieren',

    bei der externen Firewall schau ich mir das an, wie des gehen soll;


    f. diejenigen die einen Windows Server betreiben, ist das durchaus fast schon notwendig;:/

  • Ich nutze in der Regel bei den Servern bei netcup das VLAN und habe davor eine PFSense vorgeschaltet. Leider ist es so, dass bei den Servern welche sich im VLAN befinden die externe NIC nicht vom HOST aus deaktiviert werden kann. Hier könnte ich mir die vorgeschaltete Firewall durchaus vorstellen um ausschließlich Traffic über das VLAN zuzulassen. Ansonsten könnte es durch einen Konfigurationsfehler oder Upgrades dazu kommen, dass die NIC unerwünscht wieder aktiv wird.

  • Leider ist es so, dass bei den Servern welche sich im VLAN befinden die externe NIC nicht vom HOST aus deaktiviert werden kann. Hier könnte ich mir die vorgeschaltete Firewall durchaus vorstellen um ausschließlich Traffic über das VLAN zuzulassen. Ansonsten könnte es durch einen Konfigurationsfehler oder Upgrades dazu kommen, dass die NIC unerwünscht wieder aktiv wird.

    Schon einmal probiert, die Schnittstelle ens3/eth0 mittels udev-Regel auszublenden (siehe hier)? Die VLANs haben ja ihre eigene (wie von Doim1990 erwähnt):

    Code
    [2021-04-25T16:47:24+0200] root@vserver17<kvm>:~/bin# ls -l /sys/class/net
    total 0
    drwxr-xr-x  2 root root 0 2021-04-25 07:05:03 ./
    drwxr-xr-x 68 root root 0 2021-04-25 07:02:59 ../
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:05 ens3 -> ../../devices/pci0000:00/0000:00:03.0/virtio0/net/ens3/
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:04 ens4 -> ../../devices/pci0000:00/0000:00:04.0/virtio1/net/ens4/
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:07 ens6 -> ../../devices/pci0000:00/0000:00:06.0/virtio2/net/ens6/
    lrwxrwxrwx  1 root root 0 2021-04-25 16:47:30 lo -> ../../devices/virtual/net/lo/

    Die Datei, in welcher man die Regel ablegt, lässt sich ja mittels chattr +i vor Veränderungen schützen (kein normales Update-Script wird sich über dieses Attribut hinwegsetzen). Das ist zwar weniger narrensicher als eine Deaktivierung/Entfernung der Schnittstelle in der KVM-Definition (welche im SCP derzeit nicht unterstützt wird), aber kaum unabsichtlich umkehrbar.

    (Der obige udev-basierte Ansatz setzt natürlich die Nutzung von Linux voraus, aber bei anderen Betriebssystemen sollten sich Alternativen finden.)

  • Für eine komplette externe Firewall hätte ich persönlich keine Verwendung. Das würde ich eher über das vLAN und einen weiteren Server realisieren. Die primäre NIC deaktivieren zu können, wäre aber tatsächlich super! :)


    Soweit ich das verstanden habe setzt das netcup System diese NIC (bzw. die IPv4-Adresse) nur beim Rettungssystem oder Neuinstallieren voraus. Das könnte das SCP ja entsprechend abfangen und sie nur in diesen Fällen einbinden.

  • Auch fein wäre es, wenn es (gerne auch irgendwo versteckt nur für Bestandskunden), gegen kleinen Rabatt, Produkte OHNE jegliche externe NIC / IP Adressen gäbe. Weiß nicht inwiefern da Einsparpotential besteht, da die IP Ranges bei Netcup womöglich sowieso in Massen herumliegen (was sich mit IPv4 Restriktionen evtl. ändern könnte), aber vielleicht könnte man den ein oder anderen Cent ja durch ein solch abgespecktes Produkt dennoch an den Kunden weitergeben.

  • Auch fein wäre es, wenn es (gerne auch irgendwo versteckt nur für Bestandskunden), gegen kleinen Rabatt, Produkte OHNE jegliche externe NIC / IP Adressen gäbe.

    Sowas gab es früher wohl tatsächlich schon einmal (allerdings zum gleichen Preis wie äquivalente Produkte mit IPv4, lediglich die Einrichtungsgebühr entfiel – in der genannten Preiskategorie allerdings auch nicht sonderlich verwunderlich):

    Code
    % grep ">VPS 10 G7 IPv6<" * | sort -k1 | tail -1; grep ">VPS 20 G7 IPv6<" * | sort -k1 | tail -1
    netcup_produkte.xml.2017-05-26:         <ProduktName>VPS 10 G7 IPv6</ProduktName>
    netcup_produkte.xml.2019-03-02:         <ProduktName>VPS 20 G7 IPv6</ProduktName>
  • Dazu müsste man aber standardmäßig bereits Ports sperren. Ich bin da eher skeptisch, ob der Nutzen (mir ist eh nur ein wenig seriöse Blacklist bekannt, die AS blockt) größer ist als der zusätzliche Support-Aufwand.

    Inwiefern?

    Wer interne Dienste ungeschützt nach außen öffnet und keine Firewall verwendet, wird auch keine externe Firewall korrekt konfigurieren.

    Angenommen, die Firewall hat in der Standardkonfig alle Ports geschlossen. Wer dann keine Ahnung hat, muss nur solche Ports freigeben, die er benötigt. Ich hoffe ja immer noch, dass die Server ordentlich abgesichert sind. Das ist meist nicht der Fall. Auch wenn daraus nun keine Vollkaskomentalität entstehen soll, sorgt man direkt für Sicherheit.


    Eine GUI Firewall wird für Anfänger sicher einfacher zu verwalten sein als ufw netfilter iptables etc.

  • „Jeder halbwegs klar denkende Mensch“ braucht aber eigentlich keine Firewall weil er selber kontrolliert welche Ports nach außen offen sind und was darauf läuft, und auch nicht unbedingt Lust hat bei jeder Änderung sich irgendwo einzuloggen um das freizuschalten.


    Insbesondere wenn iptables bei praktisch JEDER Distribution dabei ist.

    okay, dann sind die „Unfälle“ auf shodan.io also gewollt.