Deploying Zone-based Firewalls

8/15/2019 Deploying Zone-based Firewalls

http://slidepdf.com/reader/full/deploying-zone-based-firewalls 1/112

DeployingZone-Based Firewalls

Chapter One ...........................................................3

Introduction to Zone-Based Firewalls

Chapter Two.........................................................12

Typical Zone-Based Firewall Designs

Chapter Three......................................................26

Configuring Zone-Based

Policy Firewalls in Cisco IOS

Chapter Four ........................................................54

Case Study:

Firewall with a Perimeter Network

Chapter Five.........................................................66

Advanced Zone-Based

Policy Firewall Configuration

Chapter Six...........................................................94

Configuring Transparent Firewalls

Ivan Pepelnjak

ciscopress.com



CHAPTER 1

Introduction

About the AuthorIvan Pepelnjak, CCIE No. 1354, has more than 15 years of experience in designing, installing, troubleshooting, and

operating large service provider and enterprise IP-based networks and security solutions. He is currently chief technolo-

gies advisor at NIL Data Communications, where he designed NIL’s Service Provider Academy program. He was one of

the architects of the Cisco Systems Service Provider curriculum. He also was the lead developer of several service

provider–focused courses covering Multiprotocol Label Switching (MPLS), Border Gateway Protocol (BGP), and IP

quality of service. Ivan has written four books for Cisco Press, covering Enhanced Interior Gateway Routing Protocol

(EIGRP), MPLS, and virtual private networking (VPN) technologies.

About the Technical EditorRandy Ivener, CCIE No. 10722, is a security specialist with the Cisco Systems Applied Security Intelligence team. He

is a CISSP and ASQ CSQE. Randy has spent many years as a network security consultant helping companies understandand secure their networks. Before becoming immersed in information security, he spent time in software development

and as a training instructor. Randy graduated from the U.S. Naval Academy and holds a master’s degree in business

administration.

[ 2 ]

© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.

Deploying Zone-Based Firewalls by Ivan Pepelnjak



CHAPTER 1

Introduction to

Zone-Based

Firewalls CHAPTER ONE

Introduction to Zone-Based Firewalls

In the mid-1990s, when the large corporate networks began to beconnected to less-secure public networks (for example, the early

Internet), security-conscious network administrators immediately

started to feel the need to secure their internal networks from potential

intruders. Networking vendors immediately responded with various

filtering mechanisms, most commonly implemented as packet filters

(filters that could accept or deny incoming or outgoing packets based

on their addresses, transport protocol, or port numbers). The initial

implementations of what we call firewalls today were thus more or less

a patchwork of packet filters.

It soon became obvious, however, that to implement reliable security

solutions, one needs a more structured and better documented

approach, resulting in the early concepts of firewalls, best documented

in the legendary book Firewalls and Internet Security by Cheswick and

Bellovin. Initial firewall designs were still based on packet filters, but

with the increasing complexity of Internet protocols and resulting fire-

wall policies, the concept of zone-based firewall design emerged.

[ 3 ]



NOTE

If you are not familiar

with packet filters offered

by the Cisco IOS, refer tothe Cisco IOS Access Lists

book available through

Safari Books Online or to

the relevant Cisco IOS

documentation.

Simple Zone-

Based Design.................................................4

More Complex

Zone-Based Design.......................................5

Implementing

Zone-Based Designs.....................................7



CHAPTER 1

Introduction to

Zone-Based

Firewalls Designing zone-based firewalls is a simple process using the following four steps:

Step 1. Internetworking infrastructure under consideration is split into well-documented separate zones with various

security levels. In this step, do not consider physical implementation of the firewall (number of devices,

defense depth, redundancy, and so on), just the separation of your infrastructure into zones (obviously, the

public network to which your network is connected is one of them).

Step 2. For each pair of source-destination zones (for example, from inside network to Internet ), the sessions (most

commonly, TCP and UDP sessions, but also ICMP sessions such as ICMP echo) that clients in source zones

are allowed to open to servers in destination zones are defined. For traffic that is not based on the concept of

sessions (for example, Encapsulating Security Payload [ESP] of IPSec), define unidirectional traffic flows

from source to destination and vice versa. As in the preceding step, do not contemplate the physical setup,

just the traffic requirements between zones.

Step 3. After the zones have been identified and the traffic requirements between them documented, design your

physical infrastructure, taking into account the security (dictating the number of devices between most-secure

and least-secure zones) and availability requirements (for example, redundant devices).

Step 4. For each firewall device in the design, identify zone subsets connected to its interfaces and (multiple zones

might be indirectly attached to a single interface of a firewall) merge the traffic requirements for those zones,

resulting in a device-specific interzone policy. (See the section “More Complex Zone-Based Design” on the

next page for more in-depth explanation of this rule.)

Simple Zone-Based DesignConsider, for example, a simple local area network (LAN) connected to the public Internet through the firewall, as shown

in Figure 1-1. Clearly, there are two zones in this example:

■

Inside network, which is trusted and should be protected■ Outside (including Internet), which is not trusted

[ 4 ]



NOTE

Within the context of this

discussion, server is any

host that accepts incom-

ing connections, regard-

less of its actual

hardware or software

implementation.



CHAPTER 1

Introduction to

Zone-Based

Firewalls

The firewall policy in this design is also simple:

■ Clients in the internal network can open sessions to any server in the Internet.

■ No inbound sessions are allowed from the Internet to the internal network.

Assuming that the network under consideration does not have high resilience or availability requirements, a simple design

with a single firewall device between the inside and outside network is sufficient.

More Complex Zone-Based DesignA more complex set of requirements would come from a medium-sized organization with its own publicly accessible

servers (for example, web server and e-mail server). Such a firewall would have three zones:

■ Internal network

■ Perimeter network with web and mail server

■ Public internet

[ 5 ]



Outside

Inside

Internet

FIGURE 1-1

Simple firewall setup

NOTE

The actual interzone fire-

wall policies for this

design are described in

the next chapter.



CHAPTER 1

Introduction to

Zone-Based

Firewalls If the customer would request a firewall design with at least two devices between the most protected (internal) network and the public Internet, your best option would be the traditional firewall design shown in Figure 1-2.

When implementing this design on actual devices, the firewall policy of each device would be based on a merge of

several interzone firewall policies. For example, the inner router does not differentiate between sessions originating in the

internal zone and terminating in either the perimeter or public zone. Table 1-1 documents the firewall policy that needs to

be implemented on the inner router.

TABLE 1-1 Firewall Policy of the Inner Router

Client Zone (Hosts Server Zone (Hosts

Originating the Terminating theConnections) Connections) Sessions Allowed

Inside Outside Traffic from internal zone to perimeter and public zones

Outside Inside Traffic from public and perimeter zones to internal zone

[ 6 ]



FIGURE 1-2

Traditional firewall

design

Public

Internal

Internet

Perimeter

Web/Mail Server

InnerRouter

Outer

Router

NOTE

Having a design with two

independent devices is

more secure than using a

single firewall device. If

the outside firewall in

Figure 1-2 is misconfig-

ured or fails, the insidefirewall still protects the

internal network.



CHAPTER 1

Introduction to

Zone-Based

Firewalls Implementing Zone-Based DesignsAs mentioned at the beginning of this chapter, many devices used in firewall implementations are using a concept of

packet filters to filter traffic arriving or departing through an interface. For example, Cisco IOS implements packet filters

with the ip access-list and ip access-group configuration commands that enable you to specify filtering conditions based

on source and destination IP addresses, Layer 4 protocol (for example, TCP, UDP, or ICMP), and Layer 4 port numbers

(for example, TCP port 80 for HTTP).

However, implementing even a straightforward firewall policy (like the one described in the “Simple Zone-Based Design”

section) with Cisco IOS access lists can lead to a configuration nightmare. A typical TCP session established from an

inside client to an outside server is set up as follows (as illustrated in Figure 1-3):

1. The client picks a random TCP port number (usually greater than 1024) as the source TCP port number.

2. The initial packet (TCP SYN packet) is sent from that port number to the well-known destination port (for example,

port 80 for HTTP requests).3. Return traffic from the server to the client is addressed to the high-numbered TCP port that the client picked.

To allow the return traffic, the packet filters on early firewalls thus had to permit traffic from anywhere on the Internet to

any high-numbered port in the internal network, resulting in an access list similar to the one in Listing 1-1. (The access

list also includes an antispoofing filter and allows incoming ICMP messages needed for normal network operation and

functions such as MTU path discovery.)

[ 7 ]



FIGURE 1-3

TCP session estab-

lishment across a

packet-filtering device

Outside

Inside

Internet

From 10.0.0.2 port 1030 to 172.18.25.1 port 80

10.0.0.2 172.18.25.1

From 172.18.25.1 port 80 to 10.0.0.2 port 1030

?



CHAPTER 1

Introduction to

Zone-Based

Firewalls LISTING 1-1 Sample IP Packet Filter in an Early Cisco IOS Release

interface Serial0/0/0.100 point-to-point

description Link to the Internet

ip access-group fromInternet in

!

ip access-list extended fromInternet

! prevent spoofing

deny ip 10.0.0.0 0.0.0.255 any

! allow minimum subset of ICMP messages

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any time-exceeded

permit icmp any any packet-too-big

permit icmp any any unreachable

! allow traffic to high-numbered ports

permit tcp any 10.0.0.0 0.0.0.255 gt 1023

permit udp any 10.0.0.0 0.0.0.255 gt 1023

NOTE

Later Cisco IOS releases added the established keyword, which matched return traffic in TCP sessions, making recognition of TCP sessions much

easier (but still leaving some gaps that hackers successfully exploited with skillfully crafted IP fragments). No such mechanism is possible forUDP traffic, so UDP is usually not permitted to freely flow between internal and external networks.

Permitting the inbound traffic to high-numbered ports would not represent a major security risk if some IP-based services

would not listen on high-numbered ports (some of them static, some of them assigned on demand), as demonstrated by

Listing 1-2, taken on a personal computer running Windows XP. If you use packet filters as previously proposed, all the

highlighted services are vulnerable to an attack from the Internet.

[ 8 ]



NOTECisco PIX, the Cisco

standalone firewall appli-

ance, was designed

around the concept of

conduits (old PIX termi-

nology for traffic flows),

which has from the

beginning included the

proper handling of

return traffic.



CHAPTER 1

Introduction to

Zone-Based

Firewalls LISTING 1-2 TCP and UDP Ports Opened on a Typical IP Host Running Windows XPM:\>netstat -an

Active Connections

Proto Local Address Foreign Address State

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING

TCP 0.0.0.0:443 0.0.0.0:0 LISTENING

TCP 0.0.0.0:445 0.0.0.0:0 LISTENINGTCP 0.0.0.0:990 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1039 0.0.0.0:0 LISTENING

TCP 0.0.0.0:23598 0.0.0.0:0 LISTENING

TCP 127.0.0.1:1058 0.0.0.0:0 LISTENING

TCP 127.0.0.1:5679 0.0.0.0:0 LISTENING

TCP 127.0.0.1:7438 0.0.0.0:0 LISTENING

TCP 127.0.0.1:62514 0.0.0.0:0 LISTENING

UDP 0.0.0.0:445 *:*

UDP 0.0.0.0:500 *:*

UDP 0.0.0.0:1025 *:*

UDP 0.0.0.0:1026 *:*

UDP 0.0.0.0:1515 *:*

UDP 0.0.0.0:3456 *:*

UDP 0.0.0.0:4500 *:*

UDP 127.0.0.1:123 *:*UDP 127.0.0.1:1027 *:*

UDP 127.0.0.1:1051 *:*

UDP 127.0.0.1:1540 *:*

UDP 127.0.0.1:1900 *:*

UDP 127.0.0.1:62514 *:*

UDP 192.168.229.179:123 *:*

UDP 192.168.229.179:137 *:*

UDP 192.168.229.179:138 *:*

UDP 192.168.229.179:1900 *:*

[ 9 ]





CHAPTER 1

Introduction to

Zone-Based

Firewalls Even if the challenges of return TCP traffic are solved with smarter packet filters and the return UDP traffic is addressedwith stricter filtering rules (for example, allowing only UDP on port 53 between internal and external Domain Name

System [DNS] servers), another inherent problem remains: Some protocols use separate control sessions (on well-known

ports) and data sessions (on randomly assigned high-numbered ports). Most commonly used protocols exhibiting this

problem include File Transfer Protocol (FTP) and Voice over IP (VoIP, H.323 suite of protocols).

In Cisco IOS Release 11.2P (integrated into mainstream Release 11.3) Cisco has addressed the shortcomings of packet

filters implemented in Cisco IOS with Context-Based Access Control (CBAC, later renamed IOS Firewall StatefulInspection). This is a mechanism by which a router tracks session establishment of packet flows being routed through it

and adjusts the access lists in the return direction to anticipate the arrival of return packets. CBAC also implements Layer

7 packet inspection, which properly handles protocols such as FTP and H.323, resulting in a perfect firewall solution for

supported protocols.

To deploy CBAC in the simple LAN-to-WAN (wide area network) firewall solution shown in Figure 1-1, you just replace

the inbound access-list with a placeholder access-list denying all traffic and enable CBAC on the outside interface usingthe ip inspect command. This results in the router configuration shown in Listing 1-3.

LISTING 1-3 Typical Router Configuration Using CBAC

ip inspect name Internet tcp audit-trail on router-traffic

ip inspect name Internet udp audit-trail on router-traffic

ip inspect name Internet icmp audit-trail on router-traffic!



ip access-group fromInternet in

ip inspect Internet out

!

ip access-list extended fromInternetdeny ip 10.0.0.0 0.0.0.255 any

[ 10 ]



NOTE

CBAC support for ICMPwas added in 12.2(15)T

and integrated in Cisco

IOS Release 12.3.

router-traffic is a new

keyword added in Cisco

IOS Release 12.3(14)T

and integrated in release12.4.



CHAPTER 2

Typical Zone-

Based Firewall

Designs CHAPTER TWO

Typical Zone-BasedFirewall Designs

In the preceding chapter, you saw how the philosophy of firewalldesign has evolved from packet-filter-oriented designs toward zone-

based designs. In this chapter, we discuss several well-known firewall

designs and describe the filtering policies used in them. These designs

then serve as the blueprints for the following implementation chapters,

in which you’ll see how you can translate a zone-based design directly

into Cisco IOS configuration commands.

Simple LAN-to-InternetFirewallThe simplest possible design is a protected LAN connected to the

public IP network (for example, the Internet) through a firewall. Nopublicly accessible servers reside in the protected LAN (which means,

for example, that the users connected to the LAN have to download

their e-mails from somewhere else—for example, from their Yahoo! or

Hotmail accounts). Figure 2-1 shows a simple firewall design.

[ 12 ]



NOTENetwork designers who

are already familiar with

the zone-based firewall

design principles can

skip this chapter and

continue to the imple-

mentation section. All

other readers are highly

advised to read it,

because a well-thought-

out and well-documented

design almost always

results in superior imple-

mentation.

Simple LAN-to-

Internet Firewall ..........................................12

Firewall with

Public Servers .............................................15

Redundant Firewall

Designs.........................................................20

Complex Firewall

Designs.........................................................20

Reducing the Complexity

of Advanced Firewalls................................23



CHAPTER 2

Typical Zone-

Based Firewall

Designs

Two firewall policies are commonly used in such setups:

■ Permissive policy (documented in Table 2-1), where the internal users can access any service on the Internet

■ Restrictive policy (documented in Table 2-2), where the internal users can access only a restricted set of services (forexample, web and mail services)

TABLE 2-1 Permissive Firewall Policy

Client Zone Server Zone Sessions Allowed

Inside Outside All

Outside Inside None

When establishing a restrictive inside-to-outside policy, consider the following caveats:

■ Internet Control Message Protocol (ICMP) echo has to be enabled to allow the internal users to use ping for connec-

tivity troubleshooting.

[ 13 ]



FIGURE 2-1

Simple LAN-to-

Internet firewall

OutsideInside

Internet

NOTE

All the firewall policy

tables in this book

assume a stateful firewall

implementation, so there

