Cisco ACNS Software Caching Configuration Guide, Release 4.2 - Chapter 11: Configuring URL Filtering [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring URL Filtering

URL Filtering Overview

Order of Precedence of CLI Commands

URL Filtering with URL Lists

Custom Blocking Messages

URL Filtering and RADIUS Authentication

URL Filtering with the N2H2 Server

N2H2 Features Supported

N2H2 CLI Commands

N2H2 Status and Statistics Commands

N2H2 Configuration Through the Content Engine GUI

N2H2 Configuration and Restrictions

URL Filtering with the Websense Enterprise Server

URL Filtering with SmartFilter Software

Configuring URL Filtering

This chapter lists the different methods used to filter content based on URL lists. This chapter contains the following sections:

•URL Filtering Overview

•URL Filtering with URL Lists

•URL Filtering and RADIUS Authentication

•URL Filtering with the N2H2 Server

•URL Filtering with the Websense Enterprise Server

•URL Filtering with SmartFilter Software

URL Filtering Overview

Some enterprises have a requirement to monitor, manage, and restrict employee access to nonbusiness and objectionable content on the Internet. Employees or students can be allowed or denied access to websites, or can be coached with information about acceptable use of the Internet. By having a URL filtering scheme on Content Engines, organizations realize an immediate return on investment as a result of increased productivity and recaptured network bandwidth, while reducing legal liability.

The URL filtering features presented in this chapter allow the Content Engine to control client access to websites in any of the following ways:

•Deny access to URLs specified in a list.

•Permit access only to URLs specified in a list.

•Use an authentication server in conjunction with a URL filtering scheme

•Direct traffic to an N2H2 server for filtering.

•Direct traffic to a Websense enterprise server for filtering.

•Filter traffic with Secure Computing Corporation SmartFilterSoftware, Release 3.0.2 for Cisco Content Engine ACNS Software, Release 4.2.x.

Only one form of URL filtering can be active at a time.

Note The URL filtering feature in ACNS 4.x software differs from the URL filtering feature in other releases as follows: There is now an enable command option for the good-sites and bad-sites options; the URL list filenames and the customized blocking message directory name are now specified in the command-line interface; you can now use the url-filter local-list-reload EXEC command to dynamically refresh a local URL list; and bad-sites-block has been changed to bad-sites-deny.

Order of Precedence of CLI Commands

The url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request.

URL Filtering with URL Lists

You can configure the Content Engine to deny client requests for URLs that are listed in a badurl.lst file, or configure it to fulfill only requests for URLs in a goodurl.lst file.

Note The use of URL lists applies to requests in HTTP, HTTPS, and FTP protocols only.

To deny requests for specific URLs, follow these steps:

Step 1 Create a plain text file named badurl.lst.

In this file, enter the URLs that you want to block. The list of URLs in the badurl.lst file must be written in the form http://www.domain.com/ and delimited with carriage returns.

Step 2 Copy the badurl.lst file to the /local1 system file system (sysfs) directory of the Content Engine.

Note We recommend creating a separate directory under local1 to hold the bad lists, for example, /local1/filtered_urls.

Step 3 Use the url-filter bad-sites-deny command to point to the bad URL list.
Console(config)# url-filter bad-sites-deny local/local1/badurl.lst
Step 4 Use the url-filter bad-sites-deny enable command to actively deny the URLs.
Console(config)# url-filter bad-sites-deny enable 
To permit specific URLs to the exclusion of all other URLs, follow these steps:

Step 1 Create a plain text file named goodurl.lst.

In this file, enter the URLs that you want to exclusively allow. The list of URLs in the goodurl.lst file must be written in the form http://www.domain.com and delimited with carriage returns.

Step 2 Copy the goodurl.lst file to the /local1 sysfs directory of the Content Engine.

Note We recommend creating a separate directory under local1 to hold the good lists, for example, /local1/filtered_urls.

Step 3 Use the url-filter good-sites-allow command to point to the goodurl.lst file.
Console(config)# url-filter good-sites-allow local/local1/goodurl.lst
Step 4 Use the url-filter good-sites-allow enable command to actively permit only the good URLs.
Console(config)# url-filter good-sites-allow enable
Note When you update the badurl.lst or goodurl.lst file, use the url-filter local-list-reload EXEC command to recopy the URL list file to the Content Engine.

Use the no form of the command to disable blocking, Websense, or N2H2 permission requests (for example, no url-filter bad-sites-deny).

Custom Blocking Messages

The Content Engine with ACNS 4.2 software can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML page named block.html. Make sure to copy all embedded graphics associated with the custom message HTML page to the same directory that contains the block.html file. To enable the customized blocking message, use the url-filter custom-message command and specify the directory name.

To disable the custom message, use the no url-filter custom-message command.

The url-filter custom-message command can be enabled and disabled without affecting the good-sites-allow and bad-sites-deny configuration.

Note Do not use local1 or local2 as directories for custom blocking messages. Create a separate directory under local1 or local2 for holding the custom message file.

In the block.html file, objects (such as .gif, .jpeg, and so on) must be referenced within the custom message directory string /content/engine/blocking/url, as shown in the example below.

In the following example a block.html file displays a custom message This page is blocked by the Content Engine when the Content Engine intercepts a request to the blocked site.

Note Contact your administrator if you have any questions concerning access to the blocked site you requested.
<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE>

<H1>
<CENTER><BLINK>
P
R
A
D
E
E
P
'
S
</BLINK>
Blocked Page
</CENTER>
</H1>


<IMG src="/content/engine/blocking/url/my.gif">

This page is blocked by the Content Engine.

If a new block.html file is used, it will automatically display its new message without your having to reenter the url-filter custom-message command.

URL Filtering and RADIUS Authentication

When both HTTP request authentication using a RADIUS server and URL filtering are enabled on the Content Engine, users can be configured to bypass URL filtering using the user Filter-Id attribute in the RADIUS server database.

The following is an example of a user Filter-Id attribute entry in the RADIUS server database.
test        Password = "test"
            Service-Type = Framed-User,
            Filter-Id = "No-Web-Blocking"
The Filter-Id attribute is defined as either No-Web-Blocking or Yes-Web-Blocking. If blocking is not specified, Yes-Web-Blocking is the default RADIUS filter. Yes-Web-Blocking means that the request is subject to URL filtering and No-Web-Blocking means that the request is not subject to URL filtering.

For more information on RADIUS authentication see the "RADIUS HTTP Request Authentication" section.

URL Filtering with the N2H2 Server

N2H2 is a globally deployed URL-filtering software that can filter HTTP or HTTPS requests based on destination host name, destination IP address, and username and password. It relies on a sophisticated URL database exceeding 15 million sites and is organized into over 40 categories using both Internet technology and human review.

The Content Engine can perform URL filtering based on the N2H2 server. (See Figure 11-1.) The Content Engine and the N2H2 server use the Internet Filtering Protocol (IFP) Version 1 to communicate with each other. When the Content Engine receives a URL request, it sends an IFP request to the N2H2 server with the requested URL. The N2H2 server does some necessary lookups for the URL and sends back an IFP response. Based on the N2H2 server's IFP response, the Content Engine either blocks the HTTP request by redirecting the browser to a block page or proceeds with normal HTTP processing.

Figure 11-1 N2H2 Filtering

The filtering is applied to HTTP or HTTPS traffic before the Rules Template mechanism is applied, regardless of whether the requested object is in the cache or not. Filtering is applied to these traffic types:

•Proxy-style or transparent-style HTTP or HTTPS requests

•Proxy-style and transparent redirect proxy-style FTP over HTTP requests

N2H2 Features Supported

N2H2 supports three filtering methods. Table 11-1 lists the N2H2 features supported by the Content Engine. One N2H2 server can support multiple Content Engines simultaneously.

Table 11-1 N2H2 Features Supported

N2H2 Feature Name

Description

Global filtering

Applies filtering to all HTTP or HTTPS requests.

User-based filtering

Applies filtering to specific users or groups.

Client IP-based filtering

Applies filtering to specific client IP addresses.

N2H2 CLI Commands

The url-filter N2H2 server IP address [port 1-65535] [timeout 1-120] command configures the Content Engine to query the N2H2 server. The optional port field specifies the port on the N2H2 server to which the Content Engine should send IFP requests. The default port number is 4005. The optional timeout field (in seconds) specifies how long the Content Engine should wait for an IFP response from the N2H2 server. The default timeout is 5 seconds.

This command does not verify whether or not an N2H2 server is accessible at the specified IP address in the current implementation. The configuration can be changed while N2H2 is enabled. The Content Engine will adopt the new configuration at run time.

The url-filter N2H2 enable command enables the N2H2 server as the current URL filtering scheme. The command will not succeed if the server IP address is not configured, or if another URL filter is already enabled with N2H2 or other filtering schemes.

The url-filter N2H2 allowmode enable command allows HTTP or HTTPS requests to pass when the N2H2 server is enabled but the Content Engine has problems communicating with the N2H2 server. With allowmode enabled, if the Content Engine fails to receive responses from the N2H2 server successfully, the Content Engine still allows all traffic through (it proceeds with normal HTTP or HTTPS processing). With allowmode disabled, on the other hand, the Content Engine blocks all HTTP or HTTPS traffic through the Content Engine. By default, allowmode is enabled.

The allowmode option can be configured with or without N2H2 enabled and is independent of the N2H2 server configuration. The Content Engine adopts the new configuration for allowmode if N2H2 is already running.

N2H2 Status and Statistics Commands

The show url-filter command shows the URL filtering scheme enabled on the Content Engine and the configurations for each URL filtering scheme, such as the configuration data for N2H2.

In this example, the show url-filter command is used to display the URL filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter 
URL filter is DISABLED
Local list configurations
==================================
Good-list file name : 
Bad-list file name : 
Custom message directory : 
Websense server configuration
==================================
Websense server IP : <none>
Websense server port : 15868
Websense server timeout: 20 (in seconds)
Websense allow mode is ENABLED 
N2H2 server configuration
==============================
N2H2 server IP : <none>
N2H2 server port : 4005
N2H2 server timeout : 20 (in seconds)
N2H2 allow mode is ENABLED
The show statistics url-filter N2H2 command shows the request-reply statistics of the communication between the Content Engine and the N2H2 server. These statistics show the number of requests sent, replies received, pages blocked, pages allowed, and failure cases. More detailed URL filtering statistics are available on the N2H2 server.
whh-590# show statistics url-filter N2H2 
N2H2 URL Filtering Statistics:
 Lookup requests transmitted = 1021084
 Lookup response received = 1021080
 Requests BLOCKed by N2H2 = 0
 Requests OKed by N2H2 = 1021080
Allow Mode Statistics:
 No available connection = 1105
 Error sending lookup requests = 4
 Error recving lookup responses = 1
 Server error in responses = 0
Server Error in Responses:
 Error in Filter Server = 0
 Error in IFP server = 0
The statistics shown can be cleared using the clear statistics url-filter N2H2, clear statistics urlfilter, and clear statistics all commands.

The clear statistics url-filter N2H2 command resets the statistics counters for the N2H2 server. All the statistics counters are reset to 0.

N2H2 Configuration Through the Content Engine GUI

A user can choose N2H2 as the URL-filtering scheme through the Content Engine GUI and configure N2H2 server parameters such as the IP address, port number, timeout, and allowmode option.

N2H2 Configuration and Restrictions

Only one URL filtering scheme can be active at a time. In order to enable N2H2 URL filtering, you should first make sure that no other URL filtering scheme is configured. You can then configure the server information for N2H2 using the url-filter N2H2 server IP address [port 1-65535] [timeout 1-120] command and enabling the N2H2 server.

The server IP address and port number configured in the Content Engine must match the IP address of the N2H2 server and the port that N2H2 server listens to for IFP requests. If the configuration on the Content Engine does not match the configurations on the N2H2 server, the Content Engine will time out all HTTP or HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.

URL Filtering with the Websense Enterprise Server

The Content Engine can use a Websense enterprise server as a filtering engine and enforce the filtering policy configured on the Websense server. (See Figure 11-2.) Refer to the Websense Administrator's Guide located at http://www.websense.com for further information on Websense configuration instructions and filtering policies..

Figure 11-2 URL Filtering with a Websense Server

Before you enable Websense URL filtering on the Content Engine, configure the Websense server IP address or host name using the url-filter websense server command. The timeout option in this command sets the maximum amount of time that the Content Engine will wait for a Websense response. The timeout default is 20 seconds. The port option specifies the port number on which the server will accept requests from the Content Engine (the default port is 15868). Use the no url-filter websense server command to disable Websense server settings. Enable Websense URL filtering by entering the url-filter websense enable command after you have configured the Websense server.

The url-filter websense allowmode enable command permits the Content Engine to fulfill the client request after a Websense server timeout. With allowmode disabled, on the other hand, the Content Engine blocks all HTTP or HTTPS traffic through the Content Engine. By default, allowmode is enabled.

To use Websense URL filtering with a cluster of Content Engines, make sure to configure the url-filter websense server command on each Content Engine in the cluster to ensure that all traffic is filtered.

To configure a Content Engine to use Websense URL filtering with IP address 172.16.11.22, port 15900, and a 4-second timeout, enter these commands.
ContentEngine(config)# url-filter websense server 172.16.11.22 port 15900 timeout 4
ContentEngine(config)# url-filter websense enable
URL Filtering with SmartFilter Software

SmartFilter software for the Content Engine provides employee Internet management (EIM) functionality with proxy servers, firewalls, and caching appliances. The integrated Content Engine and SmartFilter product preserves all functionality available in a regular Content Engine. The SmartFilter filtering capability is available as an add-on service on the Content Engine, and the service may be enabled or disabled as desired through the Content Engine CLI or GUI.

The integrated Content Engine and SmartFilter product provides a one-box solution for server functionality. The Content Engine uses a suite of plug-in APIs to allow the SmartFilter software to implement hooks at strategic points during an HTTP transaction and thus provide URL filtering.

The integrated Content Engine and SmartFilter product provides an end user management tool called the sfadmin console. This GUI component downloads configurations into the Content Engine for use by the SmartFilter process.

To use SmartFilter URL filtering with a cluster of Content Engines, make sure to enter the url-filter smartfilter enable command on each Content Engine in the cluster to ensure that all traffic is filtered. Refer to the SmartFilter for Cisco Content Engine User's Guide for more information on how to configure the SmartFilter software in the ACNS 4.2 release.