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

Table Of Contents

Configuring URL Filtering

URL Filtering Overview

Custom Blocking Messages

URL Filtering with URL Lists

Examples of URL Filtering with URL Lists

URL Filtering with the N2H2 Server

N2H2 Features Supported

N2H2 CLI Commands

N2H2 Status and Statistics Commands

N2H2 Configuration and Restrictions

URL Filtering with the Websense Server

Websense Configuration and Restrictions

Downloading Websense Components and Obtaining an Evaluation Key

Saving Websense Configuration Files

Configuration of Ports for the Websense Server

Configuring the Local Websense Server Using the Content Engine GUI

Enabling and Disabling the Local Websense Server Using the Content Engine GUI

Configuring Websense URL Filtering Using CLI Commands

Configuring the Local Websense Server Using CLI Commands

Configuring the Websense Client Using CLI Commands

Websense Status and Statistics Commands

URL Filtering with SmartFilter Software

RADIUS and URL Filtering

Configuring URL Filtering on the Content Engine

Configuring URL Filtering

This chapter describes the different types of URL filtering supported on a Content Engine. It also describes how to configure URL filtering on a locally deployed Content Engine. This chapter contains the following sections:

•URL Filtering Overview

•URL Filtering with URL Lists

•URL Filtering with the N2H2 Server

•URL Filtering with the Websense Server

•URL Filtering with SmartFilter Software

•RADIUS and URL Filtering

•Configuring URL Filtering on the Content Engine

Note For complete syntax and usage information for the CLI commands used in this chapter, refer to the Cisco ACNS Software Command Reference, Release 5.1.

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.

Note To ensure that URL filtering applies to every URL that passes through the Content Engine, disable all bypass features. By default, the load bypass is enabled. To use the Content Engine GUI to disable load bypass, choose Caching > Bypass and then click the Load Bypass Off radio button in the Bypass window. To use the CLI to manually disable load bypass, use the bypass load command. To use the CLI to manually disable error handling, which is also enabled by default, use the error-handling send-cache-error or error-handling reset-connection command.

As Figure 13-1 shows, the URL filtering feature allows a 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.

•Direct traffic to an N2H2 server for filtering.

•Direct traffic to either a local Websense plug-in or an external Websense server for filtering.

•Direct traffic to the SmartFilter plug-in for filtering.

Figure 13-1 Different Types of Supported URL Filtering

Although only one form of URL filtering scheme per protocol can be active, many URL filtering schemes can be supported at one time. In other words, if an N2H2 filter is applied to HTTP URLs, no other URL filtering scheme, such as Websense or SmartFilter, can be applied to this protocol, such as Websense or SmartFilter. However, the use of good lists and bad lists can be applied to streaming media protocols. The scheme enabled for a particular protocol is independent from that of other protocols.

Note Implementing URL filtering with third-party software such as the SmartFilter product or using a server such as N2H2 or Websense is only applicable to the HTTP, HTTPS, and FTP protocols.

Custom Blocking Messages

The Content Engine can be configured to return a customized blocking message to the web 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 http custom-message command and specify the directory name.

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

The url-filter http 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 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.

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.

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 the block.html file is updated, it will automatically display its new message without your having to reenter the url-filter http custom-message command.

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. The use of URL lists applies to requests in HTTP, HTTPS, and FTP format as well as streaming media protocols such as MMS and RTSP.

Tip Only one good sites file or one bad sites file can be active at one time per protocol.

The local list file for each protocol should not contain URLs that belong to other protocols. For instance, the HTTP local list file should contain only HTTP, HTTPS, or FTP URLs, and the WMT local list file should contain only MMS URLs.

Caution If the size of the local list file is too large, it can affect the device performance, because the file is loaded into memory when local list file filtering is enabled. If the size of the file is larger than 5 megabytes, a warning is issued by the device to notify you of the impact on performance.

Examples of URL Filtering with URL Lists

To deny requests for specific HTTP 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 be delimited with carriage returns.

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

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

