Deploying Zone-Based Firewalls

(1)

Deploying

Zone-Based Firewalls

Chapter Three ...26 Configuring Zone-Based

Policy Firewalls in Cisco IOS

Chapter Four ...54 Case Study:

Firewall with a Perimeter Network

Chapter Five ...66 Advanced Zone-Based

Policy Firewall Configuration

Chapter Six...94 Configuring Transparent Firewalls

Ivan Pepelnjak

(2)

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 technolo-gies advisor at NIL Data Communications, where he designed NIL’s Service Provider Academy program. He was one of the architects of the Cisco Systems Service Provider curriculum. He also was the lead developer of several service provider–focused courses covering Multiprotocol Label Switching (MPLS), Border Gateway Protocol (BGP), and IP quality of service. Ivan has written four books for Cisco Press, covering Enhanced Interior Gateway Routing Protocol (EIGRP), MPLS, and virtual private networking (VPN) technologies.

About the Technical 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.

(3)

Firewalls

_{CHAPTER ONE}

Introduction to

Zone-Based 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.

It soon became obvious, however, that to implement reliable security solutions, one needs a more structured and better documented

approach, resulting in the early concepts of firewalls, best documented in the legendary book Firewalls and Internet Security by Cheswick and Bellovin. Initial firewall designs were still based on packet filters, but with the increasing complexity of Internet protocols and resulting fire-wall policies, the concept of zone-based firewall design emerged.

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 Onlineor to the relevant Cisco IOS documentation. Simple Zone-Based Design...4 More Complex Zone-Based Design...5 Implementing Zone-Based Designs...7

(4)

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

Step 1. Internetworking infrastructure under consideration is split into well-documented separate zoneswith various security levels. In this step, do not consider physical implementation of the firewall (number of devices, defense depth, redundancy, and so on), just the separation of your infrastructure into zones (obviously, the public network to which your network is connected is one of them).

Step 2. For each pair of source-destination zones (for example, from inside network to Internet), the sessions (most commonly, TCP and UDP sessions, but also ICMP sessions such as ICMP echo) that clients in source zones are allowed to open to servers in destination zones are defined. For traffic that is not based on the concept of sessions (for example, Encapsulating Security Payload [ESP] of IPSec), define unidirectional traffic flows from source to destination and vice versa. As in the preceding step, do not contemplate the physical setup, just the traffic requirements between zones.

Step 3. After the zones have been identified and the traffic requirements between them documented, design your physical infrastructure, taking into account the security (dictating the number of devices between most-secure and least-secure zones) and availability requirements (for example, redundant devices).

Step 4. For each firewall device in the design, identify zone subsets connected to its interfaces and (multiple zones might be indirectly attached to a single interface of a firewall) merge the traffic requirements for those zones, resulting in a device-specific interzone policy. (See the section “More Complex Zone-Based Design” on the next page for more in-depth explanation of this rule.)

Simple Zone-Based 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

NOTE

Within the context of this discussion,serveris any host that accepts incom-ing connections, regard-less of its actual hardware or software implementation.

(5)

Firewalls

The firewall policy in this design is also simple:

■ Clients in the internal network can open sessions to any server in the Internet. ■ No inbound sessions are allowed from the Internet to the internal network.

Assuming that the network under consideration does not have high resilience or availability requirements, a simple design with a single firewall device between the inside and outside network is sufficient.

More Complex Zone-Based Design

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

Outside

Inside

Internet FIGURE 1-1

Simple firewall setup

NOTE

The actual interzone fire-wall policies for this design are described in the next chapter.

(6)

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

When implementing this design on actual devices, the firewall policy of each device would be based on a merge of several interzone firewall policies. For example, the inner router does not differentiate between sessions originating in the internal zone and terminating in either the perimeter or public zone. Table 1-1 documents the firewall policy that needs to be implemented on the inner router.

TABLE 1-1 Firewall Policy of the Inner Router Client Zone (Hosts Server Zone (Hosts Originating the Terminating the

Connections) Connections) Sessions Allowed

Inside Outside Traffic from internal zone to perimeter and public zones Outside Inside Traffic from public and perimeter zones to internal zone FIGURE 1-2 Traditional firewall design Public Internal Internet Perimeter Web/Mail Server Inner Router Outer Router NOTE

Having a design with two independent devices is more secure than using a single firewall device. If the outside firewall in Figure 1-2 is misconfig-ured or fails, the inside firewall still protects the

(7)

Firewalls

_{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.

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.)

