The Downside of Routers as Firewalls
Robert Owen Thomas With the rush to be online, companies have sought a secure yet inexpensive method of connecting to the Internet. Because the firewall industry has exhibited product maturity only recently, many companies opted to utilize only a screening router as the corporate firewall. While this may have been the intelligent choice 2 years ago, it is now a penny-wise and pound-foolish solution. This column discusses the elementary aspects of router-based packet filtering and the alternatives provided by host-based firewalls. Packet Filtering Although routers provide packet-filtering services, it is important to understand how packet filtering works. This is accomplished through the use of Access Control Lists (ACLs) and the logging services that are provided. The packet filter, or ACL, provides a means of limiting both incoming and outgoing traffic. This filtering can be done at the IP level and at the UDP/TCP port level. A variety of "wildcard" options allows filtering to be done for a single host or an entire subnet of hosts. This bevy of options is deceptively granular and may lead one to the belief that no "evil" packets can pass this router-based gatekeeper. Packet filtering works when the router examines the header of each packet. If the source and destination IP addresses and ports pass the ACL table check, the packet is allowed to pass. If not, the packet is discarded. Note that this means the router must pass every packet up into its CPU, examine every ACL entry until it gets a match or exhausts the ACL table, then decide the fate of the packet. Examining a typical ACL table gives a better understanding of the filtering process. For example, assume that we have a screening router as the firewall for our Class B network, 133.7.0.0. While we do not want to filter outgoing traffic, we want to allow access from the Internet only to the HTTP port (TCP port 80) of our Web server, 133.7.1.2. The access list looks like this:
access-list 102 permit tcp 0.0.0.0 255.255.255.255 133.7.0.0 0.0.255.255 established access-list 102 permit tcp 0.0.0.0 255.255.255.255 133.7.1.2 0.0.0.0 eq 80 Here is a breakdown of each part of the first ACL:
access-list - Router OS command to enter an access list. 102 - Label or tag for this ACL group. permit - Allow the following access. (There are deny rules, as well.) tcp - This ACL entry applies to TCP-based access only. (There are udp-based rules, as well.) 0.0.0.0 255.255.255.255 - IP address of origin, in this case any IP address. 133.7.0.0 0.0.255.255 - IP address of destination, in this case our subnet. established - Allow established connections (i.e., connections that originated from a host within our subnet). An example would be a telnet session from an internal host to a host at an external ISP.
The first entry allows any established connections from the Internet (again, connections that originated from a host on our intranet) to continue. The second entry allows Internet-originated access only to the HTTP port of our Web server, 133.7.1.2. All other access is implicitly denied. The rule for our Web server seems safe enough. However, how do we know that the catchall established rule is secure? It is important, then, to understand just how a router determines if an incoming packet is for an established connection. This is done by examining the contents of the packet header. If the packet has the reset (RST) or acknowledge (ACK) bits set, it is assumed to be part of an established connection and is allowed to pass. Logging can be done through the use of IP accounting. IP accounting on most routers consists of the number of bytes and packets sent and received over a given interface on a source and destination IP address basis. However, traffic to the router, or traffic originating from the router, is not measured. Also, only outbound traffic on the selected interface is measured. Further, the amount of storage for such accounting data is limited by the physical RAM in the router. Filtering Limitations The packet filtering within a router suffers from some several limitations. These include performance concerns, spoofing issues, limited scalability, limited logging capabilities, and a dearth of incident reaction capabilities. Although routers are designed to quickly process packets, the introduction of even one ACL will cause potentially significant performance degradation. As explained earlier, an ACL entry forces the router to pass every packet up to the CPU for an ACL check. With even a mildly complex ACL, this can introduce a significant latency to packet processing. Now, instead of the speed of the WAN link being the bottleneck, the screening router becomes the network choke point. And, as an ACL table grows, the performance will exponentially worsen. Because of the way a router evaluates an "established" connection, it is easy to spoof. By simply setting the RST bits on a packet, a hacker can pass packets right through the router and probe the internal network. This gives the hacker important information regarding the topology of the internal network, and leaves the hacker a security hole through which to exploit such information. Code exists on the Internet today to perform this very exploit. Due to the potential for performance issues, as well as the complexity of ACL creation, scaling a screening router is a cumbersome task. As the needs of the internal network grow, it becomes increasingly difficult to create a working set of ACLs. Increased ACL complexity also increases the likelihood that a poorly written ACL will leave the internal network wide open to a hacker's attack. Unlike firewalls, which warn of filtering misconfiguration, a router will blindly allow any mix of poor or illogical ACLs to be utilized. Although the router does have some logging capability, it is slight at best. Due to the limited space available for logging, trend analysis is difficult. Although an attack may be logged, the information may be purged before an administrator can peruse the logs. The detail in the log is also poor, giving packets and bytes, but no packet content information. Further, attacks against the router itself (e.g., the infamous "land" attack) will go undocumented. Worse than limited logging is the inability of a router to react to that information. If an attack occurs, the router has no way of analyzing the logged data and launching a script to take remedial action, such as paging an administrator. Host-based Firewalls With the increasing complexity of Internet-based security attacks, a router simply is not effective enough as a packet filter. A host-based firewall provides a more robust platform for packet filtering. Additionally, the host-based firewall scales better, provides more effective logging, and can react to events such as trends and attacks. Host-based firewalls provide support for both filtering and proxying of services. Firewall syntax is easier to understand, and the software performs error checking on the filtering rules. Thus, a host-based firewall prevents many human errors and improves overall security. Also note that a firewall can be run on a host that has much greater CPU power than a router. That capability allows for more complex ACL lists, and reduces the performance impact of ACL complexity. The logging capabilities of a host-based firewall are extensive. The host-based firewall is not constrained by RAM but can commit its logging to both local disk and a remote host, thereby allowing longer trend analysis. Additionally, host-based firewall logs can be more detailed than those provided by routers. Firewall logs can include, in addition to the source and destination IP address, such things as the source and destination port. Even such things as email headers can be logged, allowing the administrator to seek out hacked email. Such copious logging can also help the administrator detect RST-packet attacks. A host-based firewall also is less vulnerable to attacks against the "established" rule set, such as FIN and RST attacks. This is because the firewall software can maintain a connection table in memory. When a packet comes in from the Internet, claiming to be a part of an established connection, the firewall looks in its connection table to ensure that the destination internal host did in fact launch a connection or packet to the external host. An example of this would be:
b. The firewall creates an entry in its table stating that there is an established connection between 133.7.1.15, port 33023, and 204.75.18.8 port 23. c. Packets received from 204.75.18.8 for 133.7.1.15 are checked against this table entry and the timeout that was set on the entry. Packets received after the expiration of the timeout (or after the connection is closed) are discarded.
In this manner, the firewall prevents a packet claiming to be part of an established TCP connection from passing through the gates unless it originates from the correct IP address and port. This is also true of UDP traffic, which although connectionless, does have an entry in the table with a timeout value. One of the important advances in firewall technology is the addition of event monitoring. This enables the host-based firewall to react to defined situations, in contrast to a router-based packet filter that lacks that capability. For example, the host-based firewall can email or page an administrator if it discovers an attack. Additionally, scripts can be written to have the firewall take any action deemed necessary, depending upon the depth of the attack. The firewall could even be configured to disable the Internet link in the case of an all-out attack. This gives the host-based firewall a real-time edge over the packet filtering router. Conclusions Although a packet filtering router does provide some protection against Internet-based attacks, the hacker community is well aware of the shortcomings of packet filtering routers. Additionally, the primary design focus of router vendors is on performance, not security. Thus, it is no longer safe to assume that router security cannot be defeated. Although it is clear that current host-based firewalls are superior to routers from a security perspective, a combination of the two often provides the best solution. A packet filtering router, configured with a limited number of simple ACL entries and combined with a well-designed host-based firewall, often provides the best combination of configuration control and security. About the Author
Rob Thomas is a long-time UNIX and networking geek specializing in information security. He can be reached at: robt@cymru.com, http://www.cymru.com/~robt.
|