Step 3 Use the url-filter http bad-sites-deny command to point to the bad URL list.
Console(config)# url-filter http bad-sites-deny file local/local1/badurl.lst
Step 4 Use the url-filter http bad-sites-deny enable command to actively deny the URLs.
Console(config)# url-filter http bad-sites-deny enable 
To permit specific HTTP 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 be delimited with carriage returns.

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

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

Step 3 Use the url-filter http good-sites-allow file command to point to the goodurl.lst file.
Console(config)# url-filter http good-sites-allow file local/local1/goodurl.lst
Step 4 Use the url-filter http good-sites-allow enable command to actively permit only the good URLs.
Console(config)# url-filter http 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 reload the URL list file to memory.

URL Filtering with the N2H2 Server

Note URL filtering with the N2H2 server, Websense server, and SmartFilter software works only with HTTP, FTP, or HTTPS protocols.

N2H2 is a globally deployed URL-filtering solution that can filter HTTP, FTP, or HTTPS requests based on destination host name, destination IP address, and user name 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. Refer to http://www.n2h2.com for further information on N2H2 filtering products.

The Content Engine can use an N2H2 enterprise server as a filtering engine and enforce the filtering policy configured on the N2H2 server. (See Figure 13-2.) The Content Engine and the N2H2 server use Internet Filtering Protocol (IFP) Version 2 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 page where a blocking message is displayed or proceeds with normal HTTP processing by sending the URL request to an origin server.

Figure 13-2 N2H2 Filtering

URL filtering using an N2H2 server is applied to HTTP, FTP, 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 13-1 lists the N2H2 features supported by the Content Engine. One N2H2 server can support multiple Content Engines simultaneously.

Table 13-1 N2H2 Features Supported

N2H2 Feature Name

Description

Global filtering

Applies filtering to all HTTP, FTP, or HTTPS requests.

User-based filtering

Applies filtering to specific users or groups.

Client IP-based filtering

Applies filtering to specific client IP addresses.

Transparent authentication

Performs transparent authentication by passing back the initial response header to the client using the HTML page in IFP responses.

N2H2 CLI Commands

The url-filter http 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 http N2H2 enable command enables the N2H2 server as the current URL filtering scheme.

The url-filter http N2H2 allowmode enable command allows HTTP, FTP 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 traffic processing). With allowmode disabled, on the other hand, the Content Engine blocks all 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 http 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 http command is used to display the status of all HTTP URL filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter http
URL filtering is set to use bad-list
Local list configurations
==================================
Good-list file name : 
Bad-list file name : /local1/url-filter/badlist.http
Custom message directory : 
Websense server configuration
==================================
Websense server IP : 172.16.193.165
Websense server port : 15868
Websense server timeout: 20 (in seconds)
Websense allow mode is ENABLED 
N2H2 server configuration
==============================
N2H2 server IP : 172.16.193.165
N2H2 server port : 4005
N2H2 server timeout : 5 (in seconds)
N2H2 allow mode is ENABLED 
ContentEngine#
The show statistics url-filter http 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.
ContentEngine# show statistics url-filter http n2H2 
N2H2 URL Filtering Statistics:
 Lookup requests transmitted = 144
 Lookup response received = 144
 Requests timed out = 0
 Number of retransmits = 0
 Requests BLOCKed by N2H2 = 52
 Requests OKed by N2H2 = 92
Allow Mode Statistics:
 No available connection = 0
 Error sending lookup requests = 0
 Error recving lookup responses = 0
 Server error in responses = 0
Server Error in Responses:
 Error in Filter Server = 0
 Error in IFP server = 0
 Seq number mismatch = 0
 Multiple responses rcvd = 0
TCP error statistics:
 Bad network endpoint = 0
 Network unreachable = 0
 Underlying connection broken = 0
 Timeout specified is reached = 0
 Address already in use = 0
 Client connection broken = 0
 Client connection timeout = 0
 Server connection broken = 0
 Server connection timeout = 0
 Register read cancelled = 0
 Other errors = 0
Queue statistics:
 Number of xacts in Queue = 0