FIGURE 1-3 TCP session estab-lishment across a packet-filtering device Outside Inside Internet

From 10.0.0.2 port 1030 to 172.18.25.1 port 80

10.0.0.2 172.18.25.1

From 172.18.25.1 port 80 to 10.0.0.2 port 1030

(8)

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

interface Serial0/0/0.100 point-to-point description Link to the Internet

ip access-group fromInternet in !

ip access-list extended fromInternet ! prevent spoofing

deny ip 10.0.0.0 0.0.0.255 any ! allow minimum subset of ICMP messages

permit icmp any any echo permit icmp any any echo-reply permit icmp any any time-exceeded permit icmp any any packet-too-big permit icmp any any unreachable ! allow traffic to high-numbered ports

permit tcp any 10.0.0.0 0.0.0.255 gt 1023 permit udp any 10.0.0.0 0.0.0.255 gt 1023

NOTE

Later Cisco IOS releases added the establishedkeyword, 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.

NOTE

Cisco PIX, the Cisco standalone firewall appli-ance, was designed around the concept of

conduits (old PIX

termi-nology for traffic flows), which has from the beginning included the

(9)

Firewalls LISTING 1-2 TCP and UDP Ports Opened on a Typical IP Host Running Windows XP

M:\>netstat -an Active Connections

Proto Local Address Foreign Address State TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:443 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:990 0.0.0.0:0 LISTENING TCP 0.0.0.0:1039 0.0.0.0:0 LISTENING TCP 0.0.0.0:23598 0.0.0.0:0 LISTENING TCP 127.0.0.1:1058 0.0.0.0:0 LISTENING TCP 127.0.0.1:5679 0.0.0.0:0 LISTENING TCP 127.0.0.1:7438 0.0.0.0:0 LISTENING TCP 127.0.0.1:62514 0.0.0.0:0 LISTENING UDP 0.0.0.0:445 *:* UDP 0.0.0.0:500 *:* UDP 0.0.0.0:1025 *:* UDP 0.0.0.0:1026 *:* UDP 0.0.0.0:1515 *:* UDP 0.0.0.0:3456 *:* UDP 0.0.0.0:4500 *:* UDP 127.0.0.1:123 *:* UDP 127.0.0.1:1027 *:* UDP 127.0.0.1:1051 *:* UDP 127.0.0.1:1540 *:* UDP 127.0.0.1:1900 *:* UDP 127.0.0.1:62514 *:* UDP 192.168.229.179:123 *:* UDP 192.168.229.179:137 *:* UDP 192.168.229.179:138 *:* UDP 192.168.229.179:1900 *:*

(10)

Firewalls 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.

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 !

ip access-group fromInternet in ip inspect Internet out

!

ip access-list extended fromInternet

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.

(11)

Firewalls 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 firewallfeature to implement these designs on Cisco IOS-based networking devices.

(12)

Designs

_{CHAPTER TWO}

Typical Zone-Based

Firewall Designs

In the preceding chapter, you saw how the philosophy of firewall design has evolved from packet-filter-oriented designs toward zone-based designs. In this chapter, we discuss several well-known firewall designs and describe the filtering policies used in them. These designs then serve as the blueprints for the following implementation chapters, in which you’ll see how you can translate a zone-based design directly into Cisco IOS configuration commands.

Simple LAN-to-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.

NOTE

Network designers who are already familiar with the zone-based firewall design principles can skip this chapter and continue to the imple-mentation section. All other readers are highly advised to read it, because a well-thought-out and well-documented design almost always results in superior imple-mentation. Simple LAN-to-Internet Firewall ...12 Firewall with Public Servers ...15 Redundant Firewall Designs...20 Complex Firewall Designs...20 Reducing the Complexity

(13)

Designs

Two firewall policies are commonly used in such setups:

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

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

example, web and mail services)

TABLE 2-1 Permissive Firewall Policy

Client Zone Server Zone Sessions Allowed

Inside Outside All

Outside Inside None

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

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

connec-tivity troubleshooting. FIGURE 2-1 Simple LAN-to-Internet firewall Outside Inside Internet NOTE

All the firewall policy tables in this book assume a stateful firewall implementation, so there are no special entries for the return packets.

(14)

Designs ■ 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.

TABLE 2-2 Restrictive Firewall Policy

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

Outside Inside None

