VSphere host in the DMZ

[barrycuda72]

I am going to be spinning up a Vsphere server to just serve guests that are in the DMZ using local disk.

I will be connecting these to our Vcenter server in our corporate lan.

What would be the preferred network configuration for this for maximum security of both the host and our corporate lan?

I was thinking a pair of nics on a virtual switch just for the guests in the DMZ and virtual switch's for the rest on our corporate lan.

Our networking group thinks having the host in the DMZ and controlling access in and out via the firewall would be better.

Or perhaps a hybrid approach using a second firewall.

Any help on this would be appreciated. I have read the Vmware in the DMZ doc but I would like to hear from someone with experience..

Thanks

[mittim12]

I would opt for dedicated ESX host in the DMZ with a dedicated virtual switch for guest and then a dedicated switch for service console in the DMZ with communication to and from VC running through the firewall.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[khughes]

So I can tell you what we do with our DMZ setup. There are many options that you can do, it all depends on what you feel comfortable with. While most people say put a dedicated host out in the DMZ, sometimes you don't have the means to provide that extra host. After much discussion, we decided to use the same hosts but we added a dedicated pNIC to the hosts which ran directly to our DMZ switches, so phyiscally they were separated, no trunking. From there we added a separate vSwitch and attached the pNICs going to the DMZ to that vSwitch and we had our separation.

To my knowledge no one has been able to jump the virtual switches yet (or it hasn't been made public) so we feel that is acceptable in the terms of security. Again its all what fits your setup, what resources you have available etc...

• Kyle

[mittim12]

I agree you work with the resources available to you. I'm not so much against having a separate dedicated DMZ vSwitch added to your ESX Clusters as long as the appropriate security measures are put in place. You wouldn't want someone accidently connecting up a internal server to the DMZ vswitch.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[khughes]

I agree you work with the resources available to you. I'm not so much against having a separate dedicated DMZ vSwitch added to your ESX Clusters as long as the appropriate security measures are put in place. You wouldn't want someone accidently connecting up a internal server to the DMZ vswitch.

Obviously those measures have to be in place, we're a smaller shop so I'm mainly the only making those changes. But in the global scheme of things you need to have those options in place regardless, because someone could just migrate a VM to the DMZ host too. There are always risks of human error, but as long as you're careful / have the right safeguards in place it should be fine.

• Kyle

[amvmware]

Both options suggested are valid - and i have deployed both options - at the end of the day it is which option is right for the organisation - if they are very security aware then using an esx cluster that is running internal and external systems may not conform to the secuirty practises of the organisation, so the other option is to put a dedicated host in the DMZ.

The downside to sharing the cluster is someone could move or place a VM onto the wrong network - accidentally or deliberately - something worth considering, is the administration skills and knowledge sufficient that you would feel comfortable this scenario would be unlikely to happen in your organisation.

If sharing a cluster i would use a dedicated vSwitch and physical NIC's, i would also suggest colour coding the network cables - i tend to go for red cables for DMz traffic - so no one could accidentally patch the wrong cables into the wrong side of the network.

[Texiwill · Accepted solution]

Hello,

Moved to the security forum.

I am going to be spinning up a Vsphere server to just serve guests that are in the DMZ using local disk.

First you must realize that there are at least 2 network trust zones at work here. THe VM Network for DMZ VMs and the Management appliace/Service Console for virtualization management.

I will be connecting these to our Vcenter server in our corporate lan.

Well the vCenter Server really should be within a Virtualization Management Network firewalled from the rest of your Corporate LAN.

What would be the preferred network configuration for this for maximum security of both the host and our corporate lan?

2 pNICS for SC/Management Appliance, 2 pNICs for VM Networks.

I would also use NON-Local storage as Local storage could be corrupted if the host has issues. This implies bye-bye VMs. So local storage is not a very good idea from an availability concern or a performance concern. FC or iSCSI are very very fast protocols compared to local storage.

I was thinking a pair of nics on a virtual switch just for the guests in the DMZ and virtual switch's for the rest on our corporate lan.

2 for VMs. 2 for Management NOT on the corporate LAN directly.

Our networking group thinks having the host in the DMZ and controlling access in and out via the firewall would be better.

Or perhaps a hybrid approach using a second firewall.

They do not understand virtualization if they are suggesting this.

The real question is: How is the DMZ currently implemented? Is the DMZ is currently implemented using physical switch separation or VLANs. If it is VLANs then where are they currently placing their TRUST? With themselves most likely. If they are using VLANs within the physical network you can use VLANs within the virtual network. If they do not think this is the case, then they really need to learn a bit more about the protections to VLANs within the vNetwork with respect to Layer 2 attacks as compared to the pNetwork (which is all about trust and not authoritativeness). if they use physical separation then you continue to use physical separation.

The first step is to migrate your vCenter and ESX/ESXi service consoles/management appliances to a separately firewalled Virtualization Management Network. You also place a bunch of Jump Machines within this network so that Admins use RDP to access the jump machines from which they run the vSphere Client and other virtualization management tools which should never be run from within your corporate network directly.

Once that is done your management network is protected which solves 3/4s of the current batch of attacks. Then you just add the new host/cluster to this network and let the VMs live directly within the DMZ.

I personally use physical separation of separate pSwitches and vSwitches jut for DMZ workloads but I do not have a separate ESX host JUST for the DMZ. I could and that would also work.

Any help on this would be appreciated. I have read the Vmware in the DMZ doc but I would like to hear from someone with experience..

I would be very interested in seeing their reasoning behind their suggestions and how the current DMZ is designed and working. That is the real question. Once you know this you can make the proper vNetwork suggestions.

Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, 2010

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]

[barrycuda72]

Thanks for the great response. I had never considered separating the vcenter server behind its own firewall which would include the corporate lan as well.

I don't have that available to me at present but will take that into serious consideration

Currently the DMZ is a physical switch dedicated to just DMZ so no vlan's involved.

I am planning on using a software based SAN for the local storage that included replication, so I am not too worried about corruption and performance is not a concern based on the workload of these servers.

If I can summarize my 2 options as I see them now.

Option 1

Dedicated host for DMZ guests placed in the DMZ, server has 4 pnics

Host would reside in the DMZ

2 nics part of a vswitch wired physically to the physical DMZ switch with no Vlans.

2 nics part of a vswitch for the rest of the stuff that is firewalled from the corporate lan to allow only the ports I want open

Option 2

Dedicated host for DMZ guests placed in the DMZ, server has 4 pnics

Host is located on the corporate lan

2 nics on a vswitch wired physically to the physical DMZ switch with no Vlans

2 nics on a vswitch that is vlan'd on one of the corporate subnets.

If I understand you correctly either option is viable. I am trying to keep the networking guys happy and not create a management headache for myself.

[RParker]

Networking guys will say that if you have 2 NIC, one is DMZ the other is firewall, you are cross linking a machine.

VM Ware will say this is perfectly acceptable, because each zone is a separate entitiy (2 different NIC) and no way it's cross linked. Network guys will then say that it's software, they don't trust software, which is true in most cases. Linux is robust, and not without error.

Now what happens is ESX has different zones, doesn't matter how the software is setup, ESX has a proven track record of keeping networks separated, doesnt matter if we are talking DMZ or not, there are customer sites that hosts different customer engagements on the same ESX server, separated by Network so they are private, which is the same scenario as a DMZ. Just because the NICs happen to be on a dirty internet , doesn't make it any more risky. If you manage to hack a machine, and manage to hack a Network, that VM is still behind a hyper visor, you can't hack what you cannot see or gain access to. If you do manage to make a VM unstable, what happens to the hypervisor? Nothing.

VM blows up, you keep going. If you hack a VM, the hypervisor and VM network only give it visibility to the same network of VMs, no way it's cross linked. It's physical connected to the SAME nic, so how does it circumvent security when ALL the VMs are on the same network segment, they only thing that COULD happen is a hacked VM can see other VM's on the same (DMZ) network, poorly written software can essentially do the same thing. hacking doesn't always imply intentional wrong doing.

So we have a server on a DMZ and internal network, I keep them separated obviously, but if the network fails, it's like compromising a NIC. There is no chance of cross linking, the ESX server if it is somehow breached, will simply crash, but you cant really alter it. So yes you can say it hasnt been hacked... yet.

Well 20 million customers world wide use VM Ware.. somebody would have said something by now if this were the case, I have yet to see a problem of this magnitude appear. So I think that means ESX is pretty safe.

[Texiwill]

Hello,

Thanks for the great response. I had never considered separating the vcenter server behind its own firewall which would include the corporate lan as well.

I don't have that available to me at present but will take that into serious consideration

This is the ideal setup as access to vCenter is access to everything basically.

Currently the DMZ is a physical switch dedicated to just DMZ so no vlan's involved.

I am planning on using a software based SAN for the local storage that included replication, so I am not too worried about corruption and performance is not a concern based on the workload of these servers.

Then you should maintain your physical separation all the way through your design. Including separate hosts just for the DMZ.

If I can summarize my 2 options as I see them now.

Option 1

Dedicated host for DMZ guests placed in the DMZ, server has 4 pnics

Good.

Host would reside in the DMZ

No NOT good. Only the VMs reside within the DMZ. The Service Console/Management Appliance resides within the virtualization Management network.

2 nics part of a vswitch wired physically to the physical DMZ switch with no Vlans.

Good.

2 nics part of a vswitch for the rest of the stuff that is firewalled from the corporate lan to allow only the ports I want open

Sort of, this is NOT ideal, you want all your virtualization management networks in teh same network, if you want to further segment that, go for it. Personally I just do not see the need.

Option 2

Dedicated host for DMZ guests placed in the DMZ, server has 4 pnics

VMs are located in the DMZ.

Host is located on the corporate lan

Service Console/Management Network is located within the Virtualization Management Network

2 nics on a vswitch wired physically to the physical DMZ switch with no Vlans

Good.

2 nics on a vswitch that is vlan'd on one of the corporate subnets.

Once more, you need to have the 2 NICs for Service Console/management appliance within the Virtualization Management Network which is firewalled from the corporate network.

If I understand you correctly either option is viable. I am trying to keep the networking guys happy and not create a management headache for myself.

Actually you need to stop thinking of ESX as a 'host' but as a hybrid device that provides networking, storage, and compute resources. This will help in any design you use. I like the following actually:

Internet <-> DMZ Firewall <-> DMZ Network <-> pNIC(s) (DMZ) <-> vSwitch (DMZ) <-> DMZ VMs

Service Console/Management Appliance <-> vSwitch (Managment) <-> pNIC(s) (Mgmt) <-> Virualization Management Network <-> Firewall <-> Corporate LAN

Storage Network <-> pNIC(s) (Storage) <-> vSwitch (storage) <-> vmkernel NIC (storage)

Do not think of the ESX host as a traditional Host but as a hybrid device.


Best regards,
Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009, 2010

Now Available: 'VMware vSphere(TM) and Virtual Infrastructure Security'[/url]

Also available 'VMWare ESX Server in the Enterprise'[/url]

Blogging: The Virtualization Practice[/url]|Blue Gears[/url]|TechTarget[/url]|Network World[/url]

Podcast: Virtualization Security Round Table Podcast[/url]|Twitter: Texiwll[/url]