Discussion:
OT: Disadvantages of using virtual firewalls like OpenBSd
(too old to reply)
carlopmart
2010-11-23 12:38:04 UTC
Permalink
Hi all,

First of all, I don't want to start a flame. I will to know your opinion about
using virtual firewalls in virtual infraestructures like vmware, kvm ,xen, etc ...
like OpenBSD.

Advantages are very clear for me: provisioning, administration tasks, etc ... But
I will to know disadvantages. What is your opinion from the point of view of security?

Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
carlopmart
2010-11-23 12:48:49 UTC
Permalink
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several virtual
bridges under a ESXi host and then attach them to a virtual firewall like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case you have
all network stack except layer 1, correct??
--
CL Martinez
carlopmart {at} gmail {d0t} com
carlopmart
2010-11-23 13:17:11 UTC
Permalink
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several virtual
bridges under a ESXi host and then attach them to a virtual firewall like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi and KVM (I don't
know about xen), you can attach physical hardware to a specific guest, like network
interfaces. Then, you have all network stack asigned to a virtual machine. Where are
the disadvantages in scenarios like this??

Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Jim Razmus
2010-11-23 13:33:16 UTC
Permalink
Post by carlopmart
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several virtual
bridges under a ESXi host and then attach them to a virtual firewall like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi
and KVM (I don't know about xen), you can attach physical hardware
to a specific guest, like network interfaces. Then, you have all
network stack asigned to a virtual machine. Where are the
disadvantages in scenarios like this??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
You're still relying on software to the right thing and protect against
abuse. "attach physical hardware to a specific guest" is done via
software. Do you trust that software?

jim@
carlopmart
2010-11-23 13:32:53 UTC
Permalink
Post by carlopmart
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure
several virtual
bridges under a ESXi host and then attach them to a virtual firewall
like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this
case you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi and
KVM (I don't know about xen), you can attach physical hardware to a
specific guest, like network interfaces. Then, you have all network
stack asigned to a virtual machine. Where are the disadvantages in
scenarios like this??
Thanks.
http://kerneltrap.org/mailarchive/openbsd-misc/2007/10/24/352059
Yes, but this question is three years old and hypervisors have changed ....

Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
carlopmart
2010-11-23 13:39:41 UTC
Permalink
Post by Jim Razmus
Post by carlopmart
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several virtual
bridges under a ESXi host and then attach them to a virtual firewall like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi
and KVM (I don't know about xen), you can attach physical hardware
to a specific guest, like network interfaces. Then, you have all
network stack asigned to a virtual machine. Where are the
disadvantages in scenarios like this??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
You're still relying on software to the right thing and protect against
abuse. "attach physical hardware to a specific guest" is done via
software. Do you trust that software?
Uhmm ... good point Jim. But, but one question: can you compromise this virtual
firewall using a specific exploit, procedure, etc and don't do the same with a
physical firewall ??
--
CL Martinez
carlopmart {at} gmail {d0t} com
STeve Andre'
2010-11-23 12:48:10 UTC
Permalink
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your
opinion about using virtual firewalls in virtual infraestructures like
vmware, kvm ,xen, etc ... like OpenBSD.
Advantages are very clear for me: provisioning, administration tasks,
etc ... But I will to know disadvantages. What is your opinion from
the point of view of security?
Thanks.
Don't.

Search the archives for virtualization and you'll get some ideas about it.

--STeve Andre'
Bret Lambert
2010-11-23 12:42:24 UTC
Permalink
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your opinion
about using virtual firewalls in virtual infraestructures like vmware, kvm
,xen, etc ... like OpenBSD.
Advantages are very clear for me: provisioning, administration tasks, etc
... But I will to know disadvantages. What is your opinion from the point
of
Post by carlopmart
view of security?
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Post by carlopmart
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Bahador NazariFard
2010-11-23 13:56:50 UTC
Permalink
OK
You are right.
But you know in this case your security level is not higher than virtual
machine.
Because your security level in complex chained system is not higher than
weakest point.In fact you are accepting the risk of using virtual machine.
I think in this case if your virtual machine system is not stronger than
OpenBSD you should not use it.
If one can exploit virtual machine he/she can hurt your platform.

I think virtual systems are very very useful but they are not very good for
security box.

I think virtual machine is one of your assets that you should be able to
protect it.
because it may have many guest and provide several services for your client
.

For example in this senario you can not protect your network even your
firewall box against DoS or DDoS attack.
because your virtual machine has to get a lot of packet before your
firewall.
Post by carlopmart
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several
virtual
bridges under a ESXi host and then attach them to a virtual firewall like
OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case
you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi and KVM
(I don't know about xen), you can attach physical hardware to a specific
guest, like network interfaces. Then, you have all network stack asigned to
a virtual machine. Where are the disadvantages in scenarios like this??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
Gula_Gula =;=; BNF
Brad Tilley
2010-11-23 14:12:10 UTC
Permalink
Post by carlopmart
Advantages are very clear for me: provisioning, administration tasks,
etc ... But I will to know disadvantages. What is your opinion from the
point of view of security?
I use virtualization for many things (mainly for the productivity
advantages that you list), but it has always bothered me because
virtualization is pretending.

In Java, for example, the VM pretends about a lot of things that are not
true in the physical world. This makes it easy and convenient for
programmers. The problem is that they come to believe that the pretend
things are real and then make assumptions (when dealing with physical
machines) that are incorrect.

I would say that so long as you understand that a lot of pretending is
going on when doing any sort of virtualization, (and you accept that)
and that you know the differences between the pretend machines and the
real machines then you know all you need to know in order to decide if
it is right for your environment.

Brad
Michal
2010-11-23 14:11:16 UTC
Permalink
Post by Bahador NazariFard
OK
You are right.
But you know in this case your security level is not higher than virtual
machine.
Because your security level in complex chained system is not higher than
weakest point.In fact you are accepting the risk of using virtual machine.
I think in this case if your virtual machine system is not stronger than
OpenBSD you should not use it.
If one can exploit virtual machine he/she can hurt your platform.
I think virtual systems are very very useful but they are not very good for
security box.
I think virtual machine is one of your assets that you should be able to
protect it.
because it may have many guest and provide several services for your client
.
For example in this senario you can not protect your network even your
firewall box against DoS or DDoS attack.
because your virtual machine has to get a lot of packet before your
firewall.
This is a good post. I have esxi servers and they work well, but you'd
have a hardware firewall sitting at the front of network, unless you
want to do firewall testing etc. If you can afford to get some esxi
servers, I'm sure you can pay the little bit extra to get an OpenBSD
firewall on the go, even two for that matter
Stuart Henderson
2010-11-23 15:03:11 UTC
Permalink
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your opinion about
using virtual firewalls in virtual infraestructures like vmware, kvm ,xen, etc ...
like OpenBSD.
Advantages are very clear for me: provisioning, administration tasks, etc ... But
I will to know disadvantages. What is your opinion from the point of view of security?
Thanks.
How will you protect your management interface if the firewall is
virtualised?
carlopmart
2010-11-23 15:15:02 UTC
Permalink
Post by Stuart Henderson
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your opinion about
using virtual firewalls in virtual infraestructures like vmware, kvm ,xen, etc ...
like OpenBSD.
Advantages are very clear for me: provisioning, administration tasks, etc ... But
I will to know disadvantages. What is your opinion from the point of view of security?
Thanks.
How will you protect your management interface if the firewall is
virtualised?
At logical level or physical level?? At logical level I can configure a virtual
bridge on this interface and apply firewall rules. Physically, impossible, obvious.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Bahador NazariFard
2010-11-23 15:56:55 UTC
Permalink
At logical level who is responsible against layer two threats (vm or fw)?
You are using virtual machine and its network drivers aren't you?
I think it is so clear that in this solution health of VM is vital for
your network.

It seems you are concentrating and focus only about network layer
vulnerabilities.
but you VM may be vulnerable against application layer attacks even against
local guest system users.
for example VM may have a vulnerable web administration interface that can
be a good start point for your enemies!

eventually you have many guest system on your VM and your VM threats is
not limited only to network layer threats.
however I think even in this situam your firewall should process and filter
network traffic before than others(including VM).
Post by carlopmart
Post by Stuart Henderson
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your
opinion about
using virtual firewalls in virtual infraestructures like vmware, kvm
,xen, etc ...
like OpenBSD.
Advantages are very clear for me: provisioning, administration tasks,
etc ... But
I will to know disadvantages. What is your opinion from the point of view
of security?
Thanks.
How will you protect your management interface if the firewall is
virtualised?
At logical level or physical level?? At logical level I can configure a
virtual bridge on this interface and apply firewall rules. Physically,
impossible, obvious.
--
CL Martinez
carlopmart {at} gmail {d0t} com
--
Gula_Gula =;=; BNF
Vijay Sankar
2010-11-23 15:58:21 UTC
Permalink
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your opinion
about using virtual firewalls in virtual infraestructures like vmware, kvm
,xen, etc ... like OpenBSD.
Post by carlopmart
Advantages are very clear for me: provisioning, administration tasks, etc
... But I will to know disadvantages. What is your opinion from the point of
view of security?
Post by carlopmart
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
I am not a fan of using VMs for firewall infrastructure even though I like
VMs for software development/testing/staging purposes.

1) With regards to provisioning there are lots of complexities you end up
dealing with if you are in a highly available network. I could not find simple
solutions for obvious issues -- especially solutions that could be delegated
in an idiot-proof manner. In addition, when firewalls and proxies and load
balancers are on real boxes, it is easier to see where network cables are
coming from and which switches and patch panels they are going to. When hosted
on VMs stuff does happen :)

2) Administration tasks work OK when the VM is running properly and all
components are "certified". But it was very difficult to get practical advice
from vendors when I had issues running OpenBSD.

I feel it is more secure to run OpenBSD on real hardware than as a VM guest
because with real hardware you only need to restrict physical access and
OpenBSD can take care of the rest. With virtualization, you end up having to
learn a lot more about the VM environment and that knowledge seems to be very
fleeting. Installing OpenBSD firewalls on top of that "moving" structure may
still protect you but to me it makes everything needlessly complicated.


Vijay Sankar
***@foretell.ca
Jim Razmus
2010-11-23 17:00:05 UTC
Permalink
Post by carlopmart
Post by Jim Razmus
Post by carlopmart
Post by carlopmart
Because you're still relying on your host's network stack, you aren't
actually firewalling it.
Uhmm .. I am not sure about this. For example: you can configure several virtual
bridges under a ESXi host and then attach them to a virtual firewall like OpenBSD.
If you configure some pf rules, you are doing firewalling ... In this case you have
all network stack except layer 1, correct??
And one more thing: with latest releases of hypervisors like ESXi
and KVM (I don't know about xen), you can attach physical hardware
to a specific guest, like network interfaces. Then, you have all
network stack asigned to a virtual machine. Where are the
disadvantages in scenarios like this??
Thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
You're still relying on software to the right thing and protect against
abuse. "attach physical hardware to a specific guest" is done via
software. Do you trust that software?
Uhmm ... good point Jim. But, but one question: can you compromise
this virtual firewall using a specific exploit, procedure, etc and
don't do the same with a physical firewall ??
--
CL Martinez
carlopmart {at} gmail {d0t} com
Possibly, yes. Here's why. You're not attacking an OpenBSD host.

The hypervisor has a network stack that is engaged before any guest.
How else can you setup virtual switches, "attach interfaces", etc.
Assuming that stack is vulnerable in some fashion, you have the
opportunity to attack the guests from an entirely new angle. Moreover,
if your hypervisor is now compromised, why try to fight your way through
the network interface of the virtual firewall when you can attack the
firewall or other guests directly? Further, why even attack the guests
through their respective virtual network interfaces when you can poison
their virtual CPUs or other "hardware" devices?

IMO, this is a kin to the blob problem for hardware, but on a larger
scale. Your guests, OpenBSD or otherwise, are entirely dependent on
another layer of software. In this case ESXi, which is not infallible.

Does that explain it better?

jim@
Jiri B.
2010-11-23 19:28:32 UTC
Permalink
Post by carlopmart
Hi all,
First of all, I don't want to start a flame. I will to know your
opinion about using virtual firewalls in virtual infraestructures
like vmware, kvm ,xen, etc ... like OpenBSD.
Advantages are very clear for me: provisioning, administration
tasks, etc ... But I will to know disadvantages. What is your opinion
from the point of view of security?
Bypassing a virtual FW is so easy, just click in any hypervisor GUI,
moving machine, adding new iface etc... It's not so easy with real cabling.

You can have good privilegs in hypervisor GUI mgmnt but still - real
hw firewall is more separated...

What a pity OpenBSD doesn't run on Power{5,6,7} servers. I'd like to
put it in a lpar just for fun :)

jirib
Nick Holland
2010-11-23 20:14:55 UTC
Permalink
...
Post by carlopmart
http://kerneltrap.org/mailarchive/openbsd-misc/2007/10/24/352059
Yes, but this question is three years old and hypervisors have changed ....
Thanks.
what's changed?
Layering? Nope.
Crappy programming? Nope.
Better hardware? not really.
Features-before-security? Nope.

Lots new features, though.
And they fixed a few bugs AFTER they were brought to the vendor's
attention. Reactive at its best. You think they FIXED more bugs than
they added with the new features?

I think the virtualization products have proven their attitude towards
security and correctness. If something changed, it is theirs to
prove...and then, you still have the complexity issue. A more complex
system is unlikely to be more secure or more reliable than a simple system.

Nick.
Brad Tilley
2010-11-23 20:28:37 UTC
Permalink
Post by Nick Holland
what's changed?
Layering? Nope.
Crappy programming? Nope.
Better hardware? not really.
Features-before-security? Nope.
Good points. The goals of virtualization are, easy management, power
savings, quick provisioning and deployment, redundancy, etc. When you
talk about security and virtualization at the guest level, the
prevailing attitude is, "If it gets hacked, we'll just restore it from a
known good snapshot... problem solved."

I don't hear much talk at all about the host machine and security (the
real server that hosts all the pretend servers is just assumed to be
OK). There just seems to be a lot of trust in the vendors.