Overhead statistics:
 Avg total process time = 17
 Avg response time = 17
 Socket update count = 0
ContentEngine#
The statistics shown can be cleared using the clear statistics url-filter http N2H2 and clear statistics all commands.

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

Note Refer to http://www.n2h2.com for further information on N2H2 filtering configuration and policies.

N2H2 Configuration and Restrictions

Only one URL filtering scheme per protocol 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, FTP, or HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.

URL Filtering with the Websense Server

The Content Engine can use a remote Websense enterprise server as a filtering engine and enforce the filtering policy configured on the Websense server. (See Figure 13-3.)

Figure 13-3 URL Filtering with a Remote Websense Server

Cisco ACNS 5.1 software supports Websense server Version 5.0.1 on all Cisco Content Engine platforms. The integrated Websense server runs internally to the Content Engine (as opposed to running on a separate system and communicating with the Content Engine over the network).

Websense Configuration and Restrictions

This section contains information regarding Websense configuration and restrictions.

Note For the latest information about Websense configuration and restrictions with an ACNS 5.x Content Engine (including disk space requirements), refer to the Release Notes for Cisco ACNS Software, Release 5.1.

For more detailed information about configuring the Websense software, go to the following website: http://www.websense.com

When the Websense server is enabled and the Websense URL database is downloaded to the Content Engine for the first time, CPU usage will be high. Therefore, it is recommended that you enable the Websense server during off-peak times or at times of low network traffic, otherwise other processes running on the Content Engine may be affected. When the Websense server stalls, it is automatically restarted.

Websense provides an image of the Websense server that resides in the /local/local1/WebsenseEnterprise/EIM directory on the Content Engine. All the executables as well as the configuration and logging files are stored in this directory.

When configuring an external Websense server, you must specify an IP address and port number for that server. The specified IP address and port number of the external Websense server on the Content Engine must match the IP address of the external Websense server and the port that the external Websense server listens to for filtering requests.

Note The IP address of the local Websense server cannot be configured and is set at 127.0.0.1. By default, the local Websense server is configured to accept requests on port 15868.

If the Content Engine configuration of the external Websense server does not match the configuration on the external Websense server (the IP address and port number), the Content Engine will time out all HTTP, FTP, or HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.

In order to enable Websense URL filtering, you should first make sure that no other URL filtering scheme is enabled per protocol. You can then configure the information for the Websense server using the url-filter http websense server ip address [port 1-65535 [timeout 1-120 [connections 1-250]]] command and enabling the Websense server with the url-filter http websense enable command.

Downloading Websense Components and Obtaining an Evaluation Key

To download the Websense components, such as Explorer, Manager, and Reporter, or to obtain an evaluation key for using with the Websense server that runs on the locally deployed Content Engine, access the following URL and follow the sequence of steps:

http://www.websense.com/downloads

Saving Websense Configuration Files

In ACNS 5.x software releases, the write memory command has been enhanced to save modified Websense configuration files (eimserver.ini and config.xml) across disk reconfiguration and ACNS software release upgrades.

You must execute the write memory command in order to save the most recent configuration modifications, including websense.ini file modifications and Websense URL filtering configuration changes. The write memory command enables the changes made from the external Websense Manager GUI to be saved across disk reconfiguration and upgrades (which might erase disk content).

If the write memory command is not used before a reboot but after a disk reconfiguration or an ACNS software upgrade that erases disk content, the Websense configurations from the last use of the write memory command are retained. However, if the write memory command has never been used before, then default configurations will be applied when the content in the /local/local1/WebsenseEnterprise/EIM directory on the Content Engine is erased.

Configuration of Ports for the Websense Server

The Websense process requires that these three ports be opened for connections either from processes internal to the Content Engine or from external processes such as the Websense Manager:

•Websense server port

This is the TCP port that receives requests for content filtering according to the Websense protocol.

•Block message server port

