Ich brauch das zwar nicht, fände die aber aber prinzipiell gut solange ich das nicht mitfinanzieren muss 
Vllt könnte ja das ja ein zubuchbares Extra werden.
mmmh.. Wo ist den technisch der Vorteil einer externen Firewall? Ernst gemeinte Frage.
"Ich brauche nur Port 443 - den Rest bitte zu, brauche ich mich nicht kümmern" verstehe ich - aber wenn es mehr Services werden?
/Edit/: Diskussion dazu hier gefunden: https://forum.netcup.de/netcup…BCr-vserver-durch-netcup/
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.
- 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.
die externe NIC nicht vom HOST aus deaktiviert werden kann.
die Pakete vom VLAN müssen ja irgendwie durch die externe NIC durch, wie soll es auch sonst gehen?
du wirst auch keine IPv6-in-IPv4 Pakete raus bringen, wenn Du IPv4 deaktivierst;
Ich weiß nicht wie das technisch umgesetzt wird aber wenn man einen Server einem VLAN hinzufügt bekommst du ja eine zusätzliche virtuelle NIC
Dann könnte man ja theoretisch die eine deaktivieren
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):
[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.
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!
CC [netcup] Johannes B. : Vielleicht wäre das sogar ein relativ einfach umsetzbares SCP-Feature? 
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):
% 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.
Wer dann keine Ahnung hat, muss nur solche Ports freigeben, die er benötigt.
Wer keine Ahnung hat, stellt die Firewall einfach aus oder ruft den Support an. 
Davon abgesehen müsste man bei deinem Blacklist-Beispiel eher Port 25 ausgehend blocken.
okay, dann sind die „Unfälle“ auf shodan.io also gewollt.
Was hat das denn miteinander zu tun? Wer seine 3€ China-Überwachungskamera direkt ans Internet hängt ist eben kein „halbwegs klar denkender Mensch“ IMHO