Brad
Post by Nick Holland
Lots new features, though.
And they fixed a few bugs AFTER they were brought to the vendor's
attention. Reactive at its best. You think they FIXED more bugs than
they added with the new features?
I think the virtualization products have proven their attitude towards
security and correctness. If something changed, it is theirs to
prove...and then, you still have the complexity issue. A more complex
system is unlikely to be more secure or more reliable than a simple system.
Nick.
Christopher Dukes
2010-11-23 21:15:36 UTC
Permalink
Post by Brad Tilley
Post by Nick Holland
what's changed?
Layering? Nope.
Crappy programming? Nope.
Better hardware? not really.
Features-before-security? Nope.
Good points. The goals of virtualization are, easy management, power
savings, quick provisioning and deployment, redundancy, etc. When you
talk about security and virtualization at the guest level, the
prevailing attitude is, "If it gets hacked, we'll just restore it from a
known good snapshot... problem solved."
With the way most of those app stacks are it's more like
"We'll restore it from snapshot when one of our admins or developers fat
fingers and blows it all to hell. We honestly can't distinguish
malicious behavior from a 3rd party from our existing application bugs."
Post by Brad Tilley
I don't hear much talk at all about the host machine and security (the
real server that hosts all the pretend servers is just assumed to be
OK). There just seems to be a lot of trust in the vendors.
No more trust than what they are putting into the OS distributions
management chooses nor the application stacks management chooses.
What's the point of compromising the OS or hypervisors when the
memcached servers are open to the entire Internet, and the app stack was
designed to make injection attacks easy.

Chris Dukes
SJP Lists
2010-11-24 08:43:15 UTC
Permalink
Post by Brad Tilley
Post by Nick Holland
what's changed?
Layering? Nope.
Crappy programming? Nope.
Better hardware? not really.
Features-before-security? Nope.
Good points. The goals of virtualization are, easy management, power
savings, quick provisioning and deployment, redundancy, etc. When you
talk about security and virtualization at the guest level, the
prevailing attitude is, "If it gets hacked, we'll just restore it from a
known good snapshot... problem solved."
I don't hear much talk at all about the host machine and security (the
real server that hosts all the pretend servers is just assumed to be
OK). There just seems to be a lot of trust in the vendors.
I'm waiting for the worm that specifically attacks ESX, or the like
and takes out entire infrastructures that have been built on that
trust.


Shane
SJP Lists
2010-11-24 13:36:30 UTC
Permalink
Post by Brad Tilley
Post by carlopmart
Advantages are very clear for me: provisioning, administration tasks,
etc ... But I will to know disadvantages. What is your opinion from the
point of view of security?
I use virtualization for many things (mainly for the productivity
advantages that you list), but it has always bothered me because
virtualization is pretending.
In Java, for example, the VM pretends about a lot of things that are not
true in the physical world. This makes it easy and convenient for
programmers. The problem is that they come to believe that the pretend
things are real and then make assumptions (when dealing with physical
machines) that are incorrect.
Yes, the virtualization of the programmable interval timer is one
example where pretending makes for some crazy situations. Only a few
nights ago, I patched a Debian ESXi 4.1 VM and when it rebooted it
would not boot, stating that the PIT was not functioning.
Time keeping is weird in x86 virtualization. I've seen Windows ESX
VM's with time that not only stops and then suddenly jumps forwards,
but even goes back!
Seen the madness of a virtualized NTP server? VMware have a
Timekeeping whitepaper that is sugar coated to say the least.
All anyone need do is watch the advisories for VMware to soon realise
that the choice is a trade off, where the drawbacks (security and
weirdness) are as big as the benefits.
And again, I say look at the Google research that found all
implementations vulnerable. If security matters less than the cost of
dedicated hardware, then use it.
Oh and another thing, a colleague of mine and myself noticed on
separate occasions with different VM's and OS' under what probably
would have been ESX 3.5 at the time, that a scheduled task would not
run if the console was not open / have focus!