The simple LAN-to-Internet firewall design successfully addresses the needs of small home offices and small companies (SOHO environment) that do not own e-mail or web servers. If customers want to run their own publicly accessible servers, however, the firewall policies have to be changed to allow incoming sessions (for example, incoming SMTP and HTTP sessions). Because of the many times hackers have successfully exploited publicly accessible servers to penetrate private networks, it’s almost a necessity to put such servers into a separate zone, as described in the next section.

NOTE

TCP ports needed for FTP data sessions are identified automatically by the stateful firewall implementations. If you’re not using a state-ful firewall, you need to allow TCP port 20, too, and advise the clients to use passive FTP.

NOTE

Most versions of Windows use ICMP to trace the path to the destination host. UDP packets as the trace packets are used by some UNIX environments (for example,Linux) as well as

(15)

Designs

_{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).

Outside Inside Perimeter Internet Web/Mail Server FIGURE 2-2 Simple firewall with a perimeter network

(16)

Designs

As in the preceding section, a firewall with a perimeter network can implement a permissive firewall policy, where the internal users can access any service on the public network, or a more restrictive one, as documented in Table 2-3. When designing a restrictive firewall policy, you must consider the implementation details of the DNS and e-mail serv-ices. DNS service can be implemented in the following ways:

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

server must be permitted.

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

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

■ The customer runs an authoritative DNS server for its domain in the perimeter network. This server usually acts as 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.

FIGURE 2-3 Transit perimeter network Outside Inside Internet Perimeter Web/Mail Server NOTE

Please refer to Bind 9 documentationfor an in-depth explanation of name server nomencla-ture.

(17)

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

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

commu-nicate with the outside world. In this case, bidirectional SMTP is required between the inside server and the perime-ter server and between the perimeter server and any host on the outside, assuming the perimeter server is using DNS Mail Exchange (MX) records to deliver outbound mail.

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

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

TABLE 2-3 Restrictive Policy of a Firewall with a Perimeter Network Client Zone Server Zone Sessions Allowed

Inside Outside ICMP echo, HTTP, HTTPS

(Optionally) FTP

Outside Inside None

Inside Perimeter HTTP (to access own public web server)

SMTP from inside mail server to perimeter e-mail server DNS

ICMP echo

FTP and SSH for server management

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

Perimeter Outside DNS

SMTP (to deliver outbound e-mail)

Outside Perimeter DNS (as the customer runs the authoritative name server for its domain) HTTP to public web server

SMTP to public mail server

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

(18)

Designs 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 elimi-nating any direct traffic between the internal network and the public Internet, as illustrated in Table 2-4.

TABLE 2-4 Policy of a Firewall with Proxy Servers in the Perimeter Network Client Zone Server Zone Sessions Allowed

Inside Outside None

Outside Inside None

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

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

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

SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web)

(Optional) FTP ICMP echo

Outside Perimeter DNS (only if the customer runs its own name server) HTTP to public web server

SMTP to public mail server

(Optional) FTP; see also comments in Table 2-3

The transition from the single-device design (Figure 2-2) to the design with a transit perimeter network (Figure 2-3) illus-trates one of the advantages of a well-documented zone-based design: Because all the firewall policies have already been

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.

(19)

Designs 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 Policy of the Inner Firewall

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

SMTP (to send mail)

FTP and SSH for server management.

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

TABLE 2-6 Policy of the Outer Firewall

SMTP from perimeter mail server (to deliver outbound e-mail) HTTP, HTTPS (proxy access to the web)

(Optional) FTP ICMP echo

Outside Perimeter DNS (only if the customer runs its own name server) HTTP to public web server

SMTP to public mail server (Optional) FTP

(20)

Designs

