| View previous topic :: View next topic |
| Author |
Message |
TheSmallOne
Guru
Joined: 22 Jan 2005
Posts: 467
Location: Germany
|
 Posted: Wed Jul 17, 2013 6:07 pm Post subject: Erfahrungen vServer Sicherheit |
 |
|
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. |
|
| Back to top |
|
 |
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1978
Location: Schweiz
|
| Posted: Thu Jul 18, 2013 7:33 am Post subject: |
|
|
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.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
cryptosteve
Veteran
Joined: 04 Jan 2004
Posts: 1169
Location: GER
|
| Posted: Thu Jul 18, 2013 3:39 pm Post subject: |
|
|
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.
_________________
- born to create drama -
gpg: 0x9B6C7E15
CS Virtual Travel Bug: VF6G5D |
|
| Back to top |
|
|
TheSmallOne
Guru
Joined: 22 Jan 2005
Posts: 467
Location: Germany
|
| Posted: Sat Jul 20, 2013 11:14 am Post subject: |
|
|
| 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) |
|
| Back to top |
|
|
forrestfunk81
Guru
Joined: 07 Feb 2006
Posts: 567
Location: münchen.de
|
| Posted: Thu Jul 25, 2013 4:01 pm Post subject: |
|
|
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.
_________________
# cd /pub/
# more beer |
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1978
Location: Schweiz
|
| Posted: Thu Jul 25, 2013 5:20 pm Post subject: |
|
|
Bezieht sich das nur auf VMware oder auch auf andere?
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
papahuhn
l33t
Joined: 06 Sep 2004
Posts: 626
|
| Posted: Thu Jul 25, 2013 8:00 pm Post subject: |
|
|
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.
_________________
Death by snoo-snoo! |
|
| Back to top |
|
|
|
Deutsches Forum (German) 
