ESX on DMZ ?

[vcpguy]

VM's on DMZ

Is it advisable to keep ESX server which will have VM's on DMZ on internal VLAN's which has lot of ESX servers OR they should be kept on dedicated/seperate VLANs all togethar ?

I am looking for security of my ESX server (DMZ) and the internal ESx server ?

[Troy_Clavell]

check out this thread

if you found this or any other post "helpful' or "correct" please consider awarding points.

[sbeaver]

This is the way I would set thing up. Nic 0 and Nic1 should be a bond for he service console and vmotion port group. The other nics put in a bond and attached to the DMZ network, You want to be able to access the service console like you do all the rest of your ESX servers and what ever you do do NOT put the service console in the DMZ. Your internal network will be protected this way

Steve Beaver

VMware Communities User Moderator

Orlando Area VMware User Group Leader

====

Co-Author of "VMware ESX Essentials in the Virtual Data Center"

(ISBN:1420070274) from Auerbach

*Virtualization is a journey, not a project.*

[vcpguy]

Can't I just put the whole ESX box in the DMZ. This way, it will be much safer, right ? Even if the VM gets hacked and by someway, the host is also compromised, still, the attacket will not be able to access my internal LAN.

[LarsLiljeroth]

HI

If you trust a Vlan for your DMZ i would do this.

Add 2 or more nics to a vSwitch and do Vlan tagging on this. This is the most flexible way to do it in my mind.

Best regards

Lars Liljeroth

-

---

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

[sbeaver]

I fully disagree with that statement. If you put the "keys to the kingdom" on the DMZ namely the service console then if someone gets in they have access to all the VM's in on that server. Unless you run internal and dmz network to the ESX host and bridge a network in the VM there is NO KNOWN WAY to break out of vm into the host and get access via the service console to your internal network

Steve Beaver

VMware Communities User Moderator

Orlando Area VMware User Group Leader

====

Co-Author of "VMware ESX Essentials in the Virtual Data Center"

(ISBN:1420070274) from Auerbach

*Virtualization is a journey, not a project.*

[vcpguy]

But, still with this, I have Vmotion and SC for internal VLAN which has all of my ESX boxes...what is my VM gets hacked and the BOX compromised? Will that not affect all my ESX boxes ?

[sbeaver]

Again to repeat... If you VM gets hack it is the VM that get conpromised. THERE IS NO KNOWN WAY TO COMPROMISE A VM and GET ACCESS TO THE UNDERLINING ESX HOST. These vm's are isolated and the host is protected.

Steve Beaver

VMware Communities User Moderator

Orlando Area VMware User Group Leader

====

Co-Author of "VMware ESX Essentials in the Virtual Data Center"

(ISBN:1420070274) from Auerbach

*Virtualization is a journey, not a project.*

[azn2kew]

I just implemented this DMZ project for a client and suggest you read the Virtualization in DMZ guide from VMware. It has three options for you to deploy ESX in DMZ networks. This is what I have:

1. pNIC01->SC/VMotion

2. pNIC02->VMotion/SC

3. pNIC03/04->DMZ network

4. pNIC05/06->Production Network -if you want.

Make sure to secure place your VMotion, SC and Virtual Center server on management network behind a firewall. Remember VMotion traffic is clear text and that need to be protected. DO NOT place your SC network to the DMZ, basically allow people to hack and take control 100% of your ESX hosts. So basically, just add additional set of pNICs to ESX hosts and create new vSwitch for it and connect your physical DMZ cable connections to the pNICs.

After all the networks are in placed, use Tripwire, CIS, VMware, or DISA guides to lockdown your ESX hosts in more security depth. You also will be facing problems P2V the Physical DMZ servers to your production ESX cluster. You don't want port 445 & 139 to be wide open on the DMZ while P2V takes place, so we use a laptop with VMware Workstation using large external USB drives to do P2V all the physical DMZ and then import that .vmdk to your existing ESX clusters. Its a slow process but secure enough and that's the only solution we've felt comfortable.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

[azn2kew]

Here is a general visio layout of the diagram, if you want can use it but not guarantee to work on your environment. Alter it to your desires.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

Regards,

Stefan Nguyen

iGeek Systems Inc.

VMware, Citrix, Microsoft Consultant

[TomHowarth]

