6
PPOe Routing im VMware ESXi sicher?
Hallo an alle,
ich möchte meinen Homeserver umrüsten.
Im moment verwende ich als Server Opensuse 10.3 darauf ist Vmware Server (enthält: W2k3; OpenVPN) installiert.
Opensuse kümmert sich um die DSL einwahl mit PPOe und das ganze ist mit der Susefirewall2 geschützt, und läuft als Mailserver nebenbei.
Der neue Server soll VMware ESXi 4.1 bekommen, und drei Netzwerkkarten.
Der Server kann IOMMU und ich hatte vorgehabt, eine der Netzwerkkarten direkt mit passthrough
In eine VM zu leiten, welche sich um das Routing und NAT kümmert. (Entweder Opensuse 11.4, oder
eine der bekannten Router-Linux-Distros (Untangle, IPcop, etc.).
Jedoch hab ich etwas bedenken bezüglich der Sicherheit, da das ganze ja bis zum ESXi mehr oder weniger ungefiltert aufläuft, und erst in der VM PPOe geroutet wird.
Oder wäre ein standalone Router doch die bessere Variante, denke da an einen RV042, oder ITX-Board mit Untangle; IPCop ?
Beim RV042 hab ich das Problem mit meinem Dyndns, ich verwende drei IPs, kann aber nur eine
eintragen. Bis jetzt unter Linux mit dem ddclient ist das kein Problem.
Bin für Anregungen dankbar!
ich möchte meinen Homeserver umrüsten.
Im moment verwende ich als Server Opensuse 10.3 darauf ist Vmware Server (enthält: W2k3; OpenVPN) installiert.
Opensuse kümmert sich um die DSL einwahl mit PPOe und das ganze ist mit der Susefirewall2 geschützt, und läuft als Mailserver nebenbei.
Der neue Server soll VMware ESXi 4.1 bekommen, und drei Netzwerkkarten.
Der Server kann IOMMU und ich hatte vorgehabt, eine der Netzwerkkarten direkt mit passthrough
In eine VM zu leiten, welche sich um das Routing und NAT kümmert. (Entweder Opensuse 11.4, oder
eine der bekannten Router-Linux-Distros (Untangle, IPcop, etc.).
Jedoch hab ich etwas bedenken bezüglich der Sicherheit, da das ganze ja bis zum ESXi mehr oder weniger ungefiltert aufläuft, und erst in der VM PPOe geroutet wird.
Oder wäre ein standalone Router doch die bessere Variante, denke da an einen RV042, oder ITX-Board mit Untangle; IPCop ?
Beim RV042 hab ich das Problem mit meinem Dyndns, ich verwende drei IPs, kann aber nur eine
eintragen. Bis jetzt unter Linux mit dem ddclient ist das kein Problem.
Bin für Anregungen dankbar!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 163947
Url: https://administrator.de/contentid/163947
Ausgedruckt am: 23.11.2024 um 02:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
einen Router dazwischen zu setzen ist vom Sicherhetisstandpunkt auf jeden Fall besser als ein Server Bertriebssystem direkt im Internet zu platzieren.
Allerdings kann ich dir nicht sagen ob dein RV042 oder andere Router mit mehreren dyndns accounts umgehen können.
Ein Cisco 871/881 kann das zumindest schon.
brammer
einen Router dazwischen zu setzen ist vom Sicherhetisstandpunkt auf jeden Fall besser als ein Server Bertriebssystem direkt im Internet zu platzieren.
Allerdings kann ich dir nicht sagen ob dein RV042 oder andere Router mit mehreren dyndns accounts umgehen können.
Ein Cisco 871/881 kann das zumindest schon.
brammer
Hi,
ich denke in der von dir vorgeschlagenen Konfiguration sollte das problemlos machbar sein.
Da der Hypervisor beim Passtrough die direkte Kontrolle über das Gerät, in diesem Fall den NIC, verliert sollte im Umkehrschluss ein Zugriff über die NIC auf den Hypervisor auch unmöglich sein.
Aber Vorsicht bei der eingesetzten NIC. Es gibt Hardware die vom Hypervisor trotz Passtrough noch selbst verwendet werden kann (ein sehr nützliches Feature, nur nicht in deinem Fall ;))
Grüße
Bastian
ich denke in der von dir vorgeschlagenen Konfiguration sollte das problemlos machbar sein.
Da der Hypervisor beim Passtrough die direkte Kontrolle über das Gerät, in diesem Fall den NIC, verliert sollte im Umkehrschluss ein Zugriff über die NIC auf den Hypervisor auch unmöglich sein.
Aber Vorsicht bei der eingesetzten NIC. Es gibt Hardware die vom Hypervisor trotz Passtrough noch selbst verwendet werden kann (ein sehr nützliches Feature, nur nicht in deinem Fall ;))
Grüße
Bastian
Ob es besser ist, ist letztlich Ansichtssache. Sicherer ist in jedem Falle immer eine externe Lösung. Auch im Hinblick auf die Ausfallsicherheit.
Mit einem Mini ITX und z.B. PfSense oder Monowall hast du auch keinerlei Probleme mit deinen 3 IP Adressen:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Mit einem Mini ITX und z.B. PfSense oder Monowall hast du auch keinerlei Probleme mit deinen 3 IP Adressen:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Hallo,
schonmal danke für die Antworten. Ich denke dann auch, dass eine externe Lösung mehr Sinn macht, ich habe auf der Wiki-Seite zu IPCop das hier gefunden
http://www.ipcopwiki.de/index.php/%C3%9Cber_IPCop
Zitat daraus:
Die Zeitschrift c't aus dem Heise-Verlag hat im Rahmen eines Server-Projekts den „c't-Debian-Server“ vorgestellt, in dem IPCop in User Mode Linux, einer virtuellen Maschine unter Linux, läuft. Dies spart einen zweiten Rechner für die Firewall ein, wird von vielen Fachleuten jedoch als unsicher eingestuft, da ein Angreifer die Kontrolle über den kompletten Rechner übernehmen könnte, (siehe Artikel bei IPCop-Forum.de). Das Risiko ist nicht auszuschließen, aber die Angriffswege sind recht unwahrscheinlich:
Der Angreifer findet und nutzt einen Fehler im Bridging-Code zur virtuellen Maschine und hat damit direkte Kontrolle über den Rechner erlangt. Der Bridge-Code soll die Daten nur zwischen den Netzwerken weiterreichen, ohne in irgendeiner Art die Daten zu interpretieren. Damit sollte der Bridge-Code über das Netzwerk nicht angreifbar sein.
Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und greift dann mit „bewährten Mitteln“ über das Netzwerk den Rechner an. Dieses Szenario ist der GAU für eine Firewall, bei dem die Firewall selbst vom Angreifer für einen Angriff benutzt wird. Hier besteht auch kein Unterschied mehr zwischen einer Firewall auf eigener Hardware und einer Firewall in einer virtuellen Maschine.
Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und findet und nutzt dann einen Fehler im User Mode Linux, um aus der virtuellen Maschine auszubrechen, und schließlich findet und nutzt einen Fehler im Host-Betriebssystem (das direkt auf der Hardware läuft), um die Kontrolle über den Rechner zu erlangen. Drei kaskadierte Fehler sind sehr unwahrscheinlich. Auch hier tritt wieder der Firewall-GAU auf, der Angreifer nutzt die Firewall als Plattform für einen weiteren Angriff.
Ein deutlich höheres Risiko besteht jedoch, wenn neben der Firewall weitere Server-Anwendungen (insbesondere Webserver) auf der gleichen Hardware laufen, wie es auch im c't-Debian-Server der Fall sein kann. Ein Angreifer, der durch einen Fehler in diesen Server-Anwendungen innerhalb der virtuellen Maschine Administrator-Rechte erlangt, könnte durch einen weiteren Fehler in der Virtualisierungssoftware auch Administrator-Rechte im Hostsystem bekommen. Dann ist auch der Weg zur Modifikation der virtuellen Maschine der Firewall frei. Da gerade in Webservern ständig Fehler gefunden werden, müsste man auf die Fehlerfreiheit der im Allgemeinen recht komplexen Virtualisierungssoftware bauen (dies gilt für UML, aber genauso für z.B. VMware, Xen, QEMU). Dies ist durchaus kein unrealistisches Szenario, Firewalls in virtuellen Maschinen sollten deshalb nur dann eingesetzt werden, wenn man wirklich weiß, was man tut.
Grüße Michi
schonmal danke für die Antworten. Ich denke dann auch, dass eine externe Lösung mehr Sinn macht, ich habe auf der Wiki-Seite zu IPCop das hier gefunden
http://www.ipcopwiki.de/index.php/%C3%9Cber_IPCop
Zitat daraus:
Die Zeitschrift c't aus dem Heise-Verlag hat im Rahmen eines Server-Projekts den „c't-Debian-Server“ vorgestellt, in dem IPCop in User Mode Linux, einer virtuellen Maschine unter Linux, läuft. Dies spart einen zweiten Rechner für die Firewall ein, wird von vielen Fachleuten jedoch als unsicher eingestuft, da ein Angreifer die Kontrolle über den kompletten Rechner übernehmen könnte, (siehe Artikel bei IPCop-Forum.de). Das Risiko ist nicht auszuschließen, aber die Angriffswege sind recht unwahrscheinlich:
Der Angreifer findet und nutzt einen Fehler im Bridging-Code zur virtuellen Maschine und hat damit direkte Kontrolle über den Rechner erlangt. Der Bridge-Code soll die Daten nur zwischen den Netzwerken weiterreichen, ohne in irgendeiner Art die Daten zu interpretieren. Damit sollte der Bridge-Code über das Netzwerk nicht angreifbar sein.
Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und greift dann mit „bewährten Mitteln“ über das Netzwerk den Rechner an. Dieses Szenario ist der GAU für eine Firewall, bei dem die Firewall selbst vom Angreifer für einen Angriff benutzt wird. Hier besteht auch kein Unterschied mehr zwischen einer Firewall auf eigener Hardware und einer Firewall in einer virtuellen Maschine.
Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und findet und nutzt dann einen Fehler im User Mode Linux, um aus der virtuellen Maschine auszubrechen, und schließlich findet und nutzt einen Fehler im Host-Betriebssystem (das direkt auf der Hardware läuft), um die Kontrolle über den Rechner zu erlangen. Drei kaskadierte Fehler sind sehr unwahrscheinlich. Auch hier tritt wieder der Firewall-GAU auf, der Angreifer nutzt die Firewall als Plattform für einen weiteren Angriff.
Ein deutlich höheres Risiko besteht jedoch, wenn neben der Firewall weitere Server-Anwendungen (insbesondere Webserver) auf der gleichen Hardware laufen, wie es auch im c't-Debian-Server der Fall sein kann. Ein Angreifer, der durch einen Fehler in diesen Server-Anwendungen innerhalb der virtuellen Maschine Administrator-Rechte erlangt, könnte durch einen weiteren Fehler in der Virtualisierungssoftware auch Administrator-Rechte im Hostsystem bekommen. Dann ist auch der Weg zur Modifikation der virtuellen Maschine der Firewall frei. Da gerade in Webservern ständig Fehler gefunden werden, müsste man auf die Fehlerfreiheit der im Allgemeinen recht komplexen Virtualisierungssoftware bauen (dies gilt für UML, aber genauso für z.B. VMware, Xen, QEMU). Dies ist durchaus kein unrealistisches Szenario, Firewalls in virtuellen Maschinen sollten deshalb nur dann eingesetzt werden, wenn man wirklich weiß, was man tut.
Grüße Michi
Besser als die ct' kann man es nicht beschreiben.... !
Moin,
wie siehts bei dir aus? Ist dein Problem gelöst oder hakt es noch wo? Feedback bitte!
Grüße,
Dani
wie siehts bei dir aus? Ist dein Problem gelöst oder hakt es noch wo? Feedback bitte!
Grüße,
Dani
