Limitations of Packet Filtering

Reasons that packet filtering alone is not sufficient for network security include the following:

Firewalls Are Complex to Configure. Various public proclamations about penetration tests show that well over half of the firewalls regularly sampled are not properly configured. The ordering of packet filtering rules is particularly important.

Filters Can Operate Only on the Fields That Appear in the Network Packets. Some access control decisions require higher level knowledge that is only available after the data in the packets is assembled by the receiving application. It is unreasonable to presume that the same knowledge that exists in the application will be duplicated in the packet filtering code. Still, some firewall vendors provide general-purpose programming languages that can be used to strengthen the constraint capabilities of packet filters.

When Much of the Network Traffic Is Augmented with Cryptography for Integrity, Authenticity, and Privacy, Packet Filters Provide Less Value. If the traffic is cryptographically secured at the IP layer, packet filters can be applied on the receiving node after decryption. However, when application-level cryptography is applied, the packets are not decrypted until they reach the receiving application that is well past the packet filter in the IP stack.

Packet Filters Do Not Contain Application Specific Knowledge. For example, they cannot be used to limit who is allowed to log in to systems inside the network using telnet. Because user is an entity meaningful at the telnet application layer, the packet filter can limit only telnet connections at the granularity of the source IP address, rather than individual users on each IP address.

Application Proxies Provide Access Control

In addition to packet filters, a firewall should include proxies. An application proxy is an application that acts as a gateway between the untrusted and trusted network but does so at higher layers in the network stack. The application proxy can make access control decisions that are expressed in terms of objects and attributes that the proxy understands. Examples of application proxies include FTP, telnet, gopher, and HTTP.

A circuit proxy (or gateway) is a generic proxy that does not know the specifics of the application but performs a more generic set of capabilities. SOCKS (Koblas and Koblas, 1992) is one of the more popular circuit gateways. The TIS Gauntlet firewall provides generic UDP and TCP circuit gateways, too.

In general, proxies improve upon the applications that they replace by supporting more granular access control. Many firewall texts prefer to distinguish between proxies based on whether they rely on the following:

•  Modified user procedures

•  Modified clients

•  Transparency

Modified user procedures are rarely accepted and do not scale well. As an example, a user who needs to telnet from the trusted network to the untrusted network would be required to first log in to the proxy and then telnet from the proxy to the outside node. The second proxy type would avoid this inconvenience by requiring that each employee run a modified client program that would perform this additional step automatically. Concerns about this approach include scalability and cycle time. Supplying modified clients to thousands of users is difficult, and custom clients cost more to develop and may not be available.

Transparent proxies, best exemplified by the Gauntlet firewall from Trusted Information Systems, require neither modified procedures nor modified clients. Instead, the proxy runs on the firewall and transparently handles connections. A user on the inside initiates outbound connections just as if the firewall were not there. The application proxies running on the firewall intercept these outbound requests and deal with them according to configuration rules for the proxies. Because security decisions are being made at the application level, a very rich access control language can be used to regulate network traffic with application proxies. Any concepts or entities that are meaningful at the application level can appear in the access control rules. For example, one can limit FTP traffic so that only user Joe is allowed to GET files from IP address with a prefix of 7.88.99.

Generic proxies also exist for TCP and UDP; these proxies enable you to plug arbitrary client-server applications through the firewall. As with the specific proxies such as telnet, Lotus Notes, or Oracle SQL, access control rules can be defined to control which IP addresses, ports, or other packet values are allowed through these generic proxies.

Both packet filtering and proxies are needed in most environments to meet your security needs. Later, when you take a closer look at intrusion detection, you’ll see some pros and cons of both approaches. The IBM Firewall provides packet filtering, application gateways, and circuit gateways. The Gauntlet firewall also supports all three approaches and transparent circuit proxies. To take advantage of SOCKS, you need to modify your applications and bind them to the SOCKS library when you recompile.

Firewalls Provide IP Security

Almost every firewall today is equipped with a mechanism to provide secure IP traffic based on the IPsec standard. Interoperability tests are underway by various vendors to ensure that secure IP tunnels between vendors will work. Because the introduction of cryptography requires some notion of key management, unsurprisingly vendors distinguish themselves on whether they provide a useful key-management infrastructure. Support for X.509 certificates is mandatory because their use is increasing dramatically across the Internet. Firewall security policies based on the values in X.509 certificates are also appearing in products such as Gauntlet.