_{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.

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. Outside Inside Perimeter Web/Mail Server Internet FIGURE 2-4 Redundant firewall design

(21)

Designs ■ 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.

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

Inside Perimeter ICMP echo

VPN users HTTP to web servers

VPN offices SMTP to mail servers

DNS to name servers

Inside E-commerce ICMP echo

VPN users HTTPS to e-commerce servers

VPN offices

Inside Outside ICMP echo, HTTP, HTTPS, FTP

VPN users VPN offices

NOTE

This design uses a restrictive policy for inside clients with no HTTP proxy. For a less-restrictive policy or a policy with HTTP proxies, replace individ-ual items in Table 2-7 with entries from the previous sections. The design also assumes that the organization does not offer public FTP service.

(22)

Designs TABLE 2-7 Firewall Policy of a Complex Firewall continued

Client Zone Server Zone Sessions Allowed Administrators Perimeter HTTP to web servers

SMTP to mail servers DNS to name servers SSH to all servers FTP to all servers SNMP to all servers

Administrators E-commerce HTTPS, SSH, FTP, and SNMP to all servers Administrators Outside All services granted to inside users

Additional services if needed Administrators VPN users All (to support remote users) Administrators VPN offices All (to support remote offices) Perimeter Inside SMTP to internal e-mail server

Minimum set of ICMP traffic

SMTP

E-commerce Inside SQL transactions

VPN users Inside Access to a subset of internal servers

RADIUS from VPN concentrator to authentication server Outside VPN users IPsec traffic (ISAKMP + ESP)

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

RADIUS from VPN concentrator to authentication server Outside VPN offices IPsec traffic (ISAKMP + ESP)

NOTE

Missing zone pairs in the table indicate that no traffic is allowed between those zones. For

example, the e-commerce servers cannot initiate sessions to the outside zone, further limiting complex exploits.

(23)

Designs 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.

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.

FIGURE 2-5 Complex firewall design Outside Perimeter Web/Mail Server Internet E-commerce Administrators Inside VPN Users VPN Offices

(24)

Designs

The firewall policy of each individual smaller firewall is significantly less complex than the overall policy because it contains fewer security zones. Furthermore, the designer can now implement different physical setups for each firewall based on its resiliency and availability requirements. For example, under budget restrictions, the e-commerce firewall could be implemented as a redundant transit perimeter firewall design (see the section “Redundant Firewall Designs” 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.

Internet E-commerce Perimeter VPN Users VPN Offices Encrypted Outside Inside and Administrators VPN Firewall E-commerce Firewall Perimeter Firewall FIGURE 2-6 Decomposed complex firewall NOTE

The firewall design is further simplified by the intended traffic flow: Traffic from VPN users first enters the inside network and is then addi-tionally screened by the perimeter firewall.

(25)

Designs

_Summary

In this chapter, you have seen how you can use zone-based firewall design principles to design a variety of firewall solu-tions, ranging from simple firewalls suitable to SOHO environments to complex redundant solutions deployed by large organizations. In the next chapters, you’ll find out how you can use the zone-based policy firewall configuration feature of Cisco IOS to translate these designs into actual router configuration commands.

(26)

Policy Firewalls

in Cisco IOS

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.

Outside Inside Internet 10.0.0.2 10.0.0.3 10.0.0.0/24 dns.isp.com 172.16.0.1 smtp.isp.com 172.16.0.2 www.web.com 172.18.25.10 172.16.10.32/28 10.0.0.1 _{192.168.201.6} FIGURE 3-1 Sample firewall with addressing

Initial Zone-Based Policy

Firewall Configuration ...30 Limiting

Inside-to-Outside Traffic...37 Protecting the Router...43 Monitoring and

Debugging Zone-Based

(27)

Policy Firewalls in Cisco IOS

As you can see in the diagram, the inside LAN is using the private address space 10.0.0.0/24 that is translated using 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.

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

NOTE

The configuration in Listing 3-1 is slightly abridged. (For example, vty and console configu-ration has been removed.) It has also not been prop-erly secured. (For example, Finger and HTTP are enabled, and Telnet is used rather than SSH.)

(28)

LISTING 3-1 Initial Router Configuration continued description Link to the Internet

ip address 192.168.201.6 255.255.255.252 ip nat outside frame-relay interface-dlci 100 ! ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100 ! ! ip http server no ip http secure-server

ip nat pool Internet 172.16.10.34 172.16.10.46 prefix-length 28 ip nat source list InternalHosts pool Internet

ip nat inside source list InternalHosts pool Internet !

ip access-list standard InternalHosts permit 10.0.0.0 0.0.0.255

! end

The configuration seems pretty secure by itself, because NAT should be able to hide inside hosts from potential intruders. An initial port scan done from the outside (results are shown in Listing 3-2) seems to confirm this assumption, because the potential intruder can reach only one IP host (the router itself).

NOTE

nmap, a public-domain program available from

www.insecure.org, is used to perform the port scans. Printouts are abridged for clarity. Do not perform

port scans on external IP hosts without the owner’s permission.

(29)

LISTING 3-2 External Port Scan with No Active Host

External$ nnmmaapp ----ssyysstteemm--ddnnss 117722..1166..1100..3322//2288

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

23/tcp open telnet 79/tcp open finger 80/tcp open http

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

However, after an inside client establishes any session across the firewall router, its IP address becomes available to the outside world. Because the router offers no additional protection beyond address translation, the intruders have free access to the inside hosts, as documented in Listing 3-3. (Focus on the highlighted lines; the others are the publicly accessible router services.)

LISTING 3-3 External Port Scan with Active NAT Translations

External$ nnmmaapp ----ssyysstteemm--ddnnss 117722..1166..1100..3322//2288 Interesting ports on 172.16.10.33:

Interesting ports on 172.16.10.34:

135/tcp open msrpc

(30)

LISTING 3-3 External Port Scan with Active NAT Translations continued 139/tcp open netbios-ssn

445/tcp open microsoft-ds 3389/tcp open ms-term-serv 5800/tcp open vnc-http 5900/tcp open vnc

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

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

Initial Zone-Based Policy Firewall Configuration

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

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

Step 2. (Optional) Use the class-map type inspect global configuration commands to define the traffic classes based on specifications from the firewall design. A traffic classis a way of identifying a set of packets based on their content (for example, common application layer protocol).

Step 3. Use the policy-map type inspect global configuration command to specify the firewall policy (what happens to each interesting traffic class defined previously with class-map type inspect commands).

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

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

zone-member security interface configuration command.

NOTE

Class map definitions are mandatory unless you want to rely on the system-defined

class-default class, which

(31)

Policy Firewalls

in Cisco IOS IMPORTANT

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

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

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

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

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

security interface configuration command.

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

appro-priate policy map and zone pairs.

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

as Context-Based Access Control [CBAC]) feature. Remove the ip inspect interface configuration command before applying the zone-member security command.

■ The zone-based policy firewall can coexist with Cisco IOS Firewall stateful inspection. You can still use the ip inspect command on interfaces that are not members of security zones.

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

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

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

command.

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

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

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

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

configured. (Cisco IOS Firewall stateful inspection entries and access list entries are or-ed together.) The zone-based policy firewall does not change the access lists. (The interzone policy is and-ed with the access list.) Review the access list usage before using the zone-member commands.

(32)

Policy Firewalls

in Cisco IOS

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

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.

NOTE

Class default is always the last class in a policy map. It thus applies only to traffic not covered by other class maps.

(33)

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

to log the rejected packets.

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

command.

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

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

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

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

LISTING 3-5 Creating Firewall Policy

policy-map type inspect InsideToOutside class class-default

inspect !

zone-pair security InsideToOutside source Inside destination Outside service-policy type inspect InsideToOutside

Assigning Interfaces to Security 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.

NOTE

There is no need for an outside-to-inside zone pair because there are no

inside servers that would

be accessible from the

(34)

LISTING 3-6 Initial Zone-Based Policy Firewall Configuration

policy-map type inspect InsideToOutside class class-default

inspect !

zone security Inside

!

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.

(35)

LISTING 3-7 Scanning the Protected LAN from the Outside

External$ nnmmaapp ----ssyysstteemm--ddnnss 117722..1166..1100..3322//2288

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2006-07-29 23:41 Interesting ports on 172.16.10.33:

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$ nnmmaapp --vv ----ssyysstteemm--ddnnss wweebb..ccoomm

Interesting ports on web.com (172.18.25.10):

21/tcp open ftp 25/tcp open smtp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 443/tcp open https 445/tcp open microsoft-ds 1026/tcp open LSA-or-nterm continues

(36)

LISTING 3-8 Scanning an External Web Server from the Inside continued 3389/tcp open ms-term-serv

5800/tcp open vnc-http 5900/tcp open vnc

Nmap finished: 1 IP address (1 host up) scanned in 277.339 seconds Raw packets sent: 1958 (86.132KB) | Rcvd: 1685 (77.510KB)

Deploying a zone-based firewall has an additional unexpected benefit: Because all the traffic between zones is inspected, a port scan almost always triggers alerts and corresponding log messages (displayed in Listing 3-9).

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

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

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

Configuration Command Summary

(37)

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

Command Syntax Description

zone security name Creates a new security zone.

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

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

class name Within a policy map, starts configuring firewall actions for the specified traffic class.

class class-default Within a policy map, starts configuring firewall actions for all unclassified traffic. The class class-default command should be the last class specification in the policy map.

inspect Within a traffic class configuration, permits traffic and requests packet inspection to establish automatic conduits for return traffic (equivalent to the ip inspect command of Cisco IOS Firewall stateful inspection).

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

drop [log] Drops the packets of the selected traffic class with optional logging to the router’s log. police rate bps burst burst-size Rate-limits traffic within the specified traffic class to the specified bits-per-second rate with a

specified maximum burst size.

Limiting Inside-to-Outside 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 Zone-Based Firewall Designs”). To reach that goal, we first have to define the traffic classes that will later be used in the