are no special entries for

the return packets.



CHAPTER 2

Typical Zone-

Based Firewall

Designs ■ Domain Name Service (DNS) on UDP port 53 has to be enabled; otherwise, the internal clients will not be able toresolve the hostnames into IP addresses.

■ In some environments, additional UDP traffic has to be allowed to support the traceroute program.

■ Post Office Protocol version 3 (POP3) or Internet Message Access Protocol (IMAP) as well as Simple Mail Transfer

Protocol (SMTP) to some external server (for example, the Internet service provider’s servers) have to be enabled to

allow users to receive and send e-mail.

■ Web servers sometimes use nonstandard port numbers. If your users want to access those servers, you must enable

access to specific ports on specific IP addresses.

TABLE 2-2 Restrictive Firewall Policy


Inside Outside DNS (UDP port 53) to ISP’s name servers

ICMP echoHTTP (TCP port 80) to everywhere

HTTPS (TCP port 443) to everywhere

FTP (TCP port 21) to everywhere

POP3 (TCP port 110) to ISP’s e-mail servers

SMTP (TCP port 25) to ISP’s e-mail servers

Outside Inside None

The simple LAN-to-Internet firewall design successfully addresses the needs of small home offices and small companies

(SOHO environment) that do not own e-mail or web servers. If customers want to run their own publicly accessible

servers, however, the firewall policies have to be changed to allow incoming sessions (for example, incoming SMTP and

HTTP sessions). Because of the many times hackers have successfully exploited publicly accessible servers to penetrate

private networks, it’s almost a necessity to put such servers into a separate zone, as described in the next section.

[ 14 ]



NOTE

TCP ports needed for

FTP data sessions areidentified automatically

by the stateful firewall

implementations. If

you’re not using a state-

ful firewall, you need to

allow TCP port 20, too,

and advise the clients to

use passive FTP.

NOTE

Most versions of

Windows use ICMP to

trace the path to the

destination host. UDP

packets as the trace

packets are used by someUNIX environments (for

example, Linux) as well as

Cisco IOS.