If the Websense process blocks a URL, it sends a redirect URL to the user. The redirect URL is configured to print out the blocked page and policy for the user. The Websense process listens on this port to receive the pages blocked, serviced by a thread in the Websense server. This thread sends the blocked page in response to the redirected request.

•Diagnostics server port

The Websense server has an exhaustive set of diagnostics that the users can run remotely to diagnose problems in the Websense process. This port is the one that these diagnostics utilities connect to.

You can configure these ports by modifying the eimserver.ini file that resides in the /local/local1/WebsenseEnterprise/EIM directory on the Content Engine. The Websense server must be restarted so it can pick up the newly configured ports. Default port numbers for these three ports are:

•15868 (Websense server port)

•15871 (Websense block message server port)

•15869 (Websense diagnostics server port)

You can modify the ports by exporting a copy of the eimserver.ini file using FTP from the /local/local1/WebsenseEnterprise/EIM directory on the Content Engine, modifying the file, deleting the eimserver.ini file on the Content Engine, and then sending back the modified file to the Content Engine using FTP.

Note The Websense server needs to be disabled and then reenabled to pick up newly configured ports. Also make sure that you use the url-filter http websense server command to point the Websense client to the correct Websense server port. For more information about the url-filter http websense server command, refer to the Cisco ACNS Software Command Reference, Release 5.1.

Configuring the Local Websense Server Using the Content Engine GUI

To configure a locally deployed Content Engine to run the local Websense server, follow these steps:

Step 1 From the Content Engine GUI, choose Caching > URL Filtering. The URL Filtering window appears.

Step 2 Check the Websense Filtering (Local) check box to configure the Websense server to run on the Content Engine. (See Figure 13-4.)

Figure 13-4 Configuring the Local Websense Server

Note The IP address of the local Websense server cannot be configured and is set at 127.0.0.1.

Step 3 Enter information in the following fields:

•Port—Enter the port number on which the local Websense server is accepting requests. The default value is 15868.

•Timeout—Enter the number of seconds after which the Websense server times out. Enter the value in seconds. The range is between 1 and 240 seconds. The default value is 20.

•AllowMode—Check this check box to specify whether the request must be allowed or blocked if no response is received after the value specified in the Timeout field.

Step 4 Click Update to submit the changes.

Now that you have configured and enabled the local Websense server on the Content Engine, the next step is to configure the URL filter settings on the Content Engine, as described in the "Configuring URL Filtering on the Content Engine" section.

Enabling and Disabling the Local Websense Server Using the Content Engine GUI

By default, the Websense plug-in (local Websense server) is disabled.

To use the Content Engine GUI to enable or disable the local Websense server on a locally deployed Content Engine, follow these steps:

Step 1 From the Content Engine GUI, choose System > Websense Server. The Websense Server window appears. (See Figure 13-5.)

Figure 13-5 Enabling the Local Websense Server

Step 2 Click Start to enable the Websense server. The Start button appears only if the Websense server is currently disabled. The Websense Server window is updated and indicates that the local Websense server is now running on the Content Engine. (See Figure 13-6.)

Figure 13-6 Content Engine with Local Websense Server Enabled

Note To stop the Websense server, click Stop in the Websense Server window. The Stop button appears only if the Websense server is currently enabled.

For information about enabling and configuring Websense URL filtering through the CLI, see the next section. For more information about configuring the Websense software, go to the following website: http://www.websense.com

Configuring Websense URL Filtering Using CLI Commands

This section describes how to use the CLI to configure a locally deployed Content Engine for Websense URL filtering, which involves these tasks:

•Enabling the local Websense server (using the websense-server enable command) on the locally deployed Content Engine

•Configuring a Websense client (using the url-filter http websense server command) on the locally deployed Content Engine

Before you enable Websense URL filtering on the Content Engine, either choose the local Websense server option (use the websense-server enable command) or configure an external Websense server IP address or host name.

Configuring the Local Websense Server Using CLI Commands

By default, the Websense plug-in (local Websense server) is disabled. To enable the local Websense server on the Content Engine, use the websense-server enable global configuration command.
ContentEngine(config)# websense-server enable
If you are using the local Websense option with a cluster of Content Engines, make sure to use the websense-server enable command on each Content Engine in the cluster.

