Am 18.11.2012 um 20:31 schrieb Boris :

Wir machen auf unserem Produktions-Server Xen und ich mache auf meinem privaten Server (headless) VirtualBox. Xen ist sehr ressourcenschonend, aber man kriegt Windows nur mit Tricks an den Start.

Das kann ich gar nicht bestätigen. Von XP bis 2008 habe ich noch alles problemlos zum Laufen bekommen. @Helga: Solltest Du Dich für Xen entscheiden (KVM kenne ich nicht), sollest Du auch Deinen Server in eine VM heben und auf der eigentlichen Hardware nur den Hypervisor und die essentiellen Bestandteile laufen lassen (in Xen-Sprech: Dom0 vs. DomU) So kannst Du (halbwegs) sicherstellen, daß wenn eines Deiner Server-Programme wild wird, nur die eine virtuelle Maschine Probleme macht und die andere (oder alle anderen) weiterlaufen. Jedenfalls in der Theorie :-) Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Tobias, Am Sonntag 18 November 2012 schrieb Tobias Crefeld:

Am Sun, 18 Nov 2012 19:21:21 +0100 schrieb Helga Fischer :

...

welche Virtualisierungslösung bevorzugt ihr eigentlich auf einem Server? Im Alltag macht der Web, hostet als Hauptaufgabe ein CMS und schiebt ein paar Mails durch die Gegend.

Im Alltag, also privat, habe ich noch keine VM am Laufen,

Ich habe VMs auf dem Desktop schon etliche Jahre laufen. Anfangs nur VMWare-Player, schließlich vbox, als das sich netzwerktechnisch endlich 'normal' benahm.

aber @work haben wir ca. 1 Jahr lang verschiedene Virtualisierungslösungen evaluiert. Sicher nicht wissenschaftlich begleitet, aber doch mit dem Fokus darauf, was im Normalbetrieb und bei Störungen, aber auch bei Migrationen am wenigsten Kummer bereitet.

...

Auf diesen Server (Debian Lenny) möchte ich ein zweites Betriebssystem (Suse) huckepack nehmen.

OS-unabhängig würde ich ein OS für den Virtualisierer ausschließlich für diesen Zweck und für nichts anderes verwenden.

OK, ich speichere mir das für zukünftige Einsätze, im Moment muss aber mal der laufende Server so bleiben, wie er ist, nur möchten wir da eben noch ein zweites OS installieren, um was zum Experimentieren zu haben.

Auch vermeide ich sämtliche IP-Verbindungen desselben ins "böse" Internet. Das gestattet mir, Updates des Virtualisierers auf ein Minimum zu beschränken, ohne das Gesamtsystem zu gefährden. Merke: Einen Virtualisierer will man möglichst nie-niemals-nicht rebooten. ;)

Ja, da hast Du bestimmt Recht. Dem Experimentalsystem macht der Reboot sicher nichts aus. Vielleicht lassen wir das nicht einmal durchlaufen.

...

Erst wollte ich VirtualBox einsetzen, bin mir aber nicht sicher, ob das wirklich auch gut ist, um es auf einem Server einzusetzen. Ein Kollege meint, das ließe sich auf der Kommandozeile nicht gut bedienen und sei unter Debian nicht sonderlich lustig.

Haben wir unter Debian als Plattform für ein paar Firewall-Maschinen unter OpenBSD am laufen. Es hat eine charmante GUI, die komfortable Unterstützung mit schnellem Einstieg für eine Menge von Guest-OS bietet (u.a. auch OpenBSD) und deswegen könnte ich es mir gut als Plattform am Desktop vorstellen.

Du meinst VBox? Ich kann mir kein Bild von Deinem Szenario machen.

Dort lief bis vor Kurzem VMware-Server 2.0, aber mittlerweile k**zt mich deren verhunzte, tomcat-basierte GUI dermaßen an, dass ich da nur noch nen großen Bogen drum machen.

:) (Den habe ich ziemlich schnell zu den Akten gelegt und nie wieder angefasst).