(38)

policy-map commands to define the desired firewall policy. The traffic classes are defined with the well-known class-map command augmented with the type inspect keyword.

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

access lists, or based on well-known Layer 4 (TCP, UDP, ICMP, and so on) or Layer 7 (SMTP, HTTP, FTP, and so forth) protocols. Table 3-2 shows the syntax of the class-map command and the associated match commands.

TABLE 3-2 Syntax of the ccllaassss--mmaapp ttyyppee iinnssppeecctt and Associated mmaattcchh Commands

Command syntax Description

class-map type inspect Starts configuration of the named class map. The traffic matched by the class map has to [match-all | match-any] name match all the specified match conditions (match-all option, also the default behavior) or

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

match access-group Matches traffic permitted by the specified access group. You can use numbered or named {ACL-number | name ACL-name} IP access lists.

match protocol Matches any packet of the specified Layer 4 protocol. {tcp | udp | icmp}

match protocol protocol-name Matches the specified Layer 7 protocol based on its Layer 4 port number (specified as the Layer 7 protocol name in the configuration). Protocols operating on nonstandard ports or user-defined protocols can be specified with the ip port-map command, covered in Chapter 5.

match class-map name Matches traffic specified by a previously defined class map. This command is useful 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.

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

NOTE

Class maps using these parameters are known as Layer 4 class maps. Cisco IOS also supports deeper inspection of HTTP, IMAP, instant messaging (AOL, MSN, Yahoo!), and peer-to-peer (edonkey, fasttrack, gnutella, kazaa) proto-cols. Those class maps are called Layer 7 class maps and are covered in a later section.

