Systeme: Sicherheit in virtuellen KVM-Umgebungen

Nicht immer ausbruchssicher

Eigentlich ist das Absichern eines mit KVM virtualisierten Systems recht einfach: Sie sperren ein System in eine virtuelle Maschine ein und schon kann die darin laufende Software keinen Unsinn mehr anstellen. Selbst wenn ein Einbrecher den Server in der virtuellen Maschine kompromittiert, beschädigt er höchstens das Gastsystem. Doch das ist ein weitverbreiteter Irrtum. Lesen Sie in diesem Workshop, wie Sie Ihre KVM-Umgebung richtig schützen und wo Gefahren lauern.
Für die Mai-Ausgabe hat sich IT-Administrator den Schwerpunkt 'Messaging & Collaboration' auf die Fahnen geschrieben. Lesen Sie darin, wie Sie die Open ... (mehr)

Virtuelle Maschinen erwecken den Eindruck eines kleinen Gefängnisses. Alles, was in der VM geschieht, bleibt auf diese beschränkt. Doch sollten Sie sich von dieser vermeintlichen Sicherheit nicht täuschen lassen. Bereits auf der Sicherheitskonferenz BlackHat 2011 stellte Nelson Elhage eine Ausbruchsmöglichkeit vor [1]. Elhage nutzte dabei Sicherheitslücken in den damaligen Versionen von KVM beziehungsweise QEMU aus. Aber auch die im Gastsystem installierten Virtio-Treiber könnten über vorhandene oder unentdeckte Programmfehler einen Ausbruch gestatten.

 

 Hat eine Schadsoftware erst einmal die Kontrolle über das Wirtssystem erlangt, kann sie von dort die anderen virtuellen Maschinen steuern und übernehmen. Sie sollten daher unbedingt KVM, QEMU und die Virtio-Treiber immer auf dem aktuellen Stand halten. Das gilt insbesondere für Windows-Gäste, die anders als Linux-Distributionen die Virtio-Treiber nicht automatisch aktualisieren können.

Erhöhte Sicherheit etablieren

Um gegen einen Ausbruch gewappnet zu sein, ziehen Sie um jede virtuelle Maschine eine zusätzliche Mauer. Dabei hilft, dass die virtuellen Maschinen für das Wirtssystem als normale Prozesse erscheinen. Diese lassen sich mit SELinux, AppArmor oder anderen Mandatory Access Control-Systemen reglementieren. Die ab libvirt 0.6.1 enthaltene Komponente sVirt arbeitet sogar SELinux und AppArmor gezielt zu [2]. Unter SELinux heftet sVirt beispielsweise Labels an die virtuellen Maschinen, die sich dann wiederum gezielt untereinander isolieren lassen.

Des Weiteren können Sie die VMs in Cgroups sperren und so ihren Ressourcenverbrauch und den Zugriff auf Ressourcen reglementieren. Das schützt ganz nebenbei davor, dass eine amoklaufende oder abgestürzte Maschine zu viel Rechenzeit an sich zieht und ein DoS-Angriff auch den Netzwerkzugang zu den anderen virtuellen Maschinen verstopft.

Bild 1: In diesem Beispiel läuft die virtuelle Maschine unter dem Benutzer root. Würde aus ihr ein Programm ausbrechen, hätte dieses ebenfalls volle Root-Rechte.

Normalerweise erzeugt libvirt automatisch eine entsprechende Cgroup-Hierarchie [3], die Zugriffe auf Ressourcen lassen sich gezielt mit dem Werkzeug virsh regeln. Der folgende Befehl beschränkt beispielsweise die Rechenzeit der virtuellen Maschine “webserver” auf 100 Shares, was häufig ungefähr zehn Prozent der Rechenleistung entspricht:

 

 

virsh schedinfo —set cpu_shares=100
webserver

 

 

 Allerdings lassen sich mit virsh und KVM nicht alle Ressourcen reglementieren. Die Manpage von virsh nennt unter dem Eintrag “schedinfo” die entsprechenden Möglichkeiten.

Root-Rechte reduzieren

Wer direkt mit sudo qemu-kvm -m 512 die virtuelle Maschine hochfährt, gibt ihr und einem ausbrechenden Programm Systemrechte (siehe Bild 1). Glücklicherweise sind Root-Rechte gar nicht nötig: Auf “/dev/kvm” dürfen in den meisten Distributionen auch normale Benutzer aus der Gruppe “kvm” zugreifen. Es genügt folglich, das eigene Benutzerkonto in die Gruppe “kvm” zu stecken und unter diesem dann zukünftig qemu-kvm aufzurufen. Wer der virtuellen Maschine über ein TAP-Interface den Zugang zum Netz gestattet, muss zusätzlich noch die Schnittstelle für den Benutzer und die Gruppe anlegen, unter der die virtuelle Maschine läuft. In der Regel ist das “qemu” in der Gruppe “qemu”.

 

 Alternativ verwalten Sie die virtuellen Maschinen über die libvirt-Werkzeuge. Diese starten eine VM automatisch unter dem normalen Benutzer qemu. Doch auch hier lauern kleine Stolperfallen: Unter einigen Distributionen, wie etwa Ubuntu, dürfen die virsh auch alle Benutzer in der Gruppe libvirtd ausführen. Wer jedoch Zugriff auf die virsh erhält, kann damit nicht nur sämtliche VMs verwalten, sondern dank virsh nodeinfo auch Hardware-Informationen des Wirts abfragen (siehe Bild 2). virsh und Co sollten daher nur ausgewählte Administratoren nutzen können. Binden Sie die virsh in Skripte ein, sollten Sie die Rechte dieser Skripte überprüfen.

Des Weiteren möchte der auf dem Wirtssystem aktive Daemon “libvirtd” gerne mit Root-Rechten laufen. Würde es ein Angreifer schaffen, mit libvirtd Kontakt aufzunehmen, könnte er die virtuellen Maschinen und im schlimmsten Fall sogar das ganze System übernehmen. Folglich gilt es, den Zugriff auf den Daemon einzuschränken. Insbesondere darf in der Konfigurationsdatei /etc/libvirt/libvirtd.conf nicht die Zeile “listen_tcp = 1” stehen. In diesem Fall würde libvritd von jedermann Verbindungen über TCP annehmen – vorausgesetzt, die Firewall des Wirtssystems blockt den entsprechenden Port nicht ab; standardmäßig ist dies 16509.

Bild 2: virsh liefert auch Informationen über die reale Hardware eines entfernten Knotens
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019