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 firewall 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 Online or to the relevant Cisco IOS documentation.
Designing zone-based firewalls is a simple process using the following four steps:
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.
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
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.
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
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.
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.
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):
The client picks a random TCP port number (usually greater than 1024) as the source TCP port number.
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).
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.)
Example 1-1. Sample IP Packet Filter in an Early Cisco IOS Release
interface Serial0/0/0.100 point-to-point description Link to the Internet ip access-group fromInternet in ! ip access-list extended fromInternet ! prevent spoofing deny ip 10.0.0.0 0.0.0.255 any ! allow minimum subset of ICMP messages permit icmp any any echo permit icmp any any echo-reply permit icmp any any time-exceeded permit icmp any any packet-too-big permit icmp any any unreachable ! allow traffic to high-numbered ports permit tcp any 10.0.0.0 0.0.0.255 gt 1023 permit udp any 10.0.0.0 0.0.0.255 gt 1023
Note
Later Cisco IOS releases added the established keyword, which matched return traffic in TCP sessions, making recognition of TCP sessions much easier (but still leaving some gaps that hackers successfully exploited with skillfully crafted IP fragments). No such mechanism is possible for UDP traffic, so UDP is usually not permitted to freely flow between internal and external networks.
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.
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.
Example 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 *:*
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.
Example 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
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.
Example 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) --
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.
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.