Die Geschichte mit der Kommandozeile kann ich im Prinzip bestätigen. Wir starten die VM mit VBoxHeadless, was der einzige Weg ist, die VM ohne laufendes GUI (die de facto ein X11 erfordert - und das auf nem Virtualisierer!) zu betreiben.

X11 ist keine Option auf dem Server.

Eine Wartung via Kommandozeile ist da (m.W.) ebenso wenig möglich und für Wartungszwecke über eine zusätzlich gestartete (womöglich extern betriebene) GUI zuzugreifen, geht auch nicht: Da bekommt man nur eine Anzeige, dass hier eine VM aktiv ist, aber Manipulation? No way!

Das ist für mein Szenario auch kein wirkliches KO-Kriterium. Ich glaube aber, ich verstehe, was Du mir sagen willst. So weit gehen meine Virtualisierungserfahrungen nicht.

...

Jetzt liebäugle ich mit KVM. Gute Wahl?

Redhat ist darauf seit 1..2 Jahre eingeschwenkt und bietet ein paar Tools dafür.

KVM hat inzwischen mehr Medienpräsenz, während man von Xen eher nichts mehr hört. [...]

Ist kein Argument, aber insgesamt denke ich, das KVM in der Linux-Welt mittlerweile ebenso mainstream ist, wie VMware in der Microsoft-Welt.

Dann werde ich mir das mal auf meiner heimischen Suse näher angucken. Sieht ja so aus, dass mir da YaST alles liefert und ich nicht am System rumschrauben muss. Die anderen Virtualisierer will ich schließlich weiter verwenden.

...

Kollege nennt noch eine dritte Alternative: http://www.ibm.com/developerworks/linux/library/l-lxc-containers /.

[Hintergrundinfos gesnippt]. Danke für die Einblicke und Sichtwinkel. Helga -- ## Technik: [http://de.opensuse.org] ## Politik: [http://www.piratenpartei.de] ## Privat: [http://www.eschkitai.de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo Dieter, Am Montag 19 November 2012 schrieb Dieter Klünter:

Am Sun, 18 Nov 2012 23:44:27 +0100 schrieb Tobias Crefeld :

...

Am Sun, 18 Nov 2012 19:21:21 +0100 schrieb Helga Fischer

:

...

welche Virtualisierungslösung bevorzugt ihr eigentlich auf einem Server? Im Alltag macht der Web, hostet als Hauptaufgabe ein CMS und schiebt ein paar Mails durch die Gegend.

[...]

...

Die Geschichte mit der Kommandozeile kann ich im Prinzip bestätigen. Wir starten die VM mit VBoxHeadless, was der einzige Weg ist, die VM ohne laufendes GUI (die de facto ein X11 erfordert - und das auf nem Virtualisierer!) zu betreiben. Eine Wartung via Kommandozeile ist da (m.W.) ebenso wenig möglich und für Wartungszwecke über eine zusätzlich gestartete (womöglich extern betriebene) GUI zuzugreifen, geht auch nicht: Da bekommt man nur eine Anzeige, dass hier eine VM aktiv ist, aber Manipulation? No way!

Dann rufe mal VBoxManage --help auf.

Super, das schiebe ich mir gleich mal auf den Drucker. Wie sieht's eigentlich um die Sicherheit von VirtualBox auf einem Server aus? Gehört/gelesen habe ich eigentlich noch nichts. Kann ich VBox eher unbesorgt da laufen lassen? (Regelmäßig Updates ziehen ist bei meinen Anforderungen ja problemlos möglich). Helga -- ## Technik: [http://de.opensuse.org] ## Politik: [http://www.piratenpartei.de] ## Privat: [http://www.eschkitai.de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo, Am Mon, 19 Nov 2012 11:36:11 +0100 schrieb Dieter Klünter :

Am Mon, 19 Nov 2012 09:22:38 +0100 schrieb Helga Fischer :

...

Hallo Dieter,

