Case Studies

This chapter presented several interesting aspects of how firewalls operate and how they can be deployed in networks. The introduction of this information needs to be reinforced with some real-world case studies that provide some answers to questions you might still have and clarify the important aspects of what has already been covered.

Case Study: To DMZ or Not to DMZ?

Carpathian Corporation has grown and is in need of increased security and additional capacity in the form of a new firewall; this time it wants to use a dedicated DMZ. If the Carpathian Corporation wants to continue with its proposed plan for self-hosting, it needs to consider the security-related issues relevant to the suggested DMZ solution. It is taking the right steps by asking what security ramifications should be addressed prior to making the purchase. The Carpathian IT staff needs to take a good look at the risk factors involved with providing for its own Internet services (web servers) and where the pitfalls might occur:

• Question/Security Issue #1: Can Internet traffic travel to servers on the private network, or is there another solution?

Answer: The web and mail servers will be attached to the DMZ segment. They will not be dual homed or have conflicts of security in its implementation because they will be physically separated from inside hosts.

• Question/Security Issue #2: How can the IT staff ensure that inbound network traffic will stay confined to the segment containing the web and mail servers?

Answer: The DMZ interface rule set will not allow external traffic to reach the private network, by nature of configured connectivity rules. This will keep the inbound Internet traffic confined to the DMZ segment only.

• Question/Security Issue #3: What measures can be taken to hide the private network from the inbound network traffic?

Answer: The DMZ interface will not have routes or dual-homed NIC cards that would normally enable this to occur.

The Carpathian IT staff is in the “If we self-host, we must use a DMZ” frame of mind. This frame of mind is correct, and that should be obvious at this point: Use a firewall with a DMZ interface—always!! A DMZ is another layer of security and defense for your network, as shown in Figure 7-4.

Figure 7-4 Firewall Deployment with Web Server in a DMZ

Cisco lists a variety of configuration settings when viewing their devices’ configuration files. Example 7-2 shows several configuration files for clarity purposes. To illustrate the case study, comments are made surrounding key configuration entries; however, not every command is discussed because that is beyond the scope of this book. You can find additional information at Cisco.com.

Example 7-2 Firewall with Self-Hosted Internal Web Server (No DMZ)

Cyberwall(config)# sh run
: Saved
ASA Version 8.5
!
hostname CyberWall
domain-name CarpathianCorp.com
enable password <ChangeMe> encrypted
passwd <ChangeMe> encrypted
names
!
!
interface Vlan1
 description SECURE INSIDE LAN [do not change]
 nameif INSIDE
 security-level 100
 ip address 192.168.0.1 255.255.255.0
!
interface Vlan2
 description OUTSIDE UPLINK TO SERVICE PROVIDER [do not change]
nameif OUTSIDE
 security-level 0
 ip address 209.164.3.2 255.255.255.0
!
interface Vlan3
 description DMZ INTERFACE FOR INTERNET FACING SERVERS [alter with care]
nameif DMZ
 security-level 50
 ip address 10.10.10.1 255.255.255.0
!
!--- These commands name and set the security level for each vlan or interface, the
ASA 5505 uses vlans to assign inside and outside whereas all other models have
physical interfaces. Through these commands, the firewall knows which interface is
considered untrusted (outside), trusted (inside) and DMZ. Notice the numeric values in
this configuration example. Here we have the least secure interface outside assigned a
security value of 0, as it should be. The inside interface is considered secure, so it
has a value of 100, with the DMZ being somewhere in between at 50.
!
interface Ethernet0/0
 description OUTSIDE INTERFACE [do not change]
 switchport access vlan 2
!
interface Ethernet0/1
 description INTERFACE FOR THE DMZ WEB SERVER [do not change]
 switchport access vlan 3
!
interface Ethernet0/2
 description RESERVED FOR INTERNAL HOST [alter with care]
!
interface Ethernet0/3
 description RESERVED FOR INTERNAL HOST [alter with care]
!
interface Ethernet0/4
 description RESERVED FOR INTERNAL HOST [alter with care]
!
interface Ethernet0/5
 description RESERVED FOR INTERNAL HOST [alter with care]
!
interface Ethernet0/6
 description RESERVED FOR INTERNAL HOST [alter with care]
!
interface Ethernet0/7
 description RESERVED FOR INTERNAL HOST [alter with care]