I also noticed that while time appeared to completely stand still in a
Windows VM under ESX, it could be made to tick again by generating
lots of interrupts. Vigorous mouse movement barely made a difference,
however performing a file system search got the clock counting faster
than realtime.

I now wonder if this is due to dropped interrupts or lost ticks as
VMware refer to in [1], a document which describes the time keeping
weirdness that needs to be dealt with to get around the fact that the
x86 architecture was not designed from the ground up for this type of
virtualization.

So what other weird complexities do that need to employ to get around
other quirks?

Sorry, but as far as I am concerned, virtualization presents a new and
complex attack surface that no guest OS could control. So if you're
using OpenBSD for a security focused role, I'd forget x86
virtualization.


Shane

[1] http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
carlopmart
2010-11-24 15:52:58 UTC
Permalink
Post by SJP Lists
Post by Brad Tilley
Post by carlopmart
Advantages are very clear for me: provisioning, administration tasks,
etc ... But I will to know disadvantages. What is your opinion from the
point of view of security?
I use virtualization for many things (mainly for the productivity
advantages that you list), but it has always bothered me because
virtualization is pretending.
In Java, for example, the VM pretends about a lot of things that are not
true in the physical world. This makes it easy and convenient for
programmers. The problem is that they come to believe that the pretend
things are real and then make assumptions (when dealing with physical
machines) that are incorrect.
Yes, the virtualization of the programmable interval timer is one
example where pretending makes for some crazy situations. Only a few
nights ago, I patched a Debian ESXi 4.1 VM and when it rebooted it
would not boot, stating that the PIT was not functioning.
Time keeping is weird in x86 virtualization. I've seen Windows ESX
VM's with time that not only stops and then suddenly jumps forwards,
but even goes back!
Seen the madness of a virtualized NTP server? VMware have a
Timekeeping whitepaper that is sugar coated to say the least.
All anyone need do is watch the advisories for VMware to soon realise
that the choice is a trade off, where the drawbacks (security and
weirdness) are as big as the benefits.
And again, I say look at the Google research that found all
implementations vulnerable. If security matters less than the cost of
dedicated hardware, then use it.
Oh and another thing, a colleague of mine and myself noticed on
separate occasions with different VM's and OS' under what probably
would have been ESX 3.5 at the time, that a scheduled task would not
run if the console was not open / have focus!
I also noticed that while time appeared to completely stand still in a
Windows VM under ESX, it could be made to tick again by generating
lots of interrupts. Vigorous mouse movement barely made a difference,
however performing a file system search got the clock counting faster
than realtime.
I now wonder if this is due to dropped interrupts or lost ticks as
VMware refer to in [1], a document which describes the time keeping
weirdness that needs to be dealt with to get around the fact that the
x86 architecture was not designed from the ground up for this type of
virtualization.
So what other weird complexities do that need to employ to get around
other quirks?
Sorry, but as far as I am concerned, virtualization presents a new and
complex attack surface that no guest OS could control. So if you're
using OpenBSD for a security focused role, I'd forget x86
virtualization.
Shane
[1] http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Thank you all for your answers. Now I have a clearer idea of the downsides of
virtualization regarding security OS's, devices, etc..