Am Montag 19 November 2012 schrieb Dieter Klünter:

...

Am Sun, 18 Nov 2012 23:44:27 +0100 schrieb Tobias Crefeld :

...

Am Sun, 18 Nov 2012 19:21:21 +0100 schrieb Helga Fischer

:

...

welche Virtualisierungslösung bevorzugt ihr eigentlich auf einem Server? Im Alltag macht der Web, hostet als Hauptaufgabe ein CMS und schiebt ein paar Mails durch die Gegend.

[...]

...

Die Geschichte mit der Kommandozeile kann ich im Prinzip bestätigen. Wir starten die VM mit VBoxHeadless, was der einzige Weg ist, die VM ohne laufendes GUI (die de facto ein X11 erfordert - und das auf nem Virtualisierer!) zu betreiben. Eine Wartung via Kommandozeile ist da (m.W.) ebenso wenig möglich und für Wartungszwecke über eine zusätzlich gestartete (womöglich extern betriebene) GUI zuzugreifen, geht auch nicht: Da bekommt man nur eine Anzeige, dass hier eine VM aktiv ist, aber Manipulation? No way!

Dann rufe mal VBoxManage --help auf.

Super, das schiebe ich mir gleich mal auf den Drucker.

Wie sieht's eigentlich um die Sicherheit von VirtualBox auf einem Server aus? Gehört/gelesen habe ich eigentlich noch nichts. Kann ich VBox eher unbesorgt da laufen lassen? (Regelmäßig Updates ziehen ist bei meinen Anforderungen ja problemlos möglich).

Alle Virtualisierungslösungen sind nur Softwareprodukte und greifen auf die reale Hardware des Hostsystems zurück, dementsprechend muss das Hostsystem auf der Netzwerkebene durch Paketfilter gesichert werden, das Hostsystem selbst sollte weitestgehend gehärtet sein, also nur ein Minimalsystem, um mögliche Gefährdungen auf ein Minimum zu reduzieren. Das Gastsystem solle ebenfalls die erforderlichen Sicherheitsrichtlinien einhalten, also ein Regelwerk für Paketfilter, Zugangskontrolle, Zugangsberechtigungen und Systemaktualisierung sollte schon definiert werden.

Noch ein Nachtrag von mir zum Thema Sicherheit: Das BSI beschreibt in der Dokumentenreihe IT-Grundschutz den Schutzbdarf von Systemen, so z.B. für den Server unter Unix https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b03/b03102.htm... In diesem Katalog fehlt noch der virtuelle Server, im Downloadbereich bietet das BSI den neuen IT-Grundschutz-Katalog-12 an. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Mon, 19 Nov 2012 14:21:18 +0100 schrieb Martin Schröder :

Am 19. November 2012 12:32 schrieb Dieter Klünter :

...

...

Alle Virtualisierungslösungen sind nur Softwareprodukte und greifen auf die reale Hardware des Hostsystems zurück, dementsprechend muss das Hostsystem auf der Netzwerkebene durch Paketfilter gesichert werden, das Hostsystem selbst sollte weitestgehend gehärtet sein, also nur ein Minimalsystem, um mögliche Gefährdungen auf ein Minimum zu reduzieren. Das Gastsystem solle ebenfalls die erforderlichen Sicherheitsrichtlinien einhalten, also ein Regelwerk für Paketfilter, Zugangskontrolle, Zugangsberechtigungen und Systemaktualisierung sollte schon definiert werden.

Noch ein Nachtrag von mir zum Thema Sicherheit: Das BSI beschreibt in der Dokumentenreihe IT-Grundschutz den Schutzbdarf von Systemen, so z.B. für den Server unter Unix https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b03/b03102.htm... In diesem Katalog fehlt noch der virtuelle Server, im Downloadbereich bietet das BSI den neuen IT-Grundschutz-Katalog-12 an.

Softwarevirtualisierung ist per se unsicher; ein Ausbrechen aus der VM muß als möglich angesehen werden.