!
!--- An access list is created called "OUTSIDE" allowing WWW (http) traffic from
anywhere on the Internet to the host at 10.10.10.212 (the web servers REAL IP address
on the DMZ). Add additional lines to this access list as required if there is a email
or DNS Server. This is the first step in creating a rule set that permits traffic into
our network if it is destined for a specific IP Address.
!
access-list OUTSIDE extended permit tcp any host 10.10.10.212 eq www
!
! --- For purposes of this example we are not going to add anything else. Any
additional entries needing to be placed in the access list must be specified here. If
the server in question is not WWW, replace the occurrences of WWW with SMTP, DNS,
POP3, or whatever else might be required, like the ability to ping the server from the
Internet.
!
logging enable
logging timestamp
!
<<<output omitted for brevity>>>
!
! --- The following NAT commands specify that any traffic originating inside from the
ASA on the 192.168.0.0 /24 network will be NAT'd (via PAT because of the dynamic
interface command) to the ASAs public IP address that is assigned to the OUTSIDE
interface.
!
! --- The ASA NAT rules changed completely the new way is to define the subnets you
wish to NAT using object groups, the next four lines we have defined them as needed
for the INSIDE corporate as well as the DMZ.
!
object network OBJ_NAT_CORP
 description inside "corporate" subnet that must have internet access
 subnet 192.168.0.0 255.255.255.0
!
object network OBJ_NAT_DMZ
 description DMZ subnet that must have internet access
 subnet 10.10.10.0 255.255.255.0
!
! --- Once the subnets are defined in an object group we assign the type of NAT we
wish to perform as well as the direction. In the following examples we are permitting
the INSIDE and DMZ subnets to access the Internet using PAT via the ASAs outside
interface IP Address for both. This is shown in the command NAT (source interface,
destination interface) dynamic interface. The dynamic keyword means PAT to the ASA.
One of my favorite ways to check if this is working after configuring it open a web
browser and go to www.ipchicken.com this website will tell you the public IP Address
you are coming which should be the ASAs outside IP Address. Yes I know it's a goofy
name but that's what makes it easy to remember plus it makes people smile when you
tell them it.
!
object network OBJ_NAT_CORP
 nat (INSIDE,OUTSIDE) dynamic interface
!
object network OBJ_NAT_DMZ
 nat (DMZ,OUTSIDE) dynamic interface
!
! --- The last remaining NAT we must perform is for the Internet accessible Web server that is on our DMZ. Once again we create an object group but this time we specify a single host, which is the real IP address of the web server.
!
object network OBJ_NAT_WEBSERVER
 description real ip address assigned on the web servers nic card
 host 10.10.10.212
!
! --- Now that the object group is created identifying the servers real IP Address we assign a NAT in the same format as we previously did with the difference being after the direction (inside,outside) we define this as a STATIC NAT and give the public IP Address to use. In practice what will happen is as packets reach the ASA if they pass the access-list the ASA will check what their destination IP Address is. Should the destination address be 209.164.3.5 (web server public IP Address) the ASA will NAT those packets to the real IP Address of the server of 10.10.10.212 and forward them to the server on the DMZ.
!
object network OBJ_NAT_WEBSERVER
 nat (INSIDE,OUTSIDE) static 209.164.3.5
!
!
access-group OUTSIDE in interface outside
!
! --- There is only one access list allowed per interface per direction (for example,
inbound from the Internet on the outside interface) as we have shown here.
!
route outside 0.0.0.0 0.0.0.0 209.164.3.1
!
!--- Set the default route to be via the WAN routers Ethernet interface
!
<<<output omitted for brevity>>>
!
dhcpd dns 192.168.0.10 192.168.0.11
dhcpd domain mydomain.com
dhcpd address 192.168.0.2-192.168.0.125 inside
dhcpd enable inside
!
<<<output omitted for brevity>>>
!
! --- The last major functionality of an ASA show in its configuration is that of the
"inspects". Generally an inspect statement in the following section represents a
protocol that the ASA will be taking extra steps on the packets the statement
represents. For example many attacks are based on altering DNS replies so the ASA has
been configured to inspect DNS packets to help protect your network. Two inspects that
might be of importance to you are "inspect esmtp" and "inspect sip", depending on your
email server configuration and version the presence of esmtp may cause user issues
with emails, try removing it if this occurs. Regarding SIP when NATing a SIP
connection to an internal voice gateway you will want this statement as it provides
functionality that enables NAT to be done correctly and SIP to work, gotcha is it
depends on the provider. Inspects are very helpful and can be adjusted to offer very
granular security, please see www.cisco.com for more information.
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
!
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect icmp
  inspect icmp error
  inspect ip-options
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:88251e3c18c7d99dfa33f70b90228b63
: end
Cyberwall(config)#