Virtual Servers and SecurityBy Larry Seltzer | Posted 2007-01-29 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Opinion: Virtualization creates the potential for more secure servers in a hosted environment, but it might all be an illusion.There's a good argument to make, and some experts make it, that virtualization is one of those technologies that's making a cyclical comeback. The whole VM thing, after all, was invented by IBM guys in the '60s, right?
My instincts are sympathetic to this argument: VMs were invented for an era when hardware was really, really expensive, and it made sense to make maximum utilization of it. But hardware is dirt cheap these days, and having n smaller physical boxes rather than one BHS (Big Honking Server) emulating n brings a certain amount of robustness through redundancy. I could argue it both ways, especially when it comes to manageability.
But security is one area where virtualization creates interesting new potential, at least in the short term. It has already created new services for some providers to sell, largely centered around security considerations.
Compromise the server and you've very likely compromised all of the Web sites on it.
This was a part of what I was writing about a few weeks ago with respect to new threats on the server. A series of vulnerabilities in PHP and associated technologies have led to massive compromises of hosted servers, even whole farms of hosted servers. After all, the vulnerabilities in the software on one server are probably present on others in the same farm.
Shared servers are also vulnerable to the "bad neighbor" problem wherein, for example, your server gets blacklisted by an RBL because another site on the same box and same IP address is spamming. I've personally been a victim of this, although it was almost 10 years ago.
So to protect themselves from some of these problems, also for performance considerations and for software flexibility, many customers choose a dedicated server. This is your own physical box that you manage and, within some limits, run whatever you please on.
Even though, as I've said, hardware is cheap, two boxes are probably close to twice as expensive as one. It's a lot cheaper for everyone in the hosting business if the sheer number of systems can be kept down. And there are probably quite a few sites out there on dedicated servers that just can't justify it in terms of performance requirements.
This is where virtual dedicated servers come in. Instead of selling another physical box to host on, with all the space, power and management issues attending it, a hosting service can deploy a BHS and sell virtual machines on it. Hosting services have already begun offering them.
At first glance, this seems like the perfect compromise: The systems will appear to software to be running on dedicated servers and therefore should be as protected against each other as dedicated servers.
The cheapness of hardware plays somewhat to the advantage of these systems, too, as it becomes cheap and useful to add new CPUs and memory to them. And management tools are emerging to handle such complex virtual environments.
But of course, it's all just software. If operating systems and application environments are not to be trusted because of flaws in them, why should we assume that virtual machine management software is infallible? And there are plenty of examples of vulnerabilities in VM software, such as this rather serious-looking one.
Even so, I think there's something to the "security through obscurity of virtual machines" idea. Clearly it's a new hoop through which attackers must jump, and it has to be less likely that whole farms of servers will be compromised in such an environment. At least in the short term. In the longer term, it's safer to assume that the limitations of virtual servers will become evident. By then maybe, mainframes will go out of style again.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. He can be reached at firstname.lastname@example.org.