Routers Running Zone Based Firewall

By now, you should see the value of prescreening traffic on your edge router and readily agree that using your edge router as a part of your layered security strategy will bring benefits to your network. Using the edge router as a choke point is certainly useful; however, there are some limitations to its use that might be important to you. Perhaps your company is involved in government contracts, so you must have the highest possible level of security. Or perhaps you work for the government. Regardless, the next level up in security is the use of Cisco Zone Based Firewall (ZFW) on the edge router.

Cisco IOS Software Release 12.4(6)T introduced ZFW, a new configuration model for the Cisco IOS Firewall feature set. This new configuration model offers intuitive policies for multiple-interface routers, increased granularity of firewall policy application, and a default deny-all policy that prohibits traffic between firewall security zones until an explicit policy is applied to allow desirable traffic.

Nearly all classic Cisco IOS Firewall features implemented before Cisco IOS Software Release 12.4(6)T are supported in the new zone-based policy inspection interface:

• Stateful packet inspection

• VRF-aware Cisco IOS Firewall

• URL filtering

• Denial-of-service (DoS) mitigation

Cisco IOS Software Release 12.4(9)T added ZFW support for per-class session/connection and throughput limits and application inspection and control:

• HTTP

• Post Office Protocol (POP3), Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol/Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

• Sun Remote Procedure Call (RPC)

• Instant Messaging (IM) applications:

• Microsoft Messenger

• Yahoo! Messenger

• AOL Instant Messenger

• Peer-to-Peer (P2P) File Sharing:

• Bittorrent

• KaZaA

• Gnutella

• eDonkey

Cisco IOS Software Release 12.4(11)T added statistics for easier DoS protection tuning.

Some Cisco IOS Classic Firewall features and capabilities are not yet supported in a ZFW in Cisco IOS Software Release 12.4(15)T:

• Authentication proxy

• Stateful firewall failover

• Unified firewall MIB

• IPv6 stateful inspection

• TCP out-of-order support

ZFW generally improves Cisco IOS performance for most firewall inspection activities. Neither Cisco IOS ZFW nor Classic Firewall includes stateful inspection support for multicast traffic.

Zone-Based Policy Overview

Cisco IOS Classic Firewall stateful inspection (formerly known as Context-Based Access Control, or CBAC) employed an interface-based configuration model, in which a stateful inspection policy was applied to an interface. All traffic passing through that interface received the same inspection policy. This configuration model limited the granularity of the firewall policies and caused confusion of the proper application of firewall policies, particularly in scenarios when firewall policies must be applied between multiple interfaces.

Zone-Based Policy Firewall (also known as Zone Policy Firewall, or ZFW) changes the firewall configuration from the older interface-based model to a more flexible, more easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface.

Firewall policies are configured with the Cisco Policy Language (CPL), which employs a hierarchical structure to define inspection for network protocols and the groups of hosts to which the inspection will be applied.

Zone-Based Policy Configuration Model

ZFW completely changes the way you configure a Cisco IOS Firewall inspection, compared to the Cisco IOS Classic Firewall.

The first major change to the firewall configuration is the introduction of zone-based configuration. Cisco IOS Firewall is the first Cisco IOS Software threat defense feature to implement a zone configuration model. Other features might adopt the zone model over time. Cisco IOS Classic Firewall stateful inspection (or CBAC) interface-based configuration model that employs the ip inspect command set is maintained for a period of time. However, few, if any, new features are configurable with the classical command-line interface (CLI). ZFW does not use the stateful inspection or CBAC commands. The two configuration models can be used concurrently on routers but not combined on interfaces. An interface cannot be configured as a security zone member and be configured for ip inspect simultaneously.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. ZFW’s default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from the stateful inspection’s model, where traffic was implicitly allowed until explicitly blocked with an ACL.

The second major change is the introduction of a new configuration policy language known as CPL. Users familiar with the Cisco IOS Software Modular quality-of-service (QoS) CLI (MQC) might recognize that the format is similar to QoS’s use of class maps to specify which traffic will be affected by the action applied in a policy map.

Rules for Applying Zone-Based Policy Firewall

Router network interfaces’ membership in zones is subject to several rules that govern interface behavior, as is the traffic moving between zone member interfaces:

• A zone must be configured before interfaces can be assigned to the zone.

• An interface can be assigned to only one security zone.

• All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone and traffic to any interface on the router.

• Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.

• To permit traffic to and from a zone member interface, a policy enabling or inspecting traffic must be configured between that zone and any other zone.

• The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.

• Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can be applied only between two zones.

• Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.

• If it is required that an interface on the box not be part of the zoning/firewall policy, it might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is wanted.

• From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).

• The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

Designing Zone-Based Policy Network Security

A security zone should be configured for each region of relative security within the network so that all interfaces assigned to the same zone will be protected with a similar level of security. For example, consider an access router with three interfaces:

• One interface connected to the public Internet

• One interface connected to a private LAN that must not be accessible from the public Internet

• One interface connected to an Internet service demilitarized zone (DMZ), where a web server, Domain Name System (DNS) server, and email server must be accessible to the public Internet

Each interface in this network will be assigned to its own zone, although you might want to allow varied access from the public Internet to specific hosts in the DMZ and varied application use policies for hosts in the protected LAN. This concept is demonstrated in Figure 8-3.

Figure 8-3 Basic Zone Firewall Topology

In this example, each zone holds only one interface. If an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone. In addition, the hosts’ traffic to hosts in other zones is similarly affected by existing policies.

Typically, the example network will have three main policies:

• Private zone connectivity to the Internet

• Private zone connectivity to DMZ hosts

• Internet zone connectivity to DMZ hosts

Because the DMZ is exposed to the public Internet, the DMZ hosts might be subjected to unwanted activity from malicious individuals who might succeed at compromising one or more DMZ hosts. If no access policy is provided for DMZ hosts to reach either private zone hosts or Internet zone hosts, the individuals who compromised the DMZ hosts cannot use the DMZ hosts to carry out further attacks against private or Internet hosts. ZFW imposes a prohibitive default security posture. Therefore, unless the DMZ hosts are specifically provided access to other networks, other networks are safeguarded against any connections from the DMZ hosts. Similarly, no access is provided for Internet hosts to access the private zone hosts, so private zone hosts are safe from unwanted access by Internet hosts.

Using IPsec VPN with Zone-Based Policy Firewall

Recent enhancements to IPsec VPN simplify firewall policy configuration for VPN connectivity. IPsec Virtual Tunnel Interface (VTI) and GRE+IPsec enable the confinement of VPN site-to-site and client connections to a specific security zone by placing the tunnel interfaces in a specified security zone. Connections can be isolated in a VPN DMZ if connectivity must be limited by a specific policy. Or, if VPN connectivity is implicitly trusted, VPN connectivity can be placed in the same security zone as the trusted inside network.

If a non-VTI IPsec is applied, VPN connectivity firewall policy requires close scrutiny to maintain security. The zone policy must specifically enable access by an IP address for remote sites’ hosts or VPN clients if secure hosts are in a different zone than the VPN client’s encrypted connection to the router. If the access policy is not properly configured, hosts that should be protected can end up exposed to unwanted, potentially hostile hosts.