# Erfahrungen vServer Sicherheit

## TheSmallOne

Hallo Leute,

kennt sich jemand mit der Sicherheit von vServern und dergleichen aus?

Ich spiele zur Zeit mit dem Gedanken mir einen vServer zuzulegen, den ich dann als Mailserver verwenden möchte. Allerdings mache ich mir ein wenig Sorgen, was die Sicherheit der virtuellen Maschine angeht.

Es laufen ja grundsätzlich immer mehrere VMs auf einer (physischen) Maschine und ich frage mich, inwieweit die Virtualisierungsplattformen (habe die Wahl zw. KVM und XEN) da auch wirklich sicher sind. Also ich vermute mal das Wirts-System wird so oder so kein Problem damit haben in die VMs einzudringen, aber dem Provider muss ich ja sowieso vertrauen; das wäre bei einem vollwertigen dedicated Root-Server ja auch nicht anders. Was mir allerdings mehr Sorgen macht ist, das eine andere VM (also ein anderer Kunde) da irgendwie meine VM kompromittieren könnte.

Hat da jemand Erfahrungen mit? Wenn die Gefahr besteht, bzw. realistisch ist, dann würde ich vielleicht doch lieber auf eine Hardware-Maschine setzen und die Mehrkosten in Kauf nehmen.

----------

## schmidicom

Wir haben bei uns mehrere VMWare ESX Server im Einsatz und konnten noch nie eine unerwünschte gegenseitige Beeinflussung der VM's feststellen außer wenn die eine VM etwas mehr Leistung verbrauchte aber auch das könnte man durch Leistungsreservation verhindern. So lange es also in den Einstellungen der jeweiligen VM nicht explizit erlaubt ist mit anderen VM's zu kommunizieren dürfte das ganze ziemlich sicher sein. Wenn man es aber erlauben will gibt es dafür mehrere Möglichkeiten "VMCI", "gemeinsame Ordner" oder auch virtuelle Festplatten die auf mehreren VM's eingebunden werden.

----------

## cryptosteve

Ich stelle darüber hinaus die überaus mutige und total unbewiesene Behauptung auf, dass 95% aller Servereinbrüche durch schlampig programmierte oder nicht ordnungsgemäß aktualisierte php-Seiten stattfinden. Und die restlichen 5% durch das Erlauben von Passwortlogins in Verbindung mit schlechten Passworten.

----------

## TheSmallOne

 *cryptosteve wrote:*   

> Ich stelle darüber hinaus die überaus mutige und total unbewiesene Behauptung auf, dass 95% aller Servereinbrüche durch schlampig programmierte oder nicht ordnungsgemäß aktualisierte php-Seiten stattfinden. Und die restlichen 5% durch das Erlauben von Passwortlogins in Verbindung mit schlechten Passworten.

 

Das glaube ich dir glatt.

Die Sache ist doch aber die: Gegen solche Angriffe kann man (mit entsprechend Ahnung und Zeit) etwas unternehmen. Außerdem ist es für diese Angriffe unerheblich ob ein Server physisch oder virtuell ist.

Meine Frage zielt eben in erster Linie auf die möglichen (zusätzlichen) Probleme, die sich durch die Nutzung einer VM ergeben, und die man eben nicht verhindern kann. (Eine VM hat ja wohl keine Möglichkeit sich gegen ihren Wirt abzuschotten und wenn der nun Buggy ist o.ä. nimmt das Schicksal seinen Lauf)

----------

## forrestfunk81

Bin gerade über L3 Cache Side-Channel Angriffe gestolpert.

 *Quote:*   

> Flush+Reload is a cache side-channel attack that monitors access to data in shared pages. In this paper we demonstrate how to use the attack to extract private encryption keys from GnuPG. The high resolution and low noise of the Flush+Reload attack enables a spy program to recover over 98% of the bits of the private key in a single decryption or signing round. Unlike previous attacks, the attack targets the last level L3 cache. Consequently, the spy program and the victim do not need to share the execution core of the CPU. The attack is not limited to a traditional OS and can be used in a virtualised environment, where it can attack programs executing in a different VM. 

 

Das klingt nicht gut. Hatte aber noch keine Zeit, mir das ganze Dokument durchzulesen.

----------

## schmidicom

Bezieht sich das nur auf VMware oder auch auf andere?

----------

## papahuhn

Interessant. So wie ich das Paper verstehe, ist diese Side Channel Attacke aber keine allumfassende Methode, sondern nutzt Unzulänglichkeiten der heutigen GnuPG Implementierung.

@schmidicom: Das bezieht sich auch auf VMware, wenn vRAM overcommitted ist. Man muss das ganze aber mal relativieren. Auf einem normalen Hypervisor gibt es mehr als die beiden VMs des Angreifers und des Angegriffenen, d.h. es gibt viele weitere Faktoren, die für eine Cacheverdrängung sorgen und einen solchen Angriff verkomplizieren.

----------

