[Dshield] The race to the bottom - Virtualizing all your servers -security measure or not?
dianalucy00-sans at yahoo.com
Wed Aug 30 20:36:13 GMT 2006
If my host server is not using AMD CPUs, but uses Intel XEONs on brand name hardware,
does that mean that the nasty has less of an advantage? I may misunderstand,
but if AMD SVM extensions are not available, then they can't be used against
my hosting server, right? Or do AMD SVM extensions provide more protection? If so
does your virtualization host software have to support it to gain any benefit?
Do you have any better links on this subject?
- Linda :)
For my non-geek friends:Friends don't email friends .exe or .com files. So don't open those types of attachments!!
For my geek friends:
Adopt a newbie....
----- Original Message ----
From: Don Jackson <djackson at secureworks.com>
To: General DShield Discussion List <list at lists.dshield.org>
Sent: Wednesday, August 30, 2006 1:10:34 PM
Subject: Re: [Dshield] The race to the bottom - Virtualizing all your servers -security measure or not?
> Rather than throw in the towel, I thought what if I get there
> first. In other words, by virtualizing all my servers on top
> of a Linux host with a firewall and SELinux enabled, that I
> might beat that threat or at least delay it until I can
> figure out what else to do.
Rootkits (ugh) like SubVirt discussed in the article are based on the
layered architecture (bottom-up):
Hypervisor (sometimes part of the hardware)
It's good to get there first. In theory, a hypervisor that's been
installed first should be able to win over another hypervisor trying to
insinuate itself. I think the blackhats will prove that theory wrong.
However, it sounds like you are running VMs under a host OS. There are
many good reasons to do this (ask any VMware salespersion), but
protection from things like SubVirt and Blue Pill are not among them.
Trying to virtualize an already virtualized machine will probably just
crash it (but at least it won't be "0wn3d") unless the nasty first
tested for it using a VMRUN instruction from AMD's SVM extentions, for
> This is defense in depth on steroids - don't you think?
I think how the security implications of VM technology relate to other
objectives in the data center need to be better understood.
> Virtualization as a security measure, is that a good idea or a stupid
> (dee-dee-dee) one?
It's an interesting one, for sure.
There are tools being developed using sigatures and heuristics for the
classical rootkits (FU, FU2, deepdoor) by looking for inconsistencies
in EPROCESS lists, threads without processes, odd-looking handles or
other changed in NDIS structures, etc., but new tools will be required
to detect where your OS has been vurtualized by a "bad" virtualization
mechanism. Joanna Rutkowska's work at COSEINC gives us some ideas:
timing analysis for using VMMCALL and so forth (along with some ways to
cheat this, and other suggestions for additional protections). That's
much much hope for right now, however.
Of course, all these baddies still rely on basic security flaws or bad
design to insinuate themselves, so there is some immediate hope in the
sanctuary of best practices.
Don Jackson, CISSP
djackson at secureworks.com
PGP Public Key ID: 0x588C5EC1
Fingerprint: 2002 3DBB 5A1D 2A85 3EDE 0394 662E 32D4 588C 5EC1
SANS Network Security 2006 - Las Vegas NV October 1st-9th.
Wide selection of 1-6 Day Courses. Top Instructors!
(use Brochurcode "ISC")
"Best IT Security return on Investment" (Mario Chiock, Schlumberger)
More information about the list