Choosing the Right Security Tools To Protect VMs
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."
They DO exist : Juniper proposes Virtual Gatezay, Trend Micro has Deep Security, etc.
Do a google search sometimes ?
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?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Itanium emulation! You can't exploit hardware that no one runs!
This is just and ad for trend micro.
mov ah, 4ch
int 21h
"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."
And the altor networks vGW which runs in the hypervisor space isn't a real product. Nor was it ever bought by Juniper...
Nothing to see here. Because it's virtual we change all the rules.
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 web server) may in fact be accessible to the larger network or even to the Internet via the firewall, but I certainly wouldn't make the VM hosts themselves accessible in this way.
I'm really just trying to sort out why this is some sort of unique situation. Why would I need to do anything more spectacular for a Xen or VMWare host than I would for, say, an Active Directory domain controller? In both cases you have a control panel that can make very substantial changes to servers and networks via network protocols, so you don't do things like open the TCP or UDP ports to the outside world.
The world's burning. Moped Jesus spotted on I50. Details at 11.
linux iptables or windows firewall can be used to filter traffic between VMs. Network firewalls can be used for the traffic that actually leaves the physical host. It is safer to make assumption that all VMs on the host share the local network and therefore if they need to protected from each other that is responsibility of the guest system.
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
The product is on the market for some years now....
He seems to think that VMs somehow behave differently on a network than physical machines.
I would expect nothing less from a worthless "slashdot BI" advertisement for a TrendMicro product.
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's IDS (which is the commercialized version of Snort), though I haven't done any serious traffic measurement yet (and Sourcefire's very upfront about "Predicting performance in a VM without specific configuration detail is really hard so we're not making promises.") And maybe you want to run Checkpoint firewall software on a VM instead of a dedicated box, or maybe you want to run OpenBSD as a firewall. A couple of differences between the VM and appliance environments is that the appliance might have specialized ASICs or FPGAs to do pattern matching, as opposed to just using the CPU (and its vector processors etc.), and also that the virtual firewall or IPS is competing for CPU and memory resources with the application servers, so you need to pay attention to performance.
Also, because VMware can move processes between servers, you do need to size any external firewalls and network connections to accommodate the maximum load, not just an average load. For instance, if you've got two data centers for redundancy, and you're running active/active as opposed to active/backup, the load at one center might double if the other one fails. No big surprises there, though VM environments do give you a lot more flexibility about load balancing. You can get into situations with firewalls (or to a lesser extend, IDS), where a session gets started on one firewall, the VMware system moves the application process from one hardware server to another, which wants to use a different firewall, and so the second firewall might or might not know enough to pick up the session in the middle. Some firewalls let you configure a high availability pair that exchanges state information, some don't, and so sessions that were active when you moved the application between servers have a risk of breaking. (For IDS, that's less of a concern, though it's possible you could miss a malware event if it moved at just the wrong time.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Terry Tate is the man.
Security and VM in the same sentence. There is no security in VMs, whether local or hosted.