Deploying Zone Based Firewall
Content
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
Deploying Zone-Based Firewalls
Ivan Pepelnjak
ciscopress.com
[2]
CHAPTER 1 Introduction
Deploying Zone-Based Firewalls by Ivan Pepelnjak
About the Author
Ivan 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 technologies 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 Editor
Randy 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 understand and 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[3]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER ONE
Introduction to ZoneBased Firewalls
In the mid-1990s, when the large corporate networks began to be connected 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.
NOTE
If you are not familiar with packet filters offered by the Cisco IOS, refer to the Cisco IOS Access Lists book available through Safari Books Online or to the relevant Cisco IOS documentation.
Simple ZoneBased Design.................................................4 More Complex Zone-Based Design.......................................5 Implementing Zone-Based Designs.....................................7
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 firewall policies, the concept of zone-based firewall design emerged.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[4]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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). 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. 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). 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.)
NOTE
Within the context of this discussion, server is any host that accepts incoming connections, regardless of its actual hardware or software implementation.
Step 2.
Step 3.
Step 4.
Simple Zone-Based Design
Consider, 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[5]
CHAPTER 1 Introduction to Zone-Based Firewalls
FIGURE 1-1
Simple firewall setup Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Internet
Inside
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 Design
NOTE
The actual interzone firewall policies for this design are described in the next chapter.
A 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[6]
CHAPTER 1 Introduction to Zone-Based Firewalls
FIGURE 1-2
Traditional firewall design
Web/Mail Server
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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.
Public
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 misconfigured or fails, the inside firewall still protects the internal network. Internet
Inner Router Outer Router
Internal
Perimeter
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
Server Zone (Hosts Terminating the Connections) Sessions Allowed
Client Zone (Hosts Originating the Connections)
Inside Outside
Outside Inside
Traffic from internal zone to perimeter and public zones Traffic from public and perimeter zones to internal zone
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[7]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Implementing Zone-Based Designs
As 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.
FIGURE 1-3
TCP session establishment across a packet-filtering device
Outside
10.0.0.2 From 10.0.0.2 port 1030 to 172.18.25.1 port 80 172.18.25.1
Internet
From 172.18.25.1 port 80 to 10.0.0.2 port 1030
Inside
?
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.)
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[8]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 NOTE
Cisco PIX, the Cisco standalone firewall appliance, was designed around the concept of conduits (old PIX terminology for traffic flows), which has from the beginning included the proper handling of return traffic. 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 for UDP 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[9]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 1-2
TCP and UDP Ports Opened on a Typical IP Host Running Windows XP
M:\>netstat -an Active Connections Proto Local Address TCP 0.0.0.0:80 TCP 0.0.0.0:135 TCP 0.0.0.0:443 TCP 0.0.0.0:445 TCP 0.0.0.0:990 TCP 0.0.0.0:1039 TCP 0.0.0.0:23598 TCP 127.0.0.1:1058 TCP 127.0.0.1:5679 TCP 127.0.0.1:7438 TCP 127.0.0.1:62514 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
Foreign Address 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:*
State LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 10 ]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Even if the challenges of return TCP traffic are solved with smarter packet filters and the return UDP traffic is addressed with 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 Stateful Inspection). 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.
NOTE
CBAC support for ICMP was 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 release 12.4.
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 using the 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 ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip access-group fromInternet in ip inspect Internet out ! ip access-list extended fromInternet deny ip 10.0.0.0 0.0.0.255 any
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 11 ]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
After this configuration change, every session opened from an inside host to an outside server would also create a dynamic entry (pinhole) at the bottom of the outside access list. Because the CBAC also handles outbound ICMP traffic (pings and traceroutes) and ICMP responses associated with TCP or UDP sessions traversing the router, the fromInternet access list has been significantly reduced and now includes only a generic filter preventing address spoofing. The audit-trail option of the ip inspect command also generates the trail of TCP or UDP sessions in the router’s log, as illustrated in Listing 1-4.
LISTING 1-4 Audit Trail Generated by the Router
04:27:19: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session: initiator (10.0.0.2:1064) -- responder (172.18.25.1:80) 04:27:21: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session: initiator (10.0.0.2:1065) -- responder (172.18.25.1:80) 04:27:26: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator (10.0.0.2:1064) sent 307 bytes -- responder (172.18.25.1:80) sent 2850 bytes 04:27:27: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator (10.0.0.2:1065) sent 345 bytes -- responder (172.18.25.1:80) sent 771 bytes
The introduction of CBAC has successfully addressed the shortcomings of packet filters, but it did not help improve the scalability of firewall implementations—the packet filters still have to be configured to operate between interfaces. In scenarios with multiple zones connected to a single networking device, this results in a serious drawback: Each packet filter has to contain a mixture of multiple firewall policies. (For example, if three zones are attached to a router, a packet filter applied on any interface has to filter traffic being sent into or received from two other zones.) Zone-based policy firewall, a new configuration feature introduced in Cisco IOS Release 12.4(6)T, solves this problem, too, finally allowing the implementation team to follow the zone-based design and specify the traffic permitted between zones.
Summary
In the next chapter, we focus first on typical firewall design scenarios, ranging from a simple small office/home office (SOHO) LAN to a complex corporate firewall. In the subsequent chapters, a number of case studies show how you can use the zone-based policy firewall feature to implement these designs on Cisco IOS-based networking devices.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 12 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER TWO
Typical Zone-Based Firewall Designs
NOTE
Network designers who are already familiar with the zone-based firewall design principles can skip this chapter and continue to the implementation section. All other readers are highly advised to read it, because a well-thoughtout and well-documented design almost always results in superior implementation.
Simple LAN-toInternet Firewall ..........................................12 Firewall with Public Servers .............................................15 Redundant Firewall Designs.........................................................20 Complex Firewall Designs.........................................................20 Reducing the Complexity of Advanced Firewalls ................................23
In the preceding chapter, you saw how the philosophy of firewall design has evolved from packet-filter-oriented designs toward zonebased 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-Internet Firewall
The simplest possible design is a protected LAN connected to the public IP network (for example, the Internet) through a firewall. No publicly 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 13 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Inside Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
FIGURE 2-1
Simple LAN-toInternet firewall Internet
Two firewall policies are commonly used in such setups:
NOTE
All the firewall policy tables in this book assume a stateful firewall implementation, so there are no special entries for the return packets.
■ ■
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 (for example, web and mail services)
Permissive Firewall Policy
Server Zone Sessions Allowed
TABLE 2-1
Client Zone
Inside Outside
Outside Inside
All 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 connectivity troubleshooting.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 14 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
NOTE
Most versions of Windows use ICMP to trace the path to the destination host. UDP packets as the trace packets are used by some UNIX environments (for example, Linux) as well as Cisco IOS.
■ ■
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Domain Name Service (DNS) on UDP port 53 has to be enabled; otherwise, the internal clients will not be able to resolve 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.
Restrictive Firewall Policy
Server Zone Sessions Allowed
■
TABLE 2-2 NOTE
TCP ports needed for FTP data sessions are identified automatically by the stateful firewall implementations. If you’re not using a stateful firewall, you need to allow TCP port 20, too, and advise the clients to use passive FTP. Client Zone
Inside
Outside
DNS (UDP port 53) to ISP’s name servers ICMP echo HTTP (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 None
Outside
Inside
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 15 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall with Public Servers
There 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 a fatal configuration error (defense-in-depth principle).
Inside Outside
FIGURE 2-2
Simple firewall with a perimeter network
Internet
Web/Mail Server
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 16 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Inside Perimeter
Web/Mail Server
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Outside
FIGURE 2-3
Transit perimeter network
Internet
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.
NOTE
Please refer to Bind 9 documentation for an in-depth explanation of name server nomenclature.
When designing a restrictive firewall policy, you must consider the implementation details of the DNS and e-mail services. 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 a caching 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.
■
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 17 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 communicate with the outside world. In this case, bidirectional SMTP is required between the inside server and the perimeter 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.
Restrictive Policy of a Firewall with a Perimeter Network
Server Zone Sessions Allowed
■
TABLE 2-3
Client Zone
Inside Outside Inside
Outside Inside Perimeter
ICMP echo, HTTP, HTTPS (Optionally) FTP None 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 SMTP to inside mail server (to deliver inbound e-mail) DNS SMTP (to deliver outbound e-mail) 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 HTTP because its single-session design does not cause any firewall issues.)
Perimeter Perimeter Outside
Inside Outside Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 18 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The firewall policy just documented is extremely restrictive, allowing only the minimum number of services needed. This results 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 eliminating any direct traffic between the internal network and the public Internet, as illustrated in Table 2-4.
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 in HTTP requests to the proxy server.
TABLE 2-4
Client Zone
Policy of a Firewall with Proxy Servers in the Perimeter Network
Server Zone Sessions Allowed
Inside Outside Inside
Outside Inside Perimeter
None None HTTP, HTTPS (to access proxy web server) ICMP echo SMTP from inside mail server to perimeter mail server FTP and SSH for server management SMTP to internal e-mail server (to deliver inbound e-mail) DNS SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web) (Optional) FTP ICMP echo DNS (only if the customer runs its own name server) HTTP to public web server SMTP to public mail server (Optional) FTP; see also comments in Table 2-3
Perimeter Perimeter
Inside Outside
Outside
Perimeter
The transition from the single-device design (Figure 2-2) to the design with a transit perimeter network (Figure 2-3) illustrates one of the advantages of a well-documented zone-based design: Because all the firewall policies have already been documented, they don’t have to be designed from scratch. You merely split the overall firewall policy into two parts: the
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 19 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
inner firewall handles policies from inside to everywhere else, and the outer firewall handles policies from outside to everywhere 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
Client Zone
Policy of the Inner Firewall
Server Zone Sessions Allowed
Inside
Perimeter
HTTP, HTTPS (to access proxy web server) ICMP echo SMTP (to send mail) FTP and SSH for server management. SMTP to inside mail server (to deliver inbound e-mail)
Perimeter
Inside
TABLE 2-6
Client Zone
Policy of the Outer Firewall
Server Zone Sessions Allowed
Perimeter
Outside
DNS SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web) (Optional) FTP ICMP echo DNS (only if the customer runs its own name server) HTTP to public web server SMTP to public mail server (Optional) FTP
Outside
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 20 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Redundant Firewall Designs
As 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.
FIGURE 2-4
Redundant firewall design Inside Perimeter
Web/Mail Server
Outside
Internet
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 Designs
Firewalls 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 21 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Remote IPsec users—Individual users accessing the corporate network with IPsec-encrypted sessions over the public 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.
NOTE
This design uses a restrictive policy for inside clients with no HTTP proxy. For a lessrestrictive policy or a policy with HTTP proxies, replace individual items in Table 2-7 with entries from the previous sections. The design also assumes that the organization does not offer public FTP service.
TABLE 2-7
Client Zone
Firewall Policy of a Complex Firewall
Server Zone Sessions Allowed
Inside VPN users VPN offices Inside VPN users VPN offices Inside VPN users VPN offices
Perimeter
ICMP echo HTTP to web servers SMTP to mail servers DNS to name servers ICMP echo HTTPS to e-commerce servers ICMP echo, HTTP, HTTPS, FTP
E-commerce
Outside
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 22 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
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.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 2-7
Client Zone
Firewall Policy of a Complex Firewall
Server Zone Sessions Allowed
continued
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 servers HTTPS, SSH, FTP, and SNMP to all servers All services granted to inside users Additional services if needed All (to support remote users) All (to support remote offices) SMTP to internal e-mail server Minimum set of ICMP traffic DNS SMTP SQL transactions Access to a subset of internal servers RADIUS from VPN concentrator to authentication server IPsec traffic (ISAKMP + ESP) Access to a less-restricted set of internal servers RADIUS from VPN concentrator to authentication server IPsec traffic (ISAKMP + ESP)
Administrators Administrators Administrators Administrators Perimeter Perimeter E-commerce VPN users Outside VPN offices Outside
E-commerce Outside VPN users VPN offices Inside Outside Inside Inside VPN users Inside VPN offices
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 23 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Such a complex firewall is almost always implemented with multiple devices to improve its resiliency and reduce the complexity 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.
E-commerce
FIGURE 2-5
Complex firewall design
Web/Mail Server Administrators
Outside
Internet
Inside
Perimeter
VPN Users
VPN Offices
Reducing the Complexity of Advanced Firewalls
As 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 24 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
FIGURE 2-6
Decomposed complex firewall
E-commerce Firewall Perimeter Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
E-commerce
Internet Perimeter Firewall VPN Users
VPN Firewall Inside and Administrators VPN Offices Encrypted
NOTE
The firewall design is further simplified by the intended traffic flow: Traffic from VPN users first enters the inside network and is then additionally screened by the perimeter firewall.
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” and Figure 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 25 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Summary
In this chapter, you have seen how you can use zone-based firewall design principles to design a variety of firewall solutions, 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 26 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER THREE
Configuring Zone-Based Policy Firewalls in Cisco IOS
In 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 addressing scheme used in the examples.
FIGURE 3-1
Sample firewall with addressing
10.0.0.2 10.0.0.3 dns.isp.com 172.16.0.1 smtp.isp.com 172.16.0.2
Initial Zone-Based Policy Firewall Configuration ................................30 Limiting Inside-toOutside Traffic.............................................37 Protecting the Router.................................43 Monitoring and Debugging Zone-Based Policy Firewall Configuration ....................47
172.16.10.32/28
10.0.0.0/24 10.0.0.1 192.168.201.6
Internet
www.web.com 172.18.25.10
Inside
Outside
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 27 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 the Network 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.
NOTE
The configuration in Listing 3-1 is slightly abridged. (For example, vty and console configuration has been removed.) It has also not been properly secured. (For example, Finger and HTTP are enabled, and Telnet is used rather than SSH.)
LISTING 3-1
!
Initial Router Configuration
hostname fw service finger ! ip dhcp pool LAN network 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.0 ip nat inside ! interface Serial0/0/0 no ip address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 28 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
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.
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, because the potential intruder can reach only one IP host (the router itself).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 29 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 telnet finger http 23/tcp open 79/tcp open 80/tcp open
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: (The 1671 ports scanned but not shown below are in state: closed) PORT STATE SERVICE telnet finger http 23/tcp open 79/tcp open 80/tcp open
Interesting ports on 172.16.10.34: (The 1668 ports scanned but not shown below are in state: closed) PORT 135/tcp STATE SERVICE open msrpc
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 30 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-3
139/tcp 445/tcp
External Port Scan with Active NAT Translations
open open netbios-ssn microsoft-ds ms-term-serv vnc-http vnc
continued
3389/tcp open 5800/tcp open 5900/tcp open
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. NOTE
Class map definitions are mandatory unless you want to rely on the system-defined classdefault class, which matches all traffic.
Use the new zone security command to define the zones in your firewall. (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). 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). Use the zone-pair security command to apply a predefined firewall policy to a pair of source (client) and destination (server) zones. After the firewall policy is configured, assign the router interfaces to various security zones by using the zone-member security interface configuration command.
Step 2.
Step 3. Step 4. Step 5.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 31 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 appropriate 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 zonebased 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 32 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Configuring Security Zones
Our example has two security zones: inside and outside. Listing 3-4 shows the configuration commands used to create them. To help network administrators understand the router configuration, you can assign a description to each zone with the description zone configuration command.
LISTING 3-4 Creating Zones
zone security Inside description Inside network zone security Outside description Outside network
Configuring Firewall Policy
NOTE
Class default is always the last class in a policy map. It thus applies only to traffic not covered by other class maps.
The firewall policy in our design is very simple: All traffic is allowed from the inside zone to the outside zone, so we can use the class-default (match all) traffic class in the policy-map command. Similar to other modular CLI constructs in Cisco IOS, you have to specify what to do with the traffic matching the desired traffic class. You have the following options:
■
Pass the packets. This action is equivalent to an access-list permit statement and is thus unidirectional. There is no provision for return traffic, so you have to specify the handling of return traffic manually. This option is useful only for protocols such as IPsec-encrypted traffic. Inspect the packet. This action is equivalent to the functionality of the ip inspect command of the Cisco IOS Firewall Stateful Inspection feature. It automatically provides conduits for return traffic and potential ICMP messages. For protocols requiring multiple parallel signaling and data sessions (for example, FTP or H.323), the inspect action also handles the proper establishment of data sessions.
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 33 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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 destination 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.
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.
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 Zones
After 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 34 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-6
Initial Zone-Based Policy Firewall Configuration
policy-map type inspect InsideToOutside class class-default inspect ! zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 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 internal hosts 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 35 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-7
Scanning the Protected LAN from the Outside
External$ nmap --system-dns 172.16.10.32/28 Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-07-29 23:41 Interesting ports on 172.16.10.33: (The 1671 ports scanned but not shown below are in state: closed) PORT STATE SERVICE telnet finger http 23/tcp open 79/tcp open 80/tcp open
Nmap finished: 16 IP addresses (1 host up) scanned in 64.964 seconds Raw packets sent: 2581 (112.944KB) | Rcvd: 1677 (77.142KB)
On the other hand, a simple test (Listing 3-8) proves that the inside clients can reach any service or server on the Internet.
LISTING 3-8 Scanning an External Web Server from the Inside
Inside$ nmap -v --system-dns web.com Interesting ports on web.com (172.18.25.10): (The 1663 ports scanned but not shown below are in state: closed) PORT 21/tcp 25/tcp 80/tcp 135/tcp 139/tcp 443/tcp 445/tcp STATE SERVICE open open open open open open open ftp smtp http msrpc netbios-ssn https microsoft-ds LSA-or-nterm
1026/tcp open
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 36 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-8
Scanning an External Web Server from the Inside
ms-term-serv vnc-http vnc
continued
3389/tcp open 5800/tcp open 5900/tcp open
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 connections (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 connections (50) exceeded for host 172.18.25.10. 00:42:48: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connections (50) exceeded for host 172.18.25.10. 00:42:53: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connections (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 Summary
In this section, we have used the commands summarized in Table 3-1 to create an initial firewall configuration.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 37 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 3-1
Basic Zone-Based Policy Firewall Configuration Commands
Description
Command Syntax
zone security name description text policy-map type inspect name class name class class-default inspect
Creates a new security zone. Optionally assigns a description to the selected security zone. Creates a new policy map or starts configuration of the existing policy map. The type inspect keywords are mandatory. Within a policy map, starts configuring firewall actions for the specified traffic class. 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. 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). Within a traffic class configuration, permits traffic. You have to make manual provisions for return traffic handling. Drops the packets of the selected traffic class with optional logging to the router’s log. Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a specified maximum burst size.
pass drop [log] police rate bps burst burst-size
Limiting Inside-to-Outside Traffic
In 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 ZoneBased Firewall Designs”). To reach that goal, we first have to define the traffic classes that will later be used in the
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 38 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
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) protocols. Those class maps are called Layer 7 class maps and are covered in a later section.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
policy-map commands to define the desired firewall policy. The traffic classes are defined with the well-known classmap 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
Description
Command syntax
class-map type inspect [match-all | match-any] name match access-group {ACL-number | name ACL-name} match protocol {tcp | udp | icmp} match protocol protocol-name
Starts configuration of the named class map. The traffic matched by the class map has to 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). Matches traffic permitted by the specified access group. You can use numbered or named IP access lists. Matches any packet of the specified Layer 4 protocol. 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. Matches traffic specified by a previously defined class map. This command is useful when you 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. Matches all traffic not matching the specified condition.
match class-map name
match not condition
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 39 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 http match protocol ftp match protocol icmp match 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 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 ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 40 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 41 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-12
Final Simple LAN-to-Internet Firewall Configuration
continued
zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip nat inside zone-member security Inside ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252 ip nat outside zone-member security Outside ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 42 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 21/tcp 53/tcp 80/tcp STATE open open open SERVICE ftp domain http
Interesting ports on smtp.isp.com (172.16.0.2): (The 1669 ports scanned but not shown below are in state: filtered) PORT 25/tcp 53/tcp 110/tcp STATE open open open SERVICE smtp domain 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): (The 1671 ports scanned but not shown below are in state: filtered) PORT 21/tcp 80/tcp STATE SERVICE open open ftp http https
443/tcp open
Nmap finished: 1 IP address (1 host up) scanned in 26.047 seconds
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 43 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 Router
The 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 in the 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 inspection does. Therefore, special precautions must be taken to ensure that there are no undesired side effects from applying 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 44 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
IMPORTANT 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 cannot originate 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 Protection
NOTE
A more complex router protection policy will be developed in the next chapter. A more securityconscious environment would also not allow full access from the router to the inside network.
Common 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 45 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 permit icmp any any echo ! 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 self service-policy type inspect OutsideToRouter ! ip access-list extended ManagementProtocols permit tcp any any eq telnet permit tcp any any eq 22 ! ssh
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 46 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-16
Protecting the Router with the Self Zone
! https
continued
permit tcp any any eq www permit tcp any any eq 443 permit icmp any any echo ! 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-default inspect ! 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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 47 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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): (The 1671 ports scanned but not shown below are in state: filtered) PORT 23/tcp 80/tcp STATE open open SERVICE telnet http
443/tcp closed https Nmap finished: 1 IP address (1 host up) scanned in 22.552 seconds
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 Nmap finished: 1 IP address (1 host up) scanned in 71.533 seconds
Monitoring and Debugging Zone-Based Policy Firewall Configuration
As with every Cisco IOS features, a number of show and debug commands are available to network administrators to monitor 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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 48 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-19
zone self
Show Zone Security Command Displays Zones and Associated Interfaces
s fw#show zone security 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 specified 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
s 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 49 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
WARNING
The per-protocol traffic counters displayed in the show policy-map type inspect zone-pair command can be misleading. 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 the data transferred in the FTP data sessions.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 30 second rate 0 bps Match: protocol icmp 1 packets, 40 bytes 30 second rate 0 bps Match: protocol https 0 packets, 0 bytes 30 second rate 0 bps 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:13 Last statistic reset never Last session creation rate 1 Last half-open session total 0 … printout repeated for other classes of traffic …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 50 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
s 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 30 second rate 0 bps Match: protocol ftp 3 packets, 84 bytes 30 second rate 0 bps Match: protocol icmp 1 packets, 40 bytes 30 second rate 0 bps Match: protocol https 0 packets, 0 bytes 30 second rate 0 bps 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 …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 51 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
A few debugging command also support the zone-based policy firewall feature:
■ ■
The debug zone security command is focused on zone security events (for example, interface assignments). The debug ip inspect policy command gives you an in-depth view of individual packet classification. Listing 3-22 shows a printout associated with a single TCP SYN packet trying to open a Finger session to the router.
Output of the debug ip inspect policy Command
WARNING
Use debug ip inspect policy only on a lightly loaded router in a controlled environment (preferably with no logging to the router console); otherwise, you might easily overload its CPU.
LISTING 3-22
00:36:29: CBAC-C3PL : Policy lookup for pak 0x4716467C [insp_c3pl_policy_lookup] 00:36:29: CBAC-C3PL : input i/f is FastEthernet0/0, output i/f is NULL [insp_c3pl_validate_zoning] 00:36:29: CBAC-C3PL : Zone-pair and policy found [insp_c3pl_validate_zoning] 00:36:29: CBAC-C3PL : Packet L7 protocol is 59 L4 prot is 1 [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class RouterManagement [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class class-default [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Packet(0x4716467C) matched with class class-default [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Classification returned protocol-id 0x0 classid 0 [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : DROP action found in policy-map [insp_c3pl_process_actions_of_class] 00:36:29: CBAC-C3PL : Action processing returned code 1. [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : classify processing returned 1 [insp_c3pl_policy_lookup]
Furthermore, because the zone-based firewall policy feature is closely linked to the Context-Based Access Control (CBAC) code, many debug ip inspect commands work as expected. For example, you might debug DNS and FTP inspection, resulting in the following printout when a user opens an FTP session from the inside to the outside zone (Listing 3-23).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 52 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-23
Debugging FTP and DNS Sessions
d fw#debug ip inspect dns INSPECT DNS Inspection debugging is on d 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
Summary
In 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 53 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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 policy on 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 improving 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.
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 54 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER FOUR
Case Study: Firewall with a Perimeter Network
In 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
Client 10.0.0.2 Mail Server 10.0.0.10
Configuring the Firewall Policy .............................................56 Protecting the Router ....................................................60
Outside
Internet
Inside
10.0.0.1
192.168.0.1
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 55 ]
CHAPTER 4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Case Study: 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:
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.
■
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 Router
NOTE
You need to remove the previous NAT pool definition before redefining it.
interface 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 28 ip nat inside source static 192.168.0.2 172.16.10.34
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 56 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Configuring the Firewall Policy
The 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).
NOTE
Within this case study, we optimize the class definitions by grouping similar protocols in the same traffic class. When deploying applicationlevel 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 configuring the router.
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 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 !
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 57 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-2
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 troubleshooting 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 58 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-3
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 permit ip any host 192.168.0.2
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).
NOTE
The configuration of service policies and zone pairs seems highly verbose. You will see where you can benefit from this modularity when configuring morecomplex firewall policies later in this chapter.
LISTING 4-4
Firewall Policies and Zone Definitions
zone security Inside zone security Perimeter zone security Outside ! policy-map type inspect InsideToOutside 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 PerimeterToOutside class type inspect DNS
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 59 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-4
inspect class type inspect SMTP inspect class type inspect ping inspect ! policy-map type inspect OutsideToPerimeter class type inspect PublicTraffic inspect ! policy-map type inspect PerimeterToInside class type inspect MailDelivery inspect !
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall Policies and Zone Definitions
continued
zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside 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 ! interface FastEthernet0/0 description Inside LAN zone-member security Inside !
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 60 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall Policies and Zone Definitions
continued
interface FastEthernet0/0.100 description Perimeter network zone-member security Perimeter ! interface Serial0/0/0.100 point-to-point description Link to the Internet zone-member security Outside
Protecting the Router
NOTE
There might be additional public services the router itself needs to access (for example, the Network Time Protocol [NTP] service).
We 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 connectionestablishment 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.
NOTE
Note that the same policy map is used twice to specify firewall policies between the router and the outside and perimeter zones.
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 outbound firewall policy. (IP access list IcmpEcho is defined in Listing 4-2.)
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 61 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-5
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 class type inspect ping 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 62 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-6
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 management with SNMP while the router would send syslog, TFTP, and FTP traffic to the internal server. However, because
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 63 ]
CHAPTER 4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Case Study: 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 this problem:
■
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 internal server.
■
■
Listing 4-7 shows the configuration commands defining the firewall policy between the firewall router and the inside network.
LISTING 4-7
! ! 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
Securing Inside Access to the Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 64 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-7
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Securing Inside Access to the Router
continued
policy-map type inspect InsideToRouter class type inspect ping 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 permit tcp host 10.0.0.1 host 10.0.0.10 eq www permit tcp host 10.0.0.1 host 10.0.0.10 eq 443 permit udp host 10.0.0.1 host 10.0.0.10 eq snmp ! policy-map type inspect RouterToInside class type inspect RouterPublicTraffic inspect class type inspect RouterDataTransfer ! SSH/SCP ! Web (http) ! SSL (https) ! SNMP traps
permit udp host 10.0.0.1 host 10.0.0.10 eq syslog ! SYSLOG messages
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 65 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-7
inspect ! zone-pair security RouterToInside source self destination Inside service-policy type inspect RouterToInside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Securing Inside Access to the Router
continued
Summary
In this chapter, you’ve seen how you can use the basic configuration commands supported by the zone-based policy firewall 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 configuration 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 66 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER FIVE
Advanced Zone-Based Policy Firewall Configuration
In 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 ....................................................67 Tuning Denial-ofService Protection ......................................70 Identifying Masquerading Applications .................................................74 Application Layer Packet Inspection .......................................79 HTTP Packet Inspection ....................................................86 Configuring User-Defined Protocols .............................90
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 finetune its configuration.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 67 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Tuning the Stateful Inspection
The 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
Description
Command Syntax
parameter-map type inspect name alert on | off audit-trail on | off inspect parameter-map-name
Creates or modifies the specified parameter map. Enables or disables syslog alerts (default: on). Enables or disables a session audit trail written to the router’s log (default: off). 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 68 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
FIGURE 5-1
Audit trail of inbound SMTP sessions Inside
Syslog Alert External Mail Server 172.18.25.10 Inbound SMTP Session
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Client 10.0.0.2
Internal Server 10.0.0.10
Outside Internet
Web/Mail Server 192.168.0.2
Perimeter
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.
WARNING
Do not delete and recreate a policy map as you would do with an access list. Deleting a policy map silently removes all references to it, thus potentially modifying your router configuration.
■
Listing 5-1 includes the step-by-step configuration process.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 69 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-1
c fw#conf t
Configuring the Audit Trail of Inbound SMTP Sessions
End with CNTL/Z
Enter configuration commands, one per line. c fw(config)#class-map type inspect PublicSMTP m fw(config-cmap)#match class-map SMTP
m fw(config-cmap)#match access-group name ExternalServer e fw(config-cmap)#exit p fw(config)#parameter-map type inspect audit a fw(config-profile)#audit-trail on e fw(config-profile)#exit p fw(config)#policy-map type inspect OutsideToPerimeter n fw(config-pmap)#no class type inspect PublicTraffic c fw(config-pmap)#class type inspect PublicSMTP i fw(config-pmap-c)#inspect audit c fw(config-pmap-c)#class type inspect PublicTraffic i 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 70 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Half-open TCP connections are connections where the SYN packet has been received, but the first non-SYN packet hasn’t been seen yet.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Tuning Denial-of-Service Protection
The 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 parametermap syntax is described in Table 5-1.) Remember that all parameters apply to a single traffic class between a pair of zones.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 71 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 5-2 alert on | off
Configuring Inspect Thresholds
Description
Command Syntax
Enables or disables syslog alerts (default: on). Enables or disables the session audit trail written to the router’s log (default: off). Configures the maximum number of sessions in this traffic class. Configures the maximum time between the DNS query and response packet. Configures the maximum time between ICMP request and reply. Configures the threshold at which the Cisco IOS firewall starts the DoS protection (high parameter) 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. Configures the per-minute session establishment threshold that triggers the DoS protection. The process starts after the high threshold has been exceeded and stops when the session establishment rate drops below the low threshold. Configures the maximum number of half-open sessions from a single IP host. The offending host could be (optionally) blocked for the specified duration. Configures TCP timers—the maximum time between packets in session establishment, the maximum time between packets in session termination and the session idle timer. Configures the idle timer for non-DNS UDP sessions.
audit-trail on | off sessions maximum number dns-timeout seconds icmp idle-timeout seconds max-incomplete high number | low number one-minute high number | low number tcp max-incomplete host threshold [ block minutes ] tcp synwait-time seconds tcp finwait-time seconds tcp idle-time seconds udp idle-time seconds
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 72 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-3
Default Stateful Packet Inspection Thresholds
s 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-second DNS 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 idletimeout can also be reduced unless you have very slow-speed congested links.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 73 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
After you have adapted the timeouts to your environment, perform the following steps to fine-tune the half-open session thresholds:
Step 1. Step 2.
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.) 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 protection. (The alert message indicates the policy map and the class within it.) After a statistically significant time period (at least a day), review the inspect counters (see Listing 5-4).
Displaying Session Inspection Parameters of a Zone Pair
Step 3.
LISTING 5-4
s 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 …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 74 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Step 4.
Set the max-incomplete low parameter to the Maxever session counts half-open value. Set the maxincomplete high parameter to a value at least 25 percent above that. Increase the parameter to an even higher value if you expect a significant increase in network traffic (for example, increased website traffic due to a marketing campaign). The Cisco IOS printout gives you no reliable information that would allow you to set the one-minute thresholds. 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. Repeat the process for every traffic class that needs adjusted DoS protection behavior. 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.
NOTE
Server logs are an extremely valuable resource in the tuning process. Computing oneminute session establishment rate from a web server log is a simple exercise.
Step 5.
Step 6. Step 7.
Identifying Masquerading Applications
Some 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 Started
Myhost $ netstat Active Connections Proto TCP TCP Local Address myhost:1938 myhost:1957 Foreign Address cs31.msg.dcn.yahoo.com:5050 sip34.voice.re2.yahoo.com:5061 State ESTABLISHED ESTABLISHED
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 75 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-6
Yahoo Messenger Port Usage After Ports 5050 and 5061 Were Disabled on the Firewall
Myhost $ netstat Active Connections Proto TCP TCP Local Address myhost:1988 myhost:2005 Foreign Address cs31.msg.dcn.yahoo.com:telnet sip38.voice.re2.yahoo.com:https State ESTABLISHED 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 the firewall policy
Client 10.0.0.2
scs.msg.yahoo.com:5050
Unknown application, dropped
Outside
STOP
scs.msg.yahoo.com:80
Yahoo Server
Inside
Looks like web browsing, passed
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 76 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The masquerading applications fall into two categories:
■
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. 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).
Some peer-to-peer applications
■
Cisco IOS can identify both types of applications starting in Release 12.4(9)T.
Identifying Peer-to-Peer Applications
To 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 77 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Identifying Instant Messaging Applications
Instant 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
Description Command Syntax
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.
parameter-map type protocol-info name server {name name | ip address} server ip range start end
Creates or modifies the specified parameter map Specifies a single server by its name or IP address 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-topeer 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 78 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
If you want to disable access to Yahoo Messenger in our sample firewall from Chapter 4, you have to augment the InsideToOutside policy map with the commands from Listing 5-9.
LISTING 5-9 Disable Yahoo Messenger in the Sample Firewall
policy-map type inspect InsideToOutside 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 classification 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.
protocol-info-Related show Commands
LISTING 5-10
s fw#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 s 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 Number of IP Addresses: 2
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 79 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-10
protocol-info-Related show Commands
(0D:00H:00M)
continued
68.142.194.14, 68.142.231.252 Application im-yahoo.
Server DNS Name: ‘sip.yahoo.com’.
Updates: 0 failed, 2 succeeded, next after 3.086 secs Number of IP Addresses: 8 68.142.233.179 68.142.233.181 68.142.233.183 68.142.233.177 (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) 68.142.233.180 68.142.233.182 68.142.233.176 68.142.233.178 (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) (0D:00H:00M)
Application Layer Packet Inspection
In 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.
■ ■ ■
■ ■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 80 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
All application layer inspections are configured using application-specific class maps and policy maps that are then 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
WORD aol edonkey fasttrack gnutella http imap kazaa2 match-all match-any msnmsgr pop3 smtp sunrpc ymsgr
Application Layer Protocol Inspection in Cisco IOS Release 12.4(9)T
class-map name Configure CBAC class-map for IM-AOL protocol eDonkey FastTrack Traffic - KaZaA, Morpheus, Grokster... Gnutella Version2 Traffic - BearShare, Shareeza, Morpheus ... Configure CBAC class-map for HTTP protocol Configure CBAC class-map for IMAP protocol Kazaa Version 2 Logical-AND all matching statements under this classmap Logical-OR all matching statements under this classmap Configure CBAC class-map for IM-MSN protocol Configure CBAC class-map for POP3 protocol Configure CBAC class-map for SMTP protocol Configure CBAC class-map for RPC protocol Configure CBAC class-map for IM-YAHOO protocol
c fw(config)#class-map type inspect ?
NOTE
The match commands available in the class map configuration are protocol-specific; you can find a detailed list in the Cisco IOS documentation. The extensive set of HTTP match commands is described in the next section.
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 81 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-12
WORD http im imap p2p pop3 smtp sunrpc
Configuring the Application Layer Policy Map
policy-map name Configure CBAC policy-map for HTTP protocol Configure CBAC policy-map for IM protocol Configure CBAC policy-map for IMAP protocol Configure CBAC policy-map for P2P protocols Configure CBAC policy-map for POP3 protocol Configure CBAC policy-map for SMTP protocol Configure CBAC policy-map for RPC protocol
p fw(config)#policy-map type inspect ?
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).
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 require stateful 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 82 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Some of these issues could be solved with other mechanisms. For example, peer-to-peer services could be prohibited, and secure POP3 and IMAP could be deployed instead of forcing the users to use non-clear-text authentication on regular POP3/IMAP sessions.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Packets not matched by any class in a Layer 4 policy map are handled by class-default. If no action is specified in class-default, these packets are dropped. Packets not matched by an application layer policy map are not dropped but are handled according to the specifications of the parent policy map.
Application Layer Packet Inspection Example
Let’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 MP3 files 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).
No cleartext POP3 authentication
Client POP3 USER command POP3 APOP command
FIGURE 5-3
Simple LAN-toInternet firewall
Outside
STOP
pp3.isp.com 172.16.0.2
10.0.0.0/24
Inside
10.0.0.1
192.168.201.6
Internet
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 83 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Inspect class maps have to be configured to match individual protocols for which we want to perform DPI (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.
Application-Level Inspection of E-mail–Related Protocols
■
LISTING 5-13
match match !
class-map type inspect imap match-any imapMail invalid-command 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 match ! policy-map type inspect pop3 pop3Policy class type inspect pop3 pop3Mail reset log ! class-map type inspect smtp match-any smtpMail match ! data-length gt 5000000 invalid-command login clear-text
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 84 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-13
Application-Level Inspection of E-mail–Related Protocols
continued
policy-map type inspect smtp smtpPolicy class type inspect smtp smtpMail reset
LISTING 5-14
match !
Application-Level Inspection of Peer-to-Peer Traffic
class-map type inspect gnutella match-any noMP3gnutella file-transfer mp3
class-map type inspect fasttrack match-any noMP3fasttrack match ! class-map type inspect edonkey match-any noMP3edonkey match match ! class-map type inspect kazaa2 match-any noMP3kazaa match ! policy-map type inspect p2p noMP3transfer class type inspect edonkey noMP3edonkey log reset class type inspect fasttrack noMP3fasttrack log reset class type inspect gnutella noMP3gnutella log reset file-transfer mp3 file-transfer mp3 search-file-name mp3 file-transfer mp3
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 85 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-14
log reset
Application-Level Inspection of Peer-to-Peer Traffic
continued
class type inspect kazaa2 noMP3kazaa
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 signature match protocol kazaa2 signature match protocol fasttrack signature
LISTING 5-16
Inside-to-Outside Firewall Policy
policy-map type inspect InsideToOutside class type inspect peer2peer inspect service-policy p2p noMP3transfer class type inspect getMail inspect service-policy pop3 pop3Policy class type inspect readMail
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 86 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-16
inspect
Inside-to-Outside Firewall Policy continued
service-policy imap imapPolicy class type inspect sendMail inspect service-policy smtp smtpPolicy class class-default inspect
HTTP Packet Inspection
NOTE
HTTP packet inspection works only on nonencrypted HTTP sessions. If the data exchange takes place over Secure Sockets Layer (SSL, also known as HTTPS), the firewall cannot inspect the packet content.
Cisco 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).
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 87 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The match commands that you can use in the class-map type inspect http command follow these rules:
■
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.
Matching HTTP Requests and Responses
Description
■ ■
■
■
TABLE 5-4
Command Syntax
match request uri regex name match request arg regex name match request method http-method-name match request port-misuse im | p2p | tunneling | any match response status-line regex name
Matches the web address (URI) with a regular expression Matches the HTTP request arguments with a regular expression Matches the HTTP method in the request (GET, POST …) Identifies potential misuses of HTTP by tunneling, peer-to-peer, or instantmessaging applications Matches the status of the HTTP response (for example, 200 = OK, 403 = forbidden, 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 88 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 5-5
Configuring Regular Expression Parameter Maps
Description
Command Syntax
parameter-map type regex name pattern regex
Creates a new regular expression parameter map. 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 improved in 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 89 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■ ■
class-map anyOtherHttp matches all HTTP traffic, effectively replacing the class-default. policy-map validHttp defines the HTTP inspection policy. The TCP session is reset when a port misuse is detected or when the HTTP request method does not match one of the allowed methods. A new inspect class-map is defined to match the HTTP traffic and is appended at the end of the existing InsideToOutside policy map (just in front of the class-default line).
Implementing Simple HTTP Inspection
■
NOTE
Adding an unrelated condition (for example, allowing only the three request methods and only the content types text/* and image/*) would result in a large set of class maps and a complex policy map, because you would have to match each combination of method and content type individually with a separate match-all class map and then list all of them in the policy map.
LISTING 5-17
match match match !
class-map type inspect http match-any validHttpCommands request method get request method post request method head
class-map type inspect http match-any httpPortMisuse match request port-misuse any ! class-map type inspect http match-any anyOtherHttp ! policy-map type inspect http validHttp class type inspect http httpPortMisuse reset log class type inspect http validHttpCommands allow class type inspect http anyOtherHttp reset ! class-map type inspect match-any httpTraffic match protocol http
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 90 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-17
!
Implementing Simple HTTP Inspection
continued
policy-map type inspect InsideToOutside class type inspect httpTraffic inspect service-policy http validHttp
Configuring User-Defined Protocols
In 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-4
Proxy access to external web server
Client 10.0.0.2
Outside Internet
Re qu es to n po
Inside
Re
es qu
80 or t External Web Server np 172.18.25.10 to
Perimeter
rt 80 80
Proxy Web Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 91 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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
Description
Command Syntax
ip port-map user-protocol-name port {tcp | udp} port-number ip port-map protocol port {tcp | udp} port-number
Specifies port usage for a user-defined protocol. The protocol name must start with the userprefix to ensure there is no overlap with future protocol additions to Cisco IOS. Specifies a nonstandard TCP or UDP port for a protocol recognized by Cisco IOS.
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
! class-map type inspect match-all proxyhttp match protocol user-proxyhttp ! policy-map type inspect InsideToPerimeter class type inspect proxyhttp inspect class type inspect ping inspect ! matches TCP port 8080 ! cannot use HTTP service policy
Configuring a User-Defined Protocol
ip port-map user-proxyhttp port tcp 8080
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 92 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Adding TCP or UDP ports to standard protocols with the ip portmap command affects other Cisco IOS features that use the port map functionality (for example, Network-Based Application Recognition [NBAR]).
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 standard 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
! class-map type inspect match-all web match protocol http ! policy-map type inspect InsideToPerimeter class type inspect web inspect class type inspect ping inspect ! matches TCP port 80 and port 8080 ! can use HTTP service policy
Configuring Additional Port Numbers for a Standard Protocol
ip port-map http port tcp 8080
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 93 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Summary
In this chapter, you’ve seen how you can use advanced configuration commands of the zone-based policy firewall configuration 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 applications. 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.
■ ■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 94 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER SIX
Configuring Transparent Firewalls
Cisco IOS Release 12.3(7)T introduced the transparent firewall feature: the ability to filter IP traffic between a pair of bridged interfaces. This feature is fully supported by the new zone-based configuration 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 introduced in Chapter 4, “Case Study: Firewall with a Perimeter Network” (Figure 6-1).
FIGURE 6-1
Physical firewall structure
Client 10.0.0.2
Protecting Internal Servers: Alternate Design .......................103 Case Study: Migrating a Server to the Perimeter Network...........106
Perimeter VLAN 518
Web/Mail Server 192.168.0.2
Outside
Inside VLAN 516
Internet
Server 10.0.0.10
Inside VLAN 517
VLAN trunk
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 95 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Our organization has built a switched LAN network with all clients and servers residing in one IP subnet. It has successfully 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 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 intermingled 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
NOTE
It’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 configuration. However, if your router has a single physical LAN interface, that might be the only solution.
interface FastEthernet0/0 description Trunk to the LAN switch ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN ! interface FastEthernet0/0.100 encapsulation dot1Q 518 description Perimeter VLAN
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 96 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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:
Step 1. Step 2. Step 3. Step 4. Step 5.
Enable integrated routing and bridging with the bridge irb command. Create a bridge group and specify its spanning tree protocol with the bridge number protocol protocol command. Assign all bridged interfaces into the bridge group with the bridge-group number command. Configure IP routing for the bridge group with the bridge number route ip command. Configure a virtual IP interface representing the router’s attachment to the bridge group with the interface bvi number command.
NOTE
For the remainder of the router configuration, including Network Address Translation (NAT) configuration, see Chapter 4.
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
bridge irb ! interface FastEthernet0/0.1 bridge-group 1 ! interface FastEthernet0/0.5 bridge-group 1 ! interface FastEthernet0/0.100 ip address 192.168.0.1 ip nat inside
IRB and IP Configuration of the Firewall Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 97 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-2
!
IRB and IP Configuration of the Firewall Router
continued
interface BVI1 ip address 10.0.0.1 255.255.255.0 ip nat inside ! bridge 1 protocol ieee bridge 1 route ip
FIGURE 6-2
Logical structure of the firewall router
FastEthernet 0/0.1
10.0.0.0/24 VLAN 516
BVI 1
192.168.0.0/24
FastEthernet 0/0.100
VLAN 517
Serial 0/0.100
Firewall Router
192.168.201.4/30
FastEthernet 0/0.5
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 98 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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.
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), and then 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 Inside zone security Clients zone security Servers ! class-map type inspect match-any Exchange match protocol msrpc match protocol imap match protocol imaps match protocol pop3 match protocol pop3s match protocol smtp match protocol ldap match protocol ldaps ! class-map type inspect match-any Netbios
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 99 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-3
Zone Assignments of the Inside Physical and Logical Interfaces
continued
match protocol netbios-ns match protocol netbios-ssn match protocol netbios-dgm ! class-map type inspect match-any SQLServer match protocol ms-sql ! policy-map type inspect ServerTraffic class type inspect SQLServer inspect class type inspect Netbios inspect class type inspect Exchange inspect class class-default drop ! zone-pair security ClientsToServers source Clients destination Servers service-policy type inspect ServerTraffic ! interface FastEthernet0/0.1 zone-member security Clients ! interface FastEthernet0/0.5 zone-member security Servers ! interface BVI1 zone-member security Inside
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 100 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 arriving through 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).
FIGURE 6-3
Resulting firewall structure
Clients VLAN 516
BVI 1
Perimeter 192.168.0.0/24
FastEthernet 0/0.100
Inside 10.0.0.0/24
Serial 0/0.100
Servers VLAN 517
Outside 192.168.201.4/30
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 101 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 requirements 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 firewall) degrades the concept of security zones to the complexity of building firewalls with IP access lists (most obvious in the InsideToPerimeter policy map).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 102 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-4
Modified Firewall Policy for the Inside-to-Perimeter Zone Pair
class-map type inspect match-all MailFromInside match protocol smtp 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.10 permit ip host 10.0.0.10 any ! policy-map type inspect InsideToOutside class type inspect AllServerTraffic drop class type inspect WebTraffic inspect class type inspect FileTransfer inspect ! policy-map type inspect InsideToPerimeter class type inspect MailFromInside inspect class type inspect AllServerTraffic drop class type inspect PublicTraffic inspect class type inspect PublicManagement inspect ! defined in Chapter 4 ! defined in Chapter 4
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 103 ]
CHAPTER 6 Configuring Transparent Firewalls
NOTE
Adding a second firewall in the inside network also slightly increases the security of the solution (defense-in-depth principle); if an intruder gains access to the outside firewall or breaks through its defenses, the internal firewall still protects the servers.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Protecting Internal Servers: Alternate Design
The previous discussion of the transparent firewall behavior might have led you to believe that it has only marginal 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 is still 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 interVLAN 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).
Administrators Outside
FIGURE 6-4
Second firewall added to the LAN network—physical connectivity diagram
Internet
Servers Perimeter Inside Clients
Web/Mail Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 104 ]
CHAPTER 6 Configuring Transparent Firewalls
FIGURE 6-5
Bridging loop in the redesigned network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
VLAN 515 Administrators
Inside Router
VLAN 516 Clients
Firewall Router
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.
FIGURE 6-6
Final firewall structure—logical connectivity diagram
Administrators
Outside
Internet
Servers Perimeter Inside Clients
Web/Mail Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 105 ]
CHAPTER 6 Configuring Transparent Firewalls
NOTE
When configuring firewall policies, do not forget that the administrators have to pass through the clients zone to get to the Internet.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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.
LISTING 6-5
bridge irb ! zone security Administrators zone security Servers zone security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN bridge-group 1 zone-member security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 515 description Administrators VLAN bridge-group 1 zone-member security Administrators ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN
Initial Configuration of the Inside Firewall
no ip routing
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 106 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-5
Initial Configuration of the Inside Firewall
continued
bridge-group 1 zone-member security Servers ! 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 Perimeter Network
In 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 renumbering 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 107 ]
CHAPTER 6 Configuring Transparent Firewalls
FIGURE 6-7
Initial network design
172.16.10.32/28 10.0.0.2 Public Server 10.0.0.20
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Outside
dns.isp.com 172.16.0.1
smtp.isp.com 172.16.0.2
10.0.0.0/24 10.0.0.1 192.168.201.6
Internet
www.web.com 172.18.25.10
Inside
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.
FIGURE 6-8
Firewall design using local area mobility
Client 10.0.0.2
Outside
Internet
Inside
10.0.0.1/24
10.0.0.20/32
10.0.1.1/24
Host route to public server
Public Server 10.0.0.20
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 108 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
hostname fw ! interface Loopback1 ip address 172.16.10.33 255.255.255.240 ! interface FastEthernet0/0 description Inside network ip address 10.0.0.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.5 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 address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252
NOTE
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.
Configuration of Inside Interfaces on the Firewall Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 109 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-6
Configuration of Inside Interfaces on the Firewall Router
continued
ip nat outside frame-relay interface-dlci 100 ! 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 Mobility
d fw#debug arp ARP packet debugging is on d fw#debug ip mobile local-area IP local-area mobility debugging is on fw#
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 110 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 s 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 interfaces. You can complete the configuration using zones, traffic classes, and policies similar to those in Chapter 4.
Summary
In 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 physical interface 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.
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 111 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■ ■
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 112 ]
Deploying Zone-Based Firewalls
Ivan Pepelnjak
Copyright© 2007 Cisco Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this digital short cut may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing October 2006 ISBN: 1-58705-310-1
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this digital short cut or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the digital short cut title and ISBN in your message. We greatly appreciate your assistance.
Corporate and Government Sales
Cisco Press offers excellent discounts on this digital short cut when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the U.S. please contact: International Sales [email protected]
Warning and Disclaimer
This digital short cut is designed to provide information about network security. Every effort has been made to make this digital short cut as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this digital short cut. The opinions expressed in this digital short cut belong to the author and are not necessarily those of Cisco.
Trademark Acknowledgments
All terms mentioned in this digital short cut that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco cannot attest to the accuracy of this information. Use of a term in this digital short cut should not be regarded as affecting the validity of any trademark or service mark.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
Deploying Zone-Based Firewalls
Ivan Pepelnjak
ciscopress.com
[2]
CHAPTER 1 Introduction
Deploying Zone-Based Firewalls by Ivan Pepelnjak
About the Author
Ivan 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 technologies 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 Editor
Randy 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 understand and 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[3]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER ONE
Introduction to ZoneBased Firewalls
In the mid-1990s, when the large corporate networks began to be connected 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.
NOTE
If you are not familiar with packet filters offered by the Cisco IOS, refer to the Cisco IOS Access Lists book available through Safari Books Online or to the relevant Cisco IOS documentation.
Simple ZoneBased Design.................................................4 More Complex Zone-Based Design.......................................5 Implementing Zone-Based Designs.....................................7
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 firewall policies, the concept of zone-based firewall design emerged.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[4]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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). 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. 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). 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.)
NOTE
Within the context of this discussion, server is any host that accepts incoming connections, regardless of its actual hardware or software implementation.
Step 2.
Step 3.
Step 4.
Simple Zone-Based Design
Consider, 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[5]
CHAPTER 1 Introduction to Zone-Based Firewalls
FIGURE 1-1
Simple firewall setup Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Internet
Inside
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 Design
NOTE
The actual interzone firewall policies for this design are described in the next chapter.
A 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[6]
CHAPTER 1 Introduction to Zone-Based Firewalls
FIGURE 1-2
Traditional firewall design
Web/Mail Server
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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.
Public
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 misconfigured or fails, the inside firewall still protects the internal network. Internet
Inner Router Outer Router
Internal
Perimeter
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
Server Zone (Hosts Terminating the Connections) Sessions Allowed
Client Zone (Hosts Originating the Connections)
Inside Outside
Outside Inside
Traffic from internal zone to perimeter and public zones Traffic from public and perimeter zones to internal zone
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[7]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Implementing Zone-Based Designs
As 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.
FIGURE 1-3
TCP session establishment across a packet-filtering device
Outside
10.0.0.2 From 10.0.0.2 port 1030 to 172.18.25.1 port 80 172.18.25.1
Internet
From 172.18.25.1 port 80 to 10.0.0.2 port 1030
Inside
?
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.)
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[8]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 NOTE
Cisco PIX, the Cisco standalone firewall appliance, was designed around the concept of conduits (old PIX terminology for traffic flows), which has from the beginning included the proper handling of return traffic. 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 for UDP 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[9]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 1-2
TCP and UDP Ports Opened on a Typical IP Host Running Windows XP
M:\>netstat -an Active Connections Proto Local Address TCP 0.0.0.0:80 TCP 0.0.0.0:135 TCP 0.0.0.0:443 TCP 0.0.0.0:445 TCP 0.0.0.0:990 TCP 0.0.0.0:1039 TCP 0.0.0.0:23598 TCP 127.0.0.1:1058 TCP 127.0.0.1:5679 TCP 127.0.0.1:7438 TCP 127.0.0.1:62514 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
Foreign Address 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:* *:*
State LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 10 ]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Even if the challenges of return TCP traffic are solved with smarter packet filters and the return UDP traffic is addressed with 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 Stateful Inspection). 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.
NOTE
CBAC support for ICMP was 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 release 12.4.
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 using the 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 ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip access-group fromInternet in ip inspect Internet out ! ip access-list extended fromInternet deny ip 10.0.0.0 0.0.0.255 any
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 11 ]
CHAPTER 1 Introduction to Zone-Based Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
After this configuration change, every session opened from an inside host to an outside server would also create a dynamic entry (pinhole) at the bottom of the outside access list. Because the CBAC also handles outbound ICMP traffic (pings and traceroutes) and ICMP responses associated with TCP or UDP sessions traversing the router, the fromInternet access list has been significantly reduced and now includes only a generic filter preventing address spoofing. The audit-trail option of the ip inspect command also generates the trail of TCP or UDP sessions in the router’s log, as illustrated in Listing 1-4.
LISTING 1-4 Audit Trail Generated by the Router
04:27:19: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session: initiator (10.0.0.2:1064) -- responder (172.18.25.1:80) 04:27:21: %FW-6-SESS_AUDIT_TRAIL_START: Start tcp session: initiator (10.0.0.2:1065) -- responder (172.18.25.1:80) 04:27:26: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator (10.0.0.2:1064) sent 307 bytes -- responder (172.18.25.1:80) sent 2850 bytes 04:27:27: %FW-6-SESS_AUDIT_TRAIL: Stop tcp session: initiator (10.0.0.2:1065) sent 345 bytes -- responder (172.18.25.1:80) sent 771 bytes
The introduction of CBAC has successfully addressed the shortcomings of packet filters, but it did not help improve the scalability of firewall implementations—the packet filters still have to be configured to operate between interfaces. In scenarios with multiple zones connected to a single networking device, this results in a serious drawback: Each packet filter has to contain a mixture of multiple firewall policies. (For example, if three zones are attached to a router, a packet filter applied on any interface has to filter traffic being sent into or received from two other zones.) Zone-based policy firewall, a new configuration feature introduced in Cisco IOS Release 12.4(6)T, solves this problem, too, finally allowing the implementation team to follow the zone-based design and specify the traffic permitted between zones.
Summary
In the next chapter, we focus first on typical firewall design scenarios, ranging from a simple small office/home office (SOHO) LAN to a complex corporate firewall. In the subsequent chapters, a number of case studies show how you can use the zone-based policy firewall feature to implement these designs on Cisco IOS-based networking devices.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 12 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER TWO
Typical Zone-Based Firewall Designs
NOTE
Network designers who are already familiar with the zone-based firewall design principles can skip this chapter and continue to the implementation section. All other readers are highly advised to read it, because a well-thoughtout and well-documented design almost always results in superior implementation.
Simple LAN-toInternet Firewall ..........................................12 Firewall with Public Servers .............................................15 Redundant Firewall Designs.........................................................20 Complex Firewall Designs.........................................................20 Reducing the Complexity of Advanced Firewalls ................................23
In the preceding chapter, you saw how the philosophy of firewall design has evolved from packet-filter-oriented designs toward zonebased 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-Internet Firewall
The simplest possible design is a protected LAN connected to the public IP network (for example, the Internet) through a firewall. No publicly 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 13 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Inside Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
FIGURE 2-1
Simple LAN-toInternet firewall Internet
Two firewall policies are commonly used in such setups:
NOTE
All the firewall policy tables in this book assume a stateful firewall implementation, so there are no special entries for the return packets.
■ ■
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 (for example, web and mail services)
Permissive Firewall Policy
Server Zone Sessions Allowed
TABLE 2-1
Client Zone
Inside Outside
Outside Inside
All 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 connectivity troubleshooting.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 14 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
NOTE
Most versions of Windows use ICMP to trace the path to the destination host. UDP packets as the trace packets are used by some UNIX environments (for example, Linux) as well as Cisco IOS.
■ ■
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Domain Name Service (DNS) on UDP port 53 has to be enabled; otherwise, the internal clients will not be able to resolve 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.
Restrictive Firewall Policy
Server Zone Sessions Allowed
■
TABLE 2-2 NOTE
TCP ports needed for FTP data sessions are identified automatically by the stateful firewall implementations. If you’re not using a stateful firewall, you need to allow TCP port 20, too, and advise the clients to use passive FTP. Client Zone
Inside
Outside
DNS (UDP port 53) to ISP’s name servers ICMP echo HTTP (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 None
Outside
Inside
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 15 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall with Public Servers
There 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 a fatal configuration error (defense-in-depth principle).
Inside Outside
FIGURE 2-2
Simple firewall with a perimeter network
Internet
Web/Mail Server
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 16 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Inside Perimeter
Web/Mail Server
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Outside
FIGURE 2-3
Transit perimeter network
Internet
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.
NOTE
Please refer to Bind 9 documentation for an in-depth explanation of name server nomenclature.
When designing a restrictive firewall policy, you must consider the implementation details of the DNS and e-mail services. 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 a caching 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.
■
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 17 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 communicate with the outside world. In this case, bidirectional SMTP is required between the inside server and the perimeter 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.
Restrictive Policy of a Firewall with a Perimeter Network
Server Zone Sessions Allowed
■
TABLE 2-3
Client Zone
Inside Outside Inside
Outside Inside Perimeter
ICMP echo, HTTP, HTTPS (Optionally) FTP None 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 SMTP to inside mail server (to deliver inbound e-mail) DNS SMTP (to deliver outbound e-mail) 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 HTTP because its single-session design does not cause any firewall issues.)
Perimeter Perimeter Outside
Inside Outside Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 18 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The firewall policy just documented is extremely restrictive, allowing only the minimum number of services needed. This results 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 eliminating any direct traffic between the internal network and the public Internet, as illustrated in Table 2-4.
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 in HTTP requests to the proxy server.
TABLE 2-4
Client Zone
Policy of a Firewall with Proxy Servers in the Perimeter Network
Server Zone Sessions Allowed
Inside Outside Inside
Outside Inside Perimeter
None None HTTP, HTTPS (to access proxy web server) ICMP echo SMTP from inside mail server to perimeter mail server FTP and SSH for server management SMTP to internal e-mail server (to deliver inbound e-mail) DNS SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web) (Optional) FTP ICMP echo DNS (only if the customer runs its own name server) HTTP to public web server SMTP to public mail server (Optional) FTP; see also comments in Table 2-3
Perimeter Perimeter
Inside Outside
Outside
Perimeter
The transition from the single-device design (Figure 2-2) to the design with a transit perimeter network (Figure 2-3) illustrates one of the advantages of a well-documented zone-based design: Because all the firewall policies have already been documented, they don’t have to be designed from scratch. You merely split the overall firewall policy into two parts: the
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 19 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
inner firewall handles policies from inside to everywhere else, and the outer firewall handles policies from outside to everywhere 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
Client Zone
Policy of the Inner Firewall
Server Zone Sessions Allowed
Inside
Perimeter
HTTP, HTTPS (to access proxy web server) ICMP echo SMTP (to send mail) FTP and SSH for server management. SMTP to inside mail server (to deliver inbound e-mail)
Perimeter
Inside
TABLE 2-6
Client Zone
Policy of the Outer Firewall
Server Zone Sessions Allowed
Perimeter
Outside
DNS SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web) (Optional) FTP ICMP echo DNS (only if the customer runs its own name server) HTTP to public web server SMTP to public mail server (Optional) FTP
Outside
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 20 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Redundant Firewall Designs
As 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.
FIGURE 2-4
Redundant firewall design Inside Perimeter
Web/Mail Server
Outside
Internet
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 Designs
Firewalls 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 21 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Remote IPsec users—Individual users accessing the corporate network with IPsec-encrypted sessions over the public 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.
NOTE
This design uses a restrictive policy for inside clients with no HTTP proxy. For a lessrestrictive policy or a policy with HTTP proxies, replace individual items in Table 2-7 with entries from the previous sections. The design also assumes that the organization does not offer public FTP service.
TABLE 2-7
Client Zone
Firewall Policy of a Complex Firewall
Server Zone Sessions Allowed
Inside VPN users VPN offices Inside VPN users VPN offices Inside VPN users VPN offices
Perimeter
ICMP echo HTTP to web servers SMTP to mail servers DNS to name servers ICMP echo HTTPS to e-commerce servers ICMP echo, HTTP, HTTPS, FTP
E-commerce
Outside
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 22 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
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.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 2-7
Client Zone
Firewall Policy of a Complex Firewall
Server Zone Sessions Allowed
continued
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 servers HTTPS, SSH, FTP, and SNMP to all servers All services granted to inside users Additional services if needed All (to support remote users) All (to support remote offices) SMTP to internal e-mail server Minimum set of ICMP traffic DNS SMTP SQL transactions Access to a subset of internal servers RADIUS from VPN concentrator to authentication server IPsec traffic (ISAKMP + ESP) Access to a less-restricted set of internal servers RADIUS from VPN concentrator to authentication server IPsec traffic (ISAKMP + ESP)
Administrators Administrators Administrators Administrators Perimeter Perimeter E-commerce VPN users Outside VPN offices Outside
E-commerce Outside VPN users VPN offices Inside Outside Inside Inside VPN users Inside VPN offices
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 23 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Such a complex firewall is almost always implemented with multiple devices to improve its resiliency and reduce the complexity 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.
E-commerce
FIGURE 2-5
Complex firewall design
Web/Mail Server Administrators
Outside
Internet
Inside
Perimeter
VPN Users
VPN Offices
Reducing the Complexity of Advanced Firewalls
As 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 24 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
FIGURE 2-6
Decomposed complex firewall
E-commerce Firewall Perimeter Outside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
E-commerce
Internet Perimeter Firewall VPN Users
VPN Firewall Inside and Administrators VPN Offices Encrypted
NOTE
The firewall design is further simplified by the intended traffic flow: Traffic from VPN users first enters the inside network and is then additionally screened by the perimeter firewall.
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” and Figure 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 25 ]
CHAPTER 2 Typical ZoneBased Firewall Designs
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Summary
In this chapter, you have seen how you can use zone-based firewall design principles to design a variety of firewall solutions, 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 26 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER THREE
Configuring Zone-Based Policy Firewalls in Cisco IOS
In 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 addressing scheme used in the examples.
FIGURE 3-1
Sample firewall with addressing
10.0.0.2 10.0.0.3 dns.isp.com 172.16.0.1 smtp.isp.com 172.16.0.2
Initial Zone-Based Policy Firewall Configuration ................................30 Limiting Inside-toOutside Traffic.............................................37 Protecting the Router.................................43 Monitoring and Debugging Zone-Based Policy Firewall Configuration ....................47
172.16.10.32/28
10.0.0.0/24 10.0.0.1 192.168.201.6
Internet
www.web.com 172.18.25.10
Inside
Outside
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 27 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 the Network 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.
NOTE
The configuration in Listing 3-1 is slightly abridged. (For example, vty and console configuration has been removed.) It has also not been properly secured. (For example, Finger and HTTP are enabled, and Telnet is used rather than SSH.)
LISTING 3-1
!
Initial Router Configuration
hostname fw service finger ! ip dhcp pool LAN network 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.0 ip nat inside ! interface Serial0/0/0 no ip address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 28 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
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.
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, because the potential intruder can reach only one IP host (the router itself).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 29 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 telnet finger http 23/tcp open 79/tcp open 80/tcp open
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: (The 1671 ports scanned but not shown below are in state: closed) PORT STATE SERVICE telnet finger http 23/tcp open 79/tcp open 80/tcp open
Interesting ports on 172.16.10.34: (The 1668 ports scanned but not shown below are in state: closed) PORT 135/tcp STATE SERVICE open msrpc
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 30 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-3
139/tcp 445/tcp
External Port Scan with Active NAT Translations
open open netbios-ssn microsoft-ds ms-term-serv vnc-http vnc
continued
3389/tcp open 5800/tcp open 5900/tcp open
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. NOTE
Class map definitions are mandatory unless you want to rely on the system-defined classdefault class, which matches all traffic.
Use the new zone security command to define the zones in your firewall. (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). 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). Use the zone-pair security command to apply a predefined firewall policy to a pair of source (client) and destination (server) zones. After the firewall policy is configured, assign the router interfaces to various security zones by using the zone-member security interface configuration command.
Step 2.
Step 3. Step 4. Step 5.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 31 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 appropriate 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 zonebased 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 32 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Configuring Security Zones
Our example has two security zones: inside and outside. Listing 3-4 shows the configuration commands used to create them. To help network administrators understand the router configuration, you can assign a description to each zone with the description zone configuration command.
LISTING 3-4 Creating Zones
zone security Inside description Inside network zone security Outside description Outside network
Configuring Firewall Policy
NOTE
Class default is always the last class in a policy map. It thus applies only to traffic not covered by other class maps.
The firewall policy in our design is very simple: All traffic is allowed from the inside zone to the outside zone, so we can use the class-default (match all) traffic class in the policy-map command. Similar to other modular CLI constructs in Cisco IOS, you have to specify what to do with the traffic matching the desired traffic class. You have the following options:
■
Pass the packets. This action is equivalent to an access-list permit statement and is thus unidirectional. There is no provision for return traffic, so you have to specify the handling of return traffic manually. This option is useful only for protocols such as IPsec-encrypted traffic. Inspect the packet. This action is equivalent to the functionality of the ip inspect command of the Cisco IOS Firewall Stateful Inspection feature. It automatically provides conduits for return traffic and potential ICMP messages. For protocols requiring multiple parallel signaling and data sessions (for example, FTP or H.323), the inspect action also handles the proper establishment of data sessions.
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 33 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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 destination 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.
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.
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 Zones
After 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 34 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-6
Initial Zone-Based Policy Firewall Configuration
policy-map type inspect InsideToOutside class class-default inspect ! zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 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 internal hosts 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 35 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-7
Scanning the Protected LAN from the Outside
External$ nmap --system-dns 172.16.10.32/28 Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-07-29 23:41 Interesting ports on 172.16.10.33: (The 1671 ports scanned but not shown below are in state: closed) PORT STATE SERVICE telnet finger http 23/tcp open 79/tcp open 80/tcp open
Nmap finished: 16 IP addresses (1 host up) scanned in 64.964 seconds Raw packets sent: 2581 (112.944KB) | Rcvd: 1677 (77.142KB)
On the other hand, a simple test (Listing 3-8) proves that the inside clients can reach any service or server on the Internet.
LISTING 3-8 Scanning an External Web Server from the Inside
Inside$ nmap -v --system-dns web.com Interesting ports on web.com (172.18.25.10): (The 1663 ports scanned but not shown below are in state: closed) PORT 21/tcp 25/tcp 80/tcp 135/tcp 139/tcp 443/tcp 445/tcp STATE SERVICE open open open open open open open ftp smtp http msrpc netbios-ssn https microsoft-ds LSA-or-nterm
1026/tcp open
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 36 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-8
Scanning an External Web Server from the Inside
ms-term-serv vnc-http vnc
continued
3389/tcp open 5800/tcp open 5900/tcp open
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 connections (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 connections (50) exceeded for host 172.18.25.10. 00:42:48: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connections (50) exceeded for host 172.18.25.10. 00:42:53: %FW-4-HOST_TCP_ALERT_ON: (target:class)-(InsideToOutside:class-default):Max tcp half-open connections (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 Summary
In this section, we have used the commands summarized in Table 3-1 to create an initial firewall configuration.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 37 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 3-1
Basic Zone-Based Policy Firewall Configuration Commands
Description
Command Syntax
zone security name description text policy-map type inspect name class name class class-default inspect
Creates a new security zone. Optionally assigns a description to the selected security zone. Creates a new policy map or starts configuration of the existing policy map. The type inspect keywords are mandatory. Within a policy map, starts configuring firewall actions for the specified traffic class. 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. 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). Within a traffic class configuration, permits traffic. You have to make manual provisions for return traffic handling. Drops the packets of the selected traffic class with optional logging to the router’s log. Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a specified maximum burst size.
pass drop [log] police rate bps burst burst-size
Limiting Inside-to-Outside Traffic
In 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 ZoneBased Firewall Designs”). To reach that goal, we first have to define the traffic classes that will later be used in the
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 38 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
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) protocols. Those class maps are called Layer 7 class maps and are covered in a later section.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
policy-map commands to define the desired firewall policy. The traffic classes are defined with the well-known classmap 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
Description
Command syntax
class-map type inspect [match-all | match-any] name match access-group {ACL-number | name ACL-name} match protocol {tcp | udp | icmp} match protocol protocol-name
Starts configuration of the named class map. The traffic matched by the class map has to 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). Matches traffic permitted by the specified access group. You can use numbered or named IP access lists. Matches any packet of the specified Layer 4 protocol. 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. Matches traffic specified by a previously defined class map. This command is useful when you 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. Matches all traffic not matching the specified condition.
match class-map name
match not condition
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 39 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 http match protocol ftp match protocol icmp match 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 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 ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 40 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 41 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-12
Final Simple LAN-to-Internet Firewall Configuration
continued
zone security Inside description Inside network zone security Outside description Outside network zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside ! interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 ip nat inside zone-member security Inside ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252 ip nat outside zone-member security Outside ! ip access-list extended ISPServers permit ip any host 172.16.0.1 permit ip any host 172.16.0.2
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 42 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 21/tcp 53/tcp 80/tcp STATE open open open SERVICE ftp domain http
Interesting ports on smtp.isp.com (172.16.0.2): (The 1669 ports scanned but not shown below are in state: filtered) PORT 25/tcp 53/tcp 110/tcp STATE open open open SERVICE smtp domain 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): (The 1671 ports scanned but not shown below are in state: filtered) PORT 21/tcp 80/tcp STATE SERVICE open open ftp http https
443/tcp open
Nmap finished: 1 IP address (1 host up) scanned in 26.047 seconds
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 43 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 Router
The 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 in the 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 inspection does. Therefore, special precautions must be taken to ensure that there are no undesired side effects from applying 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 44 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
IMPORTANT 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 cannot originate 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 Protection
NOTE
A more complex router protection policy will be developed in the next chapter. A more securityconscious environment would also not allow full access from the router to the inside network.
Common 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 45 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 permit icmp any any echo ! 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 self service-policy type inspect OutsideToRouter ! ip access-list extended ManagementProtocols permit tcp any any eq telnet permit tcp any any eq 22 ! ssh
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 46 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-16
Protecting the Router with the Self Zone
! https
continued
permit tcp any any eq www permit tcp any any eq 443 permit icmp any any echo ! 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-default inspect ! 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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 47 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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): (The 1671 ports scanned but not shown below are in state: filtered) PORT 23/tcp 80/tcp STATE open open SERVICE telnet http
443/tcp closed https Nmap finished: 1 IP address (1 host up) scanned in 22.552 seconds
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 Nmap finished: 1 IP address (1 host up) scanned in 71.533 seconds
Monitoring and Debugging Zone-Based Policy Firewall Configuration
As with every Cisco IOS features, a number of show and debug commands are available to network administrators to monitor 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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 48 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-19
zone self
Show Zone Security Command Displays Zones and Associated Interfaces
s fw#show zone security 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 specified 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
s 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 49 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
WARNING
The per-protocol traffic counters displayed in the show policy-map type inspect zone-pair command can be misleading. 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 the data transferred in the FTP data sessions.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 30 second rate 0 bps Match: protocol icmp 1 packets, 40 bytes 30 second rate 0 bps Match: protocol https 0 packets, 0 bytes 30 second rate 0 bps 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:13 Last statistic reset never Last session creation rate 1 Last half-open session total 0 … printout repeated for other classes of traffic …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 50 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
s 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 30 second rate 0 bps Match: protocol ftp 3 packets, 84 bytes 30 second rate 0 bps Match: protocol icmp 1 packets, 40 bytes 30 second rate 0 bps Match: protocol https 0 packets, 0 bytes 30 second rate 0 bps 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 …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 51 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
A few debugging command also support the zone-based policy firewall feature:
■ ■
The debug zone security command is focused on zone security events (for example, interface assignments). The debug ip inspect policy command gives you an in-depth view of individual packet classification. Listing 3-22 shows a printout associated with a single TCP SYN packet trying to open a Finger session to the router.
Output of the debug ip inspect policy Command
WARNING
Use debug ip inspect policy only on a lightly loaded router in a controlled environment (preferably with no logging to the router console); otherwise, you might easily overload its CPU.
LISTING 3-22
00:36:29: CBAC-C3PL : Policy lookup for pak 0x4716467C [insp_c3pl_policy_lookup] 00:36:29: CBAC-C3PL : input i/f is FastEthernet0/0, output i/f is NULL [insp_c3pl_validate_zoning] 00:36:29: CBAC-C3PL : Zone-pair and policy found [insp_c3pl_validate_zoning] 00:36:29: CBAC-C3PL : Packet L7 protocol is 59 L4 prot is 1 [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class RouterManagement [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : zeroing out prot_flag [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Checking if the packet(0x4716467C) matches with class class-default [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Packet(0x4716467C) matched with class class-default [insp_c3pl_packet_classify_class_based_common] 00:36:29: CBAC-C3PL : Classification returned protocol-id 0x0 classid 0 [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : DROP action found in policy-map [insp_c3pl_process_actions_of_class] 00:36:29: CBAC-C3PL : Action processing returned code 1. [insp_c3pl_classify_packet] 00:36:29: CBAC-C3PL : classify processing returned 1 [insp_c3pl_policy_lookup]
Furthermore, because the zone-based firewall policy feature is closely linked to the Context-Based Access Control (CBAC) code, many debug ip inspect commands work as expected. For example, you might debug DNS and FTP inspection, resulting in the following printout when a user opens an FTP session from the inside to the outside zone (Listing 3-23).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 52 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 3-23
Debugging FTP and DNS Sessions
d fw#debug ip inspect dns INSPECT DNS Inspection debugging is on d 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
Summary
In 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 53 ]
CHAPTER 3 Configuring Zone-Based Policy Firewalls in Cisco IOS
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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 policy on 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 improving 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.
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 54 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER FOUR
Case Study: Firewall with a Perimeter Network
In 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
Client 10.0.0.2 Mail Server 10.0.0.10
Configuring the Firewall Policy .............................................56 Protecting the Router ....................................................60
Outside
Internet
Inside
10.0.0.1
192.168.0.1
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 55 ]
CHAPTER 4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Case Study: 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:
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.
■
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 Router
NOTE
You need to remove the previous NAT pool definition before redefining it.
interface 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 28 ip nat inside source static 192.168.0.2 172.16.10.34
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 56 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Configuring the Firewall Policy
The 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).
NOTE
Within this case study, we optimize the class definitions by grouping similar protocols in the same traffic class. When deploying applicationlevel 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 configuring the router.
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 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 !
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 57 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-2
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 troubleshooting 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 58 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-3
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 permit ip any host 192.168.0.2
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).
NOTE
The configuration of service policies and zone pairs seems highly verbose. You will see where you can benefit from this modularity when configuring morecomplex firewall policies later in this chapter.
LISTING 4-4
Firewall Policies and Zone Definitions
zone security Inside zone security Perimeter zone security Outside ! policy-map type inspect InsideToOutside 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 PerimeterToOutside class type inspect DNS
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 59 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-4
inspect class type inspect SMTP inspect class type inspect ping inspect ! policy-map type inspect OutsideToPerimeter class type inspect PublicTraffic inspect ! policy-map type inspect PerimeterToInside class type inspect MailDelivery inspect !
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall Policies and Zone Definitions
continued
zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside 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 ! interface FastEthernet0/0 description Inside LAN zone-member security Inside !
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 60 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Firewall Policies and Zone Definitions
continued
interface FastEthernet0/0.100 description Perimeter network zone-member security Perimeter ! interface Serial0/0/0.100 point-to-point description Link to the Internet zone-member security Outside
Protecting the Router
NOTE
There might be additional public services the router itself needs to access (for example, the Network Time Protocol [NTP] service).
We 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 connectionestablishment 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.
NOTE
Note that the same policy map is used twice to specify firewall policies between the router and the outside and perimeter zones.
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 outbound firewall policy. (IP access list IcmpEcho is defined in Listing 4-2.)
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 61 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-5
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 class type inspect ping 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 62 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-6
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 management with SNMP while the router would send syslog, TFTP, and FTP traffic to the internal server. However, because
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 63 ]
CHAPTER 4
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Case Study: 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 this problem:
■
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 internal server.
■
■
Listing 4-7 shows the configuration commands defining the firewall policy between the firewall router and the inside network.
LISTING 4-7
! ! 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
Securing Inside Access to the Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 64 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-7
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Securing Inside Access to the Router
continued
policy-map type inspect InsideToRouter class type inspect ping 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 permit tcp host 10.0.0.1 host 10.0.0.10 eq www permit tcp host 10.0.0.1 host 10.0.0.10 eq 443 permit udp host 10.0.0.1 host 10.0.0.10 eq snmp ! policy-map type inspect RouterToInside class type inspect RouterPublicTraffic inspect class type inspect RouterDataTransfer ! SSH/SCP ! Web (http) ! SSL (https) ! SNMP traps
permit udp host 10.0.0.1 host 10.0.0.10 eq syslog ! SYSLOG messages
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 65 ]
CHAPTER 4 Case Study: Firewall with a Perimeter Network LISTING 4-7
inspect ! zone-pair security RouterToInside source self destination Inside service-policy type inspect RouterToInside
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Securing Inside Access to the Router
continued
Summary
In this chapter, you’ve seen how you can use the basic configuration commands supported by the zone-based policy firewall 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 configuration 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 66 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER FIVE
Advanced Zone-Based Policy Firewall Configuration
In 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 ....................................................67 Tuning Denial-ofService Protection ......................................70 Identifying Masquerading Applications .................................................74 Application Layer Packet Inspection .......................................79 HTTP Packet Inspection ....................................................86 Configuring User-Defined Protocols .............................90
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 finetune its configuration.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 67 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Tuning the Stateful Inspection
The 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
Description
Command Syntax
parameter-map type inspect name alert on | off audit-trail on | off inspect parameter-map-name
Creates or modifies the specified parameter map. Enables or disables syslog alerts (default: on). Enables or disables a session audit trail written to the router’s log (default: off). 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 68 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
FIGURE 5-1
Audit trail of inbound SMTP sessions Inside
Syslog Alert External Mail Server 172.18.25.10 Inbound SMTP Session
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Client 10.0.0.2
Internal Server 10.0.0.10
Outside Internet
Web/Mail Server 192.168.0.2
Perimeter
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.
WARNING
Do not delete and recreate a policy map as you would do with an access list. Deleting a policy map silently removes all references to it, thus potentially modifying your router configuration.
■
Listing 5-1 includes the step-by-step configuration process.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 69 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-1
c fw#conf t
Configuring the Audit Trail of Inbound SMTP Sessions
End with CNTL/Z
Enter configuration commands, one per line. c fw(config)#class-map type inspect PublicSMTP m fw(config-cmap)#match class-map SMTP
m fw(config-cmap)#match access-group name ExternalServer e fw(config-cmap)#exit p fw(config)#parameter-map type inspect audit a fw(config-profile)#audit-trail on e fw(config-profile)#exit p fw(config)#policy-map type inspect OutsideToPerimeter n fw(config-pmap)#no class type inspect PublicTraffic c fw(config-pmap)#class type inspect PublicSMTP i fw(config-pmap-c)#inspect audit c fw(config-pmap-c)#class type inspect PublicTraffic i 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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 70 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Half-open TCP connections are connections where the SYN packet has been received, but the first non-SYN packet hasn’t been seen yet.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Tuning Denial-of-Service Protection
The 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 parametermap syntax is described in Table 5-1.) Remember that all parameters apply to a single traffic class between a pair of zones.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 71 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 5-2 alert on | off
Configuring Inspect Thresholds
Description
Command Syntax
Enables or disables syslog alerts (default: on). Enables or disables the session audit trail written to the router’s log (default: off). Configures the maximum number of sessions in this traffic class. Configures the maximum time between the DNS query and response packet. Configures the maximum time between ICMP request and reply. Configures the threshold at which the Cisco IOS firewall starts the DoS protection (high parameter) 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. Configures the per-minute session establishment threshold that triggers the DoS protection. The process starts after the high threshold has been exceeded and stops when the session establishment rate drops below the low threshold. Configures the maximum number of half-open sessions from a single IP host. The offending host could be (optionally) blocked for the specified duration. Configures TCP timers—the maximum time between packets in session establishment, the maximum time between packets in session termination and the session idle timer. Configures the idle timer for non-DNS UDP sessions.
audit-trail on | off sessions maximum number dns-timeout seconds icmp idle-timeout seconds max-incomplete high number | low number one-minute high number | low number tcp max-incomplete host threshold [ block minutes ] tcp synwait-time seconds tcp finwait-time seconds tcp idle-time seconds udp idle-time seconds
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 72 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-3
Default Stateful Packet Inspection Thresholds
s 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-second DNS 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 idletimeout can also be reduced unless you have very slow-speed congested links.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 73 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
After you have adapted the timeouts to your environment, perform the following steps to fine-tune the half-open session thresholds:
Step 1. Step 2.
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.) 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 protection. (The alert message indicates the policy map and the class within it.) After a statistically significant time period (at least a day), review the inspect counters (see Listing 5-4).
Displaying Session Inspection Parameters of a Zone Pair
Step 3.
LISTING 5-4
s 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 …
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 74 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Step 4.
Set the max-incomplete low parameter to the Maxever session counts half-open value. Set the maxincomplete high parameter to a value at least 25 percent above that. Increase the parameter to an even higher value if you expect a significant increase in network traffic (for example, increased website traffic due to a marketing campaign). The Cisco IOS printout gives you no reliable information that would allow you to set the one-minute thresholds. 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. Repeat the process for every traffic class that needs adjusted DoS protection behavior. 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.
NOTE
Server logs are an extremely valuable resource in the tuning process. Computing oneminute session establishment rate from a web server log is a simple exercise.
Step 5.
Step 6. Step 7.
Identifying Masquerading Applications
Some 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 Started
Myhost $ netstat Active Connections Proto TCP TCP Local Address myhost:1938 myhost:1957 Foreign Address cs31.msg.dcn.yahoo.com:5050 sip34.voice.re2.yahoo.com:5061 State ESTABLISHED ESTABLISHED
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 75 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-6
Yahoo Messenger Port Usage After Ports 5050 and 5061 Were Disabled on the Firewall
Myhost $ netstat Active Connections Proto TCP TCP Local Address myhost:1988 myhost:2005 Foreign Address cs31.msg.dcn.yahoo.com:telnet sip38.voice.re2.yahoo.com:https State ESTABLISHED 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 the firewall policy
Client 10.0.0.2
scs.msg.yahoo.com:5050
Unknown application, dropped
Outside
STOP
scs.msg.yahoo.com:80
Yahoo Server
Inside
Looks like web browsing, passed
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 76 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The masquerading applications fall into two categories:
■
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. 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).
Some peer-to-peer applications
■
Cisco IOS can identify both types of applications starting in Release 12.4(9)T.
Identifying Peer-to-Peer Applications
To 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 77 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Identifying Instant Messaging Applications
Instant 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
Description Command Syntax
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.
parameter-map type protocol-info name server {name name | ip address} server ip range start end
Creates or modifies the specified parameter map Specifies a single server by its name or IP address 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-topeer 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 78 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
If you want to disable access to Yahoo Messenger in our sample firewall from Chapter 4, you have to augment the InsideToOutside policy map with the commands from Listing 5-9.
LISTING 5-9 Disable Yahoo Messenger in the Sample Firewall
policy-map type inspect InsideToOutside 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 classification 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.
protocol-info-Related show Commands
LISTING 5-10
s fw#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 s 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 Number of IP Addresses: 2
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 79 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-10
protocol-info-Related show Commands
(0D:00H:00M)
continued
68.142.194.14, 68.142.231.252 Application im-yahoo.
Server DNS Name: ‘sip.yahoo.com’.
Updates: 0 failed, 2 succeeded, next after 3.086 secs Number of IP Addresses: 8 68.142.233.179 68.142.233.181 68.142.233.183 68.142.233.177 (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) 68.142.233.180 68.142.233.182 68.142.233.176 68.142.233.178 (0D:00H:00M) (0D:00H:00M) (0D:00H:00M) (0D:00H:00M)
Application Layer Packet Inspection
In 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.
■ ■ ■
■ ■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 80 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
All application layer inspections are configured using application-specific class maps and policy maps that are then 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
WORD aol edonkey fasttrack gnutella http imap kazaa2 match-all match-any msnmsgr pop3 smtp sunrpc ymsgr
Application Layer Protocol Inspection in Cisco IOS Release 12.4(9)T
class-map name Configure CBAC class-map for IM-AOL protocol eDonkey FastTrack Traffic - KaZaA, Morpheus, Grokster... Gnutella Version2 Traffic - BearShare, Shareeza, Morpheus ... Configure CBAC class-map for HTTP protocol Configure CBAC class-map for IMAP protocol Kazaa Version 2 Logical-AND all matching statements under this classmap Logical-OR all matching statements under this classmap Configure CBAC class-map for IM-MSN protocol Configure CBAC class-map for POP3 protocol Configure CBAC class-map for SMTP protocol Configure CBAC class-map for RPC protocol Configure CBAC class-map for IM-YAHOO protocol
c fw(config)#class-map type inspect ?
NOTE
The match commands available in the class map configuration are protocol-specific; you can find a detailed list in the Cisco IOS documentation. The extensive set of HTTP match commands is described in the next section.
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 81 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-12
WORD http im imap p2p pop3 smtp sunrpc
Configuring the Application Layer Policy Map
policy-map name Configure CBAC policy-map for HTTP protocol Configure CBAC policy-map for IM protocol Configure CBAC policy-map for IMAP protocol Configure CBAC policy-map for P2P protocols Configure CBAC policy-map for POP3 protocol Configure CBAC policy-map for SMTP protocol Configure CBAC policy-map for RPC protocol
p fw(config)#policy-map type inspect ?
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).
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 require stateful 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 82 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Some of these issues could be solved with other mechanisms. For example, peer-to-peer services could be prohibited, and secure POP3 and IMAP could be deployed instead of forcing the users to use non-clear-text authentication on regular POP3/IMAP sessions.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Packets not matched by any class in a Layer 4 policy map are handled by class-default. If no action is specified in class-default, these packets are dropped. Packets not matched by an application layer policy map are not dropped but are handled according to the specifications of the parent policy map.
Application Layer Packet Inspection Example
Let’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 MP3 files 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).
No cleartext POP3 authentication
Client POP3 USER command POP3 APOP command
FIGURE 5-3
Simple LAN-toInternet firewall
Outside
STOP
pp3.isp.com 172.16.0.2
10.0.0.0/24
Inside
10.0.0.1
192.168.201.6
Internet
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 83 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
Inspect class maps have to be configured to match individual protocols for which we want to perform DPI (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.
Application-Level Inspection of E-mail–Related Protocols
■
LISTING 5-13
match match !
class-map type inspect imap match-any imapMail invalid-command 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 match ! policy-map type inspect pop3 pop3Policy class type inspect pop3 pop3Mail reset log ! class-map type inspect smtp match-any smtpMail match ! data-length gt 5000000 invalid-command login clear-text
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 84 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-13
Application-Level Inspection of E-mail–Related Protocols
continued
policy-map type inspect smtp smtpPolicy class type inspect smtp smtpMail reset
LISTING 5-14
match !
Application-Level Inspection of Peer-to-Peer Traffic
class-map type inspect gnutella match-any noMP3gnutella file-transfer mp3
class-map type inspect fasttrack match-any noMP3fasttrack match ! class-map type inspect edonkey match-any noMP3edonkey match match ! class-map type inspect kazaa2 match-any noMP3kazaa match ! policy-map type inspect p2p noMP3transfer class type inspect edonkey noMP3edonkey log reset class type inspect fasttrack noMP3fasttrack log reset class type inspect gnutella noMP3gnutella log reset file-transfer mp3 file-transfer mp3 search-file-name mp3 file-transfer mp3
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 85 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-14
log reset
Application-Level Inspection of Peer-to-Peer Traffic
continued
class type inspect kazaa2 noMP3kazaa
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 signature match protocol kazaa2 signature match protocol fasttrack signature
LISTING 5-16
Inside-to-Outside Firewall Policy
policy-map type inspect InsideToOutside class type inspect peer2peer inspect service-policy p2p noMP3transfer class type inspect getMail inspect service-policy pop3 pop3Policy class type inspect readMail
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 86 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-16
inspect
Inside-to-Outside Firewall Policy continued
service-policy imap imapPolicy class type inspect sendMail inspect service-policy smtp smtpPolicy class class-default inspect
HTTP Packet Inspection
NOTE
HTTP packet inspection works only on nonencrypted HTTP sessions. If the data exchange takes place over Secure Sockets Layer (SSL, also known as HTTPS), the firewall cannot inspect the packet content.
Cisco 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).
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 87 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
The match commands that you can use in the class-map type inspect http command follow these rules:
■
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.
Matching HTTP Requests and Responses
Description
■ ■
■
■
TABLE 5-4
Command Syntax
match request uri regex name match request arg regex name match request method http-method-name match request port-misuse im | p2p | tunneling | any match response status-line regex name
Matches the web address (URI) with a regular expression Matches the HTTP request arguments with a regular expression Matches the HTTP method in the request (GET, POST …) Identifies potential misuses of HTTP by tunneling, peer-to-peer, or instantmessaging applications Matches the status of the HTTP response (for example, 200 = OK, 403 = forbidden, 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 88 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
TABLE 5-5
Configuring Regular Expression Parameter Maps
Description
Command Syntax
parameter-map type regex name pattern regex
Creates a new regular expression parameter map. 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 improved in 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 89 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■ ■
class-map anyOtherHttp matches all HTTP traffic, effectively replacing the class-default. policy-map validHttp defines the HTTP inspection policy. The TCP session is reset when a port misuse is detected or when the HTTP request method does not match one of the allowed methods. A new inspect class-map is defined to match the HTTP traffic and is appended at the end of the existing InsideToOutside policy map (just in front of the class-default line).
Implementing Simple HTTP Inspection
■
NOTE
Adding an unrelated condition (for example, allowing only the three request methods and only the content types text/* and image/*) would result in a large set of class maps and a complex policy map, because you would have to match each combination of method and content type individually with a separate match-all class map and then list all of them in the policy map.
LISTING 5-17
match match match !
class-map type inspect http match-any validHttpCommands request method get request method post request method head
class-map type inspect http match-any httpPortMisuse match request port-misuse any ! class-map type inspect http match-any anyOtherHttp ! policy-map type inspect http validHttp class type inspect http httpPortMisuse reset log class type inspect http validHttpCommands allow class type inspect http anyOtherHttp reset ! class-map type inspect match-any httpTraffic match protocol http
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 90 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 5-17
!
Implementing Simple HTTP Inspection
continued
policy-map type inspect InsideToOutside class type inspect httpTraffic inspect service-policy http validHttp
Configuring User-Defined Protocols
In 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-4
Proxy access to external web server
Client 10.0.0.2
Outside Internet
Re qu es to n po
Inside
Re
es qu
80 or t External Web Server np 172.18.25.10 to
Perimeter
rt 80 80
Proxy Web Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 91 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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
Description
Command Syntax
ip port-map user-protocol-name port {tcp | udp} port-number ip port-map protocol port {tcp | udp} port-number
Specifies port usage for a user-defined protocol. The protocol name must start with the userprefix to ensure there is no overlap with future protocol additions to Cisco IOS. Specifies a nonstandard TCP or UDP port for a protocol recognized by Cisco IOS.
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
! class-map type inspect match-all proxyhttp match protocol user-proxyhttp ! policy-map type inspect InsideToPerimeter class type inspect proxyhttp inspect class type inspect ping inspect ! matches TCP port 8080 ! cannot use HTTP service policy
Configuring a User-Defined Protocol
ip port-map user-proxyhttp port tcp 8080
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 92 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
NOTE
Adding TCP or UDP ports to standard protocols with the ip portmap command affects other Cisco IOS features that use the port map functionality (for example, Network-Based Application Recognition [NBAR]).
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 standard 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
! class-map type inspect match-all web match protocol http ! policy-map type inspect InsideToPerimeter class type inspect web inspect class type inspect ping inspect ! matches TCP port 80 and port 8080 ! can use HTTP service policy
Configuring Additional Port Numbers for a Standard Protocol
ip port-map http port tcp 8080
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 93 ]
CHAPTER 5 Advanced ZoneBased Policy Firewall Configuration
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Summary
In this chapter, you’ve seen how you can use advanced configuration commands of the zone-based policy firewall configuration 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 applications. 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.
■ ■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 94 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
CHAPTER SIX
Configuring Transparent Firewalls
Cisco IOS Release 12.3(7)T introduced the transparent firewall feature: the ability to filter IP traffic between a pair of bridged interfaces. This feature is fully supported by the new zone-based configuration 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 introduced in Chapter 4, “Case Study: Firewall with a Perimeter Network” (Figure 6-1).
FIGURE 6-1
Physical firewall structure
Client 10.0.0.2
Protecting Internal Servers: Alternate Design .......................103 Case Study: Migrating a Server to the Perimeter Network...........106
Perimeter VLAN 518
Web/Mail Server 192.168.0.2
Outside
Inside VLAN 516
Internet
Server 10.0.0.10
Inside VLAN 517
VLAN trunk
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 95 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Our organization has built a switched LAN network with all clients and servers residing in one IP subnet. It has successfully 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 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 intermingled 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
NOTE
It’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 configuration. However, if your router has a single physical LAN interface, that might be the only solution.
interface FastEthernet0/0 description Trunk to the LAN switch ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN ! interface FastEthernet0/0.100 encapsulation dot1Q 518 description Perimeter VLAN
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 96 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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:
Step 1. Step 2. Step 3. Step 4. Step 5.
Enable integrated routing and bridging with the bridge irb command. Create a bridge group and specify its spanning tree protocol with the bridge number protocol protocol command. Assign all bridged interfaces into the bridge group with the bridge-group number command. Configure IP routing for the bridge group with the bridge number route ip command. Configure a virtual IP interface representing the router’s attachment to the bridge group with the interface bvi number command.
NOTE
For the remainder of the router configuration, including Network Address Translation (NAT) configuration, see Chapter 4.
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
bridge irb ! interface FastEthernet0/0.1 bridge-group 1 ! interface FastEthernet0/0.5 bridge-group 1 ! interface FastEthernet0/0.100 ip address 192.168.0.1 ip nat inside
IRB and IP Configuration of the Firewall Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 97 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-2
!
IRB and IP Configuration of the Firewall Router
continued
interface BVI1 ip address 10.0.0.1 255.255.255.0 ip nat inside ! bridge 1 protocol ieee bridge 1 route ip
FIGURE 6-2
Logical structure of the firewall router
FastEthernet 0/0.1
10.0.0.0/24 VLAN 516
BVI 1
192.168.0.0/24
FastEthernet 0/0.100
VLAN 517
Serial 0/0.100
Firewall Router
192.168.201.4/30
FastEthernet 0/0.5
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).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 98 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■
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.
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), and then 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 Inside zone security Clients zone security Servers ! class-map type inspect match-any Exchange match protocol msrpc match protocol imap match protocol imaps match protocol pop3 match protocol pop3s match protocol smtp match protocol ldap match protocol ldaps ! class-map type inspect match-any Netbios
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 99 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-3
Zone Assignments of the Inside Physical and Logical Interfaces
continued
match protocol netbios-ns match protocol netbios-ssn match protocol netbios-dgm ! class-map type inspect match-any SQLServer match protocol ms-sql ! policy-map type inspect ServerTraffic class type inspect SQLServer inspect class type inspect Netbios inspect class type inspect Exchange inspect class class-default drop ! zone-pair security ClientsToServers source Clients destination Servers service-policy type inspect ServerTraffic ! interface FastEthernet0/0.1 zone-member security Clients ! interface FastEthernet0/0.5 zone-member security Servers ! interface BVI1 zone-member security Inside
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 100 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 arriving through 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).
FIGURE 6-3
Resulting firewall structure
Clients VLAN 516
BVI 1
Perimeter 192.168.0.0/24
FastEthernet 0/0.100
Inside 10.0.0.0/24
Serial 0/0.100
Servers VLAN 517
Outside 192.168.201.4/30
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
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 101 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 requirements 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 firewall) degrades the concept of security zones to the complexity of building firewalls with IP access lists (most obvious in the InsideToPerimeter policy map).
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 102 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-4
Modified Firewall Policy for the Inside-to-Perimeter Zone Pair
class-map type inspect match-all MailFromInside match protocol smtp 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.10 permit ip host 10.0.0.10 any ! policy-map type inspect InsideToOutside class type inspect AllServerTraffic drop class type inspect WebTraffic inspect class type inspect FileTransfer inspect ! policy-map type inspect InsideToPerimeter class type inspect MailFromInside inspect class type inspect AllServerTraffic drop class type inspect PublicTraffic inspect class type inspect PublicManagement inspect ! defined in Chapter 4 ! defined in Chapter 4
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 103 ]
CHAPTER 6 Configuring Transparent Firewalls
NOTE
Adding a second firewall in the inside network also slightly increases the security of the solution (defense-in-depth principle); if an intruder gains access to the outside firewall or breaks through its defenses, the internal firewall still protects the servers.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Protecting Internal Servers: Alternate Design
The previous discussion of the transparent firewall behavior might have led you to believe that it has only marginal 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 is still 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 interVLAN 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).
Administrators Outside
FIGURE 6-4
Second firewall added to the LAN network—physical connectivity diagram
Internet
Servers Perimeter Inside Clients
Web/Mail Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 104 ]
CHAPTER 6 Configuring Transparent Firewalls
FIGURE 6-5
Bridging loop in the redesigned network
Deploying Zone-Based Firewalls by Ivan Pepelnjak
VLAN 515 Administrators
Inside Router
VLAN 516 Clients
Firewall Router
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.
FIGURE 6-6
Final firewall structure—logical connectivity diagram
Administrators
Outside
Internet
Servers Perimeter Inside Clients
Web/Mail Server 192.168.0.2
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 105 ]
CHAPTER 6 Configuring Transparent Firewalls
NOTE
When configuring firewall policies, do not forget that the administrators have to pass through the clients zone to get to the Internet.
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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.
LISTING 6-5
bridge irb ! zone security Administrators zone security Servers zone security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN bridge-group 1 zone-member security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 515 description Administrators VLAN bridge-group 1 zone-member security Administrators ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN
Initial Configuration of the Inside Firewall
no ip routing
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 106 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-5
Initial Configuration of the Inside Firewall
continued
bridge-group 1 zone-member security Servers ! 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 Perimeter Network
In 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 renumbering 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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 107 ]
CHAPTER 6 Configuring Transparent Firewalls
FIGURE 6-7
Initial network design
172.16.10.32/28 10.0.0.2 Public Server 10.0.0.20
Deploying Zone-Based Firewalls by Ivan Pepelnjak
Outside
dns.isp.com 172.16.0.1
smtp.isp.com 172.16.0.2
10.0.0.0/24 10.0.0.1 192.168.201.6
Internet
www.web.com 172.18.25.10
Inside
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.
FIGURE 6-8
Firewall design using local area mobility
Client 10.0.0.2
Outside
Internet
Inside
10.0.0.1/24
10.0.0.20/32
10.0.1.1/24
Host route to public server
Public Server 10.0.0.20
Perimeter
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 108 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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
hostname fw ! interface Loopback1 ip address 172.16.10.33 255.255.255.240 ! interface FastEthernet0/0 description Inside network ip address 10.0.0.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.5 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 address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252
NOTE
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.
Configuration of Inside Interfaces on the Firewall Router
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 109 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
LISTING 6-6
Configuration of Inside Interfaces on the Firewall Router
continued
ip nat outside frame-relay interface-dlci 100 ! 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 Mobility
d fw#debug arp ARP packet debugging is on d fw#debug ip mobile local-area IP local-area mobility debugging is on fw#
continues
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 110 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
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 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 s 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 interfaces. You can complete the configuration using zones, traffic classes, and policies similar to those in Chapter 4.
Summary
In 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 physical interface 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.
■
■
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 111 ]
CHAPTER 6 Configuring Transparent Firewalls
Deploying Zone-Based Firewalls by Ivan Pepelnjak
■ ■
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.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
[ 112 ]
Deploying Zone-Based Firewalls
Ivan Pepelnjak
Copyright© 2007 Cisco Published by: Cisco Press 800 East 96th Street Indianapolis, IN 46240 USA All rights reserved. No part of this digital short cut may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing October 2006 ISBN: 1-58705-310-1
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this digital short cut or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the digital short cut title and ISBN in your message. We greatly appreciate your assistance.
Corporate and Government Sales
Cisco Press offers excellent discounts on this digital short cut when ordered in quantity for bulk purchases or special sales. For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the U.S. please contact: International Sales [email protected]
Warning and Disclaimer
This digital short cut is designed to provide information about network security. Every effort has been made to make this digital short cut as complete and as accurate as possible, but no warranty or fitness is implied. The information is provided on an “as is” basis. The author, Cisco Press, and Cisco shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this digital short cut. The opinions expressed in this digital short cut belong to the author and are not necessarily those of Cisco.
Trademark Acknowledgments
All terms mentioned in this digital short cut that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco cannot attest to the accuracy of this information. Use of a term in this digital short cut should not be regarded as affecting the validity of any trademark or service mark.
© 2007 Cisco. All rights reserved. This publication is protected by copyright. Please see page 112 for more details.