(39)

Policy Firewalls

in Cisco IOS ■ 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

(40)

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

(41)

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

!

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.0 ip nat inside

zone-member security Inside !

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).

(42)

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

Inside$ nnmmaapp ----ssyysstteemm--ddnnss 117722..1166..00..00//2288

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

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

21/tcp open ftp 53/tcp open domain 80/tcp open http

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

25/tcp open smtp 53/tcp open domain 110/tcp open pop3

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

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

Inside$ nnmmaapp ----ssyysstteemm--ddnnss wwwwww..wweebb..ccoomm

Interesting ports on web.com (172.18.25.10):

21/tcp open ftp 80/tcp open http 443/tcp open https

(43)

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

inspec-tion does. Therefore, special precauinspec-tions must be taken to ensure that there are no undesired side effects from apply-ing access lists on interfaces assigned to security zones.

Zone-based policy firewall configuration in Cisco IOS offers a novel approach to this problem: The router itself can be defined as a separate security zone (with the predefined name self), and the incoming and outgoing sessions can be limited in the same way as the routed interzone traffic.

(44)

Policy Firewalls

in Cisco IOS 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

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

NOTE

A more complex router protection policy will be developed in the next chapter. A more security-conscious environment would also not allow full

(45)

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

(46)

LISTING 3-16 Protecting the Router with the Self Zone continued permit tcp any any eq www

permit tcp any any eq 443 ! https 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).

(47)

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

Inside$ nnmmaapp ----ssyysstteemm--ddnnss 1100..00..00..11 Interesting ports on fw (10.0.0.1):

23/tcp open telnet 80/tcp open 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$ nnmmaapp ----ssyysstteemm--ddnnss 117722..1166..1100..3333

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).

(48)

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

fw#sshhooww zzoonnee sseeccuurriittyy zone self

Description: System defined zone

zone Inside

Description: Inside network Member Interfaces:

FastEthernet0/0

zone Outside

Description: Outside network Member Interfaces:

Serial0/0/0.100

If you would like to see more details about the configured traffic classes and interzone policies, the obvious commands are show class-map type inspect, show policy-map type inspect, and show zone-pair security. They display the speci-fied class map, policy map, or zone pair so that you don’t have to browse through the router configuration. More useful is the show policy-map type inspect zone-pair name command, which displays the traffic and usage statistics for a zone pair, as shown in Listing 3-20.

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

fw#sshhooww ppoolliiccyy--mmaapp ttyyppee iinnssppeecctt zzoonnee--ppaaiirr IInnssiiddeeTTooOOuuttssiiddee Zone-pair: InsideToOutside

Service-policy inspect : InsideToOutside

(49)

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 …

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.