8.5 CONCLUSIONS

Team-Fly

As of this writing, static and dynamic packet filtering are used and widely deployed on the Internet. There are at least three reasons for its success:

Packet filtering is a low-cost technology. We have seen that packet-filtering capabilities are already integrated into many commercial off-the-shelf (COTS) products (and will continue to be integrated in future COTS products).
The use of packet filtering is transparent to both application programs and users. There is no need to make an application program aware of (static or dynamic) packet filtering. This level of transparency is also available but more complicated to achieve for other firewall technologies.
Vendors have promoted the technology, since it is not based on cryptography and has not been export-controlled accordingly. This feature has allowed a worldwide distribution and promotion of products that make use of packet filtering.

Because of these advantages, it is possible and very likely that we will see a further proliferation and sophistication of packet-filtering techniques and corresponding implementations in the future. Stateful inspection and its integration in many networking products are one example of this trend.

But packet filtering is not a panacea for network security, particularly in the form in which it is currently implemented by many vendors. As a matter of fact, packet filters and screening routers suffer from a number of weaknesses and disadvantages [4]. The primary weakness relates to the complexity of correctly configuring and managing packet filter rules. There are two points here:

Correctly specifying packet-filtering rules is still a difficult and error-prone process.
Reordering packet-filtering rules makes correctly specifying rules even more difficult by turning a ruleset that works if evaluated in the order given into a ruleset that does not work. The difficulty is somehow related to the complexity of correctly setting up rules in knowledge-based expert systems.

In general, the way in which packet-filtering rules must be specified and the order in which they are applied are key determinants of how useful and powerful certain packet-filtering capabilities really are. Most implementations require the administrator to specify filters in ways that make the filters easy to parse and apply, but make them rather difficult for the administrator to fully understand and properly manage. Also, the configuration process requires intricate knowledge of TCP/IP networking and addressing. Note that most users still consider networking activities in terms of "connections," while packet filtering, by definition, is concerned only with IP packets (that eventually make up a connection or virtual circuit on a higher layer). For example, an inbound connection must usually be translated into at least two packet-filtering rules, namely, one for the inbound IP packets and one for the outbound packets. To make things worse, the concept of a connection is applied even when considering a connectionless protocol, such as ICMP, UDP, or UDP-based application protocols. This mismatch among the abstractions commonly used and the mechanisms provided by many packet-filtering implementations contributes to the difficulties of correctly and completely specifying packet-filtering rules.

As a result, network and firewall administrators may very well commit mistakes in setting up packet filter rules. Often, exceptions to rules must be made to allow certain types of access that normally would be blocked. Unfortunately, such exceptions make a packet-filtering ruleset so complex as to be unmanageable. For example, it is relatively simple and straightforward to specify a rule to block all inbound connections to a Telnet server that is running on port 23. If exceptions are made (i.e., if certain systems need to accept direct Telnet connections from the outside), then a rule for each system must be added to the ruleset. Sometimes the addition of certain rules may complicate the entire packet-filtering scheme. This is due to the fact that the simple syntax used in most packet-filtering implementations makes it easy for the screening router but difficult for the administrator.

Brent Chapman compares the task of specifying packet-filtering rules with the task of programming in assembly language [4]. Instead of being able to use some high-level language abstractions, the administrator is forced to produce a tabular representation of the packet-filtering rules. However, the desired behavior may or may not map on to a tabular representation. Fortunately, the industry direction is to make it more simple to specify packet-filtering rules. In addition, utilities and tools are being developed to test and validate packet-filtering rules, perhaps including test suites and automatic test case generators. There are also tools available that can be used to derive packet-filtering rules directly from a given router network specification.

In summary, the advantages of packet filters and screening routers are simplicity and low cost, whereas the disadvantages are related to the difficulties in setting up packet-filtering rules correctly, as well as the lack of user authentication. It is very important to note that any packet filter has to decide whether to forward or discard packets based on information that may not be authentic. Because the authenticity of an IP source address is not protected, a given host can spoof another host by simply changing the source IP address of the packets it sends out. The sequence number guessing attack described in Chapter 3 exploits this vulnerability. A countermeasure to reduce or even eliminate this vulnerability is cryptographic authentication, as implemented, for example, by the IP security authentication header (AH) mechanism (the IPsec AH mechanism is described in Chapter 14). Using such a mechanism, a screening router could be configured to drop and silently discard any IP packet that is not properly authenticated using a valid AH.

Team-Fly