Home > Articles > Cisco Network Technology > General Networking > Network Security First-Step: Firewalls

Network Security First-Step: Firewalls

Chapter Description

This chapter dissects a firewall’s duties to understand what makes a firewall operate and how it does its job.

From the Book

Network Security First-Step

Network Security First-Step, 2nd Edition

$29.59 (Save 20%)

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

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




interface Vlan1

 description SECURE INSIDE LAN [do not change]

 nameif INSIDE

 security-level 100

 ip address


interface Vlan2

 description OUTSIDE UPLINK TO SERVICE PROVIDER [do not change]

nameif OUTSIDE

 security-level 0

 ip address


interface Vlan3

 description DMZ INTERFACE FOR INTERNET FACING SERVERS [alter with care]

nameif DMZ

 security-level 50

 ip address


!--- 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 (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 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



logging enable

logging timestamp


<<<output omitted for brevity>>>


! --- The following NAT commands specify that any traffic originating inside from the

ASA on the /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



! --- 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



object network OBJ_NAT_DMZ

 description DMZ subnet that must have internet access



! --- 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



! --- 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 (web server public IP Address) the ASA will NAT those
packets to the real IP Address of the server of and forward them to the server on the DMZ.


object network OBJ_NAT_WEBSERVER

 nat (INSIDE,OUTSIDE) static



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


!--- Set the default route to be via the WAN routers Ethernet interface


<<<output omitted for brevity>>>


dhcpd dns

dhcpd domain mydomain.com

dhcpd address 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


  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


: end

7. Firewall Limitations | Next Section Previous Section