Internet Content Filtering Architectures

Three predominant content-filtering architectures are in use today: client, server, and gateway content filtering. Each architecture type has its own unique pros and cons that address items such as cost, effectiveness, and manageability.

Client-Based Content Filtering

Client-based content filtering is designed to be implemented at the client desktop. Client-based content filtering works by maintaining a database of blocked websites that the user can download updates to via the Internet.

One of the appeals of client-based content filtering is that the initial cost is usually cheaper than the alternatives, particularly for small-to- medium- sized businesses. Unfortunately, the long term costs are usually much higher because of the maintenance costs associated with trying to manage and maintain the software running on hundreds or thousands of desktops. Client-based content filtering is great for home users or very small shops , but it does not scale very well. Finally, because the software is running on the client, it is more susceptible to users not downloading updates or shutting down the service completely, which can render it ineffective . Although your acceptable-use policy (AUP) should prohibit this type of behavior in the first place, the reality is that the content-filtering software prevents access that is prohibited by the AUP, and you still need it. If people are willing to browse inappropriate content, they certainly won t have problems disabling software that prevents it.

Some examples of client-based content-filtering solutions are Zone Labs ZoneAlarm (http://www.zonelabs.com/store/content/home.jsp), NetNanny (http://store.netnanny.com/dr/v2/ec_dynamic.main?sp=1&pn=12&sid=53), and Cybersitter (www.cybersitter.com). In addition, many ISPs are starting to provide content-filtering solutions integrated into their client software. I do not recommend implementing client-based content filtering in most circumstances, but if your environment is small, it might be an option worth investigating.

Server-Based Content Filtering

Server-based content filtering provides a centralized mechanism for controlling content coming in and out of the network. Server-based content filtering is typically a two-part solution: the database server platform and the firewall or gateway. This is known as a gateway integrated server-based content-filtering solution . The database server platform is where the actual content-filtering software and database reside, and it contains the rulesets that define what will and will not be permitted. The firewall or gateway is then configured to query the content-filtering server when it receives an outbound request and will either forward the packet to the Internet or return an access denied page based on the content-filtering policy. Figure 7-1 details the topology for a gateway integrated server-based content-filtering solution.

Figure 7-1: Gateway integrated server-based content-filtering solution

A variation of server-based content filtering does not include the integration of the content filter and the firewall or gateway. Instead, the content-filtering server is configured on the network so that it can observe all the traffic on a segment. The content-filtering server will then intercept the web requests and determine whether the content is permitted or denied. If it is permitted, it is passed on to the Internet. If it is denied, the content server responds with an access denied page. Figure 7-2 demonstrates the topology of this configuration.

Figure 7-2: Standalone content-based filtering solution

One Step Further

For a content-filtering server to work in this fashion, it must be able to view every web request. Implementing a hub and connecting the content filter to the hub will not be a problem because the hub transmits the data signal to all ports. However, if you implement a switch, you will need to ensure that you have configured your switch with a monitor port for the content-filtering server to connect to, and this port must mirror all traffic to and from the Internet. If you do not do this, the content-filtering server will not be able to protect your network.

 

One of the benefits of a server-based content-filtering solution is that it is much easier to manage and maintain than a client-based solution. You merely need to update the server configuration and, by default, the clients are affected by the change. The server-based content-filtering solution also scales much better than a client-based solution because it is simply a matter of upgrading the server hardware in the event that the server begins having performance problems. A drawback of server-based solutions is increased cost. In addition to the cost of a firewall, these solutions typically require a dedicated server, and that server may need to be an extremely powerful server (or even a cluster of servers) in large environments.

Some examples of server-based content-filtering are Websense (www. websense .com), N2H2 (www.n2h2.com), and SurfControl (www.surfcontrol.com), all of which can operate in both modes.

I highly recommend server-based solutions; in fact, this chapter contains configuration examples for all three of these content-filtering solutions.

Heads Up

If you do not integrate your content-filtering server with your gateway or firewall, it functions by essentially sniffing the network to detect what traffic is passing. If it detects traffic that should be blocked, it generates a blocking packet, preventing the traffic from being received by the end-user system, and instead returns an access denied page. This is not a perfect situation, however, because often the page will initially load the first time someone attempts to connect to the website due to latency in the sniffing-to-blocking process. However, if the user then attempts to refresh the page, it will then be blocked, as will all subsequent connection attempts. This is referred to as sneak and peek because the user can potentially sneak access a website, even though they shouldn't be able to, and peek at the content the first time they connect. This only occurs when SurfControl is not integrated with a gateway or firewall. If you need to ensure that under no circumstances should a user be able to even view disallowed content, you will need to integrate SurfControl with one of the firewall/gateway devices it supports, such as one of the following:

• Microsoft ISA Server

• Novell BorderManager

• Microsoft Proxy Server

• Check Point Firewall-1

• Nokia IPSO 3.5 and higher

• Linux Kernel 2.4 of later and glib 2.2 or later

 

Gateway-Based Content Filtering

Gateway-based content filtering functions in a very similar fashion to server-based content filtering. It attempts to eliminate the drawback of server-based content filtering by removing the need for a dedicated external server and placing the content-filtering functionality into the firewall or gateway device. This can make for an even easier management task because the firewall and content-filtering functionality are centrally managed typically with the same management interface. The primary drawback of this type of system is that you are essentially placing all your eggs in one basket . If the content filter fails for some reason, you may need to take the firewall down to repair or replace it, which you would not have to do with a server-based solution. As a result, gateway-based content-filtering solutions are particularly suited for small-to-medium-sized environments and environments that cannot afford the cost of a server-based solution. However, if you require a separation of functions in your devices for either security or reliability reasons, a gateway-based content filter may not be the best choice.

Some examples of gateway-based content filters are Fortinet (www.fortinet.com), Symantec (www. symantec .com), and SonicWALL (www.sonicwall.com).

I recommend gateway-based content filters if you cannot afford a server-based solution or if you do not need the separation of resources in your gateway device.