VMware Cloud Community
mvoss18
Hot Shot
Hot Shot
Jump to solution

DMZ Design Validation

Here is a summary of my current customer's environment30 physical machines total. I have a data center with 3 different vlansa public facing DMZ, a corporate DMZ, and our intranet. Security is important in this environment, and we do have to go through certification and accreditation audits. I'm worried that the security officer is going to push physical separation for each network, as in running different ESX clusters for each. This is going to be very expensive and inefficient, especially since both DMZ networks have 3-4 VMs each. I'd hate to run 4 VMs on a pair of DL380 G6s just because they're in a different trust zone!

I am proposing creating a distributed vSwitch with 4 teamed NICs, with each vlan segmented using vlan tagging, and combining all three sites on the same physical hosts. We're also considering having the MGMT and VMotion vlans on these same 4 pNICs. I've already read through this document and it details how this could be done.

http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf

I think we're going to need to use a product like vShield zones, or a 3rd party virtual firewall (like Altor) to pass our audits and keep the security folks happy. We can get more physical NICs on the hosts if that will provide better separation. I suppose from a network traffic perspective, it might be a good practice to at least put the service console and VMotion on separate pNICs.

Should we go with VLANs here, or would you recommend using pNICs on separate virtual switches for separation? Ultimately my question boils down to this--is my design solid and are there any additional recommendations to running three different trust zones in one cluster?

Thanks in advance!

0 Kudos
1 Solution

Accepted Solutions
Texiwill
Leadership
Leadership
Jump to solution

Hello,

EST still implies you are using VLANs within your physical network for DMZ and other trust zones.... So continue to use VLANs within the virtual world. You cannot really treat the vNetwork as 'less' secure than the pNetwork as it is actually NOT. It is more secure 'out of the box' from a Layer 2 perspective as the vNetwork is not susceptible to many Layer-2 attacks while the pNetwork 'out of the box' is susceptible.

So you use VLANs in the physical world and 'trust' that your pSwitches remain or are properly configured.

So use VLANs within the vNetwork as well. VST works just fine in this case.

However, if your DMZ is PHYSICALLY Separate from your other pNetworks then maintain that separation using EST from the DMZ pSwitch. I would not take the DMZ pSwitch connected it to the pSwitch directly upstream of the ESX host and then use EST/VST. This would not be correct.

In either case when you combine DMZs and non DMZ trust zones on the same cluster you need to increase your vigilance to ensure things are not moved to where they do not belong.

Even within the same cluster I tend to keep my DMZ VMs on their own host or hosts to ensure their load does not impact the rest of the environment or at least start them that way and let DRS figure the rest. I would also have separate LUNs just for DMZ VMs to offset disk IO issues.

However, if you need to be PCI compliant, your auditors MAY insist on physical separation at this juncture as PCI has yet to put out any other type of guidance. This decision is left up to the auditor actually. Which means most likely that you WILL Have to physically separate. Talk to your auditors they are there to help.


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

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]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill

View solution in original post

0 Kudos
4 Replies
sflanders
Commander
Commander
Jump to solution

Unfortunately, this question is tough to answer as different companies and auditors have different feelings on the topic. Personally, I think that VLAN separation (L2) is sufficient to ensure security between different networks on the same ESX host. Now, this is not to say that additional security measures such as firewalls, intrusion detection systems (IDSs) with taps, and web application firewalls (WAFs) if applicable are not required. However, if the question is whether or not VLAN separation is sufficient, I would say it is. It really comes down to the requirements of the company and its auditors as I have seen the demand for complete separation (something that I think defeats the purpose of virtualization and that can be cost prohibitive).

As for pNICs to separate VM versus management traffic, I use to configure ESX hosts that way, but with 10G connectivity on 1U or even 2U servers this sometimes is not an option. I think the bigger concern about having VM and management traffic in the same vSwitch is ensuring that network contention does not occur. To ensure each connection gets the appropriate throughput, I ensure the active/standby configuration is manually configured to balance throughput and redundancy.

Overall, I would say your design and thought process are sound and reasonable, but I would advise consulting the company and its auditors requirements and best practices.

Hope this helps! === If you find this information useful, please award points for "correct" or "helpful". ===
Texiwill
Leadership
Leadership
Jump to solution

Hello,

How are you 'currently' segmenting your trust zone traffic? If you currently use physical separation then I would continue to do this and still use a single cluster of ESX hosts.

If your trust zones in the physical world currently use VLANs, then using VLANs in the virtual network is acceptable usage and better protected actually than the physical world. However, if in the physical world you use different pSwitches for EACH trust zone, then I would maintain that separation by using multiple vSwitches within the virtual network which implies using multiple pSwitches.

Then I would assign roles and permissions to each network so that no one admin can push VMs from network to network. I may also go as far as use something like HyTrust to ensure VMs cannot be moved to networks where they do not belong.


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

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]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
mvoss18
Hot Shot
Hot Shot
Jump to solution

Hi Texiwill,

We are currently segmenting the trust zone traffic uzing EST VLANs all running through the same pSwitch. So each switch port can be configured with any one of the 3 VLANs. Are you suggesting physical separation in terms of having ports on my vSwitches dedicated to the VLANs the same way they are now and no VST? I guess we could do that but we're working with DL380s, so with iSCSI storage we'd be talking 10 pNICs per host--2 for SC/VMotion, 2 for iSCSI, 2 for Public DMZ, 2 for Corporate DMZ, and 2 for internal.

I'm thinking more like 2 pNICs for SC/VMotion, 2 pNICs for iSCSI, and 2 pNICs for VM traffic using vlan tagging (VST). We don't manage the pSwitches, but the network team has already blessed trunked ports. It's just a matter of getting security to accept it.

Thanks for the insight!

0 Kudos
Texiwill
Leadership
Leadership
Jump to solution

Hello,

EST still implies you are using VLANs within your physical network for DMZ and other trust zones.... So continue to use VLANs within the virtual world. You cannot really treat the vNetwork as 'less' secure than the pNetwork as it is actually NOT. It is more secure 'out of the box' from a Layer 2 perspective as the vNetwork is not susceptible to many Layer-2 attacks while the pNetwork 'out of the box' is susceptible.

So you use VLANs in the physical world and 'trust' that your pSwitches remain or are properly configured.

So use VLANs within the vNetwork as well. VST works just fine in this case.

However, if your DMZ is PHYSICALLY Separate from your other pNetworks then maintain that separation using EST from the DMZ pSwitch. I would not take the DMZ pSwitch connected it to the pSwitch directly upstream of the ESX host and then use EST/VST. This would not be correct.

In either case when you combine DMZs and non DMZ trust zones on the same cluster you need to increase your vigilance to ensure things are not moved to where they do not belong.

Even within the same cluster I tend to keep my DMZ VMs on their own host or hosts to ensure their load does not impact the rest of the environment or at least start them that way and let DRS figure the rest. I would also have separate LUNs just for DMZ VMs to offset disk IO issues.

However, if you need to be PCI compliant, your auditors MAY insist on physical separation at this juncture as PCI has yet to put out any other type of guidance. This decision is left up to the auditor actually. Which means most likely that you WILL Have to physically separate. Talk to your auditors they are there to help.


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

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]

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos