As I mentioned in the introduction, there are a number of ways to deploy secure DMZ infrastructure. The definition of secure is going to vary from person to person, and business to business. I will cover the options, the high level considerations of each and it is up to you to make your own choice moving forward.

The easiest DMZ deployment involves sitting ESX on your internal or management network and physically connecting some of the nics for virtual machine traffic into the DMZ. In this configuration your ESX server is actually crossing both your secure DMZ zone and your production zone. Now the interesting part, what are the risks ?

The risks are twofold, and the actual risk level is dependant on an unkown and your own staff. The first major risk is a management risk, there is a chance that someone fumbling in the server room on a maintenance window will actually physically patch a nic into the incorrect network segment.

There are a number of things you can do to minimise this risk by actually labelling physical network ports correctly. You should also make sure that the nics are configured as access ports with specific VLAN tagging so that a mispatch rejects traffic to the wrong network segment due to the incorrect VLAN tag etc. But more than likely when this sort of accident occurs it is two in the morning, the eyes are blurry, labels are hard to read and you are out of red bull!

Another risk in this situation is again in the management of the environment. You have labeled all of your vswitches and your port groups with meaningful names but your sysadmin is away and you have a contractor in. How easy would it be for the unitiated person who doesnt understand the environment to multihome a server on both networks or to misconfigure a virtual machine on the wrong network segment. After all changing port group access on a virtual nic is too easy. There are obviously a number of ways to minimise this risk, by locking down permissions, making sure that no other port groups are on the host etc. The managment risk still exists.

And now the big discussion point. The ESX infrastructure itself. What if someone compromises the virtualisation layer ? Gets direct access from a virtual machine to the ESX host sitting on the production network segment. What if someone compromises the ESX host and jumps port groups or vswitches ? Could it be done ? The risk level there is up to you.

So what are the other options ? The next option is to deploy ESX in the DMZ, both the ESX server and the virtual machines that reside on it. If this path is taken, security zones should not be crossed, physical seperation is always the best medicine. So please do not sit ESX in the internal DMZ and the bridge the security zone to the external DMZ on the same server. 

This is not a bad option, a lot of purists will tell you that deploying ESX in the DMZ is introducing an extra element of risk and that the boxes should be physical to reduce box count and surface attack area. That is true to some degree, but take a look at the average DMZ there are normally redhat boxes out there in most DMZ's right now. Yes, ESX is not redhat but a lot of the same securing concepts from redhat apply to ESX. There is no reason that ESX cannot be as secure as another box if the time was taken to design the deployment and secure it correctly.

The issues with the ESX in the DMZ arise when you consider how to manage the infrastructure. The devil is always in the detail. Do you deploy VirtualCenter in the DMZ as well ? If you are not using virtualcenter then why even bother ? You do not get HA, you dont get DRS, but you do get a higher risk level from server failure. If you consolidate onto one server you increase your chances of heartache. Do you leave VirtualCenter on the inside of your network and punch a hole in the firewall on a random port with specific source and target address detail to minimise the risk ? Or do you configure up a seperate management vlan on the outside of the firewall, but isolated from the internal DMZ zone. My preference is the latter.

In this configuration we have an isolated VLAN management network that ESX and virtualcenter reside in, as a secondary range on your pix. The ESX hosts then have specific patching to the internal DMZ for virtual machine traffic, locked down with specific access ports again so traffic doesnt end up in the wrong place from management mistakes. So the ESX host is bridging zones but secure DMZ zones, minimising attack area, and even if the underlying infrastructure was exploited and undermined then the intruder would be no better off. They would still be on the wrong side of the firewall, just located in a different VLAN!

Obviously as many security practices as possible should also be applied in any configuration, like backing up the infrastructure, custom ports, honey pots, random usernames with minimal permissions and log exports to a seperate secure location.