Over the last few years virtualization has become increasingly popular. I’ve been virtualizing my datacenters for the last eight years, so the sudden rush to virtualization came as a bit of a surprise to me. However, it was a good surprise, because it showed that I was right to promote virtualization as a management, high availability and disaster recovery solution, even when nobody seemed to care about it.
With all the goodness that virtualization gives, there’s one thing that it doesn’t provide — a security solution. Virtualization is many things to many people, but one thing it’s not is a security solution. This means you need to consider how virtualization affects the security posture of your enterprise.
There are a lot of approaches you can take when designing your virtualized topology. The one I find the most useful is one that works in a non-virtualized infrastructure. You put all machines belonging to the same security zone on the same host machine. Servers that belong to different security zones are put on different host servers.
What this means in practice is that you mirror your network security zones to host servers. There are all types of security zones: anonymous access DMZs, authenticated access DMZs, network services segments, client segments, departmental segments, honeypot segments, and so-forth. The key issue with security zones is that there is a network security device controlling access into and out of the security zone.
So how would we approach this situation in an actual deployment? Let’s take a very simple network, I have the following security zones:
- Network services segment — this contains AD domain controllers, Exchange back-end servers, internal DNS resolvers, and SharePoint servers
- Anonymous access DMZ — this contains public Web servers, public DNS servers, public FTP servers, public media streaming servers, and inbound SMTP relays (Edge Exchange Servers)
- Authenticated access DMZ — this contains resources that require authentication at the firewall before access is allowed to these servers. For example, front-end/client access Exchange Servers, public facing SharePoint servers, and authenticated SMTP relays (used by external users who require SMTP to support POP3 or IMAP4 clients)
- Firewall zone — this zone is separate an distinct from other zones, since the firewall zone has the largest “attacker surface” representing all users on the Internet
Using this model, how many host servers do we require? Since there are 4 security zones, we use 4 different host servers. The goal is to reduce the risk of compromise of high value assets in relatively lower risk security zones by VMs in higher risk security zones. In this way, we don’t put all the VMs in the network services segment host machine at risk of attacks that would take place on VMs located on the public access DMZ host machine.
Keep in mind that we still need to segment these security zones from one another in the same way we did with our non-virtualized environment. What this means is that while we’ve consolidated all the servers located in each zone onto one or more physical host machines, we still need inline network security devices (which can be VMs on separate host machines if you like) to provide network level access controls between the zones. Virtualization doesn’t add any “magic security sauce” to the equation — the same principles of network security and zone segmentation apply. A possible exception to this rule is when you’re using IPsec server and domain isolation to create “virtual” network segments, but that’s another story for a different day.
Most importantly, this answers the question as to whether or not you should run network security devices in a VM. The answer is yes, there’s no problem putting network security devices such as firewalls, remote access VPN servers and SSL VPN gateways in virtual machines, but you have to make sure that you put all of these “edge” devices on a host separate from hosts containing virtual machines belonging to other security zones.
But sometimes a picture is worth a thousand words. Christofer Hoff in his blog entry regarding virtualizing security appliances at http://rationalsecurity.typepad.com/blog/2008/08/f…t.html sums up the entire issue with this picture:
The only thing I would change here is that the top line should read “Every time you deploy a security virtual appliance on the same host as non-security virtual machines….”
HTH,
Tom
Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com
PROWESS CONSULTING documentation | integration | virtualization
Email: [email protected]
MVP – Forefront Edge Security (ISA/TMG/IAG)