Choosing the Right Security Tools To Protect VMs 44
Nerval's Lobster writes "Tech writer David Strom starts a discussion about how you should go about securing virtual machines for your organization. 'The need to protect physical infrastructure is well known at this point: most enterprises would balk at a network without any firewalls, intrusion prevention devices or anti-virus scanners. Yet these devices aren’t as well deployed in the virtual context. ... Take firewalls, for example. The traditional firewalls from Checkpoint or Juniper aren’t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers. Because VMs can start, stop, and move from hypervisor to hypervisor at the click of a button, protective features have to be able to handle these movements and activities with ease and not set off all sorts of alarms within an IT department.' He goes through the main functional areas that need protection, and points out that many vendors make it difficult to price out a given security plan."
Hypervisor Firewalls (Score:3, Insightful)
They DO exist : Juniper proposes Virtual Gatezay, Trend Micro has Deep Security, etc.
Do a google search sometimes ?
Re:Hypervisor Firewalls (Score:4, Funny)
They DO exist : Juniper proposes Virtual Gatezay, Trend Micro has Deep Security, etc.
Do a google search sometimes ?
But that would mean they would have to do their own research, {gasp}
Re: (Score:3)
http://www.vmware.com/products/vshield/overview.html [vmware.com]
Uh what? (Score:4, Funny)
The traditional firewalls from Checkpoint or Juniper arenâ(TM)t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers
So uh, how do those firewalls normally handle the "vast amount of traffic" originating from that many REAL systems, which can actually send MORE data than a bunch of virtualized ones?
Re: (Score:3)
I think you're on the right track there. It isn't about how many machines ... or whether they're virtual or physical ... it's about the cat5 connections. (or cat6 or whatever)
If you cannot manage the firewall so that the traffic over the data cables that are connected to it is handled correctly then find someone who can.
It's all about correctly designing the network and segmenting the systems. Do NOT put your external servers on the same VM host as your DMZ servers and/or your internal servers. (Yes, I have
Re: (Score:2)
Why not?
With proper VLAN segmentation, it's fine. Heck, we have VLANs on top of VLANs. The blade chassis does VLANs for its internal capabilities, then via ESXi we have actual VLANs for the different networks.
Re:Uh what? (Score:4, Informative)
Because it puts you in danger from "VLAN hopping" attacks.
http://en.wikipedia.org/wiki/VLAN_hopping [wikipedia.org]
And if one of your external servers is cracked then you SHOULD distrust all the systems on that system. If they're all on the same VM host then you have a big problem.
If they were segmented then the problem domain is reduced.
Just because it can be done does not mean it is good practice to do it.
Re: (Score:2)
depends on your size as a company. The VLAN setup is likely the best you can do if you are a very small startup. It certainly is better then stuff we've all seen where the domain server is also the web server is also the DB server, etc.
At some point you need to do better, but starting out I would say it's viable.
On the flip side, if you already have enough demand to need the capacity for two blade systems full of blades, then you really should be physically segmenting stuff at that point.
-nB
Re: (Score:3)
It's trivial to mitigate vlan-hopping attacks in several ways (the wiki pages covers two, a third is to simply use a physically different set of adapters for DMZ vlans).
Uh, no. VMs can't just up and communicate with each other through the host at a whim.
Re: (Score:2)
This is no different from physical servers when you're looking at the environment as a whole..
Re: (Score:1)
Re: (Score:1)
sure, at the fortune 500 scale you can probably justify this. anyone else who does not have multiple clusters of hosts cannot.
as previous posters commented, vlan tagging and the fear of hopping is pretty easily mitigated, there are also fun things one can do such as disallow spoofed packets from vm guests.
the odds of a meaningful exploit traversing the guest VM stack and into a hypervisor are pretty slim in my view, i see xen has one alert for something like this, but again...pretty slim.
Re: (Score:1)
How can you attack another VM on the same host? Seriously, I'd like to know if there's weaknesses in the hypervisor that could allow this?
Some Non-Fictitious Issues :-) (Score:2)
Yes, of course the article's mostly confused. But there are a few issues that aren't fictitious, to go along with the ones that are.
Inter-VM traffic is a problem, because it stays inside the server instead of getting out to where a firewall or intrusion detection system might see it, so there are cases where you might want either a virtual machine firewall or IDS, or need to move some of that traffic out of the server's virtual networks onto a physical Ethernet. I've been starting to work with Sourcefire
Re: (Score:2)
IMHO the real security issue isn't network traffic -- a bad virtual network design isn't worse than a bad physical design, the real security issue is in the hypervisor and hypervisor management. In large clusters, what vulnerabilities are there at the hypervisor level? Is it possible to inject a VM? Mask a VM from management software (ie, vCenter)? Change VM attributes (execution, memory, I/O priorities, virtual disk configurations, network access)? Initiate management controls (ie, self-vMotion)?
Right
Re: (Score:2)
you fail to see the marketing potential of this article.... buy buy buy
No brainer (Score:2)
The traditional firewalls from Checkpoint or Juniper aren’t designed to inspect and filter the vast amount of traffic originating from a hypervisor running, say, ten virtualized servers.
LOL very funny. If it were true, which it is not, but for the sake of argument were it true, then you'd just use the magic of VLANs to put a tenth on each of ten VLANs, and have 10 firewalls run in parallel.
Traffic is parallelizable. This is not the famous "nine chicks give birth to a baby in one month by cooperation" situation. This is more like you got 9 inches of old fashioned printed paperwork, and 9 interns who can only handle one inch of paperwork each, hmm I wonder how that works.
Re: (Score:2)
So it's like Snow White complaining, "Yeah, you promised me 7 inches... but not one inch AT A TIME!!!"
I run my VMs using (Score:5, Funny)
Itanium emulation! You can't exploit hardware that no one runs!
Re: (Score:2)
That will only go so far. Architecture-agnostic code is fairly common these days; an exploit for, eg. SSH is likely to work on many platforms.
Running NetBSD on MIPS or something like that does have a somewhat inherent advantage in that regard, though. Ecological diversity leads to robustness.
Re: (Score:2)
I doubt it. I would say an exploitable bug in SSH is like to effect multiple platforms. Its highly unlikely and shell code will be cross platform. Which might save you from the script kiddies running metasploit, but not from anyone who knows a little C.
This is an Ad. (Score:2)
This is just and ad for trend micro.
Re: (Score:1)
And an effort to get the writer some "I've been published" resume building cred.
Either way the article isn't helpful, nor does it provide any insight. Save yourselves the 20 minutes.
Re: (Score:2)
20? Man, you must read slow.
I just wasted 2 minutes, dismissed the article as shallow and ill thought out pap, and thought I'd see how many others thought the same.
Re: (Score:1)
Re: (Score:1)
+1 We're a Trend shop, and we investigated Deep Security (antivirus and soft firewall that runs at the hypervisor level, so no client on your VMs) but it was ridiculously expensive compared to running Officescan with Intrusion Defence Firewall on each VM. It is more efficient in terms of host resources, but we've got IO and CPU to burn, so there was no return for the huge cost.
I hear they may be moving away from a per VM licence, so it may become financially realistic for us. But for now we're sticking wit
Ummm... (Score:2)
I may be a little dense here, but I can't figure out why you would be exposing your VM host in such a fashion that you would need some special security measures. I'm just running KVM, and my hosts sit on the internal network. When I need direct access to virsh it's via SSH and if I need direct access to a guest's console it's via VNC over SSH. Moving guests around isn't really different than any other sort of network traffic, and is done via encrypted connections. Individual guests (like a mail server or we
Re: (Score:3)
Re: (Score:2)
The main problem is that VM-to-VM traffic doesn't always head out over a physical network. It's easy to put a firewall between different sections of a physical LAN; it's a good deal harder to put it between different sections of a single physical computer.
Re: (Score:2)
Iptables doesn't really care whether the network interfaces it's working on are real or virtual. If you have a problem with configuring iptables to deal with virtual networks on a host, then I'd say you've got bigger problems than just securing communications between guests.
I've had no problem setting up firewalls between guests on the same machine. I have two hosts that serve two different networks each, and the rules controlling the guests on both networks are not any worse than any other firewall rules.
Re: (Score:2)
How are you firewalling traffic between two physical machines plugged into the same switch and on the same vlan ?
Re: (Score:2)
software firewalls (Score:1)
When did he do his last google search? (Score:3)
When did he do his last google search?
Must be some time, otherwise he might have found Firewalls from "traditional vendors" integrated into the Hypervisor like https://www.checkpoint.com/products/security-gateway-virtual-edition/index.html [checkpoint.com]
The product is on the market for some years now....
I use an office linebacker (Score:1)