Virtualisierung ist mit Sicherheit derzeit eines der Topthemen in der IT. Eigentlich nutzen diese Technologie fast die mehr als eine Handvoll Server haben. Auch für den Heimanwender gibt es zahlreiche Nutzungsmöglichkeiten. Sofern es Dich *Wirklich* interessieren sollte und dies kein plumper Trollversuch war, schau mal in das aktuelle LinuxUser (http://www.linuxuser.de/)
Von der kommentator am So, 20. Mai 2007 um 08:24 #
moin...
wir haben hier ein kleines internetcafe mit ca. 15 clients (win2k oder Linux) und einem physischen server. anstatt 3 maschinen hier rumstehen zu haben, die krach machen und strom verbrauchen, konnten wir dank Xen das alles konsolidieren: ein server fuer dateidienste, ein server als gateway zum internet und ein server als der webserver des cafes von aussen zugreifbar.
richtig, mit "xm console " kann man auf die Konsole des Gast-OS wechseln, d.h. du kannst z.B. über SSH auf dom0 deinen virtuellen Maschinen beim Booten zugucken usw.
In der Schule, wo ich Admin bin, konnte ich dank Xen auch mehrere Server (WWW/Intranet/Mail-Server, Proxy, Login-Server, VPN-Server tc.) auf eine neue Maschine konsolidieren und die Images kann man kinderleicht mal eben schnell sichern
Nur daß alle Servies platt sind, wenn die eine Maschine in die Knie geht. Ohne mitlaufenden Ersatzserver ist Virtualisierung eine zweischneidige Sache. Dazu kommt, daß man sich mit der Virtualisierungssoftware einen neuen Angriffsvektor ins Haus holt.
> Nur daß alle Servies platt sind, wenn die eine Maschine in die Knie geht. Ohne mitlaufenden Ersatzserver ist Virtualisierung eine zweischneidige Sache. Das kann man nicht bestreiten, aber in diesem Fall ist Hochverfügbarkeit keine zwingende Sache, insofern ist das akzeptabel.
> Dazu kommt, daß man sich mit der Virtualisierungssoftware einen neuen Angriffsvektor ins Haus holt. Achso? dom0 ist bei uns ein Minimalsystem und nur per SSH vom internen Netz aus erreichbar. Der Server an sich ist in einer DMZ, d.h. bestimmte Ports der äußeren Firewall werden per DNAT über das jeweilige getaggte VLAN (weil der Xen-Host nur 1 Ethernet-Uplink hat, aber mehrere Netze bedient) und Ethernet-Bridges in dom0 direkt in die entsprechende domU "getunnelt". IP-Forwarding in dom0 ist generell deaktiviert und sämtlicher Verkehr findet nur über die Bridges statt (und mitschneiden kann man da nix, wenn man nicht gerade root-Zugriff auf die Xen-Maschine hat).
Ich seh da keine zusätzlichen Sicherheitsprobleme. Du? Wenn ja, nehm ich Hinweise dankend entgegen
Wie jede Software kann Xen eine Sicherheitslücke enthalten. Wie sehr du die VMs absicherst, ist in schlimmsten Fall völlig uninteressant. Irgendein scheinbar normales Paket, das ohne Probleme durch die Firewall schlüpft und ein Loch ins virtuelle Ethernet reißt, reicht schon. Und von wg. dom0 nur intern: Ernst zu nehmende Angriffe kommen durchaus von Innen.
Lies mal http://taviso.decsystem.org/virtsec.pdf für Beispiele.
Ist prinzipiell was wahres dran, obwohl der Autor z.B. bei Xen einfach die gleichen Fehler wie bei QEMU *angenommen* hat, obwohl er Paravirtualisierung sehr wohl hätte testen können (also nichts von wegen "fehlender Hardware"). Aber all diese Attacken gehen davon aus, dass du bereits mehr oder weniger vollen Zugriff auf die virtualisierten Maschinen hast, was zwar sicher nicht ausgeschlossen ist, aber halt auch erstmal geschafft werden muss.
Bezüglich der Angriffe von Innen: es gibt (wie das bei einer DMZ nunmal so ist) auch eine innere Firewall, d.h. von innen kommt im Prinzip auch nicht mehr durch als von außen, der einzige Unterschied ist halt, dass SSH von innen her offen ist, was dir aber ohne Kenntnis des root-Accounts auch so schnell nichts nützen wird.
Versteh mich nicht falsch, ich will keinesfalls behaupten, "mein" System wäre zu 100% sicher o.ä., aber dass die Virtualisierung der Server mittels Xen ernsthafte praxis-relevante Sicherheitsprobleme mit sich gebracht hat, würde ich so nicht behaupten wollen.
> obwohl er Paravirtualisierung sehr wohl hätte testen können (also nichts von wegen "fehlender Hardware")
Zumindest solange nicht mit unmodifiziertem Client getestet werden soll, ja.
> Aber all diese Attacken gehen davon aus, dass du bereits mehr oder weniger vollen Zugriff auf die virtualisierten Maschinen hast, was zwar sicher nicht ausgeschlossen ist, aber halt auch erstmal geschafft werden muss.
Jein. Ich habe das Papier nur als Beispiel genommen, daß auch Virtualisierungssoftware nicht vor Fehlern gefeit ist. Es sind selbstverständlich auch Sicherheitslücken möglich, bei denen kein direkter Zugriff auf eine VM nötig ist. Alles nur eine Frage dessen, wie intensiv man sucht. ;)
> dass SSH von innen her offen ist, was dir aber ohne Kenntnis des root-Accounts auch so schnell nichts nützen wird.
Direkten root access via ssh zuzulassen halte ich schon für nicht unbedingt schlau. Wenn jemand doch einmal an eine Kopie des notwendigen ssh keys kommen sollte, hat man immer noch das root passwort als zweite Sicherung.
> aber dass die Virtualisierung der Server mittels Xen ernsthafte praxis-relevante Sicherheitsprobleme mit sich gebracht hat, würde ich so nicht behaupten wollen.
Natürlich kann man virtualisierte Systeme sehr wohl nutzen. Wenn das Kind aber tatsächlich mal ins Wasser fällt, darf man sich nicht wundern. Ist natürlich auch eine Frage dessen, gegen wen (und welches Budget) man sich zu schützen gedenkt.
Wir setzten so was ein. Berichtet bitte weiter über XEN. XEN und Linux als Basis haben sich bei uns als wirklich stabile und performante Virtualisierungslösung etabliert. Wir setzen es hauptsächlich für Tests und Entwicklung ein, aber auch im Bereich Hosting ist XEN nicht mehr wegzudenken.
Auch zur Software/Distributionsanpassung ist Xen gut geeignet. Ich kann sehr schnell und einfach Probleme nachstellen. Dazu bruche ich keine dutzend Rechner nehr, sondern kann das über Xen erledigen.
"[...] Die Nutzung von Xen setzt einen speziell angepassten Kernel voraus. [...]"
Soweit ich mich erinnern kann wird doch ein angepasster System-Kern nur dann benötigt, wenn ein Prozessor eingesetzt wird, der keine Virtualisierung beherrscht, oder?
Der Host braucht immer einen angepaßten Kernel. Der Gast braucht dann auch einen, wenn der Prozessor keine Hardwarevirtualisierung unterstützt. Dies nennt man dann auch Paravirtualisierung. Wenn der Prozessor diese unterstützt, wird natürlich für den Gast kein angepaßter Kernel benötigt.
- Paravirtualisierung: setzt einen modifizierten Kernel bei Host und Gast voraus. - Vollvirtualisierung: bedeutet Hardwareunterstützung von der CPU, (bei Intel heißt diese Technologie VT-x und bei AMD Pacifica), und vom Mainboard. Dann kann man auch unmodifizierte Kernels laufen lassen, so z. B. Windows Server 2003 oder auch Windows XP.
Hallo, zu >Leistung, die gegenüber echter Hardware nur 0,5% bis 3% geringer ist. Für die CPU kann ich mir das ja vorstellen, weil hier ja nur x86-Befehle durchgereicht werden (sofern der gleiche Prozessortyp "paravirtualisiert" wird. Kann aber jemand sagen, wie es mit der restlichen Hardware aussieht? V.A. Netzwerk, RAM, Festplatte, etc.? Danke!
ja man kann halt Windows auch in einer virtuellen Maschiene laufen lassen, allerdings nur über die Hardware-VT Funktionen von Prozessoren die das unterstützen.
Das ist dann aber nicht mehr über den Paravirtualisierungsansatz machbar. Und da diese bisher nur die CPU virtualisieren und den Speicher nicht, hat man dort dann niedrige Speicher-Zugriffsgeschwindigkeiten.
Ich begrüße virtualisierungen von Servern sehr. Aber bei Xen muss man aufpassen. Ich nam mal an nem Xen Workshop auf den Linux Tagen teil und der Dozent meinte nur: "Xen ist auf dem richtigen Weg, aber man sollte es zur Zeit nur im Bereich der Entwicklung und Test einsetzen, da es für produktive System noch sehr instabil läuft". Mit praktischen Erfahrungen kann ich leider nicht dienen, aber wenn man es von so einer Person hört, klingt das nicht besonders gut.
Ich bin ja mal auf VMware's Para-Lösung gespannt...
Was sollen die Meldungen über Sache die sowieso nicht eingesetzt werden ?
Sofern es Dich *Wirklich* interessieren sollte und dies kein plumper Trollversuch war, schau mal in das aktuelle LinuxUser (http://www.linuxuser.de/)
wir haben hier ein kleines internetcafe mit ca. 15 clients (win2k oder Linux) und einem physischen server.
anstatt 3 maschinen hier rumstehen zu haben, die krach machen und strom verbrauchen, konnten wir dank Xen das alles konsolidieren: ein server fuer dateidienste, ein server als gateway zum internet und ein server als der webserver des cafes von aussen zugreifbar.
hth,
Gruss -
devnull
In der Schule, wo ich Admin bin, konnte ich dank Xen auch mehrere Server (WWW/Intranet/Mail-Server, Proxy, Login-Server, VPN-Server tc.) auf eine neue Maschine konsolidieren und die Images kann man kinderleicht mal eben schnell sichern
Das kann man nicht bestreiten, aber in diesem Fall ist Hochverfügbarkeit keine zwingende Sache, insofern ist das akzeptabel.
> Dazu kommt, daß man sich mit der Virtualisierungssoftware einen neuen Angriffsvektor ins Haus holt.
Achso? dom0 ist bei uns ein Minimalsystem und nur per SSH vom internen Netz aus erreichbar. Der Server an sich ist in einer DMZ, d.h. bestimmte Ports der äußeren Firewall werden per DNAT über das jeweilige getaggte VLAN (weil der Xen-Host nur 1 Ethernet-Uplink hat, aber mehrere Netze bedient) und Ethernet-Bridges in dom0 direkt in die entsprechende domU "getunnelt". IP-Forwarding in dom0 ist generell deaktiviert und sämtlicher Verkehr findet nur über die Bridges statt (und mitschneiden kann man da nix, wenn man nicht gerade root-Zugriff auf die Xen-Maschine hat).
Ich seh da keine zusätzlichen Sicherheitsprobleme. Du? Wenn ja, nehm ich Hinweise dankend entgegen
Lies mal http://taviso.decsystem.org/virtsec.pdf für Beispiele.
Bezüglich der Angriffe von Innen: es gibt (wie das bei einer DMZ nunmal so ist) auch eine innere Firewall, d.h. von innen kommt im Prinzip auch nicht mehr durch als von außen, der einzige Unterschied ist halt, dass SSH von innen her offen ist, was dir aber ohne Kenntnis des root-Accounts auch so schnell nichts nützen wird.
Versteh mich nicht falsch, ich will keinesfalls behaupten, "mein" System wäre zu 100% sicher o.ä., aber dass die Virtualisierung der Server mittels Xen ernsthafte praxis-relevante Sicherheitsprobleme mit sich gebracht hat, würde ich so nicht behaupten wollen.
Zumindest solange nicht mit unmodifiziertem Client getestet werden soll, ja.
> Aber all diese Attacken gehen davon aus, dass du bereits mehr oder weniger vollen Zugriff auf die virtualisierten Maschinen hast, was zwar sicher nicht ausgeschlossen ist, aber halt auch erstmal geschafft werden muss.
Jein. Ich habe das Papier nur als Beispiel genommen, daß auch Virtualisierungssoftware nicht vor Fehlern gefeit ist. Es sind selbstverständlich auch Sicherheitslücken möglich, bei denen kein direkter Zugriff auf eine VM nötig ist. Alles nur eine Frage dessen, wie intensiv man sucht. ;)
> dass SSH von innen her offen ist, was dir aber ohne Kenntnis des root-Accounts auch so schnell nichts nützen wird.
Direkten root access via ssh zuzulassen halte ich schon für nicht unbedingt schlau. Wenn jemand doch einmal an eine Kopie des notwendigen ssh keys kommen sollte, hat man immer noch das root passwort als zweite Sicherung.
> aber dass die Virtualisierung der Server mittels Xen ernsthafte praxis-relevante Sicherheitsprobleme mit sich gebracht hat, würde ich so nicht behaupten wollen.
Natürlich kann man virtualisierte Systeme sehr wohl nutzen. Wenn das Kind aber tatsächlich mal ins Wasser fällt, darf man sich nicht wundern. Ist natürlich auch eine Frage dessen, gegen wen (und welches Budget) man sich zu schützen gedenkt.
weiß jemand, ob es irgendwo Pakete mit dieser neuen Version für Ubuntu gibt? Vielleicht so etwas wie ein Backports Repo
Gruß
Christian
Solche Kommentare wie Deinen kann man sich sparen. Dann schweige lieber
Soweit ich mich erinnern kann wird doch ein angepasster System-Kern nur dann benötigt, wenn ein Prozessor eingesetzt wird, der keine Virtualisierung beherrscht, oder?
Oliver
- Paravirtualisierung: setzt einen modifizierten Kernel bei Host und Gast voraus.
- Vollvirtualisierung: bedeutet Hardwareunterstützung von der CPU, (bei Intel heißt diese Technologie VT-x und bei AMD Pacifica), und vom Mainboard. Dann kann man auch unmodifizierte Kernels laufen lassen, so z. B. Windows Server 2003 oder auch Windows XP.
zu
>Leistung, die gegenüber echter Hardware nur 0,5% bis 3% geringer ist.
Für die CPU kann ich mir das ja vorstellen, weil hier ja nur x86-Befehle durchgereicht werden (sofern der gleiche Prozessortyp "paravirtualisiert" wird.
Kann aber jemand sagen, wie es mit der restlichen Hardware aussieht? V.A. Netzwerk, RAM, Festplatte, etc.?
Danke!
Was hat das mit Xen zu tun?
Das ist dann aber nicht mehr über den Paravirtualisierungsansatz machbar. Und da diese bisher nur die CPU virtualisieren und den Speicher nicht, hat man dort dann niedrige Speicher-Zugriffsgeschwindigkeiten.
Mit praktischen Erfahrungen kann ich leider nicht dienen, aber wenn man es von so einer Person hört, klingt das nicht besonders gut.
Ich bin ja mal auf VMware's Para-Lösung gespannt...