Don't Get Burned By Virtual Appliances

The Heartbleed bug highlights potential drawbacks of virtual appliances and the flexibility and control offered by installable software.

Doug Hazelman

May 6, 2014

4 Min Read
Network Computing logo

Virtualization has provided us with packaged appliances that can be deployed as virtual machines (VMs), pre-configured and ready to run on a hypervisor. But threats like the OpenSSL bug Heartbleed coming to light should make you wonder what's running in that virtual appliance.

Heartbleed sent companies in a panic to update their systems, developers scrambling to identify vulnerabilities and patch them immediately, and users rushing to sites to change passwords. And still questions remain.

Virtual appliances are attractive because they're easy to deploy and don't require an operating system (OS) license. Yet, considering the extensive corrective measures triggered by Heartbleed -- and the exposed weaknesses -- some question if the ease and cost of virtual appliances are worth the price they may end up paying.

I am often asked why we don't offer our software as a virtual appliance. I often turn the question around and ask, "Why should we?" The most common reason customers want a virtual product is because of OS licensing -- specifically Microsoft Windows. Customers don't want to allocate additional Microsoft licensing for data center availability, and they often think virtual appliances are free. Besides licensing concerns, customers also view virtual appliances as easier to deploy; just slap them on a host, tweak a few settings, and, theoretically, you're good to go.

Virtual appliances are also attractive to software manufacturers, because they can more easily control the OS and installation of their software. They don't have to worry about conflicts with device drivers, other software applications, or even the service packs applied. Taking all that responsibility away from the customer means that support costs should be lower. There simply shouldn't be installation errors and conflicts.

But what's inside?

This is the biggest question I have for any virtual appliance. Obviously, there's the manufacturer's software, but what else? What's the OS distribution and version? What components have been removed or disabled that aren't needed? Are all the OS components up-to-date and patched? These questions proved especially important with Heartbleed: Does your virtual appliance use a vulnerable version of OpenSSL? Is your virtual appliance open to unauthenticated root attacks because of a patch that hasn't been applied to the OS?

These are difficult questions for a customer to answer, because they typically have no view or ability to control what's inside the virtual appliance. Also, if a vulnerability is discovered by the manufacturer, the customer usually has to wait for the manufacturer to deliver a new appliance or a set of patch instructions, and it could literally take weeks for the vendor to identify, fix, test, and distribute a solution.

Virtual appliances, by their nature, also take resources away from the very infrastructure they're designed to support or protect. An appliance requires a host, which is most likely running other VMs. If the appliance begins a CPU- or IO-intensive operation, like backup, then it must take resources away from other VMs -- and those could be critical production VMs.

Is installable software any better? In my opinion, yes.

If the customer installs software on top of an OS, then the customer is in control. It may require customers to license the OS, but chances are they already have licenses, as well as people familiar with managing that OS. Giving the customer control may require the software manufacturer to perform additional quality assurance, and it might cost a bit more in support due to configuration and installation issues. The important thing is the customer has that control.

In the event of an OS patch or vulnerability, customers can apply the patch themselves without having to wait for the manufacturer. They can also follow their own hardening guides for operating systems. They can close systems down or open them up. Or they can enable only the features needed for the software to run.

The other benefit of this approach is that software can be installed outside the virtual infrastructure. It may seem counterintuitive to have a physical server to protect a virtual workload. However, at least the virtual workload doesn't have to fight for host resources.

Flexibility and choice are important to customers when they have unique situations or rules they must follow. Installable software may not be the easiest route, but it is the most flexible. As we've seen with Heartbleed, it provides the reliability and performance that the "always-on" business needs for the modern data center.

Read more about:


About the Author(s)

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights