Thursday, January 26, 2012

Creating DMZ on ASA for Virtual Infrastructure (Part 1)

Recently I was tasked with creating a DMZ on our Cisco ASA 5510 for use with virtual machines in our vSphere environment.  In a physical environment I would have created a DMZ off another physical interface on the ASA and attached our physical servers to that but with the virtual infrastructure I had to design it a bit different.  Since our virtual infrastructure currently resides on the inside of our network we need to find a way of extending a secure DMZ into that environment.  To do this we will need to use sub-interfaces, 802.1q trunks, and typical ACL's on our ASA.  VMware refers to this as a "Partially Collapsed DMZ with Virtual Separation of Trust Zones".  Basically what that means is you use both physical and virtual pieces to enforce security.  Virtually separate the servers into different port groups on separate VLAN's and then enforce security between these port groups with a physical firewall device like our ASA.  This first post will focus solely on initial design and configuration of the Cisco ASA firewall device.

Currently we have a very flat network with a single VLAN and basic configuration.  The ASA has an inside and outside interface and all network switches operate on VLAN 1.  I will be adding two new sub-interfaces on the ASA for a multi-tiered DMZ as well as the associated VLAN's on our switches and virtual infrastructure.

Name       Interface    IP Address
Outside:     eth0/0         1.1.1.1
Inside:        eth0/1         172.20.6.0/24
dmzint:       eth0/1.10    192.168.10.0/24
dmzext:      eth0/1.9      192.168.9.0/24

Our virtual infrastructure resides on our inside network hung off of interface eth0/1.  I mentioned before that I would normally use for example eth0/2 to create a separate physical DMZ.  To take advantage of virtualization and avoid using addition physical ports on the ASA/network switch I opted to create virtual sub-interfaces on eth0/1.  Each sub-interface will serve as a DMZ network with different security levels.

asa1#conf t
asa1(config)#int eth0/1.10
asa1(config-subif)#vlan 10
asa1(config-subif)#nameif dmzint
asa1(config-subif)#security-level 50
asa1(config-subif)#ip add 192.168.10.1 255.255.255.0

asa1(config)#int eth0/1.9
asa1(config-subif)#vlan 9
asa1(config-subif)#nameif dmzext
asa1(config-subif)#security-level 25
asa1(config-subif)#ip add 192.168.9.1 255.255.255.0

What this does is create virtual sub-interfaces on our inside interface.  For eth0/1.10 the sub interface ID is 10 and will tag outgoing packets with VLAN 10.  For eth0/1.9 the sub-interface ID is 9 and is tagged with VLAN 9.  The interface ID and VLAN number do not have to match but it will ease administration if you do so.  The security levels chosen are relevant because they determine the default interface security.  The ASA by default allows an interface of higher security to pass traffic to an interface of lower security. What this means is the Inside interface (security level 100) will pass all traffic to the Outside interface (security level 0) without needing an ACL because there is an implicit allow rule.  Once we start implementing ACL's these implicit rules will drop off and we will need to manually configure security.

The overall logical ASA design will look like the picture below.

























We have the ability to control which traffic will flow between which networks as well apply additional NAT rules for further obfuscation.  We have also opened the option of dual homing servers in both demilitarized zones.  You can see from the picture below the enhanced isolation/segmentation we gain from this topology.  In the next segment I will discuss the switch and vSphere configuration.


No comments:

Post a Comment