Virtualized DMZ Network

Bl8ckr0uter

I have read a few docs on putting your DMZ boxes into your Virtual Network. The other guy here is on a real rampage ie he wants to virtualize every server in the company (including our current and future web proxy and our future IDS) I said we should keep a few out (mainly the proxy and IDS boxes as well as our web servers due to some other issues I don't really want to discuss). He disagrees of course. I was wondering what you guys though of a full virtual DMZ network. Here are some key facts:

The DMZ network will reside on the same physical set of ESX servers as our production network

It will sit on a different physical nic (of course)

Anyone doing anything like this? Any concerns?

blargoe

Our DMZ network is partially virtualized, using the same hosts that run internal VM's. Using separate physical nics, which are connected to our physical DMZ switches.

This isn't necessarily a best practice; however, I don't see it as much of a risk in my environment as it stands today.

azjag

Bl8ckr0uter wrote: »

I have read a few docs on putting your DMZ boxes into your Virtual Network. The other guy here is on a real rampage ie he wants to virtualize every server in the company (including our current and future web proxy and our future IDS) I said we should keep a few out (mainly the proxy and IDS boxes as well as our web servers due to some other issues I don't really want to discuss). He disagrees of course. I was wondering what you guys though of a full virtual DMZ network. Here are some key facts:

The DMZ network will reside on the same physical set of ESX servers as our production network

It will sit on a different physical nic (of course)

Anyone doing anything like this? Any concerns?

At my previous position I virtualized all of our DMZ boxes (OWA, TS gateway and Webservers) namely because the hardware they were running on was ancient. Didn't have to much of an issue with it. The DMZ servers were members of one domain running on a host that also had an members of another domain on it.

I would add another nic to increase redundancy and throughput. Gives you a failover just in case and can handle a spike in traffic.

As far as virtualizing the entire domain, i would leave one domain controller on a physical box sitting off to the side. This way if something happens you can still seize the fsmo roles. As much as I like virtualization and am a proponent of it, I still can't put all my eggs in one basket.

earweed

As far as virtualizing EVERYTHING it is not a good idea. There are some things which aren't recommended to be virtualized and best practices to follow.

Bl8ckr0uter

Well I guess we can close this thread. We are going to virtualize our DMZ because the other guy doesn't think there is any risk at all. I wasn't really concerned with making a VDMZ but the servers that we were going to put in there were well, I am not going to go into that. Anywho doesn't matter what I think now.

SteveO86

If you've got a Essentials+ license I think you have access to vShield it might help in lieu of VM security

Can't say I myself recommend virtualization everything, after all I have redundant servers for a few applications I refuse to virtualize the redundant servers. (Even though I have dual switches/NICs/upload links to my network from my virtual infrastructure)


When I setup our Blade servers to run virtualization, I did not design it to used in a DMZ only the internal network and it took a few weeks of going back and forth to keep it that way. Mainly because the blades I have can only have a max of 2 NICs I had each going to 2 separate switches already for redundancy, and I had to argue how much of a necessity the redundancy was.

MentholMoose

Here is a recent article covering security in virtual environments:
The Scary Side of Virtualization - Computerworld

One point of the article is basically that virtualization is new, and people are scared of the unknown. I don't really like this. Although the heavy reliance on virtualization may be a relatively new phenomena (at least for many companies), virtualization itself is a mature technology. If you arm yourself with knowledge, then it will no longer be unknown.

Anyway, besides this I think some valid points are made. One issue brought up in the article that would be important when deploying VMs in a DMZ is the status of templates used to deploy the VMs. You have to make sure the templates are free of vulnerabilities before deploying the VM into the DMZ, and they obviously need to be malware-free in the first place.

Even if you are diligent about keeping templates patched, they probably aren't always going to be fully patched, so it would be unsafe to deploy a VM from such a template directly into a DMZ. You could, for example, deploy a VM into a locked down remediation network that only provides connectivity to update servers, patch the VM, then move it into the DMZ.

Keeping templates malware-free will require ongoing effort, such as doing offline scans of the disk(s) in the template. You could, for example, deploy a new VM, but boot it directly to an ISO that has updated antivirus software (e.g. a BartPE disk).

Chris:/*

One very interesting piece of information I found in my GSEC course was when Eric Cole discussed how a SANS group was testing to see if they could complete a Guest Breakout. In 2009 it was successful on ESX but all it did was crash the entire Host. That being said the people who attempted the hack were some of the best in the buisness. This provides no greater risk than any other system in a DMZ other than they are multiple Guest on one Host. This was one of the reasons VMware is moving away from ESX.

This could cause serious problems in a DMZ but as MentholMoose mentioned reducing your vulnerability footprint would reduce the likely hood of it happening.

MentholMoose

Chris:/* wrote: »

This was one of the reasons VMware is moving away from ESX.

Right. If you check the VMware security advisories, the vast majority of them are for components of the ESX service console (a RHEL derivative). ESX 4.1 is the final release of ESX, and only ESXi will continue being developed and updated. I think this is the right move even though there are a few benefits of having a general purpose OS serving as the parent partition for the host. Having only a hardened parent partition with few moving parts reduces potential vulnerabilities and likewise will reduce the number of security advisories, and should go a long way toward assuaging the concerns expressed by execs in the article I linked above.

psneathen

Does anyone happen to have a sample diagram of the physical comonents and logical data flow of a virtualized DMZ. I'm looking for more than the high level diagram that VMware provides. For example, I'm looking for details on switch layout, FW placement, shared storage usage, etc. Anything you can offer would be greatly appreciated. We are a small library, so we are considering virtualizing our DMZ on 2 or 3 physical host servers running ESXi standard. These would be the same physical host systems that will contain our VMs for our internal trusted network. I'm also not sure if I should/need to consider vShield, as it is very expensive.

azjag

I don't have a diagram like that handy. I'll look around and see what I can find. If you are going to host both internal and external on the same physical hosts then I would recommend vShield to keep things separate.

Welcome to TechExams

RouteThisWay

I'll see what I can help with.

We have virtualized our entire DMZ. Our web servers share the same hosts and datastores as our internal machines. We use seperate physical NICs on the hosts that are tried to them to connect directly into our FW.

Again, as stated above, this may not be best practices per se but it is an acceptable risk for our environment. Especially since previously they were running on ancient 2950s that were ready to explode.