Habe ich noch nicht erlebt, beschreibe doch mal ein mögliches Szenario. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am 19. November 2012 16:48 schrieb Ralf Prengel :

Meiner Meinung nach gibt es aber genügend andere Problemzonen die mehr Potential für massive Sicherheitslücken haben.

Keine Frage. Aber wer meint, daß Virtualisierung SICHER sei (also bspw. seine Firewall virtualisiert), nimmt Drogen. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Mon, 19 Nov 2012 21:12:36 +0100 schrieb Helga Fischer :

Am Montag 19 November 2012 schrieb Martin Schröder:

...

Keine Frage. Aber wer meint, daß Virtualisierung SICHER sei (also bspw. seine Firewall virtualisiert), nimmt Drogen.

Das würde ich nun nicht tun.

Kommt auf das "wie" an. Auf einem öffentlich zugänglichen OS als Virtualisierer wie im Falle Eures Webservers würde ich von einer Firewall auch nicht zuviel erwarten. Wenn die einzige Schnittstelle aus dem Internet jedoch eine virtuelle Bridge ist, bei der nur die Guest-VM des Firewall-Servers überhaupt eine IP-Bindung hat, würde ich das Risiko als gering einstufen.

Ums noch einmal zu wiederholen: Auf einem laufenden Webserver mit Mail und Perl möchte ich zu Testzwecken einen weiteren Webserver huckepack nehmen, der jedoch zusätzlich PHP bieten soll.

Da ist zwar schon viel unternommen worde, aber bestimmt ist PHP die kritischere Komponente als welche-Virtualisierung-auch-immer.

Jetzt frage ich mich, reißt mir VBox Löcher in den Host? (Gehört habe ich bisher nichts davon, was vielleicht auch daran liegt, dass VBox eher nicht auf Servern eingesetzt wird).

Ich weiß nicht, ob Virtualbox open source ist. Das böte zumindest eine erhöhte Chance, dass jemand feststellt, wenn Virtualbox ein Sicherheitsleck hat, sofern man selber für diese Evaluation nicht die nötigen Kenntnisse (oder Zeit) hat. Aber trotzdem muss man zu dem Angriffspunkt erstmal durchkommen. Wenn Management-Schnittstellen ins public internet gestellt werden, ist das so ein Angriffspunkt. Denke, es ist klar, dass eine Guest-VM nicht sicherer sein kann als sein Host. Mehr Applikationen und mehr OS bieten potentiell mehr Angriffsfläche. Das diese trotzdem klein bleibt, erledigt man noch immer am besten durch solide Administration, also frühzeitiges Patchen, Abschalten unnötiger listeners, ALG, Paketfilter und den sonst so üblichen Kram. -- Gruß, Tobias. xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Mon, 19 Nov 2012 14:21:18 +0100 schrieb Martin Schröder :

Softwarevirtualisierung ist per se unsicher; ein Ausbrechen aus der VM muß als möglich angesehen werden.

Das ist eine triviale Feststellung, weil "per se" erstmal jeder Host unsicher ist, egal ob er auf einer virtuellen oder auf einer Silizium-Maschine läuft. Wenn ein Bug innerhalb der Guest-VM erstmal den Einbruch in den Kernel oder sonstige privilege escalations erlaubt, ist das Scheunentor offen und die Möglichkeiten sich via Netzwerk weiter zu verbreiten, sind in der Regel nützlicher, als von dort aus auf einen weiteren Bug im Virtualisierer zu hoffen. Die relevantere Frage scheint mir, ob "Softwarevirtualisierung" (auch so ein Marketing-Jargon, weil es erstmal egal ist, ob die Software des Virtualisierers wie bei LPAR als Firmware in PROM gegossen ist oder auf Platte liegt...) unsicherer als harte Ware ist? Und da gibt es pro und cons. Einerseits bietet die Reduzierung auf wenige Treiber das Potential, besser getestete Kernelmodule zu betreiben und Hacks, die die zusätzlichen CPU-Befehle zur Hardware-Virtualisierung nutzen, werden in einer Guest-VM automatisch, da notwendigerweise, deaktiviert. Kann man zwar auch häufig manuell im BIOS machen, tut aber kaum jemand. Andererseits bietet ein erstmal geschaffenes Tor zum Host-OS natürlich freien Zugang zu allen darauf laufenden Guest-VM. So wie ein chroot auch nur solange dicht hält, wie kein trap in den Kernel gefunden wird. So what? Muss man halt dafür sorgen, dass der Zugriff auf den Virtualisierer restriktiv ist. Besonders zahlreich sind die bislang gefundenen Möglichkeiten, aus der Guest-VM eines bare-metal-virtualizers auszubrechen, jedenfalls nicht und das Stadium des proof of concept haben sie nicht verlassen. Vom Auftauchen in freier Wildbahn habe ich jedenfalls bislang nichts gelesen. Da sind Angriffe via Layer 8 noch immer zahlreicher, weil erfolgversprechender. Also vielleicht einfach mal die Kirche im Dorf lassen? -- Gruß, Tobias. xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Tue, 20 Nov 2012 10:22:14 +0100 schrieb Martin Schröder :

Am 20. November 2012 09:44 schrieb Tobias Crefeld :

...

Besonders zahlreich sind die bislang gefundenen Möglichkeiten, aus der Guest-VM eines bare-metal-virtualizers auszubrechen, jedenfalls nicht und das Stadium des proof of concept haben sie nicht verlassen.

http://marc.info/?l=openbsd-misc&m=129053180430168&w=2 http://marc.info/?l=openbsd-misc&m=129054362313648&w=2 http://marc.info/?l=openbsd-misc&m=129080928626980&w=2

Aber das ist nur die Sicht von Masturbating Monkeys. :-)

Ja, dieses könnte-müsste-sollte meine ich eigentlich nicht mit "proof-of-concept", auch wenn die Regel sicher stimmt, dass Komplexität mehr Fehlerrisiken bietet. Wobei es andererseits auch wieder mehr zu mehr Übersicht führen kann, wenn ich nicht alle Anwendungen in eine Maschine packe, sondern auf mehrere (virtuelle) Maschinen verteile, die jeweils spezifisch hinsichtlich Netzzuordnungen und Filterregeln konfiguriert sind. Kommt halt wie immer drauf an... Muss aber leider passen: Weiß leider nicht mehr, wo ich die Berichte über ein paar Sicherheitslecks in Virtualisierern gelesen hatte. Könnten ein paar Demos auf einer Blackhat gewesen sein. -- Gruß, Tobias. Email: crefeld@gmx.net xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Am Tue, 20 Nov 2012 12:08:21 +0100 schrieb Torsten Förtsch :

On 11/20/2012 09:44 AM, Tobias Crefeld wrote:

...

So wie ein chroot auch nur solange dicht hält, wie kein trap in den Kernel gefunden wird.

Um aus einer chroot Umgebung auszubrechen, braucht es keinen Bug im Kernel. Chroot ist *kein* Security-Feature!

Hier eine kurze Anleitung, wie root aus einer chroot-Umgebung ausbricht: [..]

Halte chroot schon für ein "Sicherheits-Feature". Natürlich nicht, wenn der Angreifer bereits eine privilege escalation auf UID root geschafft hat. Auf derselben Maschine bremsen einen dann nur noch Konzepte aus, wie sie hinter AppArmor oder SELinux stehen. chroot hilft aber sehr gut, Schäden zu vermeiden, wenn Daemon oder User sowieso mit beschränkten Rechten auskommen kann und zur Vermeidung einer weiteren privilege escalation der Zugriff auf Tools und Daten mittels chroot restriktiv gehandhabt wird. Selbst wenn durch ein Leck im daemon sowas wie ein shell-Zugriff ermöglicht wird, stehen auf diese Weise normalerweise keine weiteren Werkzeuge zur Verfügung. -- Gruß, Tobias. xmpp: crefeld@xabber.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org