Content Filtering | Firewall Fundamentals

Many enterprises are beginning to concern themselves with the use of the corporate Internet connection by their employees. The unmanaged access to inappropriate or distracting web content can involve significant legal risk and may well jeopardize network security. Additionally, unmanaged access to web content typically results in significant reduction of employee productivity. These issues cannot be easily ignored by many companies.

One of the newer features being required of firewalls is the capability of filtering the content that passes through them. This filtering typically is defined as URL filtering, whereby the firewall is used either by itself or in conjunction with another appliance or software suite to control which websites users are allowed to visit. However, given that web content can range from the simple to the complex, firewalls typically offload the detailed evaluation and decision making to other devices, which is an excellent example of the limitations of a firewall being a selfcontained contentfiltering device. Rather, the firewall becomes a control point where the decision made by the evaluation device (whether it is a content engine or a filtering software suite) is applied to user traffic.

Implementing a URL Filter

Implementing URL filters is relatively straightforward. There are two typical ways to implement a URL filter. The first is to maintain a list of URLs that will be blocked on the firewall, typically in the format of an access control list (ACL). This can be a timeconsuming process for both the implementation and maintenance of the URL list. Additionally, because ACLs are typically stored in a flat file format, the firewall can be subjected to latency in permitting or denying traffic while a large ACL is being processed.

The second method is to utilize a thirdparty contentfiltering application running on a separate server from the firewall or on a content engine that is separate from the firewall to handle the actual building, maintaining, and configuring of the URL filter list. As previously mentioned, this allows the firewall to offload the processing and evaluation of traffic to the contentfiltering device, which enables the firewall to do what it does best, to serve as a control point for traffic, blocking content as defined by the contentfiltering device. Because this is the most efficient and effective way to perform content filtering with most firewalls, this is the situation that we detail in this chapter.

For most firewalls to be able to block specific content, they must have access to a database that contains a list of URLs that are prohibited; whenever a user opens a connection to one of these sites, the firewall blocks the connection. Given that the list can be quite extensive and that the enterprise's management may want to deny access to sites that are considered wasteful in terms of time, many higherend firewalls provide for the use of an external URL database system that can decide whether the connection should be permitted. Thus a specialized devicefor example, a content engine or a contentfiltering serverperforms all the processing of the traffic, which in turn allows the firewall to just provide the necessary enforcement by either permitting or denying the traffic as determined by the contentfiltering system.

The Cisco PIX Firewall can work in conjunction with two webfiltering software suites: WebSense and N2H2.

Note

In 2003, Secure Computing acquired N2H2 and integrated the N2H2 filtering software into their SmartFilter product. The Cisco documentation and command syntax still refers to N2H2, however, and for the sake of simplicity this book uses the term N2H2 to refer to both products, because the configuration for either is exactly the same.

To configure the PIX to enforce URL filtering, the administrator needs to first configure the PIX to work with the URLfiltering software suite by configuring the PIX with the IP address of the filtering server. For a WebSense server, the command is as follows:

[View full width]
 gandalf(config)# url-server (inside) vendor websense host 172.28.230.44 protocol TCP    version 1

You can specify either TCP or UDP for the protocol (TCP is recommended) as well as Version 1 or Version 4. The default for TCP is Version 1, whereas UDP only supports Version 4. For an N2H2 server, the command is as follows:

 gandalf(config)# url-server (inside) vendor n2h2 host 172.28.230.45 port 4005 protocol tcp

For N2H2, you can define the port and protocol to use. The default values are port 4005 and protocol TCP.

After you have identified the filtering server and defined how the firewall should connect to the filtering server, the next step is to configure the PIX firewall to actually filter URL traffic by running the following command:

 gandalf(config)# filter url http 0 0 0 0

In this case, the PIX firewall will filter all traffic that passes through the firewall. You can also configure the firewall to filter only specific subnets. For example, if you want to filter traffic from network 172.28.238.0/24 to any network, you run the following command:

 gandalf(config)# filter url http 172.28.238.0 255.255.255.0 0.0.0.0 0.0.0.0

When the PIX sees the outbound connection, it does not allow the return traffic from the web server back to the client until it has received a response from the URLfiltering server. When the filtering server approves the connection, the PIX allows the connection to complete back to the client. If the filtering server denies the request, the user is redirected to a block page indicating that access was denied and possibly the reason it was denied. Figure 14-1 shows this filtering.

Figure 14-1. URL Filtering with the Cisco PIX Firewall

The following is a description of the process in Figure 14-1:

The client sends the initial connection to the web server, which replies back as expected. This reply is held at the firewall, however, until a filtering determination has been made.
At the same time, the firewall connects to the filtering server using connection 2 to query the filtering server about whether the traffic should be permitted.
The filtering server replies to the firewall with whether the traffic should be permitted or denied.
If the filtering server approves the URL, it notifies the PIX firewall, and the firewall allows the return traffic to reach the client system. If the filtering server denies the URL, it notified the PIX firewall, and the firewall drops the return traffic, preventing it from reaching the client.

Maintaining URL Filters

One of the biggest problems with URL filtering is the maintenance required of the URL database. To help network administrators maintain their URL filters and keep them as up-to-date as possible, many vendors turn to a subscription service whereby the filtering server at the client site connects to a web server at the vendor's location and downloads a database of URLs with default settings associated with each URL. This service conveniently allows administrator to keep relatively current with new sites that they want to block as soon as possible. Additionally, administrators can configure the system to automatically download new URL databases periodically.

The only difficulty presented by these systems is that they rely on a third-party vendor to determine whether a URL is to be included in the database. In some cases, this reliance can lead to the blocking of legitimate websites that would not necessarily fall into the category of inappropriate during business hours or as a waste of employee time. Additionally, some URL lists may include one website but completely neglect the mirror located in another country. Administrators should use caution when deciding what category of URLs to block and what to allow through.

What to Do If. . .

Many of the more powerful URL-filtering software systems such as WebSense and N2H2 provide detailed reports of which user went to a particular URL or set of URLs. The problem, which is really a human resources issue, then becomes what to do when a user continuously violates the web policy as specified in the corporate network security policy. Network administration staff should not have to deal with the problem; instead, that staff should provide human resources with the necessary information to make an informed decision.