Many thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Joachim Schipper
2010-11-26 16:50:13 UTC
Permalink
I will to know your opinion about using virtual firewalls in virtual
infraestructures like vmware, kvm ,xen, etc (...) [What about]
security?
Let me add one more reason to the ones already offered: there are *many*
side-channel attacks that can cross VM barriers. In other words, don't
do any sort of crypto (SSH, IPsec...) on virtualized machines, unless
you trust every VM on the same physical box.

I'm not online at the moment, but look at e.g. "Hey, You, Get Off of My
Cloud: Exploring Information Leakage in Third-Party Compute Clouds" by
Ristenpart, Tromer, Shacham and Savage for this kind of attack on
Amazon's VMs. There are many others.

Joachim
--
TFMotD: ipsec.conf (5) - IPsec configuration file
http://www.joachimschipper.nl/
Kevin Chadwick
2010-11-26 22:05:55 UTC
Permalink
On Fri, 26 Nov 2010 17:50:13 +0100
Post by Joachim Schipper
Let me add one more reason to the ones already offered: there are *many*
side-channel attacks that can cross VM barriers. In other words, don't
do any sort of crypto (SSH, IPsec...) on virtualized machines, unless
you trust every VM on the same physical box.
The cpu caches (encryption keys etc.) grabbed my interest at the
beginning but were then not mentioned further and their best examples
were not amasingly problematic for my purposes. The password grabbing
timing attack may be a concern if the hoster sets default management
passwords and must be kept in mind, but once setup I use ssh keys not
passwords and OTP once logged in. I don't doubt that more and more
attacks will see the light of day and so it is interesting but I
certainly wouldn't throw VMs to the wall due to this paper, but it
certainly reaffirms native to be far better and raises further questions
to marketers that say vms are good to use FOR security reasons.

Thanks for the link though and please send any others on this topic you
find.

Loading...