By default, the local Websense server listens on the IP address of the first interface of the Content Engine. If the Content Engine has multiple interfaces and you want the local Websense server to listen on an IP address that is not the first interface, then use the websense-server ip-address command to specify the interface IP address that the local Websense server should be listening on. After the websense-server ip-address command is used, the Websense server is restarted in order for these configuration changes to take effect.

If there is an external user server installed and you want to configure user/group-based URL filtering using a Windows NT directory, then use the websense-server user-server external command.

Configuring the Websense Client Using CLI Commands

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

The url-filter http websense allowmode enable command permits the Content Engine to fulfill an HTTP request from a client if the Websense server does not respond.

The following example shows how to configure a Content Engine to use Websense URL filtering with IP address 172.16.11.22, port 15900, and a 4-second timeout:

ContentEngine(config)# url-filter websense server 172.16.11.22 port 15900 timeout 4

Note For information about configuring the Websense software, go to the following website: http://www.websense.com

Websense Status and Statistics Commands

To display URL filtering statistics for the local Websense server, use the show websense-server EXEC command. This command has no arguments or keywords, as shown in the following example.
ContentEngine# show websense-server 
Local Websense Server Information :
------------------------------
Websense Enterprise Version : 5.0.1
Websense Server running.
------------------------------------------
 Sending SERVER_STATUS_REQUEST...
------------------------------------------
 Status Code = 0
 License Count = 0
 Elapsed Time = 1 ms
AVG TIME PER REQUEST = 1 ms
Websense Server Port : 15868 
Websense Block Message Port : 15871 
Websense Config Server Port : 55806
Websense Diagnostics Server Port : 15869 
ContentEngine#
The show url-filter http command shows the URL filtering scheme enabled on the Content Engine for HTTP traffic and the configurations for each URL filtering scheme, such as the configuration data for Websense.

In this example, the show url-filter http command is used to display the status of all HTTP URL filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter http
URL filtering is set to use Websense server
Local list configurations
==================================
Good-list file name : 
Bad-list file name : 
Custom message directory : 
Websense server configuration
==================================
Websense server IP : local
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 : 5 (in seconds)
N2H2 allow mode is DISABLED 
ContentEngine#
The show statistics url-filter http websense command shows the request-reply statistics of the communication between the Content Engine and the Websense 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 Websense server.
ContentEngine# show statistics url-filter http websense 
Websense URL Filtering Statistics:
Transmission statistics:
 Lookup requests transmitted = 1
 Lookup requests timed-out = 1
 Lookup responses received = 1
 Lookup responses received with error = 0
 Multiple response received = 0
 Sequence number mismatch = 0
TCP errors:
 Connection reset = 0
 Connection timeout = 3
 Other errors = 0
Filter results:
 Requests BLOCKed by Websense = 1
 Requests OKed by Websense = 0
 Sent to Allowmode ok = 1
 Sent to Allowmode block = 0
 desc_filtered_and_passed = 0
 desc_category_blocked = 1
 desc_category_not_blocked = 0
 desc_category_blocked_custom_deny = 0
 desc_category_not_blocked_custom_permit = 0
Websense log statistics:
 Logs sent successfully = 1
 Connection error = 0
 Error during log processing = 0
 Log not complete = 1
 Log not sent because Websense disabled = 0
 No available connection = 0
Congestion statistics:
 Pending requests = 0
 Pending log requests = 0
ContentEngine# 
The statistics shown can be cleared using the clear statistics url-filter http websense and clear statistics all commands. All the statistics counters are then reset to 0.

URL Filtering with SmartFilter Software

SmartFilter software running on the Content Engine provides employee Internet management (EIM) functionality when used 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 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, and a management server tool called the sfadmin server. The administrator configures the SmartFilter product on the sfadmin console and then stores the configuration on the sfadmin server. The sfadmin server then propagates this configuration to the end client Content Engines, to be used by SmartFilter software running on the Content Engines.