[ 15 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs Firewall with Public ServersThere are two common ways of designing a firewall with a perimeter network (also known as demilitarized zone [DMZ])

containing public servers:

■ A simple setup in which all three zones are connected to the same networking device, as shown in Figure 2-2.

■ A more complex setup with two firewalls and a transit perimeter network, as shown in Figure 2-3. This setup is

slightly more secure because the two networking devices are configured independently, thus reducing the risk of afatal configuration error (defense-in-depth principle).

[ 15 ]



OutsideInside

Perimeter

Internet

Web/Mail Server

FIGURE 2-2

Simple firewall with a

perimeter network

[ 16 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs

As in the preceding section, a firewall with a perimeter network can implement a permissive firewall policy, where the

internal users can access any service on the public network, or a more restrictive one, as documented in Table 2-3.

When designing a restrictive firewall policy, you must consider the implementation details of the DNS and e-mail serv-

ices. DNS service can be implemented in the following ways:

■ The customer does not run a DNS server. In this case, DNS requests from inside to an outside (ISP-owned) DNS

server must be permitted.

■ The customer runs a caching DNS server in the perimeter network but does not control its own domain. In this case,

DNS requests flow from inside to the perimeter and from the perimeter to outside.

■ The customer runs an authoritative DNS server for its domain in the perimeter network. This server usually acts as acaching DNS server for the inside clients. In this setup, the DNS requests to the perimeter DNS server arrive from

inside and outside zones, and the perimeter DNS server (when acting on behalf of the inside clients) sends DNS

requests to the outside. Table 2-3 describes this scenario.

■ The customer runs a caching name server on the inside network and an authoritative name server on the perimeter

network. DNS requests thus flow from the inside server to the outside. There is also a bidirectional flow of requests

between the perimeter server and the outside.

[ 16 ]



FIGURE 2-3

Transit perimeter

network

OutsideInside

Internet

PerimeterWeb/Mail Server

NOTE

Please refer to Bind 9

documentation for an

in-depth explanation of

name server nomencla-

ture.

[ 17 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs E-mail service can also be implemented in several ways:

■ Most commonly (also assumed in Table 2-3), the customer runs an internal e-mail server that uses SMTP to commu-

nicate with the outside world. In this case, bidirectional SMTP is required between the inside server and the perime-

ter server and between the perimeter server and any host on the outside, assuming the perimeter server is using DNS

Mail Exchange (MX) records to deliver outbound mail.

■ The customer could also decide to store all external e-mail on the perimeter server. In this scenario, bidirectional

SMTP is needed between the perimeter server and outside servers. Inside clients use SMTP to send mail to the perimeter server and POP3 or IMAP to retrieve it from the perimeter server.

TABLE 2-3 Restrictive Policy of a Firewall with a Perimeter Network


Inside Outside ICMP echo, HTTP, HTTPS

(Optionally) FTP

Outside Inside None

Inside Perimeter HTTP (to access own public web server)

SMTP from inside mail server to perimeter e-mail server

DNS

ICMP echo

FTP and SSH for server management

Perimeter Inside SMTP to inside mail server (to deliver inbound e-mail)

Perimeter Outside DNS

SMTP (to deliver outbound e-mail)

Outside Perimeter DNS (as the customer runs the authoritative name server for its domain)

HTTP to public web server

SMTP to public mail server

(Optional) FTP to public FTP server (Many sites are replacing FTP with HTTPbecause its single-session design does not cause any firewall issues.)

[ 17 ]



[ 18 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs The firewall policy just documented is extremely restrictive, allowing only the minimum number of services needed. Thisresults in a secure network (for example, if the perimeter server is compromised, it cannot be used to launch attacks on

other networks), but it could also lead to reduced robustness of the network. (For example, if the perimeter server is

compromised, the inside clients cannot access the Internet because the DNS services are no longer accessible.)

Some large organizations opt for an even more restraining policy with proxy servers in the perimeter network, thus elimi-

nating any direct traffic between the internal network and the public Internet, as illustrated in Table 2-4.

TABLE 2-4 Policy of a Firewall with Proxy Servers in the Perimeter Network


Inside Outside None

Outside Inside None

Inside Perimeter HTTP, HTTPS (to access proxy web server)ICMP echo

SMTP from inside mail server to perimeter mail serverFTP and SSH for server management

Perimeter Inside SMTP to internal e-mail server (to deliver inbound e-mail)

Perimeter Outside DNSSMTP from perimeter mail server (to deliver outbound e-mail)HTTP, HTTPS (proxy access to the web)(Optional) FTP

ICMP echoOutside Perimeter DNS (only if the customer runs its own name server)

HTTP to public web serverSMTP to public mail server(Optional) FTP; see also comments in Table 2-3

The transition from the single-device design (Figure 2-2) to the design with a transit perimeter network (Figure 2-3) illus-

trates one of the advantages of a well-documented zone-based design: Because all the firewall policies have already beendocumented, they don’t have to be designed from scratch. You merely split the overall firewall policy into two parts: the

[ 18 ]



NOTE

DNS service between the

inside and the perimeter

zones is no longer

needed when using

HTTP proxy, because the

external hostnames are

passed as strings inHTTP requests to the

proxy server.

[ 19 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs inner firewall handles policies from inside to everywhere else, and the outer firewall handles policies from outside toeverywhere else. In fact, two zones are merged into one on each of the devices ( perimeter and outside zones are merged

into the perimeter zone on the inner firewall, and perimeter and inside zones are merged into the perimeter zone on the

outer firewall), resulting in policies shown in Table 2-5 and Table 2-6 (assuming a transit perimeter network with proxy

servers). The merge is extremely simple because the previous firewall policy did not allow any direct traffic between the

inside and outside zones.

TABLE 2-5 Policy of the Inner Firewall


Inside Perimeter HTTP, HTTPS (to access proxy web server)

ICMP echo

SMTP (to send mail)

FTP and SSH for server management.

Perimeter Inside SMTP to inside mail server (to deliver inbound e-mail)

TABLE 2-6 Policy of the Outer Firewall



SMTP from perimeter mail server (to deliver outbound e-mail)

HTTP, HTTPS (proxy access to the web)(Optional) FTP

ICMP echo

Outside Perimeter DNS (only if the customer runs its own name server)

HTTP to public web server

SMTP to public mail server

(Optional) FTP

[ 19 ]



[ 20 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs Redundant Firewall DesignsAs we move from simple SOHO designs to more-complex corporate designs, robustness and availability become more

and more important. To reach high availability, network designers usually deploy redundant setups in which each critical

device is duplicated, resulting in a design similar to the one shown in Figure 2-4.

This scenario does not change the firewall policies. All the rules outlined in the preceding section are still valid (yet

another benefit of a good design independent of the physical implementation).

Complex Firewall DesignsFirewalls deployed by large organizations usually contain several zones in addition to the ones discussed in the previous

sections. Typical large-scale firewalls include zones to support the following:

■ Network administrators—Clients in this zone would have privileged access to servers in the perimeter network.

For example, they could open Secure Shell (SSH) sessions to them to change their configuration and perform other

maintenance duties.

[ ]



OutsideInside Perimeter

Web/Mail Server

Internet

FIGURE 2-4

Redundant

firewall design

[ 21 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs ■

Remote IPsec users—Individual users accessing the corporate network with IPsec-encrypted sessions over thepublic Internet would be in this zone. These users have limited access to the resources in the internal network; their

access to the perimeter network is usually equal to access granted to the regular internal users.

■ Remote offices—This zone is similar to individual users using IPsec to access the internal network. However,

because the remote offices are usually under stricter physical control (so that the risk of an intruder gaining access

through a remote office is lower), users in the remote offices would have access to more internal resources than the

individual users.■ E-commerce perimeter network—Publicly accessible e-commerce servers usually execute transactions on internal

database servers. They are therefore best separated from other public servers; otherwise, an intruder gaining access

to any public server could penetrate the internal database.

Not surprisingly, the firewall policy for such a firewall is substantial, as shown in Table 2-7.

TABLE 2-7 Firewall Policy of a Complex Firewall


Inside Perimeter ICMP echo

VPN users HTTP to web servers

VPN offices SMTP to mail servers

DNS to name servers

Inside E-commerce ICMP echoVPN users HTTPS to e-commerce servers

VPN offices

Inside Outside ICMP echo, HTTP, HTTPS, FTP

VPN users

VPN offices

[ ]



NOTE

This design uses a

restrictive policy for

inside clients with no

HTTP proxy. For a less-

restrictive policy or a

policy with HTTP

proxies, replace individ-

ual items in Table 2-7

with entries from the

previous sections. The

design also assumes that

the organization does not

offer public FTP service.

continues

[ 22 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs TABLE 2-7 Firewall Policy of a Complex Firewall continued Client Zone Server Zone Sessions Allowed

Administrators Perimeter HTTP to web servers

SMTP to mail servers

DNS to name servers

SSH to all servers

FTP to all servers

SNMP to all serversAdministrators E-commerce HTTPS, SSH, FTP, and SNMP to all servers

Administrators Outside All services granted to inside users

Additional services if needed

Administrators VPN users All (to support remote users)

Administrators VPN offices All (to support remote offices)

Perimeter Inside SMTP to internal e-mail server

Minimum set of ICMP traffic


SMTP

E-commerce Inside SQL transactions

VPN users Inside Access to a subset of internal servers

RADIUS from VPN concentrator to authentication server

Outside VPN users IPsec traffic (ISAKMP + ESP)

VPN offices Inside Access to a less-restricted set of internal servers

RADIUS from VPN concentrator to authentication server

Outside VPN offices IPsec traffic (ISAKMP + ESP)



NOTE

Missing zone pairs in the

table indicate that no

traffic is allowed between

those zones. For

example, the e-commerce

servers cannot initiate

sessions to the outside

zone, further limiting

complex exploits.

[ 23 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs Such a complex firewall is almost always implemented with multiple devices to improve its resiliency and reduce thecomplexity of each individual device’s configuration. Assuming a two-device nonredundant setup, you could end up with

a design similar to the one in Figure 2-5.

Reducing the Complexity of Advanced FirewallsAs you saw in the preceding section, firewalls of larger organizations tend to become rather complex. Developing a good

overall firewall policy in such cases can be a complicated, tedious, and error-prone task. It’s therefore best to approach

the complex firewalls with the millennia-old divide-and-conquer principle. In the example from the preceding section,you could split the problem into three independent smaller firewalls, as shown in Figure 2-6.



FIGURE 2-5

Complex firewall

design

Outside

Perimeter

Web/Mail Server

Internet

E-commerce

Administrators

Inside

VPN

Users

VPN

Offices

[ 24 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs

The firewall policy of each individual smaller firewall is significantly less complex than the overall policy because it

contains fewer security zones. Furthermore, the designer can now implement different physical setups for each firewall

based on its resiliency and availability requirements. For example, under budget restrictions, the e-commerce firewall

could be implemented as a redundant transit perimeter firewall design (see the section “Redundant Firewall Designs” andFigure 2-4 earlier in this chapter), the perimeter firewall could use the nonredundant setup (see the “Firewall with Public

Servers” section), and the VPN firewall could be based on a simple LAN-to-Internet firewall design.



Internet

E-commerce

Perimeter

VPN Users

VPN Offices Encrypted

Outside

Inside

and

Administrators

VPNFirewall

E-commerce Firewall

Perimeter Firewall

FIGURE 2-6

Decomposed

complex firewall

NOTE

The firewall design is

further simplified by the

intended traffic flow:

Traffic from VPN users

first enters the inside

network and is then addi-

tionally screened by the

perimeter firewall.

[ 25 ]



CHAPTER 2

Typical Zone-

Based Firewall

Designs SummaryIn this chapter, you have seen how you can use zone-based firewall design principles to design a variety of firewall solu-

tions, ranging from simple firewalls suitable to SOHO environments to complex redundant solutions deployed by large

organizations. In the next chapters, you’ll find out how you can use the zone-based policy firewall configuration feature of

Cisco IOS to translate these designs into actual router configuration commands.



[ 26 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewallsin Cisco IOS CHAPTER THREEConfiguring Zone-BasedPolicy Firewalls in

Cisco IOSIn the previous chapters, you’ve seen how you can design your firewall

using the zone-based design concepts. In this chapter, you’ll find the

Cisco IOS configuration commands that enable you to translate the

firewall policy into a working router configuration. Throughout this

chapter, we focus on the simple LAN-to-Internet firewall design

described in the preceding chapter. Figure 3-1 outlines the addressingscheme used in the examples.



OutsideInside

Internet

10.0.0.2 10.0.0.3

10.0.0.0/24

dns.isp.com172.16.0.1

smtp.isp.com172.16.0.2

www.web.com172.18.25.10

172.16.10.32/28

10.0.0.1192.168.201.6

FIGURE 3-1

Sample firewall with

addressing

Initial Zone-Based Policy

Firewall Configuration ................................30

Limiting Inside-to-

Outside Traffic.............................................37

Protecting the Router.................................43

Monitoring and

Debugging Zone-Based

Policy Firewall Configuration ....................47

[ 27 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewallsin Cisco IOS As you can see in the diagram, the inside LAN is using the private address space 10.0.0.0/24 that is translated using theNetwork Address Translation (NAT) functionality of Cisco IOS into the provider-allocated public address space

172.16.10.32/28. Because the public address space covers the needs of the inside clients, NAT overload is not used.

The ISP provides mail (SMTP and POP3) services on smtp.isp.com and DNS and Web services on dns.isp.com. The

client computers will also access a third-party Web server at www.web.com.

Listing 3-1 shows the initial router configuration with basic IP addressing and NAT.

LISTING 3-1 Initial Router Configuration

hostname fw

!

service finger

!

ip dhcp pool LANnetwork 10.0.0.0 255.255.255.0

!

interface Loopback1

ip address 172.16.10.33 255.255.255.240

!

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0ip nat inside

!

interface Serial0/0/0

no ip address

encapsulation frame-relay

!




NOTE

The configuration in

Listing 3-1 is slightly

abridged. (For example,

vty and console configu-

ration has been removed.)

It has also not been prop-

erly secured. (For example,

Finger and HTTP are

enabled, and Telnet is

used rather than SSH.)

continues

[ 28 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewallsin Cisco IOS LISTING 3-1 Initial Router Configuration continued description Link to the Internet

ip address 192.168.201.6 255.255.255.252

ip nat outside

frame-relay interface-dlci 100

!

ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100

!!

ip http server

no ip http secure-server

ip nat pool Internet 172.16.10.34 172.16.10.46 prefix-length 28

ip nat source list InternalHosts pool Internet

ip nat inside source list InternalHosts pool Internet

!ip access-list standard InternalHosts

permit 10.0.0.0 0.0.0.255

!

end

The configuration seems pretty secure by itself, because NAT should be able to hide inside hosts from potential intruders.

An initial port scan done from the outside (results are shown in Listing 3-2) seems to confirm this assumption, becausethe potential intruder can reach only one IP host (the router itself).



NOTE

nmap, a public-domain

program available from

www.insecure.org, is used

to perform the port scans.

Printouts are abridged for

clarity. Do not perform

port scans on external

IP hosts without the

owner’s permission.

[ 29 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewallsin Cisco IOS

LISTING 3-2 External Port Scan with No Active Host

External$ nmap --system-dns 172.16.10.32/28

(The 1671 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE

23/tcp open telnet

79/tcp open finger

80/tcp open http

Nmap finished: 16 IP addresses (1 host up) scanned in 23.473 seconds

However, after an inside client establishes any session across the firewall router, its IP address becomes available to the

outside world. Because the router offers no additional protection beyond address translation, the intruders have free

access to the inside hosts, as documented in Listing 3-3. (Focus on the highlighted lines; the others are the publicly

accessible router services.)

LISTING 3-3 External Port Scan with Active NAT Translations

External$ nmap --system-dns 172.16.10.32/28

Interesting ports on 172.16.10.33:


PORT STATE SERVICE

23/tcp open telnet

79/tcp open finger

80/tcp open http

Interesting ports on 172.16.10.34:


PORT STATE SERVICE

135/tcp open msrpc



continues

[ 30 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-3 External Port Scan with Active NAT Translations continued

139/tcp open netbios-ssn

445/tcp open microsoft-ds

3389/tcp open ms-term-serv

5800/tcp open vnc-http

5900/tcp open vnc

Nmap finished: 16 IP addresses (2 hosts up) scanned in 44.083 seconds

Obviously, additional protection is needed to change the initial setup into a real firewall.

Initial Zone-Based Policy Firewall Configuration

The zone-based policy firewall in Cisco IOS is configured in a modular fashion through these steps:

Step 1. Use the new zone security command to define the zones in your firewall.

Step 2. (Optional) Use the class-map type inspect global configuration commands to define the traffic classes based

on specifications from the firewall design. A traffic class is a way of identifying a set of packets based on

their content (for example, common application layer protocol).

Step 3. Use the policy-map type inspect global configuration command to specify the firewall policy (what happens

to each interesting traffic class defined previously with class-map type inspect commands).

Step 4. Use the zone-pair security command to apply a predefined firewall policy to a pair of source (client) and

destination (server) zones.

Step 5. After the firewall policy is configured, assign the router interfaces to various security zones by using the

zone-member security interface configuration command.



NOTE

Class map definitions are

mandatory unless you

want to rely on the

system-defined class-default class, which

matches all traffic.

[ 31 ]



CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS IMPORTANT■ Only policy maps with type inspect can be used in the zone-pair security command.

■ Only class maps with type inspect can be used in policy maps with type inspect.

■ There can be no name overlap with other types of class maps or policy maps. You cannot have a quality-of-service

class map (with no type keyword) and an inspect class map with the same name.

■ A zone must be configured with the zone security global command before it can be used in the zone-member

security interface configuration command.

■ An interface cannot belong to multiple zones. To create a union of security zones, specify a new zone and appro-

priate policy map and zone pairs.

■ The zone-based policy firewall feature is a replacement for the Cisco IOS Firewall Stateful Inspection (also known

as Context-Based Access Control [CBAC]) feature. Remove the ip inspect interface configuration command

before applying the zone-member security command.

■ The zone-based policy firewall can coexist with Cisco IOS Firewall stateful inspection. You can still use the ip

inspect command on interfaces that are not members of security zones.

■ Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment.

Applying the zone-member configuration commands will therefore always result in temporary interruption of

service.

■ The default interzone policy is to drop all traffic unless specified otherwise in the zone-pair configuration

command.

■ The router never filters the traffic between interfaces in the same zone.

■ The zone-member command does not protect the router itself (traffic to and from the router is not affected) unless

you configure the zone pairs using the predefined self zone (described later in this chapter).

■ CBAC dynamically creates entries in access lists attached to interfaces on which the ip inspect command is

configured. (Cisco IOS Firewall stateful inspection entries and access list entries are or -ed together.) The zone-

based policy firewall does not change the access lists. (The interzone policy is and -ed with the access list.) Review

the access list usage before using the zone-member commands.





[ 33 ]

D l i Z B d Fi ll b I P l j k



CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

■ Drop the packet. Equivalent to the access-list deny statement. Similar to the access lists, you can use the log option

to log the rejected packets.

■ Police. Rate-limits the traffic of the specified class. Can be used only in conjunction with the inspect or pass

command.

After the firewall policy has been configured, you can apply it to traffic between a pair of zones using the zone-pair

security configuration command. In this command, you specify the source zone (in which the clients reside), the destina-

tion zone (where the servers are), and the policy for handling the traffic between them.

Listing 3-5 shows the InsideToOutside firewall policy and the corresponding zone-pair command used in our firewall.

LISTING 3-5 Creating Firewall Policy

policy-map type inspect InsideToOutside

class class-default

inspect!

zone-pair security InsideToOutside source Inside destination Outside

service-policy type inspect InsideToOutside

Assigning Interfaces to Security ZonesAfter the firewall policy is complete, you can assign individual interfaces to security zones with the zone-member

security configuration command, resulting in the final router configuration in Listing 3-6.



NOTE

There is no need for an

outside-to-inside zone

pair because there are no

inside servers that would

be accessible from the

outside zone.

CHAPTER 3

[ 34 ]

Deploying Zone Based Firewalls by Ivan Pepelnjak



CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-6 Initial Zone-Based Policy Firewall Configuration


class class-default

inspect

!

zone security Inside

description Inside network

zone security Outsidedescription Outside network



!


zone-member security Inside

!interface Serial0/0/0.100 point-to-point

zone-member security Outside

Testing the Firewall Configuration

The first port scan results from an outside host are encouraging; after the firewall policy has been configured, the internalhosts are no longer visible to port scans from the outside, as shown in Listing 3-7. However, it’s obvious that the router

itself is still vulnerable.





CHAPTER 3

[ 36 ]




CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-8 Scanning an External Web Server from the Inside continued

3389/tcp open ms-term-serv

5800/tcp open vnc-http

5900/tcp open vnc

Nmap finished: 1 IP address (1 host up) scanned in 277.339 seconds

Raw packets sent: 1958 (86.132KB) | Rcvd: 1685 (77.510KB)

Deploying a zone-based firewall has an additional unexpected benefit: Because all the traffic between zones is inspected,

a port scan almost always triggers alerts and corresponding log messages (displayed in Listing 3-9).

LISTING 3-9 Alerts Generated by the Router During Port Scan

00:42:35: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connec-

tions (50) exceeded for host 172.18.25.10.

00:42:43: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connec-tions (50) exceeded for host 172.18.25.10.





00:42:56: %FW-4-ALERT_ON: (target:class)-(InsideToOutside:class-default):getting aggressive, count (2/500)

current 1-min rate: 501

Configuration Command SummaryIn this section, we have used the commands summarized in Table 3-1 to create an initial firewall configuration.



CHAPTER 3

[ 37 ]




CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

TABLE 3-1 Basic Zone-Based Policy Firewall Configuration Commands

Command Syntax Description

zone security name Creates a new security zone.

description text Optionally assigns a description to the selected security zone.

policy-map type inspect name Creates a new policy map or starts configuration of the existing policy map. The type inspect

keywords are mandatory.

class name Within a policy map, starts configuring firewall actions for the specified traffic class.class class-default Within a policy map, starts configuring firewall actions for all unclassified traffic. The class

class-default command should be the last class specification in the policy map.

inspect Within a traffic class configuration, permits traffic and requests packet inspection to establish

automatic conduits for return traffic (equivalent to the ip inspect command of Cisco IOS

Firewall stateful inspection).

pass Within a traffic class configuration, permits traffic. You have to make manual provisions forreturn traffic handling.

drop [log] Drops the packets of the selected traffic class with optional logging to the router’s log.

police rate bps burst burst-size Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a

specified maximum burst size.

Limiting Inside-to-Outside TrafficIn the preceding section, we configured a simple firewall that protected the inside network while allowing the inside users

to access any service on the Internet. In this section, we extend this design by limiting the services the inside users are

allowed to access (the second design of the section “Simple LAN-to-Internet Firewall” in Chapter 2, “Typical Zone-

Based Firewall Designs”). To reach that goal, we first have to define the traffic classes that will later be used in the



CHAPTER 3

[ 38 ]




CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

policy-map commands to define the desired firewall policy. The traffic classes are defined with the well-known class-

map command augmented with the type inspect keyword.

class-map can classify traffic based on source and destination addresses and Layer 4 port numbers using extended IP

access lists, or based on well-known Layer 4 (TCP, UDP, ICMP, and so on) or Layer 7 (SMTP, HTTP, FTP, and so forth)

protocols. Table 3-2 shows the syntax of the class-map command and the associated match commands.

TABLE 3-2 Syntax of the class-map type inspect and Associated match Commands

Command syntax Description

class-map type inspect Starts configuration of the named class map. The traffic matched by the class map has to

[match-all | match-any] name match all the specified match conditions (match-all option, also the default behavior) or

any of them (match-any option, which has to be explicitly specified).

match access-group Matches traffic permitted by the specified access group. You can use numbered or named

{ ACL-number | name ACL-name} IP access lists.

match protocol Matches any packet of the specified Layer 4 protocol.

{tcp | udp | icmp}

match protocol protocol-name Matches the specified Layer 7 protocol based on its Layer 4 port number (specified as the

Layer 7 protocol name in the configuration). Protocols operating on nonstandard ports or

user-defined protocols can be specified with the ip port-map command, covered in

Chapter 5.

match class-map name Matches traffic specified by a previously defined class map. This command is useful whenyou want to extend a previous traffic definition (use the match-any option in the class-map

command) or narrow it (with the match-all option in the class-map command). This command

can also be used to implement complex logical conditions that cannot be specified with a

single class map.

match not condition Matches all traffic not matching the specified condition.


p y g y p j

NOTE

Class maps using these

parameters are known as

Layer 4 class maps.

Cisco IOS also supports

deeper inspection of HTTP, IMAP, instant

messaging (AOL, MSN,

Yahoo!), and peer-to-peer

(edonkey, fasttrack,

gnutella, kazaa) proto-

cols. Those class maps

are called Layer 7 class

maps and are covered in

a later section.

CHAPTER 3

[ 39 ]




CHAPTER 3

Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

To configure the desired firewall policy, we need to specify two traffic classes:

■

Traffic permitted to any destination on the Internet (HTTP, HTTPS, FTP, ICMP)■ Traffic permitted to the Internet service provider’s (ISPs) servers (SMTP, POP3, DNS).

The configuration of the first traffic class is simple: Just use the class-map command with the match-any option and list

all the desired protocols, as shown in Listing 3-10.

LISTING 3-10 Class Map Matching the Default Internet Traffic

class-map type inspect match-any InternetTraffic

match protocol httpmatch protocol ftpmatch protocol icmpmatch protocol https

NOTE

You might be tempted to use the access list to match both IP addresses and TCP port numbers instead of using the match protocol commands.

However, when a protocol uses control and data sessions (as FTP does), the match protocol command matches all relevant sessions, and the

access list cannot do it. For example, match protocol ftp is not equivalent to permit tcp any any eq ftp.

The definition of traffic allowed toward the ISP servers is a bit more complex because we have to specify two conditions:

a list of protocols (using the match-any keyword) toward a set of IP addresses (here we need a match-all keyword).

Listing 3-11 contains the minimum configuration needed to achieve these goals.

LISTING 3-11 Matching Traffic Toward ISP Servers

class-map type inspect match-any ISPTrafficmatch protocol dnsmatch protocol smtpmatch protocol pop3!class-map type inspect match-all ToISPmatch class-map ISPTrafficmatch access-group name ISPServers!ip access-list extended ISPServers

permit ip any host 172.16.0.1permit ip any host 172.16.0.2


CHAPTER 3

[ 40 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

After defining the two traffic classes, you can specify the target firewall policy as follows:

■ Inspect all traffic in classes ToISP and InternetTraffic.

■ Drop and log all the other traffic.

Listing 3-12 shows the final firewall configuration.

LISTING 3-12 Final Simple LAN-to-Internet Firewall Configuration

class-map type inspect match-any ISPTraffic

match protocol dns

match protocol smtp

match protocol pop3

class-map type inspect match-all ToISP

match class-map ISPTraffic

match access-group name ISPServers

class-map type inspect match-any InternetTraffic

match protocol http

match protocol ftp

match protocol icmp

match protocol https

!

!policy-map type inspect InsideToOutside

class type inspect ToISP

inspect

class type inspect InternetTraffic

inspect

class class-default

drop log!


continues

CHAPTER 3

[ 41 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-12 Final Simple LAN-to-Internet Firewall Configuration continued



zone security Outside

description Outside network



!interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0

ip nat inside


!


description Link to the Internetip address 192.168.201.6 255.255.255.252

ip nat outside


!

ip access-list extended ISPServers

permit ip any host 172.16.0.1


To verify the proper operation of your configuration, you can use a port-scanning program from an inside host. As Listing

3-13 shows, Internet services (FTP, HTTP) can be reached on the ISP servers together with the ISP-specific services

(SMTP, POP3, DNS). On the other hand, only Internet services are available to inside clients on any other Internet host

(Listing 3-14).


CHAPTER 3

[ 42 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-13 Port Scan of the ISP Servers from the Inside

Inside$ nmap --system-dns 172.16.0.0/28

Interesting ports on dns.isp.com (172.16.0.1):

(The 1669 ports scanned but not shown below are in state: filtered)

PORT STATE SERVICE

21/tcp open ftp

53/tcp open domain80/tcp open http

Interesting ports on smtp.isp.com (172.16.0.2):


PORT STATE SERVICE

25/tcp open smtp

53/tcp open domain110/tcp open pop3

Nmap finished: 16 IP addresses (2 hosts up) scanned in 82.939 seconds

LISTING 3-14 Port Scan of an External Web Server from an Inside Host

Inside$ nmap --system-dns www.web.com

Interesting ports on web.com (172.18.25.10):


PORT STATE SERVICE

21/tcp open ftp

80/tcp open http

443/tcp open https



CHAPTER 3

[ 43 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

As expected, the port scan generates a number of router alerts, as shown in Listing 3-15.

LISTING 3-15 Router Alerts During the Port Scan

01:06:13: %FW-6-DROP_PKT: Dropping tcp pkt 172.16.10.34:35860 => 172.16.0.1:535

01:07:44: %FW-6-DROP_PKT: Dropping rtsp pkt 172.16.10.34:58360 => 172.16.0.1:554

01:08:14: %FW-6-DROP_PKT: Dropping tcp pkt 172.16.10.34:58360 => 172.16.0.2:895

Protecting the RouterThe firewall configuration in the previous section has successfully protected inside hosts from Internet attacks and limited

the services the inside hosts can access on the Internet. The router itself, however, remains vulnerable because the traffic

to and from the router itself is not restricted by the interzone policies (as shown in Listing 3-2 earlier in this chapter).

To protect the router, you could use incoming IP access lists on all interfaces. This approach (although commonly used inthe past) has a number of severe drawbacks:

■ The access list has to include all IP addresses configured on the router.

■ Whenever the router participates in several security zones, a different access list has to be specified for each zone.

■ The access lists cannot restrict the traffic originating in the router. (The only way to influence outgoing traffic is

through local policy routing.)■ The zone-based policy firewall feature does not amend the access lists the way Cisco IOS Firewall stateful inspec-

tion does. Therefore, special precautions must be taken to ensure that there are no undesired side effects from apply-

ing access lists on interfaces assigned to security zones.

Zone-based policy firewall configuration in Cisco IOS offers a novel approach to this problem: The router itself can be

defined as a separate security zone (with the predefined name self ), and the incoming and outgoing sessions can be

limited in the same way as the routed interzone traffic.


CHAPTER 3

[ 44 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOSIMPORTANT

When configuring the self zone, consider these facts:

■ All IP addresses configured on the router belong to the zone self , regardless of the zone memberships of their

interfaces.

■ Unless configured otherwise, traffic to and from the self zone is unrestricted.

■ The moment you use the self zone in a zone pair, the traffic between the self zone and the other zone in the zone

pair is restricted in both directions. For example, if you define a zone pair from inside to self , the router cannotoriginate any sessions toward the inside zone until you define a zone pair from self to inside.

■ Traffic between the router itself and the zones not mentioned in combination with the self zone in a zone pair is

not affected.

■ When configuring the restrictions for the inbound traffic, consider the necessary outbound traffic (including the

routing and network management protocols). For example, if you restrict inbound traffic from a zone to the router

itself, the routing protocols could stop working on all interfaces belonging to that zone.■ In early releases supporting zone-based policy firewall configuration (Cisco IOS 12.4(6)T), the match protocol

command cannot be used to classify traffic to or from the self zone. Only IP access lists can be used for traffic

classification purposes.

Configuring Router ProtectionCommon router protection measures in a small LAN-to-Internet firewall might include the following:

■ No external access, apart from ping (icmp echo) and routing protocols (if needed)

■ No access to the Internet from the router (apart from the routing protocols, if needed)

■ Limited internal access (for example, ping, Telnet or SSH, SNMP, HTTP, and HTTP/HTTPS

■ Full access from the router to the inside network


NOTE

A more complex router

protection policy will be

developed in the next

chapter. A more security-

conscious environment

would also not allow fullaccess from the router to

the inside network.

CHAPTER 3

[ 45 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

To implement these protection measures, you need to configure, at minimum, the following:

■ Two IP access lists, one for external (ping only) traffic and one for internal traffic.

■ Two class maps and three policy maps. (The third policy map allows any traffic from the router to the inside zone.)

■ Several zone pairs.

Listing 3-16 shows the complete configuration needed to protect the router.

LISTING 3-16 Protecting the Router with the Self Zone

ip access-list extended ICMPEcho


!

class-map type inspect match-any ping

match access-group name ICMPEcho

!policy-map type inspect OutsideToRouter

class type inspect ping

inspect

class class-default

drop log

!

zone-pair security OutsideToRouter source Outside destination selfservice-policy type inspect OutsideToRouter

!

ip access-list extended ManagementProtocols

permit tcp any any eq telnet

permit tcp any any eq 22 ! ssh


continues

CHAPTER 3

[ 46 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-16 Protecting the Router with the Self Zone continued

permit tcp any any eq www

permit tcp any any eq 443 ! https


!

class-map type inspect match-any RouterManagement

match access-group name ManagementProtocols

!policy-map type inspect InsideToRouter

class type inspect RouterManagement

inspect

class class-default

!

policy-map type inspect RouterToInside

class class-defaultinspect

!

zone-pair security InsideToRouter source Inside destination self

service-policy type inspect InsideToRouter

zone-pair security RouterToInside source self destination Inside

service-policy type inspect RouterToInside

Quick port scans from an inside (Listing 3-17) and outside (Listing 3-18) host verify that the configuration in Listing

3-16 does protect the router. The inside host can only access the services that we have specified in the RouterManagement

access list, and the outside host cannot access the router at all (although it can still be pinged as –; see the “1 host up”

message from nmap).


CHAPTER 3

[ 47 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-17 Port Scan of a Protected Router from the Inside

Inside$ nmap --system-dns 10.0.0.1

Interesting ports on fw (10.0.0.1):


PORT STATE SERVICE

23/tcp open telnet

80/tcp open http

443/tcp closed https


LISTING 3-18 Port Scan of a Protected Router from the Outside

External$ nmap --system-dns 172.16.10.33

All 1674 scanned ports on 172.16.10.33 are: filtered


Monitoring and Debugging Zone-Based PolicyFirewall Configuration

As with every Cisco IOS features, a number of show and debug commands are available to network administrators tomonitor and troubleshoot the zone-based configurations.

If you would like to see the summary of your zone configuration, the show zone security command is the one you’re

looking for (Listing 3-19).


CHAPTER 3

C fi i

[ 48 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-19 Show Zone Security Command Displays Zones and Associated Interfaces

fw#show zone security

zone self

Description: System defined zone

zone Inside

Description: Inside network

Member Interfaces:

FastEthernet0/0

zone Outside

Description: Outside network

Member Interfaces:

Serial0/0/0.100

If you would like to see more details about the configured traffic classes and interzone policies, the obvious commands

are show class-map type inspect, show policy-map type inspect, and show zone-pair security. They display the speci-

fied class map, policy map, or zone pair so that you don’t have to browse through the router configuration. More useful is

the show policy-map type inspect zone-pair name command, which displays the traffic and usage statistics for a zone

pair, as shown in Listing 3-20.

LISTING 3-20 Output of a show policy-map type inspect zone-pair Command

fw#show policy-map type inspect zone-pair InsideToOutside

Zone-pair: InsideToOutside

Service-policy inspect : InsideToOutside

Class-map: InternetTraffic (match-any)

Match: protocol http

0 packets, 0 bytes


continues

CHAPTER 3

C fi i

[ 49 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-20 Output of a show policy-map type inspect zone-pair Command continued

30 second rate 0 bps

Match: protocol ftp

3 packets, 84 bytes


Match: protocol icmp

1 packets, 40 bytes


Match: protocol https

0 packets, 0 bytes


Inspect

Packet inspection statistics [process switch:fast switch]

tcp packets: [133:2363]

icmp packets: [0:8]ftp packets: [46:0]

Session creations since subsystem startup or last reset 7

Current session counts (estab/half-open/terminating) [2:0:0]

Maxever session counts (estab/half-open/terminating) [2:1:1]

Last session created 00:00:13

Last session created 00:00:13Last statistic reset never

Last session creation rate 1

Last half-open session total 0

… printout repeated for other classes of traffic …


WARNING

The per-protocol traffic

counters displayed in the

show policy-map type

inspect zone-pair

command can bemisleading. For example,

the counters for the FTP

protocol list only the

actual content packets

(excluding the TCP setup

packets) exchanged in

the FTP control session

and do not include thedata transferred in the

FTP data sessions.

CHAPTER 3

Configuring

[ 50 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

The show policy-map type inspect zone-pair name sessions command gives an even more detailed printout. It includes all

the open sessions, too (see Listing 3-21). The name parameter is optional; without it, the router displays all sessions it tracks.

LISTING 3-21 Sessions Established Between a Pair of Zones

fw#show policy-map type inspect zone-pair sessions

Zone-pair: InsideToOutside

Service-policy inspect : InsideToOutside

Class-map: InternetTraffic (match-any)

Match: protocol http

0 packets, 0 bytes


Match: protocol ftp

3 packets, 84 bytes

30 second rate 0 bpsMatch: protocol icmp

1 packets, 40 bytes


Match: protocol https

0 packets, 0 bytes


Inspect

Established Sessions

Session 478AF96C (172.16.0.1:20)=>(10.0.0.2:1053) ftp-data SIS_OPEN

Created 00:04:30, Last heard 00:00:00

Bytes sent (initiator:responder) [1917424:0]

Session 478AFC24 (10.0.0.2:1051)=>(172.16.0.1:21) ftp SIS_OPEN

Created 00:06:04, Last heard 00:04:29

Bytes sent (initiator:responder) [98:247]

… rest of printout deleted …




CHAPTER 3

Configuring

[ 52 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

LISTING 3-23 Debugging FTP and DNS Sessions

fw#debug ip inspect dns

INSPECT DNS Inspection debugging is on

fw#debug ip inspect ftp-cmd

INSPECT FTP commands and responses debugging is on

fw#

00:43:01: CBAC FUNC: insp_dns_sis_ext_create

00:43:01: CBAC FUNC: insp_handle_dns_control_stream

00:43:01: CBAC FUNC: insp_handle_dns_control_stream

00:43:01: CBAC FTP sis 478AFEDC FTP-Server: 220 sp IOS-FTP server (version 1.00) ready.~~

00:43:06: CBAC FUNC: insp_dns_handle_inactivity

00:43:16: CBAC FTP sis 478AFEDC FTP-Client: USER myUser~~

00:43:16: CBAC FTP sis 478AFEDC FTP-Server: 331 Password required for ‘myUser’.~~

00:43:18: CBAC FTP sis 478AFEDC FTP-Client: PASS xxxxxx

00:43:18: CBAC FTP sis 478AFEDC FTP-Server: 230 Logged in.~~

00:43:18: CBAC sis 478AFEDC User authenticated

SummaryIn this chapter, you’ve seen how you can do almost a one-to-one mapping between your zone-based firewall design and

Cisco IOS configuration commands:

■ Traffic specifications described in your design are configured with class-map type inspect commands that can

match individual transport layer or application layer protocols with the match protocol command or IP addresses

(or port numbers) with the match access-group command. More complex logical conditions are also possible with

the right combination of match-all or match-any keywords, sometimes combined with hierarchical class-maps.


CHAPTER 3

Configuring

[ 53 ]




Configuring

Zone-Based

Policy Firewalls

in Cisco IOS

■ Interzone policies are expressed as policy-map type inspect commands in Cisco IOS and are assigned to specific

pairs of zones with the zone-pair security command. The two configuration layers allow you to use the same policyon multiple pairs of zones, thus further simplifying the configuration.

■ Interfaces are assigned to security zones with the zone-member security commands. All traffic entering or exiting

these interfaces (apart from traffic to and from the router itself) is subject to security screening, additionally improv-

ing the security of the zone-based firewall in Cisco IOS.

■ Traffic to and from the router is not monitored (doing so by default would probably quickly kill routing protocols

and network management in most implementations). To protect the router itself, you specify the interactions of the

predefined zone self with other security zones.


CHAPTER 4

Case Study:

[ 54 ]




Case Study

Firewall with a

Perimeter Network

CHAPTER FOURCase Study:Firewall with aPerimeter NetworkIn the preceding chapter, you saw the mandatory configuration

commands used to configure the zone-based policy firewall feature of

Cisco IOS. In this chapter, we use those commands to develop a

complete configuration of a firewall with a perimeter network shown

in Figure 4-1. The policy rules used by this firewall are documented in

Table 2-3 (Restrictive Policy of a Firewall with a Perimeter Network)

of Chapter 2, “Typical Zone-Based Firewall Designs.”


FIGURE 4-1

Firewall with a

perimeter network

Outside

Inside

Perimeter

Internet

Client

10.0.0.2

Mail Server

10.0.0.10

10.0.0.1

192.168.0.1

Configuring the

Firewall Policy .............................................56

Protecting

the Router ....................................................60

CHAPTER 4

Case Study:

[ 55 ]




y

Firewall with a

Perimeter Network To include the perimeter network in the existing firewall configuration (Listing 3-1) discussed in Chapter 3, “Configuring

Zone-Based Policy Firewalls in Cisco IOS,” we need to do the following:

■ Configure a separate interface to which the public web server will be connected. If you’re limited by the router’s

physical setup (for example, if it has only one Fast Ethernet interface), the best approach is to create a subinterface

in a different virtual LAN (VLAN).

■ Configure the IP subnet on the perimeter interface. We’ll use subnet 192.168.0.0/24 from the private IP address

range.■ Fix the network address translation configuration. We reduce the size of the IP address pool (to gain a public IP

address for the web server) and establish a static inside-to-outside mapping for the web server.

Listing 4-1 shows the corresponding router configuration.

LISTING 4-1 Changes in IP Routing Configuration of the Firewall Routerinterface FastEthernet0/0.100

description public Web server

encapsulation dot1Q 100

ip address 192.168.0.1 255.255.255.0

ip nat inside

!

ip nat pool Internet 172.16.10.38 172.16.10.46 prefix-length 28ip nat inside source static 192.168.0.2 172.16.10.34


NOTE

Using VLANs to connect

interfaces in public and

private zones on the same

physical interface of a

firewall should be done

only as a last resort. Any

misconfiguration of the

switch to which these

devices are attached

could cause a security

breach.

NOTEYou need to remove the

previous NAT pool defi-

nition before redefining

it.

CHAPTER 4

Case Study:

[ 56 ]




Firewall with a

Perimeter Network

Configuring the Firewall PolicyThe first step in firewall policy configuration is defining traffic classes. We start by defining class maps matching the

basic protocol sets (ping, web traffic, mail delivery, and network management) encountered in this firewall (Listing 4-2).

LISTING 4-2 Configuring Basic Protocol Sets

class-map type inspect match-any ping

match access-group name IcmpEcho

!

ip access-list extended IcmpEcho


permit icmp any any echo-reply

!

! Note: Web traffic also includes ability to ping

!

class-map type inspect match-any WebTraffic

match protocol http

match protocol https

match class-map ping

!

class-map type inspect FileTransfer

match protocol ftp

!

class-map type inspect match-any PublicManagement

match protocol ftp

match protocol ssh

match protocol snmp

!


NOTE

Within this case study,

we optimize the class

definitions by groupingsimilar protocols in the

same traffic class. When

deploying application-

level packet inspection,

each protocol has to be

defined as a separate

traffic class (see the next

chapter for more details),

increasing the complexity

of the configuration. It’s

therefore mandatory that

you understand the final

firewall requirements

before you start configur-

ing the router.

continues

CHAPTER 4

Case Study:

[ 57 ]




Firewall with a

Perimeter Network LISTING 4-2 Configuring Basic Protocol Sets continued

class-map type inspect match-any SMTP

match protocol smtp extended

!

class-map type inspect match-any DNS

match protocol dns

Within the firewall policy, we also need refined traffic class definitions where a specific protocol (for example, SMTP)

will be allowed on only a specific server (for example, the inside mail server). For convenience, we also define a broader

traffic class covering all public services offered by the perimeter server: SMTP, HTTP, and DNS and ping for trou-

bleshooting purposes. The perimeter server is the authoritative server for the organization’s domain and a caching DNS

server for the internal clients.

Listing 4-3 shows the refined and extended traffic classes.

LISTING 4-3 Additional Traffic Class Definitions

class-map type inspect match-all MailDelivery

match class-map SMTP

match access-group name InternalServer

!

ip access-list extended InternalServer

permit ip any host 10.0.0.10!

class-map type inspect match-any PublicProtocols

match class-map SMTP

match class-map WebTraffic

match class-map DNS

match class-map ping

!


continues

CHAPTER 4

Case Study:

[ 58 ]




Firewall with a

Perimeter Network LISTING 4-3 Additional Traffic Class Definitions continued

class-map type inspect match-all PublicTraffic

match class-map PublicProtocols

match access-group name PerimeterServer

!

ip access-list extended PerimeterServer


Next, we configure the individual zones and the policies between pairs of zones. Finally, individual interfaces are

assigned to the configured security zones (Listing 4-4).

LISTING 4-4 Firewall Policies and Zone Definitions


zone security Perimeter

zone security Outside!


class type inspect WebTraffic

inspect

class type inspect FileTransfer

inspect

!policy-map type inspect InsideToPerimeter

class type inspect PublicTraffic

inspect

class type inspect PublicManagement

inspect

!

policy-map type inspect PerimeterToOutsideclass type inspect DNS


NOTE

The configuration of

service policies and zone

pairs seems highly

verbose. You will see

where you can benefit

from this modularity

when configuring more-

complex firewall policies

later in this chapter.

continues

CHAPTER 4

Case Study:

Fi ll ith

[ 59 ]




Firewall with a

Perimeter Network LISTING 4-4 Firewall Policies and Zone Definitions continued

inspect

class type inspect SMTP

inspect


inspect

!

policy-map type inspect OutsideToPerimeter

class type inspect PublicTraffic

inspect

!

policy-map type inspect PerimeterToInside

class type inspect MailDelivery

inspect

!



zone-pair security InsideToPerimeter source Inside destination Perimeter

service-policy type inspect InsideToPerimeter

zone-pair security PerimeterToInside source Perimeter destination Inside

service-policy type inspect PerimeterToInside

zone-pair security PerimeterToOutside source Perimeter destination Outside

service-policy type inspect PerimeterToOutside

zone-pair security OutsideToPerimeter source Outside destination Perimeter

service-policy type inspect OutsideToPerimeter

!


description Inside LAN


!


continues

CHAPTER 4

Case Study:

Firewall with a

[ 60 ]




Firewall with a

Perimeter Network LISTING 4-4 Firewall Policies and Zone Definitions continued

interface FastEthernet0/0.100

description Perimeter network

zone-member security Perimeter

!




Protecting the RouterWe complete the firewall configuration with the router-protection measures. Obviously, the only traffic allowed from the

outside or the perimeter network to the router is ICMP echo (ping). The router itself can only perform DNS queries, ping,

and traceroute to external networks. To monitor potential intrusion activities, the router should log all other connection-

establishment attempts.

Because you cannot match any other protocol except TCP, UDP, and H323 in class maps used in conjunction with the self

zone, we need to define a completely new set of traffic classes based exclusively on extended IP access lists.

Cisco IOS is using UDP packets to perform the traceroute function. The initial destination UDP port number is 33434

(unless modified with the extended traceroute command); the port number is increased in every probe to allow the router

to match probes with ICMP replies. Therefore, the IP access list matching traceroute traffic defines a wide range of target

UDP ports.

Furthermore, because the router cannot properly handle ICMP responses to the UDP packets sent with the traceroute

command, we need to include special provisions for ICMP replies arriving from the public network.

The configuration commands used to define firewall policy for inbound traffic from perimeter and outside networks are

shown in Listing 4-5. (Class map ping is defined in Listing 4-2.) Listing 4-6 contains commands defining the outboundfirewall policy. (IP access list IcmpEcho is defined in Listing 4-2.)


NOTE

There might be addi-

tional public services the

router itself needs to

access (for example, the

Network Time Protocol

[NTP] service).

NOTE

Note that the same policy

map is used twice to

specify firewall policies

between the router andthe outside and perimeter

zones.

CHAPTER 4

Case Study:

Firewall with a

[ 61 ]




Firewall with a

Perimeter Network LISTING 4-5 Firewall Policy for Inbound Traffic from Perimeter and Outside Zones

class-map type inspect match-all ICMPreply

match access-group name ICMPreply

!

ip access-list extended ICMPreply

permit icmp any any host-unreachable

permit icmp any any port-unreachable

permit icmp any any ttl-exceeded

permit icmp any any packet-too-big

!

policy-map type inspect PublicToRouter


inspect

class type inspect ICMPreply

pass

class class-default

drop log

!

zone-pair security PerimeterToRouter source Perimeter destination self

service-policy type inspect PublicToRouter

zone-pair security OutsideToRouter source Outside destination self

service-policy type inspect PublicToRouter


CHAPTER 4

Case Study:

Firewall with a

[ 62 ]




Firewall with a

Perimeter Network LISTING 4-6 Firewall Policy for Traffic from the Router Toward the Perimeter and Outside Zones

class-map type inspect match-any RouterPublicTraffic

match access-group name traceroute

match access-group name domainLookup

match access-group name IcmpEcho

!

ip access-list extended domainLookup

permit udp any any eq domain

ip access-list extended traceroute

permit udp any range 32768 65535 any range 33434 33523

!

policy-map type inspect RouterToPublic

class RouterPublicTraffic

inspect

!

zone-pair security RouterToPerimeter source self destination Perimeter

service-policy type inspect RouterToPublic

zone-pair security RouterToOutside source self destination Outside

service-policy type inspect RouterToPublic

The permitted traffic between the internal hosts and the firewall router shall obviously include ping and traceroute (as

above) as well as network management access to the firewall.

Ideally, the internal hosts would be allowed to open Telnet and SSH sessions to the router and perform router manage-

ment with SNMP while the router would send syslog, TFTP, and FTP traffic to the internal server. However, because


CHAPTER 4

Case Study:

Firewall with a

[ 63 ]




Firewall with a

Perimeter Network Cisco IOS Release 12.4 does not perform in-depth inspection of router-generated traffic, FTP or TFTP to or from the

router cannot be handled properly. (The router cannot identify the data sessions.) There are three ways to resolve thisproblem:

■ Full IP connectivity shall be allowed between the router and the internal server. This solution is not recommended

because anyone getting access to the firewall router would have full access to the internal server.

■ Use SSH or SCP (SSH-based Secure Copy) to download router configurations to the management station. You can

also use SCP to upgrade a router’s software.

■ Use HTTPS (preferred) or HTTP to download new software to the router and store router configurations to the inter-

nal server.

Listing 4-7 shows the configuration commands defining the firewall policy between the firewall router and the inside

network.

LISTING 4-7 Securing Inside Access to the Router

!

! Define inside-to-router policy

!

class-map type inspect RouterManagement

match access-group name RouterManagement

!ip access-list extended RouterManagement

permit tcp any any eq telnet

permit tcp any any eq 22 ! SSH

permit udp host 10.0.0.10 host 10.0.0.1 eq snmp ! Network management

!


continues

CHAPTER 4

Case Study:

Firewall with a

[ 64 ]




Firewall with a

Perimeter Network LISTING 4-7 Securing Inside Access to the Router continued

policy-map type inspect InsideToRouter


inspect

class type inspect RouterManagement

inspect

class type inspect ICMPreply

pass

class class-default

drop log

!

zone-pair security InsideToRouter source Inside destination self

service-policy type inspect InsideToRouter

!

! Define router-to-inside policy

!

class-map type inspect RouterFileTransfer

match access-group name RouterFileTransfer

!

ip access-list extended RouterDataTransfer

permit tcp host 10.0.0.1 host 10.0.0.10 eq 22 ! SSH/SCP

permit tcp host 10.0.0.1 host 10.0.0.10 eq www ! Web (http)

permit tcp host 10.0.0.1 host 10.0.0.10 eq 443 ! SSL (https)

permit udp host 10.0.0.1 host 10.0.0.10 eq snmp ! SNMP traps

permit udp host 10.0.0.1 host 10.0.0.10 eq syslog ! SYSLOG messages

!

policy-map type inspect RouterToInside

class type inspect RouterPublicTraffic

inspect

class type inspect RouterDataTransfer


continues

CHAPTER 4

Case Study:

Firewall with a

[ 65 ]




Perimeter Network LISTING 4-7 Securing Inside Access to the Router continued

inspect

!

zone-pair security RouterToInside source self destination Inside

service-policy type inspect RouterToInside

SummaryIn this chapter, you’ve seen how you can use the basic configuration commands supported by the zone-based policy fire-

wall feature of Cisco IOS to configure a firewall with public servers in a perimeter network. The configuration by itself is

sufficient for smaller organizations where you would not expect heavy load on the public servers; otherwise, the router

parameters have to be tuned to differentiate expected traffic load from denial-of-service attacks. In addition, this configu-

ration does not detect applications that hide within the HTTP protocol (for example, instant messaging or peer-to-peer

protocols). In the next chapter, you’ll see the advanced configuration commands that address these issues.


CHAPTER 5

Advanced Zone-

Based Policy

[ 66 ]




Firewall

ConfigurationCHAPTER FIVE

Advanced Zone-BasedPolicy FirewallConfigurationIn the previous chapters, you’ve seen the mandatory configuration

commands used to configure the zone-based policy firewall feature of

Cisco IOS and how they can be used to implement various firewall

designs. In this chapter, we focus on optional and advanced topics,

including the following:

■ Tuning the stateful inspection

■ Tuning denial-of-service protection

■ Identifying applications masquerading as other well-known

applications

■ Configuring application layer inspection policies

■ Configuring user-defined application protocols

Throughout most of this chapter, we discuss the firewall with a

perimeter network from the previous chapter and incrementally fine-

tune its configuration.


Tuning the Stateful

Inspection ....................................................67

Tuning Denial-of-

Service Protection......................................70

Identifying Masquerading

Applications.................................................74

Application Layer

Packet Inspection.......................................79

HTTP Packet

Inspection ....................................................86

Configuring

User-Defined Protocols .............................90

CHAPTER 5

Advanced Zone-

Based Policy

[ 67 ]




Firewall

ConfigurationTuning the Stateful InspectionThe zone-based policy firewall shares a number of features with Cisco IOS firewall stateful inspection, one of them being

the capability to generate an audit log of interesting sessions. The audit log can be enabled for an individual traffic class

in a policy map with the help of a global parameter-map object that defines the inspection parameters. To configure

auditing of inspected sessions, use the configuration commands in Table 5-1.

TABLE 5-1 Configuring Session Auditing


parameter-map type inspect name Creates or modifies the specified parameter map.

alert on | off Enables or disables syslog alerts (default: on).

audit-trail on | off Enables or disables a session audit trail written to the router’s log (default: off ).

inspect parameter-map-name Within a policy-map class definition, attaches a predefined parameter map to the

inspect action to modify its default behavior.

For example, in the firewall setup from the preceding chapter, we might want to log all incoming SMTP sessions as

shown in Figure 5-1.


CHAPTER 5

Advanced Zone-

Based Policy

[ 68 ]




Firewall

Configuration

To configure the audit trail for the SMTP session, we need to do the following:

■ Configure a parameter map with the audit trail.

■ Assign SMTP to a separate traffic class. (Currently, it’s bundled with all other public protocols, and you can apply

auditing only to an entire class.)

■ Reconfigure the OutsideToPerimeter policy map to include the new traffic class. Because the new traffic class is a

subset of the existing traffic class, we need to put it at the beginning of the policy map. There is no way to insert

class commands in a policy map (they are always appended), so all class definitions have to be erased and reentered.

Listing 5-1 includes the step-by-step configuration process.


FIGURE 5-1

Audit trail of inbound

SMTP sessions

WARNING

Do not delete and re-

create a policy map as

you would do with an

access list. Deleting a

policy map silently

removes all references to

it, thus potentially modi-

fying your router config-

uration.

Outside

Inside

Perimeter

Internet

Client

10.0.0.2

Internal Server

10.0.0.10

External Mail Server

172.18.25.10

Syslog Alert

Inbound SMTPSession

Web/Mail Server

192.168.0.2

CHAPTER 5

Advanced Zone-

Based Policy

Fi ll LISTING 5 1 C fi i h A di T il f I b d SMTP S i

[ 69 ]




Firewall

Configuration

LISTING 5-1 Configuring the Audit Trail of Inbound SMTP Sessions

fw#conf t

Enter configuration commands, one per line. End with CNTL/Z

fw(config)#class-map type inspect PublicSMTP

fw(config-cmap)#match class-map SMTP

fw(config-cmap)#match access-group name ExternalServer

fw(config-cmap)#exit

fw(config)#parameter-map type inspect audit

fw(config-profile)#audit-trail on

fw(config-profile)#exit

fw(config)#policy-map type inspect OutsideToPerimeter

fw(config-pmap)#no class type inspect PublicTraffic

fw(config-pmap)#class type inspect PublicSMTP

fw(config-pmap-c)#inspect audit

fw(config-pmap-c)#class type inspect PublicTraffic

fw(config-pmap-c)#inspect

fw(config-pmap-c)#^Z

fw#

After this configuration change, the router generates a line in the syslog for every session establishment and termination

event. Sample log messages are displayed in Listing 5-2.

LISTING 5-2 SMTP Session Audit Trail

%FW-6-SESS_AUDIT_TRAIL_START: (target:class)-(OutsideToPerimeter:PublicSMTP):Start smtp session: initiator

(172.18.25.10:1044) -- responder (192.168.0.2:25)

%FW-6-SESS_AUDIT_TRAIL: (target:class)-(OutsideToPerimeter:PublicSMTP)

:Stop smtp session: initiator (172.18.25.10:1044) sent 31 bytes -- responder (192.168.0.2:25) sent 306 bytes


CHAPTER 5

Advanced Zone-

Based Policy

Fire all T i D i l f S i P i

[ 70 ]




Firewall

ConfigurationTuning Denial-of-Service ProtectionThe stateful firewall inspection in Cisco IOS contains inherent denial-of-service (DoS) protection mechanisms. The router

constantly monitors the number of established and half-open connections and the connection creation rate and issues

warnings or alerts when they exceed configured thresholds. The router also tries to cope with a DoS attack (primarily

SYN attacks in which the intruder sends a large number of TCP SYN packets, also called SYN floods) by aggressively

deleting half-open sessions when their number exceeds the threshold or when the session establishment rate exceeds the

threshold.

WARNING

The rapid deletion of half-open TCP sessions helps preserve the integrity of the network infrastructure and

the existing TCP sessions (servers might simply crash or hang up under a DoS attack). It does not help

preserve the service availability, because the legitimate sessions in the establishment phase also get

dropped among the fake ones. TCP intercept is a much better mechanism to maintain service availability

during an aggressive SYN flood. However, it has a big performance impact, which might prevent its use on

a heavily loaded router.

The Cisco IOS Firewall Stateful Inspection (CBAC) feature enables you to configure only the global thresholds. The

zone-based policy firewall uses parameter maps that can be attached to every inspect statement in a policy map, resulting

in a very granular solution that can be fine-tuned to the actual network environment and traffic patterns.

The commands described in Table 5-2 are used to configure the inspect thresholds in a parameter map. (The parameter-

map syntax is described in Table 5-1.) Remember that all parameters apply to a single traffic class between a pair of

zones.


NOTE

Half-open TCP connec-

tions are connections

where the SYN packet

has been received, but the

first non-SYN packethasn’t been seen yet.

CHAPTER 5

Advanced Zone-

Based Policy

Firewall TABLE 5 2 Configuring Inspect Thresholds

[ 71 ]




Firewall

Configuration

TABLE 5-2 Configuring Inspect Thresholds


alert on | off Enables or disables syslog alerts (default: on).

audit-trail on | off Enables or disables the session audit trail written to the router’s log (default: off ).

sessions maximum number Configures the maximum number of sessions in this traffic class.

dns-timeout seconds Configures the maximum time between the DNS query and response packet.

icmp idle-timeout seconds Configures the maximum time between ICMP request and reply.max-incomplete high Configures the threshold at which the Cisco IOS firewall starts the DoS protection (high parameter)

number | low number and when the DoS protection stops (low parameter). While the DoS protection is active, the firewall

resets one half-open connection for every new connection attempt.

one-minute high number | Configures the per-minute session establishment threshold that triggers the DoS protection. The

low number process starts after the high threshold has been exceeded and stops when the session establishment

rate drops below the low threshold.

tcp max-incomplete host Configures the maximum number of half-open sessions from a single IP host. The offending host

threshold [ block minutes ] could be (optionally) blocked for the specified duration.

tcp synwait-time seconds Configures TCP timers—the maximum time between packets in session establishment, the

tcp finwait-time seconds maximum time between packets in session termination and the session idle timer.

tcp idle-time seconds

udp idle-time seconds Configures the idle timer for non-DNS UDP sessions.

You can display the default values of all these parameters with the show parameter-map type inspect default command,

which displays the values in Listing 5-3.


CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-3 Default Stateful Packet Inspection Thresholds

[ 72 ]




Firewall

Configuration

LISTING 5-3 Default Stateful Packet Inspection Thresholds

fw#show parameter-map type inspect default

parameter-map type inspect default values

audit-trail off

alert on

max-incomplete low 400

max-incomplete high 500

one-minute low 400

one-minute high 500

udp idle-time 30

icmp idle-time 10

dns-timeout 5

tcp idle-time 3600

tcp finwait-time 5

tcp synwait-time 30

tcp max-incomplete host 50 block-time 0

You would usually need to modify the inspect thresholds in high-volume environments when the router starts issuing

warning and alert messages (similar to Listing 3-9). For example, it’s quite easy to get more than 500 HTTP requests per

minute on a popular website.

Before changing the thresholds, it might be beneficial to reduce the various timeouts (which will by itself reduce the

number of half-open sessions). For example, many host DNS resolvers time out in 2 seconds. Thus, having a 5-secondDNS timeout is overkill. Similarly, a 30-second synwait-time is useful only if there is a dialup connection in the

outbound session establishment path; otherwise, you should use a timeout of a few seconds. The 10-second icmp idle-

timeout can also be reduced unless you have very slow-speed congested links.


CHAPTER 5

Advanced Zone-

Based Policy

Firewall After you have adapted the timeouts to your environment perform the following steps to fine-tune the half-open session

[ 73 ]




Firewall

Configuration

After you have adapted the timeouts to your environment, perform the following steps to fine tune the half open session

thresholds:

Step 1. Make sure your network is not infected with a worm or a target of a DoS attack. (In both cases, tuning DoS

protection will obviously not help.)

Step 2. Create a new parameter map that considerably increases the current thresholds (for example, by a factor of

10). Apply the new parameter map to the inspect statement in the policy map that triggers the DoS protec-

tion. (The alert message indicates the policy map and the class within it.)

Step 3. After a statistically significant time period (at least a day), review the inspect counters (see Listing 5-4).

LISTING 5-4 Displaying Session Inspection Parameters of a Zone Pair

fw#sh policy-map type inspect zone-pair OutsideToPerimeter

Zone-pair: OutsideToPerimeter

Service-policy inspect : OutsideToPerimeter

… service policy printout deleted …

Inspect

Session creations since subsystem startup or last reset 15480

Current session counts (estab/half-open/terminating) [6:2:0]

Maxever session counts (estab/half-open/terminating) [73:7:0]

Last session creation rate 37

Last half-open session total 0

… rest of printout deleted …


CHAPTER 5

Advanced Zone-

Based Policy

Firewall Step 4. Set the max-incomplete low parameter to the Maxever session counts half-open value. Set the max-

[ 74 ]




Firewall

Configuration

Step 4. Set the max incomplete low parameter to the Maxever session counts half open value. Set the max

incomplete high parameter to a value at least 25 percent above that. Increase the parameter to an even highervalue if you expect a significant increase in network traffic (for example, increased website traffic due to a

marketing campaign).

Step 5. The Cisco IOS printout gives you no reliable information that would allow you to set the one-minute thresh-

olds. As a starting point, set the one-minute low value to 3 times the Maxever session counts estab value and

the one-minute high value to a 50 percent higher value.

Step 6. Repeat the process for every traffic class that needs adjusted DoS protection behavior.

Step 7. Perform ongoing firewall DoS protection monitoring, and log all related events to a syslog server. The logged

events will help you perform additional fine-tuning of the parameters.

Identifying Masquerading ApplicationsSome applications (most notably, instant messaging and peer-to-peer applications) are extremely aggressive in their

attempts to establish connections with their servers. For example, Yahoo Messenger first tries to connect to Yahoo! servers

using its standard port numbers (5050 for instant messaging, 5061 for voice; see Listing 5-5 for details), but if that fails, it

uses any TCP port number that the firewall permits (for example, Telnet or HTTPS; see Listing 5-6 for an example). To

be fair, other instant messaging (IM) applications are no better, and Yahoo! even documents this behavior.

LISTING 5-5 Active TCP Connections After the Yahoo Messenger Has StartedMyhost $ netstat

Active Connections


TCP myhost:1938 cs31.msg.dcn.yahoo.com:5050 ESTABLISHED

TCP myhost:1957 sip34.voice.re2.yahoo.com:5061 ESTABLISHED


NOTE

Server logs are an

extremely valuable

resource in the tuning

process. Computing one-

minute session establish-

ment rate from a web

server log is a simple

exercise.

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-6 Yahoo Messenger Port Usage After Ports 5050 and 5061 Were Disabled on the Firewall

[ 75 ]




Configuration

g g

Myhost $ netstat

Active Connections


TCP myhost:1988 cs31.msg.dcn.yahoo.com:telnet ESTABLISHED

TCP myhost:2005 sip38.voice.re2.yahoo.com:https ESTABLISHED

The applications that can adapt their TCP or UDP port usage or use well-known ports reserved for other applications as a

disguise are effectively trying to bypass firewall policies. For example, in the sample firewall designed in Chapter 4,“Case Study: Firewall with a Perimeter Network,” the internal clients were only allowed to browse the web and use FTP

for file transfer. However, they could still use IM applications, because the inside clients have unlimited access to outside

web servers, giving the IM applications a TCP port they can use, as shown in Figure 5-2.


FIGURE 5-2

Yahoo Messenger

bypassing thefirewall policy

Outside

Inside

Perimeter

Client10.0.0.2

Unknown

application, dropped

Looks like webbrowsing, passed

scs.msg.yahoo.com:5050

Yahoo Server

scs.msg.yahoo.com:80

STOP

CHAPTER 5

Advanced Zone-

Based Policy

Firewall The masquerading applications fall into two categories:

[ 76 ]




Configuration

q g pp g

■ They use any TCP port permitted by the firewall, but only toward a well-known range of servers. For example, all

IM applications have to connect to well-known servers as they exchange the chat traffic through them.

■ Some peer-to-peer applications use any TCP port (or a fixed range of ports, such as web only) toward a wide range

of IP addresses. The only means of identifying these applications is by looking for their specific signatures in the

data stream (similar to the way virus scanners identify new viruses).

Cisco IOS can identify both types of applications starting in Release 12.4(9)T.

Identifying Peer-to-Peer ApplicationsTo identify the peer-to-peer applications by their signature, use the signature option in the match command of a class

map. For example, to match all peer-to-peer applications in our sample firewall, you could use the traffic class definition

in Listing 5-7.

LISTING 5-7 Matching Peer-to-Peer Applications by Their Signature

class-map type inspect match-any peer2peer

match protocol gnutella signature

match protocol edonkey signature

match protocol kazaa2 signature

match protocol fasttrack signature

The signature-based classification bypasses the order of classes in a policy map, so the peer-to-peer sessions misusing

ports from other applications are detected regardless of the order of class maps in a policy map.


CHAPTER 5

Advanced Zone-

Based Policy

Firewall Identifying Instant Messaging Applications

[ 77 ]




Configuration

Identifying Instant Messaging ApplicationsInstant messaging applications (and other applications that use unspecified ports to connect to their server) are identified

with the help of the protocol-info parameter-map using the syntax in Table 5-3.

TABLE 5-3 Configuring a Protocol Information Parameter Map


parameter-map type protocol-info name Creates or modifies the specified parameter map

server {name name | ip address} Specifies a single server by its name or IP address

server ip range start end Specifies a range of servers between start and end IP addresses

The name of the protocol-info parameter-map can then be appended to the match command in a class map definition.

For example, to identify Yahoo Messenger, you could use the parameter map and class map configuration in Listing 5-8.

NOTE

The router allows you to attach a protocol-info parameter-map to any match protocol statement in a class map (with the exception of peer-to-peer applications, where the signature keyword follows the protocol name), but it only works correctly for instant messaging applications in

Cisco IOS Release 12.4(9)T.

LISTING 5-8 Identifying a Yahoo Messenger Application

parameter-map type protocol-info YMServers

server name scs.msg.yahoo.com

server name insider.msg.yahoo.com

server name sip.yahoo.com!

class-map type inspect match-all YahooMessenger

match protocol ymsgr YMServers

When you use protocol-info-based traffic classification in a policy map, you don’t have to worry about the order of the

class commands. The destination IP address match with the parameter map is done before the sequential scan of the

policy map, so the IM applications are correctly identified regardless of their position in the policy map.


NOTE

Domain name resolution

must be enabled in the

router with the ip

domain lookup

command and an external

DNS server configured

with the ip name-server

command before you can

use the server name

name command.

CHAPTER 5

Advanced Zone-

Based Policy

Firewall If you want to disable access to Yahoo Messenger in our sample firewall from Chapter 4, you have to augment the

[ 78 ]




Configuration InsideToOutside policy map with the commands from Listing 5-9.

LISTING 5-9 Disable Yahoo Messenger in the Sample Firewall


class type inspect YahooMessenger

drop

You can monitor the protocol-info parameter maps with two show commands (both printouts are included in Listing 5-10):

■ show parameter-map type protocol-info {name} displays the definition of the parameter map (so you don’t have

to browse the router configuration).

■ show parameter-map type protocol-info dns-cache zone-pair name displays the IP addresses used in traffic clas-

sification in the specified zone pair; all parameter-maps used in the policy map attached to the zone pair with IP

addresses to which the hostnames specified in them resolve to.

LISTING 5-10 protocol-info-Related show Commandsfw#show parameter-map type protocol-info

parameter-map type protocol-info YMServers

server name scs.msg.yahoo.com

server name insider.msg.yahoo.com

server name sip.yahoo.com

fw#show parameter-map type protocol-info dns-cache zone-pair InsideToOutside

Application im-yahoo. Server DNS Name: ‘scs.msg.yahoo.com’.Updates: 0 failed, 328 succeeded, next after 5.866 secs

Number of IP Addresses: 8

216.155.193.138 (0D:00H:00M) 216.155.193.139 (0D:00H:00M)

216.155.193.140 (0D:00H:00M) 216.155.193.141 (0D:00H:00M)

216.155.193.142 (0D:00H:00M) 216.155.193.143 (0D:00H:00M)

216.155.193.136 (0D:00H:00M) 216.155.193.137 (0D:00H:00M)

Application im-yahoo. Server DNS Name: ‘insider.msg.yahoo.com’.

Updates: 0 failed, 17 succeeded, next after 0.942 secs



continues

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-10 protocol-info-Related show Commands continued

[ 79 ]




Configuration 68.142.194.14, 68.142.231.252 (0D:00H:00M) Application im-yahoo. Server DNS Name: ‘sip.yahoo.com’.

Updates: 0 failed, 2 succeeded, next after 3.086 secs


68.142.233.179 (0D:00H:00M) 68.142.233.180 (0D:00H:00M)

68.142.233.181 (0D:00H:00M) 68.142.233.182 (0D:00H:00M)

68.142.233.183 (0D:00H:00M) 68.142.233.176 (0D:00H:00M)

68.142.233.177 (0D:00H:00M) 68.142.233.178 (0D:00H:00M)

Application Layer Packet InspectionIn addition to the transport layer stateful inspection (which, for protocols with separate control and data sessions such as

FTP and H.323, includes some processing of an application data stream), the zone-based policy firewall feature supports

application layer inspection (also called deep packet inspection [DPI]) of several popular protocols, including the following:

■ Internet Mail Access Protocol (IMAP) and Post Office Protocol (POP). You can check whether the users are trying to

use cleartext authorization.

■ Simple Mail Transfer Protocol (SMTP). You can check maximum message length.

■ Sun Remote Procedure Call (SUNRPC). You can block access to specific programs over the RPC mechanism.

■ Peer-to-peer applications (eDonkey, FastTrack, Gnutella, and Kazaa). You can match and block transfer of files

matching the specified regular expression.

■ Instant messaging (AOL, MSN, Yahoo!). You can block the entire messaging service or just the text chat within it.

■ Hypertext Transport Protocol (HTTP). You can match on a large number of parameters, including web address

(Universal Resource Locator [URL]), content type, or any other component of the HTTP request or response header.

You can also identify applications misusing HTTP for tunneling, instant messaging, or peer-to-peer applications.


CHAPTER 5

Advanced Zone-

Based Policy

Firewall All application layer inspections are configured using application-specific class maps and policy maps that are then

[ 80 ]




Configuration attached with the service-policy command as children of Layer 4 policy maps.

Application-specific class maps are configured with the class-map type inspect protocol name configuration command.

The list of protocols supported is displayed in Listing 5-11.

LISTING 5-11 Application Layer Protocol Inspection in Cisco IOS Release 12.4(9)T

fw(config)#class-map type inspect ?

WORD class-map nameaol Configure CBAC class-map for IM-AOL protocol

edonkey eDonkey

fasttrack FastTrack Traffic - KaZaA, Morpheus, Grokster...

gnutella Gnutella Version2 Traffic - BearShare, Shareeza, Morpheus ...

http Configure CBAC class-map for HTTP protocol

imap Configure CBAC class-map for IMAP protocol

kazaa2 Kazaa Version 2match-all Logical-AND all matching statements under this classmap

match-any Logical-OR all matching statements under this classmap

msnmsgr Configure CBAC class-map for IM-MSN protocol

pop3 Configure CBAC class-map for POP3 protocol

smtp Configure CBAC class-map for SMTP protocol

sunrpc Configure CBAC class-map for RPC protocol

ymsgr Configure CBAC class-map for IM-YAHOO protocol

Within each class map definition, you can use the match commands to match supported features of the protocol. After

the class maps have been defined, you can configure the application-specific policy maps with the policy-map type

inspect application name command. The set of applications is a bit shorter (see Listing 5-12) because you can use any

instant-messaging class-map (aol, msnmsgr, and ymsgr) in im policy-map and similarly any peer-to-peer class map

(edonkey, fasttrack, gnutella) in p2p policy-map. For all other protocols, the type of the class-map has to match the

type of the policy map within which it’s used.


NOTE

The match commands

available in the class

map configuration are

protocol-specific; you

can find a detailed list in

the Cisco IOS documen-

tation. The extensive set

of HTTP match

commands is describedin the next section.

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-12 Configuring the Application Layer Policy Map

[ 81 ]




Configuration fw(config)#policy-map type inspect ? WORD policy-map name

http Configure CBAC policy-map for HTTP protocol

im Configure CBAC policy-map for IM protocol

imap Configure CBAC policy-map for IMAP protocol

p2p Configure CBAC policy-map for P2P protocols

pop3 Configure CBAC policy-map for POP3 protocol

smtp Configure CBAC policy-map for SMTP protocolsunrpc Configure CBAC policy-map for RPC protocol

Within application layer policy maps, you can use the following actions:

■ log—Logs the session

■ allow—Allows the traffic matching the class map

■ reset—Resets the connection

After the application layer policy maps are configured, you can attach them as a service policy to existing traffic classes

in the Layer 4 policy maps.

IMPORTANT

■ You can only attach a service policy to a class with the inspect action. Application layer policies thus requirestateful inspection at the parent level.

■ Application layer policies can be used only inside Layer 4 policies, not in zone pair definitions.

■ A single application layer policy map can be attached to a class in a Layer 4 policy map. This restriction might

force you to implement more granular Layer 4 classes.

■ The class to which a service policy is attached can match only protocols handled by the service policy. For

example, you cannot attach a POP3 service policy to a class matching both POP3 and IMAP protocols.


NOTE

Not all the actions are

available in all policy

maps. The allow action

is not available in IMAP

and POP3 policy maps,

and the reset action is

not available in the

SUNRPC policy map

(because you cannot reset

a UDP connection).

CHAPTER 5

Advanced Zone-

Based Policy

Firewall ■ Packets not matched by any class in a Layer 4 policy map are handled by class-default. If no action is specified in

[ 82 ]




Configuration class-default, these packets are dropped. Packets not matched by an application layer policy map are not droppedbut are handled according to the specifications of the parent policy map.

Application Layer Packet Inspection ExampleLet’s illustrate these concepts with an example. We’ll use the very simple LAN-to-Internet firewall from Chapter 3,

“Configuring Zone-Based Policy Firewalls in Cisco IOS,” where there were no restrictions on traffic from inside clients

to outside server. To control the Internet access link utilization, the IT manager would like to prevent download of MP3files with peer-to-peer services and limit the size of e-mails the users can send. Furthermore, because the e-mail is hosted

on external servers, the users shall be forced to use non-clear-text authentication methods to prevent a potential intruder

or an external wiretap from collecting the passwords (Figure 5-3).

To implement these requirements, a large number of class maps and policy maps must be configured:

■ A class map and a policy map have to be configured for POP3, IMAP, and SMTP DPI (Listing 5-13).

■ Four class maps must be configured to cover all four supported peer-to-peer services together with a P2P policy map

(Listing 5-14).


NOTE

Some of these issues

could be solved with

other mechanisms. For

example, peer-to-peer

services could be prohib-

ited, and secure POP3and IMAP could be

deployed instead of

forcing the users to use

non-clear-text authentica-

tion on regular

POP3/IMAP sessions.

FIGURE 5-3

Simple LAN-to-

Internet firewall

Outside

Inside

Client

No cleartext POP3authentication

STOPPOP3 USER command

Internet

POP3 APOP command

10.0.0.0/24

pp3.isp.com

172.16.0.2

192.168.201.610.0.0.1

CHAPTER 5

Advanced Zone-

Based Policy

Firewall ■ Inspect class maps have to be configured to match individual protocols for which we want to perform DPI

[ 83 ]




Configuration (Listing 5-15).■ Finally, a policy map ( InsideToOutside) is configured tying together all the previously configured objects

(Listing 5-16). From there onward, use the remainder of the configuration from the beginning of Chapter 3.

LISTING 5-13 Application-Level Inspection of E-mail–Related Protocols

class-map type inspect imap match-any imapMail

match invalid-command

match login clear-text

!

policy-map type inspect imap imapPolicy

class type inspect imap imapMail

log

reset

!

class-map type inspect pop3 match-any pop3Mail

match invalid-command

match login clear-text

!

policy-map type inspect pop3 pop3Policy

class type inspect pop3 pop3Mail

resetlog

!

class-map type inspect smtp match-any smtpMail

match data-length gt 5000000

!


continues

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-13 Application-Level Inspection of E-mail–Related Protocols continued

[ 84 ]




Configuration policy-map type inspect smtp smtpPolicyclass type inspect smtp smtpMail

reset

LISTING 5-14 Application-Level Inspection of Peer-to-Peer Traffic

class-map type inspect gnutella match-any noMP3gnutella

match file-transfer mp3

!

class-map type inspect fasttrack match-any noMP3fasttrack


!

class-map type inspect edonkey match-any noMP3edonkey


match search-file-name mp3!

class-map type inspect kazaa2 match-any noMP3kazaa


!

policy-map type inspect p2p noMP3transfer

class type inspect edonkey noMP3edonkey

logreset

class type inspect fasttrack noMP3fasttrack

log

reset

class type inspect gnutella noMP3gnutella

log

reset


continues

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-14 Application-Level Inspection of Peer-to-Peer Traffic continued

[ 85 ]




Configuration class type inspect kazaa2 noMP3kazaalog

reset

LISTING 5-15 Class Maps Matching Individual Deeply Inspected Application Protocols

class-map type inspect match-any getMail

match protocol pop3

class-map type inspect match-any sendMail

match protocol smtp extended

class-map type inspect match-any readMail

match protocol imap

class-map type inspect match-any peer2peer

match protocol gnutella signature

match protocol edonkey signaturematch protocol kazaa2 signature

match protocol fasttrack signature

LISTING 5-16 Inside-to-Outside Firewall Policy


class type inspect peer2peer

inspect

service-policy p2p noMP3transfer

class type inspect getMail

inspect

service-policy pop3 pop3Policy

class type inspect readMail


continues

CHAPTER 5

Advanced Zone-

Based Policy

Firewall LISTING 5-16 Inside-to-Outside Firewall Policy continued

[ 86 ]




Configuration inspectservice-policy imap imapPolicy

class type inspect sendMail

inspect

service-policy smtp smtpPolicy

class class-default

inspect

HTTP Packet InspectionCisco IOS Firewall software offers only rudimentary packet-matching features for most protocols for which deep packet

inspection is supported. Hypertext Transfer Protocol (HTTP), the protocol used to exchange content between the web

server and its clients, is a notable exception. You can use a number of different match conditions (introduced in Cisco IOS

Release 12.3(14)T with the HTTP Application Inspection Engine) to classify the web traffic, from extremely helpful ones(identifying HTTP misuse for unauthorized traffic) to arcane ones (for example, the number of header fields in the

request or response header).

HTTP packet inspection is configured using the same configuration syntax as any other DPI:

■ The class-map type inspect http name command is used to define traffic classes.

■ The policy-map type inspect http name command defines the HTTP inspection policy. You can use allow, reset,

and log action commands within it.

■ The HTTP inspection policy is attached to a class within a type inspect policy map with the service-policy http

name command. The class within which service-policy http is configured can match only the HTTP packets (and it

has to match them with the match protocol http command).


NOTE

HTTP packet inspection

works only on non-

encrypted HTTPsessions. If the data

exchange takes place

over Secure Sockets

Layer (SSL, also known

as HTTPS), the firewall

cannot inspect the packet

content.

CHAPTER 5

Advanced Zone-

Based Policy

Firewall

C fi i

The match commands that you can use in the class-map type inspect http command follow these rules:

Y h di i i h HTTP l ( t h t ) i h HTTP l l

[ 87 ]




Configuration ■ You can match on a condition in the HTTP request only (match request …), in the HTTP reply only

(match reply …), or in request or reply (match req-resp …).

■ You can match the fields in the HTTP request or response header (match … header) or body (match … body).

■ You can match header or body length (match … length gt size or match … length lt size) or inspect its contents

and match it with a regular expression (match … regex parameter-name).

■ You can also test individual fields in the request or response header, comparing them with a regular expression(match … header fieldname regex parameter-name), checking whether the response values match the request

values, or checking for potential protocol violations.

■ Finally, several generic match commands are listed in Table 5-4.

TABLE 5-4 Matching HTTP Requests and Responses

Command Syntax Descriptionmatch request uri regex name Matches the web address (URI) with a regular expression

match request arg regex name Matches the HTTP request arguments with a regular expression

match request method Matches the HTTP method in the request (GET, POST …)

http-method-name

match request port-misuse Identifies potential misuses of HTTP by tunneling, peer-to-peer, or instant-

im | p2p | tunneling | any messaging applicationsmatch response status-line Matches the status of the HTTP response (for example, 200 = OK, 403 = forbidden,

regex name 404 = not found)

Contrary to many other Cisco IOS features where you just enter the regular expression you need, the HTTP-specific

match commands use a new object named regex parameter-map, which is configured with the commands in Table 5-5.


CHAPTER 5

Advanced Zone-

Based Policy

Firewall

C fi ti

TABLE 5-5 Configuring Regular Expression Parameter Maps

Command S nta Description

[ 88 ]




Configuration Command Syntax Descriptionparameter-map type regex name Creates a new regular expression parameter map.

pattern regex Specifies the pattern to match. Multiple patterns can be specified in the

same parameter-map.

The extensive set of match commands would let you believe that you can easily match almost any web-related condition

on the firewall. The reality is a bit different due to very limited syntax of the class-map and policy-map commands:■ Hierarchical HTTP-specific class maps are not supported. You can thus only match on all conditions (match-all) or

any of them (match-any). There is no mechanism to build more complex logical expressions with the class maps.

■ Negation in a class map is not supported. It’s thus impossible to identify an HTTP request not matching a condition.

■ You cannot attach an action to the class-default of the HTTP-specific policy map. You are thus forced to define a

bogus match-all class to be able to attach an action to it.

Effectively, the configuration syntax only allows you to specify a logical condition that is an OR of multiple conditions,

each of those being an OR or an AND of the various match conditions.

Configuring Simple HTTP Inspection

Consider, for example, the simple LAN-to-Internet firewall with no traffic restrictions (from Chapter 3) that was improvedin the previous section (Figure 5-3). Now the IT manager would like to implement a simple HTTP inspection policy:

HTTP misuses and uncommon HTTP commands (anything but GET, POST, and HEAD) shall be denied. To configure

this requirement, you have to perform the following configuration steps (final configuration is in Listing 5-17):

■ class-map validHttpCommands is defined to match all allowed HTTP request methods.

■ class-map httpPortMisuse is defined to match any misuses of TCP port 80.




CHAPTER 5

Advanced Zone-

Based Policy

Firewall

Configuration

LISTING 5-17 Implementing Simple HTTP Inspection continued

!

[ 90 ]




!policy-map type inspect InsideToOutside

class type inspect httpTraffic

inspect

service-policy http validHttp

Configuring User-Defined ProtocolsIn many firewall scenarios, you have to identify nonstandard protocols (or protocols not yet recognized by Cisco IOS) or

standard protocols operating on nonstandard port numbers. A common requirement is the support for HTTP proxy

servers, which usually operate on TCP port 8080. For example, to implement a firewall with proxy server in the perimeter

network, the firewall policy configuration shall allow TCP sessions to port 8080 of the proxy server (Figure 5-4).


FIGURE 5-4Proxy access to

external web server

Outside

Inside

Perimeter

Internet

Proxy Web Server

192.168.0.2

Client10.0.0.2

External Web Server

172.18.25.10

R e q u e s t o n p o r t 8

0 8 0 R e q u e

s t o n

p o r t 8

0

CHAPTER 5

Advanced Zone-

Based Policy

Firewall

Configuration

You could solve this challenge with existing configuration commands by defining an extended IP access list and a class

map based on the access list (similar to how we’ve recognized ICMP echo packets in previous configurations), or you

ld d fi d fi d t l ith th i t d ( th t i T bl 5 6)

[ 91 ]




could define a user-defined protocol with the ip port-map command (see the syntax in Table 5-6).

TABLE 5-6 Defining Nonstandard TCP or UDP Port Use


ip port-map user- protocol-name Specifies port usage for a user-defined protocol. The protocol name must start with the user-

port {tcp | udp} port-number prefix to ensure there is no overlap with future protocol additions to Cisco IOS.

ip port-map protocol port Specifies a nonstandard TCP or UDP port for a protocol recognized by Cisco IOS.

{tcp | udp} port-number

In the sample firewall, you could define your own protocol on TCP port 8080 and use it in a class map in a configuration

similar to the one in Listing 5-18.

LISTING 5-18 Configuring a User-Defined Protocolip port-map user-proxyhttp port tcp 8080

!

class-map type inspect match-all proxyhttp

match protocol user-proxyhttp

!

policy-map type inspect InsideToPerimeter

class type inspect proxyhttp ! matches TCP port 8080

inspect ! cannot use HTTP service policy


inspect


CHAPTER 5

Advanced Zone-

Based Policy

Firewall

Configuration

When you define your own protocol, you cannot use extended features Cisco IOS supports for standard protocols. For

example, if you configure FTP on a nonstandard port as a user-defined protocol, Cisco IOS will not recognize its data

sessions You also cannot use DPI for a user defined protocol In both cases specifying additional port numbers for stan

[ 92 ]




sessions. You also cannot use DPI for a user-defined protocol. In both cases, specifying additional port numbers for stan-

dard protocols is preferred. So, if you want to use DPI of requests made from inside clients to the proxy server, you

should define an additional port for the HTTP protocol (Listing 5-19).

LISTING 5-19 Configuring Additional Port Numbers for a Standard Protocol

ip port-map http port tcp 8080

!

class-map type inspect match-all web

match protocol http

!


class type inspect web ! matches TCP port 80 and port 8080

inspect ! can use HTTP service policy


inspect

After you define additional port numbers for standard protocols, any match protocol command will match these port

numbers as well. If you want to limit a traffic class to the standard port number (for example, when matching inbound

traffic for the public web server), you have to combine the match protocol command with an access list (Listing 5-20).

LISTING 5-20 Defining the WebTraffic Class

class-map type inspect WebTraffic

match protocol http

match access-group name WebPort80

!

ip access-list extended WebPort80

permit tcp any any eq www


NOTE

Adding TCP or UDP

ports to standard proto-

cols with the ip port-

map command affects

other Cisco IOS features

that use the port mapfunctionality (for

example, Network-Based

Application Recognition

[NBAR]).

CHAPTER 5

Advanced Zone-

Based Policy

Firewall

ConfigurationSummaryIn this chapter, you’ve seen how you can use advanced configuration commands of the zone-based policy firewall config-

[ 93 ]




In this chapter, you ve seen how you can use advanced configuration commands of the zone based policy firewall config

uration to do the following:

■ Generate an audit log of inspected sessions with a parameter-map type inspect containing the audit on parameter.

■ Configure DoS-prevention parameters with a parameter map.

■ Identify peer-to-peer and instant-messaging applications even when they use port numbers reserved for other appli-

cations.

■ Configure firewall policies for POP3, IMAP, SMTP, HTTP, peer-to-peer, and instant-messaging applications.

■ Configure user-defined protocols or add nonstandard TCP or UDP port numbers to protocols already recognized by

Cisco IOS with the ip port-map command.


CHAPTER 6

Configuring

Transparent

Firewalls CHAPTER SIX

Configuring

[ 94 ]




ConfiguringTransparent FirewallsCisco IOS Release 12.3(7)T introduced the transparent firewall

feature: the ability to filter IP traffic between a pair of bridged inter-

faces. This feature is fully supported by the new zone-based configura-

tion commands, making transparent firewall configuration extremely

simple. Before configuring this interesting feature (which introduces

no additional configuration commands), you have to understand its

underlying mechanisms and design rules, which we cover in depth in

this chapter. Throughout most of the examples, we focus on a slightly

modified version of the firewall with a perimeter network introducedin Chapter 4, “Case Study: Firewall with a Perimeter Network”

(Figure 6-1).


FIGURE 6-1

Physical firewall

structure

Client10.0.0.2

Outside

Internet

Perimeter VLAN 518

Inside

VLAN 516

Inside

VLAN 517 VLAN trunk

Web/Mail Server192.168.0.2

Server10.0.0.10

Protecting Internal

Servers: Alternate Design .......................103

Case Study: Migrating a

Server to the Perimeter Network...........106

CHAPTER 6

Configuring

Transparent

Firewalls Our organization has built a switched LAN network with all clients and servers residing in one IP subnet. It has success-

fully implemented the external firewall and wants to increase the security of its internal LAN by isolating servers from

the end users and giving only the network administrators privileged access to the servers. Traditionally, to implement this

[ 95 ]




the end users and giving only the network administrators privileged access to the servers. Traditionally, to implement this

requirement, you would split the network into three subnets (requiring at least partial renumbering of the network) and

install a firewall in the middle. In not-so-well-managed LAN environments, where the DNS and DHCP services are inter-

mingled with static IP address and hostnames entered in hosts files, renumbering might not be a viable option.

In the new firewall design, the inside clients and servers have been split into two separate VLANs, and the perimeter

network is connected to a third VLAN, all three of them being connected to the firewall router with a VLAN trunk.(VLAN configuration on the router is included in Listing 6-1.) The client and the server host are in the same IP subnet, so

the traffic between them has to be bridged. The firewall should thus perform interzone checks both on routed and bridged

IP traffic.

LISTING 6-1 VLAN Configuration on the Firewall Router


description Trunk to the LAN switch

!



description Client VLAN

!



description Server VLAN

!



description Perimeter VLAN


NOTEIt’s a bad idea to connect

inside and perimeter or

outside devices to the

same switch because they

might end up being

directly connected if the

switch loses its configu-

ration. However, if your

router has a single physi-

cal LAN interface, that

might be the only solu-

tion.

CHAPTER 6

Configuring

Transparent

Firewalls The Cisco IOS transparent firewall relies on the integrated routing and bridging (IRB) infrastructure, where a group of

bridged ports is treated as a logical IP interface. To configure IRB, perform the following steps:

[ 96 ]




Step 1. Enable integrated routing and bridging with the bridge irb command.

Step 2. Create a bridge group and specify its spanning tree protocol with the bridge number protocol protocol

command.

Step 3. Assign all bridged interfaces into the bridge group with the bridge-group number command.

Step 4. Configure IP routing for the bridge group with the bridge number route ip command.Step 5. Configure a virtual IP interface representing the router’s attachment to the bridge group with the interface

bvi number command.

Listing 6-2 shows the IRB configuration of the firewall router. After these configuration commands, the router performs

two distinct logical functions: It bridges between two interfaces and routes between BVI1, FastEthernet0/0.100, and the

serial interface (see Figure 6-2).

LISTING 6-2 IRB and IP Configuration of the Firewall Router

bridge irb

!


bridge-group 1

!


bridge-group 1

!


ip address 192.168.0.1

ip nat inside


NOTE

For the remainder of the

router configuration,

including Network Address Translation

(NAT) configuration,

see Chapter 4.

continues

CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-2 IRB and IP Configuration of the Firewall Router continued

!interface BVI1

[ 97 ]




interface BVI1

ip address 10.0.0.1 255.255.255.0

ip nat inside

!

bridge 1 protocol ieee

bridge 1 route ip

The packets traversing the router thus take one of the following paths:

■ If the packet arrives through one of the bridged interfaces and the destination MAC address is not the router’s own

MAC address, it’s bridged according to the entries in the bridge forwarding database (displayed with the show

bridge number command).


10.0.0.0/24

Firewall Router

FastEthernet 0/0.100

192.168.0.0/24

Serial 0/0.100VLAN 517

BVI 1

FastEthernet 0/0.5

FastEthernet 0/0.1

192.168.201.4/30

VLAN 516

FIGURE 6-2

Logical structure of

the firewall router

CHAPTER 6

Configuring

Transparent

Firewalls ■ If the packet arrives through one of the bridge interfaces with the router’s MAC address as the destination MAC

address, it’s routed as if it were received through the BVI interface. The physical interface through which the packet

has been received is mostly ignored in the routing process.

[ 98 ]




NOTE

BVI interface configuration is considered when routing these packets. For example, if you configure ip access-group in on the physical

interface and the BVI interface, only the one on the BVI interface is applied.

■ If the packet arrives through any other interface and is routed to the BVI interface, the outbound configuration of the

BVI interface is applied (for example, the IP access list is checked, NAT translation is performed, and so on), andthen the packet is bridged into the bridge group (which might involve flooding the packet if the ARP cache entry is

still valid, but the destination MAC address is not available in the bridge forwarding database).

The transparent firewall feature of Cisco IOS can now be applied to the bridged interfaces by assigning them to security

zones. For example, you can create two new zones (clients and servers) and assign VLAN 516 to the clients zone and

VLAN 517 to the servers zone (Listing 6-3). The BVI1 interface is obviously assigned to the inside zone.

LISTING 6-3 Zone Assignments of the Inside Physical and Logical Interfaces

zone security Insidezone security Clientszone security Servers!class-map type inspect match-any Exchangematch protocol msrpc

match protocol imapmatch protocol imapsmatch protocol pop3match protocol pop3smatch protocol smtpmatch protocol ldapmatch protocol ldaps!class-map type inspect match-any Netbios


continues

CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-3 Zone Assignments of the Inside Physical and Logical Interfaces continued

match protocol netbios-nsmatch protocol netbios-ssn

[ 99 ]




match protocol netbios-dgm

!

class-map type inspect match-any SQLServer

match protocol ms-sql

!

policy-map type inspect ServerTrafficclass type inspect SQLServer

inspect

class type inspect Netbios

inspect

class type inspect Exchange

inspect

class class-defaultdrop

!

zone-pair security ClientsToServers source Clients destination Servers

service-policy type inspect ServerTraffic

!


zone-member security Clients!


zone-member security Servers

!

interface BVI1



CHAPTER 6

Configuring

Transparent

Firewalls When defining the interzone policies, you have to define rules for traffic crossing from the clients zone to the servers

zone (in our example, we allowed NetBIOS, SQL Server, and Outlook traffic from clients to the server) and vice versa (in

our example, no sessions are allowed to be established from the servers toward the clients), but not between clients (or

[ 100 ]




servers) and outside (or perimeter ). This is a bit startling at first glance, but not if you consider the switching path a

packet takes in the router:

■ When a packet is bridged between the Fast Ethernet interfaces, it’s considered to be crossing between the clients and

servers zones.

■ When a packet arrives through the bridged interfaces and is routed to another subnet, it’s considered to be arrivingthrough the BVI1 interface (thus from the inside zone).

It looks like a router would be split in two separate firewalls, one operating on the bridged level, and another one on the

routed level (see Figure 6-3).

Using the transparent firewall feature in our sample firewall, you can filter the communication between the clients and the

servers residing in separate VLANs, but you cannot use the clients and servers zones to limit traffic that these two groups

of hosts are allowed to send to or receive from the perimeter or outside zones. If these hosts send the traffic to another


FastEthernet 0/0.100

Perimeter

192.168.0.0/24

Outside

192.168.201.4/30

Serial 0/0.100

Clients

VLAN 516

BVI 1

Inside10.0.0.0/24

Servers

VLAN 517

FIGURE 6-3

Resulting firewall

structure

CHAPTER 6

Configuring

Transparent

Firewalls routed zone, it appears as if the traffic is coming from the inside zone, so the only way to differentiate between clients

and servers when routing IP traffic is to define traffic classes used in the inside zone based on their IP addresses. In our

example, we would have to extend the configuration from Chapter 4 by defining new traffic classes covering traffic

d h i i i f h d i i h h b i i f di li

[ 101 ]




toward the server or originating from the server and inserting them at the beginning of corresponding policy maps:

■ Class map AllServerTraffic covers all routed traffic to and from the server. This class is used as a catchall class that

drops all sessions that are not explicitly allowed.

■ Class map MailFromInside covers SMTP traffic from inside server to perimeter server.

■ There is no need for new classes covering traffic from outside or perimeter zones into the inside zone; no sessions

are allowed from outside to inside anyway and the existing configuration of PerimeterToInside policy map (Listing 4-4)

already filters traffic based on the server’s IP address.

■ The new classes are inserted at the beginning of the existing InsideToPerimeter policy map. (See Listing 4-4 for the

complete configuration.) The InsideToOutside policy map is also modified to prevent session establishment from the

server to the outside zone.

The modified firewall policy is included in Listing 6-4. As you can see, mixing IP hosts with different security require-

ments in the same security zone (which is obviously against the rules we established in Chapter 2, “Typical Zone-Based

Firewall Designs,” but is necessary because our design requirements and implementation details of the transparent fire-

wall) degrades the concept of security zones to the complexity of building firewalls with IP access lists (most obvious in

the InsideToPerimeter policy map).


CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-4 Modified Firewall Policy for the Inside-to-Perimeter Zone Pair

class-map type inspect match-all MailFromInside

match protocol smtp

[ 102 ]




match access-group name ServerAccess

class-map type inspect match-all AllServerTraffic

match access-group name ServerAccess

!

ip access-list extended ServerAccess

permit ip any host 10.0.0.10permit ip host 10.0.0.10 any

!


class type inspect AllServerTraffic

drop

class type inspect WebTraffic ! defined in Chapter 4

inspectclass type inspect FileTransfer

inspect

!


class type inspect MailFromInside

inspect

class type inspect AllServerTrafficdrop

class type inspect PublicTraffic ! defined in Chapter 4

inspect

class type inspect PublicManagement

inspect


CHAPTER 6

Configuring

Transparent

Firewalls Protecting Internal Servers: Alternate DesignThe previous discussion of the transparent firewall behavior might have led you to believe that it has only marginalusability for our case study. This is the completely wrong impression; it’s counterintuitive only when used in a combined

[ 103 ]


NOTE

Addi d fi ll



usability for our case study. This is the completely wrong impression; it s counterintuitive only when used in a combined

routed/bridged environment. As an alternative, cleaner design, you could deploy the second physical firewall between the

servers and the clients, operating it in bridged-only mode. To illustrate the dilemmas arising in a mixed bridged/routed

environment, we will also add the administrators zone (VLAN 515) that has privileged access to the servers

(Figure 6-4).

In the modified design, we still have three VLANs (servers, administrators, and clients) in the same IP subnet, so IRB isstill needed to connect them. Ideally, both the inside and outside firewall would connect to all relevant VLANs (inside

firewall to all three of them, outside firewall to clients and servers). However, with the introduction of the inter-VLAN

bridge in the inside firewall, IRB can no longer be used on the outside firewall, because the attachment of two inter-

VLAN bridges to the same VLANs would create a bridging loop, and at least one subinterface on the inside or outside

firewall would be disabled, resulting in suboptimal traffic flow (Figure 6-5).


Adding a second firewall

in the inside network also

slightly increases the

security of the solution

(defense-in-depth princi-

ple); if an intruder gains

access to the outside fire-wall or breaks through its

defenses, the internal

firewall still protects the

servers.

FIGURE 6-4Second firewall

added to the LAN

network—physical

connectivity diagram

Inside Clients

Outside

Perimeter

Web/Mail Server192.168.0.2

Administrators

Servers

Internet

CHAPTER 6

Configuring

Transparent

Firewalls

[ 104 ]


VLAN 515

AdministratorsFIGURE 6-5Bridging loop in the

d i d k



The easiest way out of this problem is to give administrators VLAN access to the firewall router through the clients

VLAN, resulting in the logical firewall structure in Figure 6-6. (The switch physically connecting end devices to VLANs

has been removed from the diagram for clarity.) The outside firewall router can then use the unmodified configuration

from Chapter 4, and the inside firewall performs interzone traffic control on bridged traffic between internal VLANs.


Firewall RouterInside Router VLAN 516

Clients

redesigned network

Inside Clients

Outside

PerimeterWeb/Mail Server

192.168.0.2

Administrators

Servers

Internet

FIGURE 6-6

Final firewall

structure—logical

connectivity diagram

CHAPTER 6

Configuring

Transparent

Firewalls The inside firewall does not need IP routing at all, so it can be disabled if desired. IRB should be configured to give the

device a single IP address reachable through all interfaces. The firewall zones can then be configured and attached to

subinterfaces (Listing 6-5). After the initial configuration, you would create traffic classes, define firewall policies, and

apply them to zone pairs as explained in the previous chapters

[ 105 ]


NOTE

When configuring fire-



apply them to zone pairs as explained in the previous chapters.

LISTING 6-5 Initial Configuration of the Inside Firewall

no ip routing

bridge irb

!zone security Administrators

zone security Servers

zone security Clients

!



description Client VLANbridge-group 1

zone-member security Clients

!



description Administrators VLAN

bridge-group 1zone-member security Administrators

!



description Server VLAN


When configuring fire-

wall policies, do not

forget that the adminis-

trators have to pass

through the clients zone

to get to the Internet.

continues

CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-5 Initial Configuration of the Inside Firewall continued

bridge-group 1

zone-member security Servers

!

[ 106 ]




!

interface BVI1

ip address 10.0.0.1 255.255.255.0

!

bridge 1 protocol ieee

bridge 1 route ip

Case Study: Migrating a Server to the PerimeterNetworkIn this case study, you’ll see how you can use IP routing tricks to work around the limitations of the transparent firewall.

Consider the network in Figure 6-7, where the public server is attached to the same LAN as the internal clients.

Obviously, this is a large security risk (an intruder gaining access to the public server could immediately explore the

internal LAN), so the administrator would like to move the server to the perimeter network. Assuming that IP renumber-

ing is not possible, a transparent firewall would be an ideal solution. However, because of its limitations, it would be

impossible to apply a clean three-zone design from Chapter 4 to this scenario.


CHAPTER 6

Configuring

Transparent

Firewalls

[ 107 ]


FIGURE 6-7Initial network design

Outside10.0.0.2

Public Server10.0.0.20

dns.isp.com

172.16.0.1

smtp.isp.com

172.16.0.2



The best solution in this case study is to use three IP subnets on the firewall as in Chapter 4 and rely on the local area

mobility feature introduced in Cisco IOS Release 11.0 to insert a host route toward the public server in the perimeter

network (see the Local Area Mobility White Paper and Cisco IOS documentation for more details), as illustrated in

Figure 6-8.


Inside

Internet10.0.0.0/24 www.web.com

172.18.25.10

172.16.10.32/28

10.0.0.1 192.168.201.6

FIGURE 6-8Firewall design using

local area mobility

Outside

Inside

Perimeter

Internet

Public Server

10.0.0.20

Client

10.0.0.2

10.0.0.1/24

10.0.1.1/24 Host route topublic server

1 0 . 0 . 0 .2 0 / 3 2

CHAPTER 6

Configuring

Transparent

Firewalls The local area mobility feature is configured with the ip mobile arp command. Apart from that command, the IP routing

configuration of the firewall is similar to the one from Chapter 4 (Listing 6-6).

LISTING 6-6 Configuration of Inside Interfaces on the Firewall Router

[ 108 ]


NOTE



hostname fw

!

interface Loopback1

ip address 172.16.10.33 255.255.255.240

!interface FastEthernet0/0


ip address 10.0.0.1 255.255.255.0

ip nat inside

!


description Public Web server (Perimeter network)encapsulation dot1Q 100

ip address 10.0.1.1 255.255.255.0

ip nat inside

ip mobile arp access-group PublicServerAddresses

!

interface Serial0/0/0

no ip addressencapsulation frame-relay

!



ip address 192.168.201.6 255.255.255.252


You could also use a

static route pointing to

the perimeter interface

(ip route 10.0.0.20

255.255.255.255

FastEthernet0/0.5)rather than local

area mobility. Local area

mobility might not work

on all router platforms.

continues

CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-6 Configuration of Inside Interfaces on the Firewall Router continued

ip nat outside

frame-relay interface-dlci 100

!

[ 109 ]




ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100

!

ip nat pool Internet 172.16.10.38 172.16.10.46 prefix-length 28

ip nat inside source static 10.0.0.20 172.16.10.34

ip nat source list InternalHosts pool Internet

ip nat inside source list InternalHosts pool Internet

!

! list all IP addresses of the public servers in the following access-list

!

ip access-list standard PublicServerAddresses

permit host 10.0.0.20

!

ip access-list standard InternalHosts

permit 10.0.0.0 0.0.0.255

After you’ve configured the local area mobility, you can check the proper insertion of the host routes with the show ip

route mobile command and debug its operation with debug arp and debug ip mobile local-area (Listing 6-7).

LISTING 6-7 Debugging and Monitoring Local Area Mobilityfw#debug arp

ARP packet debugging is on

fw#debug ip mobile local-area

IP local-area mobility debugging is on

fw#


continues

CHAPTER 6

Configuring

Transparent

Firewalls LISTING 6-7 Debugging and Monitoring Local Area Mobility continued

04:02:45: Local MobileIP: FastEthernet0/0.5 add 10.0.0.20 accepted

04:02:45: IP ARP: rcvd req src 10.0.0.20 0017.5926.3f50, dst 10.0.0.1 FastEthernet0/0.5

04:02:45: Local MobileIP: FastEthernet0/0.5 add 10.0.0.20 accepted

[ 110 ]




04:02:45: Local MobileIP: route 10.0.0.20 added

04:02:45: IP ARP: sent rep src 10.0.0.1 0017.5926.5c58,

dst 10.0.0.20 0017.5926.3f50 FastEthernet0/0.5

fw#show ip route mobile

10.0.0.0 255.0.0.0 is variably subnetted, 3 subnets, 2 masks

M 10.0.0.20 255.255.255.255

[3/1] via 10.0.0.20, 00:36:24, FastEthernet0/0.5

After you’ve successfully configured and tested local area mobility, you have a working firewall with three routed inter-

faces. You can complete the configuration using zones, traffic classes, and policies similar to those in Chapter 4.

SummaryIn this chapter, you’ve seen how you can configure the Cisco IOS transparent firewall using the zone-based configuration

commands. When designing the zone-based transparent firewall, keep in mind these guidelines:

■ Only a single zone pair is checked for every packet traversing the router.

■

If a packet is bridged through the router, the router checks the zone pair policy configured between the physicalinterface zones.

■ If a packet is routed, the router checks the zone pair policy between the zones of the BVI interface and the outbound

IP interface.

■ If a packet is sent to the router itself, the router checks the zone pair policy between the zone of the BVI interface

and the self zone.


CHAPTER 6

Configuring

Transparent

Firewalls ■ Configuring a zone pair between a bridged and a routed zone makes no sense (because it will never be used).

■

Although you could, do not apply the same zone on bridged and routed interfaces; that will only lead to confusion.

[ 111 ]


Deploying Zone-based Firewalls

Documents

Transcript of Deploying Zone-based Firewalls