Guten Tag,
ich würde hier ganz gerne einige Sicherheitsbedenken teilen und hoffe auf Lösungsansetze. Die KVM Guests haben, so fürchte ich, die intrinsische Eigenschaft, dass rein theoretisch doch vom Host auf alle Daten zugegriffen werden kann. Nicht zuletzt kann man ja sogar im Servercontrolpanel das root Passwort resetten oder über das Rettungssystem zugreifen. Gibt es eine Möglichkeit diesen Zugriff grundsätzlich zu unterbinden?
Damit das Resetten des root Passworts funktioniert, muss der "qemu-guest-agent" installiert sein.
Falls Du ein fertiges Image verwendet hast, in dem das Paket bereits installiert ist, kannst Du es einfach deinstallieren.
Dann ist das Resetten nicht mehr möglich.
Die Daten Deiner virtuellen Festplatte kannst Du verschlüsseln, dann kann keiner einfach auf diese zugreifen, auch nicht über das Rettungssystem.
Bleibt noch das Problem mit dem RAM.
Wenn der Hoster hier keine Technik wie "AMD Secure Encrypted Virtualization (SEV)" verwendet, gibt es hier leider keine Möglichkeit das RAM zu schützen.
Soviel ich weiß bietet Netcup so was nicht an. Und zumindest 2019 war die Technik auch noch nicht ausgereift.
Somit ist es theoretisch möglich, dass ein Admin auf dem Host Dein RAM ausliest (z.B. einfach einen Snapshot macht), und damit dann auch an den Key für Deine Festplattenverschlüsselung herankommt.
Wobei das auch nicht gerade leicht ist. Dazu muss der Admin das ganze RAM analysieren. Das macht (fast) niemand nur so zum Spaß 
Wenn Dir das Risiko zu hoch ist, benötigst Du eigene dedizierte Hardware.
Wobei selbst hier die Möglichkeit besteht an das RAM heran zu kommen. Allerdings braucht man dafür physikalischen Zugriff, und der Aufwand ist riesig.
Wenn Du nicht gerade das BESTE Entenbild aller Zeiten auf Deinem Server hast, lohnt sich der Aufwand wahrscheinlich nicht 
Passend dazu von xkcd: https://xkcd.com/538/
P.S.: auch wenn ich etwas flapsig geschrieben habe, meine ich das mit dem "Wenn Dir das Risiko zu hoch ist" durchaus ernst.
Ich habe einige, für mich, sehr wertvolle Daten, die ich keiner Cloud/VM anvertrauen würde.
Allerdings fallen 99% meiner Daten nicht unter diese Paranoia.
Bei denen reicht mir ein AV-Vertrag von Netcup aus 
https://www.netcup-wiki.de/wik…_zur_Auftragsverarbeitung
https://www.netcup-wiki.de/wik…sche_Ma%C3%9Fnahmen_(TOMs)
Für die meisten privaten und geschäftlichen Belange sollte das ausreichen.
Wie schon geschrieben, ist der Aufwand, um über einen RAM-Snapshot (oder CPU Fehler wie Meltdown und Spectre, ...), an Deine Daten heran zu kommen, ziemlich hoch.
"qemu-guest-agent" deinstallieren und HDD verschlüsseln ist für das Meiste sicher ausreichend. Evtl reicht es auch z.B. nur die DB zu verschlüsseln. Hängt von Deinem Anwendungsfall ab.
Zu bedenken gebe ich hier allerdings: sollte es notwendig sein, dass der Host durchgefahren werden,
und es auch keine Mglkt. gibt, dem kVM-Guest auf einen anderen Host zu migrieren,
dann hat man mit diesem "qemu-guest-agent" die Mglkt. den kVM-Guest sauber niederzufahren;
andernfalls wird die eiskalt abgedreht;
Gibt es eine Möglichkeit diesen Zugriff grundsätzlich zu unterbinden?
hier sollte man darüber nachdenken, ob diese Daten da überhaupt sein dürfen ...
Damit das Resetten des root Passworts funktioniert, muss der "qemu-guest-agent" installiert sein.
Falls Du ein fertiges Image verwendet hast, in dem das Paket bereits installiert ist, kannst Du es einfach deinstallieren.
[...] hat man mit diesem "qemu-guest-agent" die Mglkt. den kVM-Guest sauber niederzufahren [...]
Mit entsprechendem Aufwand könnte man das genannte QEMU-Paket auch derart modifizieren, dass die Funktion "guest-set-user-password" keine Auswirkungen mehr hat. Sofern sichergestellt ist, dass "qemu-guest-agent" nicht versehentlich im Zuge eines Updates mit dem "Original" überschrieben wird bzw. nur aus Quellen übernommen wird, welche obige Modifikation aufweisen, dürfte in Verbindung mit einer verschlüsselten Festplatte (unter Verwendung von NBDE) ein Eindringen erschwert werden.
Noch sicherer wird es natürlich, wenn man ein Login von "root" (=bekanntes Nutzerkonto) gänzlich verhindert, was in der (sauberen) Ausführung jedoch mehr Aufwand bedeutet als obige Paketmodifikation.
dann hat man mit diesem "qemu-guest-agent" die Mglkt. den kVM-Guest sauber niederzufahren;
andernfalls wird die eiskalt abgedreht;
Sendet Netcup hier keinen Shutdown Befehl per ACPI ?
Hat da schon mal einer den Support befragt?
Mit entsprechendem Aufwand könnte man das genannte QEMU-Paket auch derart modifizieren, dass die Funktion "guest-set-user-password" keine Auswirkungen mehr hat.
Reicht hier nicht ein
qemu-ga --blacklist=guest-set-user-password
um das zu verbieten, bzw evtl weitere wie "guest-exec", ... verbieten?
Sendet Netcup hier keinen Shutdown Befehl per ACPI ?
frag lieber was der kVM-Host macht,
wenn man ihm den Befehl gibt die kVM-Guests niederzufahren;
Sendet Netcup hier keinen Shutdown Befehl per ACPI ?
Meine letzte mir bekannte vServer Migration durch Host-Hardwarefehler ("Meldung über Migration Ihres vServers" Mail von Netcup) war irgendwann 2018 und da hat das einwandfrei geklappt. Irgendwelche Guest-Additions habe ich noch nie benutzt. Ich installiere mein Linux auch immer selbst und nicht mit den vorgefertigten Images...
Verschlüsselung kann man machen - rein aus Datenschutzgründen oder gegen menschliche Fehler. Aber solange die VM die Schlüssel hat käme der Host über einen RAM-Dump da auch jederzeit dran. An irgendeinem Punkt muss man dem Host einfach vertrauen.
Edit: wortlaut email
QuoteBei einer Migration wird zunächst ein temporärer Snapshot erstellt. Dies ist auch im angeschalteten Zustand möglich. Sobald der Snapshot erstellt wurde, werden die "alten" Daten auf den neuen Host kopiert.
Sobald diese kopiert wurden, wird der Server normal per ACPI heruntergefahren und die "neuen" Daten, die nach dem Snapshot erstellt oder verändert wurden werden noch kopiert. Im letzten Schritt wird Ihr Server dann auf dem neuen Host gestartet.
Sendet Netcup hier keinen Shutdown Befehl per ACPI ?
Doch, natürlich. Ich habe den qemu-guest-agent (absichtlich) noch nie in einer VM bei netcup installiert, läuft trotzdem alles einwandfrei über ACPI.
Allerdings gab bzw. gibt es im SCP immer wieder mal Bugs, bei denen z.B. bei der Speicheroptimierung gar kein Shutdown erfolgte. Das hat mir mindestens zwei mal den Server hart abgeschaltet. Seitdem fahre ich einen Server bei solchen Aktionen vorher lieber händisch (übers SCP/ACPI) herunter.
Ich danke für die vielen und ausführlichen Antworten. Macht es denn überhaupt sinn die Festplatte zu verschlüsseln wenn doch eigentlich sowieso die entschlüsselten Daten während des Betriebes vorliegen was bei Servern naturgemäß fast immer ist?
Meiner Meinung nach muss dabei schon noch mal unterschieden werden: Während des Betriebs ist es *theoretisch* möglich, den RAM auszulesen und dadurch den Key zu bekommen. Da ist schon noch mal ein großer Unterschied zwischen "Provider kann die ganze Platten im Klartext lesen" und "theoretisch könnte er den Key durch einen Dump bekommen".
Ganz sicher sind letztlich nur Daten, die der Server niemals unverschüsselt gesehen hat, die also bereits vor der Übertragung auf den Server verschlüsselt sind.
Edit: Natürlich vorbehaltlich dessen, dass die Verschlüsselungsmethode sicher ist, was in der Regel auch nicht für die Ewigkeit gültig ist sondern nur für den Moment.
Ich danke für die vielen und ausführlichen Antworten. Macht es denn überhaupt sinn die Festplatte zu verschlüsseln wenn doch eigentlich sowieso die entschlüsselten Daten während des Betriebes vorliegen was bei Servern naturgemäß fast immer ist?
Die Daten liegen niemals entschlüsselt vor, sie können lediglich von dem System das den Schlüssel hat entschlüsselt werden.
Je nachdem wie du das Ganze aufsetzt gibt es aber auch ein paar Nachteile. Zum einen ein gewisser Komfortverlust. Die SCP Snapshots können ggf. groß sein und die Disk-Optimierung kann ggf. mehr oder weniger nichts mehr für dich tun, das kommt aber auf das konkrete Setup an. Daneben musst du bei jedem Reboot, Patching oder Ausfall des Hosts bei Fuß stehen und das Passwort eingeben bevor die Daten wieder zugänglich sind und ggf. deine Dienste laufen.
Zusätzlich hast du je nach VM-Typ eine kleine bis große Performance-Einbuße, die du nur durch den Einsatz von AES minimieren kannst (weil selbiges ist in Hardware auf der CPU implementiert).
Wenn du mit diesen Nachteilen leben kannst oder deine Daten in irgendeiner Weise kritisch sind dann verschlüssele sie. Diese Frage kannst aber nur du beantworten.
Ich habe z.B. ein verschlüsseltes LVM Volume das ich nur bei Bedarf einhänge und auf dem logischerweise nur ein Teil meiner Daten liegt.
Daneben musst du bei jedem Reboot, Patching oder Ausfall des Hosts bei Fuß stehen und das Passwort eingeben bevor die Daten wieder zugänglich sind und ggf. deine Dienste laufen.
Genau dieses Problem wird mit NBDE (Network Bound Disk Encryption) ja in der Regel umgangen, beispielsweise mittels Clevis und Tang:clevis_testrun.png
Grundsätzlich kann man eine VM nicht vor dem Host schützen, auf dem sie läuft. Den Guest-Agent nicht zu aktivieren macht es zwar schwerer, kann es aber nicht verhindern. Letztendlich muss man sich einfach fragen, ob man dem Hoster vertraut, oder nicht. Wenn man ihm nicht vertraut, sollte man dort nicht hosten.
Der Guest-Agent dient vor allem dazu, das Load-Balancing bei geteilten Resourcen zu optimieren. Ihn nicht einzusetzen schadet letztendlich Allen, da ungenutzte Resourcen, wie beispielsweise freier Arbeitsspeicher, nicht für andere VMs freigegeben werden können, oder anders gesagt: Es ist asozial. Zudem glaube ich nicht, dass die Root-Passwort-Funktion auf diese Weise funktioniert. Da der Server dafür heruntergefahren werden muss, gehe ich davon aus, dass Netcup die Images dann extern mountet und anschließend ein Script nach bekannten Strukturen, wie z.B. einer /etc/shadow-Datei sucht. Wer das verhindern will, müsste die Festplatte verschlüsseln, was ebenfalls wieder eine effiziente Resourcen-Nutzung unterbindet, und ebenfalls nicht völlig verhindern kann, dass der Host auf die VM Zugriff erlangt.
Die SCP Snapshots können ggf. groß sein und die Disk-Optimierung kann ggf. mehr oder weniger nichts mehr für dich tun, das kommt aber auf das konkrete Setup an.
Die Disk-Optimierung dient eher Anderen als einem selbst, Stichwort "Thin Provisioning". Ohne diese Möglichkeiten könnte Netcup aber vermutlich nicht so günstig anbieten. Außerdem schont freier Speicherplatz die SSDs, da Wear Leveling dort besser stattfinden kann.
Zudem glaube ich nicht, dass die Root-Passwort-Funktion auf diese Weise funktioniert.
Wie genau Netcup diese Funktion derzeit oder zukünftig umsetzt, ist aber nicht der Punkt, sondern es geht hierbei darum, wie man unautorisierte Zugriffe verhindert oder erschwert.
Der qemu-guest-agent ("QGA") erlaubt standardmäßig tatsächlich das Ändern des Passworts über die entsprechende Funktion guest-set-user-password, und sofern das Hostsystem diese Methode ausführen kann, ist es unumgänglich, diese auch im laufenden Betrieb als potentiellen Angriffsvektor zu berücksichtigen (wie man mit einer lokalen KVM austesten kann):
(Wer obiges selbst nachstellen will, kann die erforderlichen Schritte/Beispiele hier, hier und hier nachlesen – bei Verwendung des Virtual Machine Managers musste ich die VM-Definition manuell ergänzen.)
Durch Deaktivierung der o.g. QGA-Funktion und Verschlüsselung der Festplatte sperrt man effektiv die Möglichkeit einer nicht erwünschten Passwortänderung über das SCP/den QGA-Kontrollkanal und somit ist es deutlich schwerer für Unbefugte, an die Inhalte der eigenen virtuellen Maschine gelangen. Dies erfordert dann mindestens einen vollständigen Speicher- und Plattenabzug und entsprechende Kenntnisse, diese auszuwerten. Zum Vergleich: Gelingt es einem Angreifer (nicht notwendigerweise ein Netcup-Mitarbeiter), ein Passwort zu ändern, ist ein Login über den Hostrechner relativ einfach.
(Brute-Force-Login-Versuche über die virtuelle Konsole sollten übrigens ebenfalls überwacht, protokolliert, und unterbunden werden – bspw. durch erzwungenes Herunterfahren der virtuellen Maschine derart, dass ein "normales" Neustarten nicht mehr funktioniert. Damit greift dann die "Encryption at Rest".)
man sollte bei dem ganzen manche andere Dinge nicht aus den Augen verlieren;
mit 2FA wirds eigentlich etwas seltsam f. unbefugte in das SCP-Konto einzusteigen;
ohne SCP gibts auch keine virt. Konsole würde ich mal sagen;
sollte es möglich sein, mittels eines lokalen VNCviewer z.B. RealVNC und Zugriff auf Host xxx mit Port xxx quasi ebenfalls eine virtualle Konsole zu erhalten,
hat jemand seine Aufgaben nicht gemacht, und 2FA quasi fürn Hugo erklärt;
ohne SCP gibts auch keine virt. Konsole würde ich mal sagen;
Ich glaube, er meint etwas anderes. Die virtuelle Konsole ist natürlich unabhängig vom SCP über den Host erreichbar, ebenso wie jeder virtuelle, serielle Port. Wenn man es mit der Paranoia weit genug treibt, kann man natürlich alles mögliche versuchen, um Zugriffe über den Host zu erschweren. Allerdings wiegt der Nutzen die Einschränkungen kaum auf, denn generell gillt in der IT die Maxime, dass wer physischen Zugriff auf ein laufendes Gerät hat, dieses so gut wie immer irgendwie unter seine Kontrolle bringen kann, und für eine VM ist der Host gewissermaßen die physische Umgebung. Theoretisch gibt es 1001 Methoden eine VM vom Host aus anzugreifen. Anstatt einen Schlüssel auszulesen, könnte man z.B. auch code injizieren um laufende Prozesse zu beeinflussen. Aber bevor ich mir Sorgen darüber mache, wie ich mich im Falle einer unsicheren Host-Konfiguration durch Netcup schütze, würde ich mir wirklich eher Gedanken darum machen, wie ich die eigene VM zum Netzwerk hin absichere, denn das ist definitiv die größere Gefahr, und zudem der Bereich für den ich persönlich haftbar gemacht werden kann. Wenn du z.B. einen Shop betreibst, und plötzlich die Daten deiner Kunden woanders auftauchen, dann garantiere ich dir, dass die nicht vom letzten, großen Netcup-Hack stammen, sondern weil du $shopsystem nicht rechtzeitig gepatcht hast.
Es besteht auch die Möglichkeit per VeraCrypt ein Volume zu errichten und es zu mounten, falls die zu verschlüsselnde Datenmenge nicht zu groß ist und man nicht das ganze System verschlüsseln muss bzw. möchte, da die Nachteile eben schon recht groß sind.
Ihn nicht einzusetzen schadet letztendlich Allen, da ungenutzte Resourcen, wie beispielsweise freier Arbeitsspeicher, nicht für andere VMs freigegeben werden können, oder anders gesagt: Es ist asozial.
Habe ich noch nicht gehört. Freien Arbeitsspeicher habe ich auch gar nicht. Linux verwertet den ja stets zu 100% für den Dateisystemcache. Wenn das tatsächlich für Netcup relevant ist, wäre eine technisch fundierte Dokumentation im Wiki ganz nett, sei es zum Guest Agent direkt oder allgemein zur Fair use Thematik.
