DMZ Recommendations

[Useless1]

Hi,

I was just reading up on DMZ deployment and have read the vmware guide and this post:

http://communities.vmware.com/thread/126555

Allowing one cluster for use with DMZ and production..

The never really do option would be to use DMZ/Production on the same vSwitch using VLANs... There are just too many attacks against this configuration to make it worthwhile, you really want physical separation of these networks within ESX and preferably outside ESX as well.

Why? Simple question, what attacks is this person referring to?

Also I am trying to understand why people would create a seperate cluster for DMZ VM's??

I am trying to gauge people's opinions on the approach of having 6 NIC's per host:

2 NICs in a vSwitch for Console and vMotion

2 NICs in a vSwitch for Production LAN

2 NICs in a vSwitch for DMZ

Or alternatively 4 NIC's per host

2 NICs in a vSwitch for Console and vMotion

2 NICs in a vSwitch for Production LAN and DMZ (With 2 port groups)

Anyone?

[Texiwill]

Hello,

Why? Simple question, what attacks is this person referring to?

Layer 2 attacks within your switching network.

Also I am trying to understand why people would create a seperate cluster for DMZ VM's??

For two reasons, usually there are not enough pNIC to have good separation, remember a DMZ should ideally use its own physical switches and NOT just be a VLAN on your existing switches (those Layer 2 attacks again). The other reason is that it isincredibly easy to move a VM from one security zone to another if they are all hosted on the same node. You have to have extra monitoring to find out if this happens. Usually visual monitoring.

I am trying to gauge people's opinions on the approach of having 6 NIC's per host:

2 NICs in a vSwitch for Console and vMotion

2 NICs in a vSwitch for Production LAN

2 NICs in a vSwitch for DMZ

Works quite well as long as the DMZ is actually going to separate DMZ physical switches.

Or alternatively 4 NIC's per host

2 NICs in a vSwitch for Console and vMotion

2 NICs in a vSwitch for Production LAN and DMZ (With 2 port groups)

THis is Just not worth the hassle, it is not security, as VLANs do not really provide security. Seperation does.

If you do not have separate physical switches for your DMZ, then you have to make a choice that you TRUST that your physical switches will never be susceptible to a Layer 2 attack. That means in general that you trust your firewall and other security measures to keep this from happening. if you only use VLANS to segregate yoru DMZ then the number of pNICs on your ESX hosts depends on what you want for performance and redundancy and nothing really security related as you have put your TRUST in VLANs as being safe.

I would involve your security team and do some risk assessment on the value of the data within the DMZ if it was to be compromised in some manner. Also the risk of an attack. DMZs are really hot tickets for attack hence the name, and good penetration testers can go through a DMZ as if it was not there depending on security setups on each host, etc within the DMZ.

Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

[vSerge]

These are really good questions, and there are a number of considerations with regards to using VLANs and how to properly secure L2 environments to reduce your attack surface area. To say that VLANs aren't secure and can't be used for DMZ usage isn't fair - the reality is that there lots of very secure VLAN implementation in production networks since the early part of this decade, especially seen in service provider networks. When you go to a Savvis, Global Crossing, AT&T, etc - you get a VLAN + CIDR block and datacenters' tenants are split up this way across the access layer. I recall building out the GlobalCenter datacenters in the late 90s/early part of this decade (these are now Savvis through Exodus acquisition), and the flat edge network which was 5500s with shared broadcast domains became 6500s or 7600 Ciscos or comparable solutions by other vendors w/ VLAN segregation by customer w/ VLAN counts in 1k+ range per datacenter. That was almost 10 years ago and we now see lots of large and small enteprise networks heavily leverage VLANs to reduce numbers of physical NICs, simplify physical topoligy, reduce port density requirements on the switching edge, provide more configuration flexibility, reach large consolidation ratios by having more VMs run on smaller number of ESX servers in collapsed DMZ+Internal environments, etc.

The following is a little bit of information about L2 attacks that folks often talk about and how to put some controls in place to prevent them.

1. CAM flooding or MAC flooding. Switches use content-addressable memory which contain VLAN/PORT/MAC-ADDRESS tables for looking up egress ports as frames are forwarded. These are the forwarding tables for the switches and they have limits in size. The CAM tables are populated by looking at the source MAC on a frame and creating a CAM entry that records which port maps to what source MAC. This attack type tries to overrun the table by generating large numbers of frames with different MACs, to the point that there is no more room in the CAM to store the MAC entries. When the CAM can no longer be populated, the switch will act like a hub and flood frames to all ports except the one the frame came in on (to prevent loops). To avoid this, there are features like setting the max number of MAC entries per port - in most cases you only need one per NIC. By setting this config, you get rid of this risk. Secondly, you have to evaluate the risk of such attack. The attacker has to penetrate into the DMZ, own a host within the DMZ or be already on a segment close to the DMZ to run this attack. This attack could not occur if there are intermediate routers in the path, since a mac rewrite occurs on those nodes. It's a good idea to limit your L2 broadcast domains and the diameter of the switched network to avoid propagation of these type of issues.

2. VLAN Cross-talk Attacks (or VLAN Hopping) - on Cisco switches, the dot1q trunks pass all tags be default. When you configure the ESX host to uplink via a dot1q trunk, and guest tagging is allowed, it's conceivable that a rogue guest can generate frames for VLANs it should not be a part off. Avoid enabled guest tagging and monitor your vSwitch config activity for such things. Another way to hop VLANs is to spoof dynamic trunk configuration frames from a host; protocols like these are used by vendors to automatically configure 802.1q trunks to set up and allow VLANs. To avoid this, configure switch ports passing tagged frames explicitly to be trunks and to explicitly forward specific tags. Also, don't allow for unplugged ports on the switches to remain in a VLAN used by important assets - put them into an unused VLAN to avoid the possibility of someone plugging in to a port and getting access to the VLAN. Avoid using default VLANs (like VLAN1 on Ciscos).

3. ARP spoofing - this is where a host on the same segment as other hosts modify the ARP table on the edge router/gateway to point to the attacker's MAC and are able to redirect traffic to themselves.This can be done using ARP request or Gratuitious ARP mechanisms. This is a bit tougher to defend against, but can happen regardless of whether you are using VLANs or not.

4. Spanning-Tree attacks - this is where attackers could cause a DoS and bring down the L2 network section by generated malicious STP BDPUs and become root bridges or confuse the protocol to block specific ports. This can happen regardless of usage of VLANs, plus features like bpdu-guard and root-guard help prevent this type of stuff.

5. VRRP or HRSP tampering - break the failover proocol for the default gateway, take over the gateway MAC yourself, etc.

6. Starve out the DHCP address range - not as big of deal of DMZ, unless you are using DHCP for servers.

We on the vShield Zones teams recognize these issues and try to provide visibility to VMs and flows destined/sourced to and from VMs from a network perspective. Using Zones, you can see an ARP spoofing attack from a VM or a physicl host on a segment and remediate the issue. Security best practices claim that you need visibility into L2 to deal with these type of issues, so in addition to providing firewalling functionality, we spent a lot of time on providing microflow visibility.

Also, we are seeing lots of customers using vShield Zones to isolate and segment clusters to provide dual-purpose for DMZ and internal server VMs usage using VLANs + vShield Zones isolation. We will be posting papers on this front and there will be examples at VMworld on how this can work. We are seeing three major use cases in the context of this:

1. Isolated/Segment DMZ in a dedicated set of ESX hosts or cluster with multiple trust zones provided by the vShield Zones.

2. Fully collapsed DMZ where the cluster or set of ESX hosts are shared by internal VMs and Internet-facing VMs.

3. Branch office environments where there may be some VMs hosted w/ Internet access, some for internal server usage and VDI as well.

[Useless1]

Hi,

This is a fantastic response and I really appreciate it...

Thanks

[Texiwill]

Hello,

The debate has always been to use VLANs or Not....

Since the 802.1q RFC does not mention VLANs are a security construct (no where do they mention security within this document) you are now in the area of TRUST and TRUST is a hard thing to define. If you choose to use VLANs outside the VIrtual Network (within your physical network) then you have to involve your security and networking teams. Your security team may already have addressed this TRUST and you do not have to worry.

Basing your security decisions however on TRUST that is NOT well defined within your environment implies that your security could be quite suspect.

VLANs within the virtual network are pretty safe actually (all the normal L2 attacks just do not work within the virtual network). Its the boundaries between physical and virtual networking that becomes the issue. This however is not to say that sometime in the future an L2 attack may not actually work within the virtual network as well. This depends on things outside of control today.

Since vShield Zones works within the vNetwork and not the pNetwork, and the vNetwork is currently inherrently secure from known L2 attacks, it is to your physical network that you must take a hard look.... Hopefully your Network and Security teams have ALREADY done this.

But realize that use of VLANs like CNAs and other data-commingling network technologies, security is based on TRUST unless each 'stream' is encrypted in some fashion which is quite difficult to setup and may not be possible depending on WHAT you are commingling.

Could an L2 attack originate from a VM? Most likely not, but an L3 or higher attack could.

Could an L2 attack originate from a host on your physical network? Yes, as could an L3 or greater attack.

Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]