As Steve says, compromising a guest does not compromise the Host, leaving your Service console in the DMZ is inviting unwelcome visitors to the keys to the kingdom, There is no known I REPEAT NO KNOWN escape form the guest to the host.

if you are installing a DMZ ESX server, make sure that you secure your service console and Vmotion network on your internal Administation LAN

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator

[Texiwill]

Hello,

Please read http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf for information on using ESX in a DMZ.

Placing your SC within the DMZ is extremely dangerous and NOT secure by any stretch of the imagination.

Placing VMotion within the DMZ is even worse as it can be used to gain credential information for your VMs.

Placing your storage network within the DMZ is also considered dangerous.

So in essence any SC and vmkernel port should NOT be placed within the DMZ. Only the DMZ Virtual Machine network. Consider and ESX host to be a set of hybrid network, fabric, and compute appliance. For more information on security you can also refer to http://www.astroarch.com/wiki/index.php/Virtualization as a roll up of the blog posts I have written on the subject.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[JonT]

To go along with what has been stated several times by Steve here, we have implimented the split configuration for some of our "PCI Compliant" DMZ systems. This way our guests are isolated on the DMZ but our service console and VMKernel interfaces are on the internal PROTECTED network. This way was the easiest and most secure way for us to deploy into the DMZ. Trust me when I state that originally we were not going to virtualize our DMZ systems, but after several architectural discussions we committed to this. One of the fears we had with virtualizing in the DMZ was under-utilization of the capacity we built. Using this "split" model we can now host for multiple PCI Compliant applications/services using separate VLAN's from the same clusters of hosts.

[vcpguy]

OK, how about if from the external site, the IP address of my service console is blocked. No body can see that IP address(no advertisment) how does that sounds ? No body can connect to that IP address from outside. Only from internal they can connect to that IP address. If. we want to add further complexity, we can make some firewall rules that, XYZ address(internal) can only connect to the service console. Now, what would u suggest ?

Thanks

[Texiwill]

Hello,

OK, how about if from the external site, the IP address of my service console is blocked. No body can see that IP address(no advertisment) how does that sounds ? No body can connect to that IP address from outside. Only from internal they can connect to that IP address. If. we want to add further complexity, we can make some firewall rules that, XYZ address(internal) can only connect to the service console. Now, what would u suggest ?

Absolutely not. If an attacker breaks into your DMZ then they can then directly attack the Service Console/VMotion Network and thereby get access to everything. This is just NOT suggested. The type of attack is a Pivot attack and most attackers will pivot attacks from within DMZ to gain access to your internal network. Being able to attack the SC from within the DMZ would be considered gravy and an attacker would absolutely attack the SC once he sees that it is ESX. BTW, that information is also easy to get.

Your security team is missing a key point. ESX is a hybrid compute-network-storage appliance. Their are at least 3 maybe 4 networks in play here. They all need to be treated separately from each other! I.e. Service Console is not the same as the VM Network which is not the same as VMotion. If you place SC and VMotion within your DMZ, then there is a clear misunderstanding of how ESX handles networking.

Personally I would refuse to implement such a disaster pending HIGH RISK design.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[JonT]

Ok the obvious risk/question is "what if a hacker compromizes your DMZ system (guest)?" To go along with what Texiwill is stating here, if you truly want the protection that is architecturally the purpose of a DMZ, you have to segment your guest DMZ systems to be isolated from all others, aside from the port traffic you specifically allow through your firewalls using rules. Technically you COULD setup the SC and VMK interfaces in the DMZ as well, and setup rules to try to protect those interfaces but as Texiwill states you have just defeated the purpose of segmenting the networks out in the DMZ space. If you setup a physical host in your DMZ today, would you put the "out of band" management interface such as HP iLO or Dell DRAC inside the DMZ as well? Or would you put this other interface on a separate network such as a management "internal" network? If you answer yes to the separation question then why would you do it any differently in a virtual host environment. Also if you have the host SC and VMK interfaces on internal networks, you don't have to worry about maintaining the host (patching and deploying new guests from templates) to take place through your firewalls. Not sure what types of FW hardware/software you are using, but why waste those resources that should be servicing your applications and customers for these management type workloads?

Overall it is just a better and more efficient design to separate and leave ONLY the VM Networks (Guest traffic) on the DMZ segments. Other ways are techinically acceptable, but definately not recommended solutions in a large scale DMZ installation.

JonT