To use SmartFilter URL filtering with a cluster of Content Engines, make sure to enter the url-filter http smartfilter enable command on each Content Engine in the cluster to ensure that all traffic is filtered.

Note For more information about configuring the SmartFilter software, go to the following website: http://www.securecomputing.com

RADIUS and URL Filtering

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

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.

Note For more information about the use of a RADIUS server for authentication purposes and URL filtering, see the "Understanding RADIUS Authentication and Authorization" section.

Configuring URL Filtering on the Content Engine

You can configure URL filtering for a locally deployed Content Engine through the Content Engine GUI or the CLI.

•From the Content Engine GUI, choose Caching > URL Filtering. The URL Filtering window appears. Enter information for general URL filter settings. For more information about these fields, click the Help button in the URL Filtering window. Click Update to save the URL filtering settings.

•From the CLI, use the CLI commands, as described in Table 13-2.

Table 13-2 Locally Configuring URL Filtering on a Content Engine

Parameter

Description

Command

URL Filtering Parameter

Custom Msg Location

Creates a customized URL blocking message to the client. This custom message must be an administrator-created HTML file named block.html, as described in the "Custom Blocking Messages" section.

url-filter http custom-message

HTTP URL Filter Options

Enable Bad Site Local File Filtering

Enables the use of local list filtering for bad sites.

url-filter http bad-sites-deny enable

Bad Site FileName

File that contains URLs to which access is denied.

url-filter http bad-sites-deny file

Enable Good Site Local File Filtering

Enables the use of local list filtering for good sites.

url-filter http good-sites-allow enable

Good Site FileName

File that contains URLs to which access is permitted.

url-filter http good-sites-allow file

Enable SmartFilter Filtering

Enables the use of SmartFilter software.

url-filter http smartfilter enable

Enable N2H2 Filtering

Enables the use of an N2H2 server for URL filtering.

url-filter http N2H2 enable

N2H2 Server Hostname

Host name or IP address of the N2H2 server.

url-filter http N2H2 server

N2H2 Port

Port number on which the N2H2 server is accepting requests.

url-filter http N2H2 server IPaddress or hostname port

N2H2 Request Timeout

Number of seconds that the Content Engine should wait for a response from the N2H2 server.

url-filter http N2H2 server IPaddress or hostname port 1-65535 timeout

N2H2 Allow Mode

Allows the request to be served if there is no response from the N2H2 server.

url-filter http N2H2 allowmode enable

Enable Websense Filtering

Enables the use of a Websense server for URL filtering.

url-filter http websense enable

Websense Server Hostname

Host name of the external Websense server.

url-filter http websense server hostname

Websense Port

Port number on which the Websense server is accepting requests.

url-filter http websense server hostname or IP address port 1-65535

Websense Request Timeout

Number of seconds that the Content Engine should wait for a response from the Websense server.

url-filter http websense server IPaddress or hostname port 1-65535 timeout

Enable Websense Allow Mode

Allows the request to be served if there is no response from the Websense server.

url-filter http websense allowmode enable

RTSP URL Filter Options

Enable Bad Site File Name

Enables the use of local list filtering for bad sites.

url-filter rtsp bad-sites-deny enable

Bad Site File Name

File that contains URLs to which access is denied.

url-filter rtsp bad-sites-deny file

Enable Good Site File Name

Enables the use of local list filtering for good sites.

url-filter rtsp good-sites-allow enable

Good Site File Name

File that contains URLs to which access is permitted.

url-filter rtsp good-sites-allow file

WMT URL Filter Options

Enable Bad Site File Name

Enables the use of local list filtering for bad sites.

url-filter wmt bad-sites-deny enable

Bad Site File Name

File that contains URLs to which access is denied.

url-filter wmt bad-sites-deny file

Enable Good Site File Name

Enables the use of local list filtering for good sites.

url-filter wmt good-sites-allow enable

Good Site File Name

File that contains URLs to which access is permitted.

url-filter wmt good-sites-allow file

Tip 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.