Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.2 - Chapter 12: Configuring Request Processing Services [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring Request Processing Services

Configuring ICAP

Configuring ICAP Settings

Configuring ICAP Services

Configuring an ICAP Server for ICAP Service

Configuring Service Rules

Enabling Rule Settings

Configuring Service Rules

Configuring the Rules Template Using CLI Commands

Configuring a Pattern List

Adding a Pattern to an Existing Pattern List

Associating an Action with an Existing Pattern List

Verifying an Action Performed on a Pattern List

Configuring URL Filtering

Custom Blocking Messages

Configuring URL Filter Settings Using the Content Distribution Manager GUI

Creating a Text File URL List for URL Filtering

URL Filtering with the N2H2 Server

N2H2 Features Supported

Enabling N2H2 Filtering Using the Content Distribution Manager GUI

N2H2 Configuration Commands

N2H2 Status and Statistics Commands

N2H2 Configuration and Restrictions

URL Filtering with Websense Enterprise Software

Using a Websense Enterprise Server

Using the Integrated Websense Server

Configuring Ports for the Integrated Websense Server

About Websense Server Failover

Enabling Websense Filtering Using the Content Distribution Manager GUI

Websense Status and Statistics Commands

Websense Configuration and Restrictions

URL Filtering with SmartFilter Software

SmartFilter Software and the Action No-Auth Command Rule Interaction

Configuring the Content Engine GUI for Secure or Nonsecure Access

Configuring Request Processing Services

You can configure various content filtering services for the Content Engine, such as ICAP services, rules, and URL filtering. The following sections describe how to define and configure these various features:

•Configuring ICAP

•Configuring Service Rules

•Configuring URL Filtering

•Configuring the Content Engine GUI for Secure or Nonsecure Access

Configuring ICAP

The Internet Content Adaptation Protocol (ICAP) is an open-standards protocol that can be used for content adaptation, typically at the network edge. ICAP provides a common standard for communication between edge devices and ICAP services such as content filtering and virus scanning provided by third-party vendors. ICAP support on Content Engines enables system resources to be used for other critical applications while using the services offered by third-party vendors for content adaptation.

ICAP has various vectoring points (decision points) that enable modification of HTTP requests and responses when they are processed by the Content Engine. You can define one or more ICAP services and associate them with one or more vectoring points that the service is able to support. An ICAP service is a collection of attributes and ICAP servers. You can configure a maximum of ten ICAP services per Content Engine, with an upper limit of five ICAP servers per ICAP service. Also, you can choose to apply ICAP services to all HTTP requests processed by the Content Engine or apply ICAP processing only to requests that match the Rules Template.

Note The maximum file size that is supported in the ACNS software in pass-through mode is 2 GB. Files that exceed this size limit are not supported for ICAP processing.

Configuring ICAP Settings

To configure ICAP settings for the Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Device Home window appears.

Step 3 In the Contents pane, choose Request Processing > ICAP. The ICAP Settings window appears. (See Figure 12-1.) Table 12-1 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 12-1 ICAP Settings Window

Step 4 From the Apply to drop-down list, choose the type of ICAP processing that you wish to apply to requests:

The all option applies ICAP processing to all HTTP requests. The rules-template option applies ICAP processing only to requests that match the rule action use-icap-service rule defined in the Rules Template.

Step 5 Uncheck the Bypass Requests Streaming Media check box if you do not want to bypass ICAP processing for streaming media requests (that is, requests from Windows, RealMedia, and QuickTime media players) that enter the Content Engine. This check box is checked by default.

You can configure the Content Engine to append the client and server IP address headers to requests that are passed to the ICAP server. This specifies that the ICAP extension headers are passed to the ICAP server during the session negotiation between the Content Engine and the ICAP server. This capability allows you to use your ICAP server to perform URL filtering based on the client IP address and server IP address.

Step 6 To add an X-client-IP header for ICAP processing of HTTP requests, check the Append X-Client-IP headers check box.

Step 7 To add an X-server-IP header for ICAP processing, check the Append X-Server-IP headers check box.

You can configure the Content Engine to append the username and groupname headers to the request that is passed to the ICAP server was added. This capability allows you to use your ICAP server to perform URL filtering based on username and groupname. The currently supported authentication schemes include LDAP, NTLM, RADIUS, and TACACS+.

Step 8 Check the Append X-Authenticated-User headers check box to allow the username information to be passed to the ICAP server for global services. This check box is unchecked by default. When this check box is checked, the x-authenticated-user information is inserted into the ICAP request sent to the ICAP server.

Step 9 Check the Append X-Authenticated-User-Groups headers check box to allow the groupname information to be passed to the ICAP server for global services. This check box is unchecked by default. When check box is checked, the x-authenticated-groups information is inserted into the ICAP request sent to the ICAP server.

Step 10 To rescan cached objects, check the Rescan Cache Service Update (ISTag) check box. The ISTag is a field in the HTTP response header that can change as a result of such things as updates to the ICAP server or ICAP policy. A change in the ISTag triggers the ICAP server to send a cookie to the ICAP client, indicating that a change has occurred and that the client should therefore not use any previously cached material and should instead rescan the cache.

Step 11 Check the Enable Logging check box if you wish to configure and enable logging in ICAP standard logging format for ICAP exchanges between ICAP servers and Content Engines.

Step 12 Click Submit to save your settings. A "Click Submit to Save" message appears in red next to the current settings line when there are pending changes to be saved after you have applied default and device group settings. To revert to the previously configured window settings, click Reset. The Reset button appears only when you have applied default or group settings to change the current device settings but the settings have not yet been submitted.

Table 12-1 ICAP Settings

GUI Parameter

Function

CLI Command

Apply to

The all option applies ICAP processing to all HTTP requests. The rules-template option applies ICAP processing only to requests that match the rule action use-icap-service rule defined in the Rules Template.

icap apply {all | rules-template}

Bypass Requests Streaming Media

When checked, bypasses ICAP processing for streaming media requests.

icap bypass streaming-media

Append X-Client-IP headers

Appends the client IP address header to requests that are passed to the ICAP server.

icap append-x-headers x-client-ip

Append X-Server-IP headers

Appends the server IP address header to requests that are passed to the ICAP server.

icap append-x-headers x-server-ip

Append X-Authenticated-User headers

Allows the username information to be passed to the ICAP server for global services.

icap append x-authenticated-user

Append X-Authenticated-Groups headers

Allows the groupname information to be passed to the ICAP server for global services.

icap append x-authenticated-groups

Rescan Cache

Rescans cached objects.

icap rescan-cache ISTag-change

Enable Logging

Enables logging in ICAP standard logging format for ICAP exchanges between ICAP servers and Content Engines.

icap logging {format {standard} | enable}

Configuring ICAP Services

ACNS 5.2 software supports the following three vectoring points:

•Request modification-precache

This vectoring point applies to requests from clients. The ICAP server specifies whether to terminate the connection, send a modified error response to the client, search the cache using the requested URL, use a modified URL before looking up the cache, or modify the request headers or bodies, in the case of a cache miss.

•Request modification-postcache

This vectoring point applies only to requests after a cache miss and before the request is forwarded to the origin server for content retrieval. The ICAP server determines whether to terminate the client connection, send a modified error response to the client, send the request to the origin server using the client-specified URL or an alternative URL, or modify the request headers or bodies.

•Response modification-precache

This vectoring point applies to responses that are received from the origin server. The ICAP server specifies whether to return the response to the client, modify the response headers or bodies before sending them to the client, or cache the response using the same or an alternative URL.

ICAP servers configured with various vectoring points (especially request modification-precache) may become overloaded with HTTP requests because all requests pass through this point. We therefore recommend that you use a cluster of ICAP servers to load balance requests based on various parameters such as weighted load, client IP and server IP address-hash based format, or round-robin format.

More than one ICAP service can be associated with a vectoring point. An ICAP service configured at a vectoring point can have only one load-balancing scheme, irrespective of the number of servers. However, multiple ICAP services configured at one or all of the vectoring points can have different load-balancing schemes.

Note When the Aggregate Settings option is used, ICAP services that have been previously configured for device groups to which the Content Engine belongs cannot be modified or deleted in the ICAP Services for Content Engine window. In other words, you can only view the ICAP services created for the device groups.

To configure an ICAP service for a Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine for which you want to configure an ICAP service. The Device Home window appears.

Step 3 In the Contents pane, choose Request Processing > ICAP Services. The ICAP Services for Content Engine window appears.

Step 4 The Yes radio button for aggregate settings is selected by default, meaning that the ICAP services defined for the Content Engine and the device groups to which the Content Engine belongs are displayed. Click the No radio button if you wish to display only the settings defined for the Content Engine.

Step 5 Click the Create New ICAP Service icon in the taskbar. The Creating New ICAP Service for Content Engine window appears. (See Figure 12-2.) Table 12-3 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 12-2 Creating New ICAP Service

Step 6 Configure the ICAP service, as follows:

a. In the Name field, enter a string identifying the ICAP service to be configured.

b. Check the Enable check box to enable ICAP service.

c. Choose the type of load-balancing mechanism for ICAP processing from the Load Balancing drop-down list. Table 12-2 describes the load-balancing options.

Table 12-2 ICAP Load-Balancing Options

Load-Balancing Type

Description

Client IP Hash

Uses a hash-based algorithm based on the client IP address for load-balancing the ICAP servers in the cluster.

Round Robin

Uses the round-robin method, in which ICAP servers take turns processing HTTP requests.

Server IP Hash

Uses a hash-based algorithm based on the server IP address for load balancing the ICAP servers in the cluster.

Weighted

Uses a farm of ICAP servers with different load capacities.

Step 7 Choose the type of error handling mechanism for ICAP processing from the Error Handling drop-down list. If you wish to bypass this ICAP service, choose Bypass. Otherwise, choose Return Error if you want errors to be returned for client requests. These errors are also entered in the transaction log to show the status of the action performed by the ICAP services.

Step 8 Under the ICAP Service Vectoring Points heading, configure the following options:

a. To enable the vectoring point that is to be invoked when a Content Engine receives a request from a client, check the Pre-cache check box for request modification.

b. To enable the vectoring point that is to be invoked if the request is a cache miss and must be sent to the origin server for the content, check the Post-cache check box for request modification.

c. To enable the vectoring point that is to be invoked only when the response is from the origin server, check the Pre-cache check box for response modification.

Step 9 Click Submit to save your settings. The configured settings are saved to the database and the ICAP Services for Content Engine window appears, listing the configured ICAP service.

Step 10 To display a subset of the entire list of ICAP services, click the Filter Table icon in the taskbar.

Step 11 To revert to the display of all configured ICAP services, click the View All ICAP Services icon in the taskbar.

Table 12-3 ICAP Service Settings

GUI Parameter

Function

CLI Command

ICAP Service Configuration

Name

Identifies the ICAP service to be configured.

icap service service-id

Enable

Enables the ICAP service.

icap service service-id enable

Load Balancing

Configures the type of load-balancing mechanism for ICAP processing.

icap service service-id load-balancing {round-robin | client-ip-hash | server-ip-hash | weighted-load}

Error Handling

Configures the type of error handling mechanism for ICAP processing.

icap service service-id error-handling {bypass | return-error}

ICAP Service Vectoring Points

Request Modification:

Pre-cache

When checked, enables the vectoring point that is to be invoked when a Content Engine receives a request from a client.

icap service service_id vector-point reqmod-precache

Post-cache

When checked, enables the vectoring point that is to be invoked if the request is a cache miss and must be sent to the origin server for the content.

icap service service_id vector-point reqmod-postcache

Response Modification: Pre-cache

When checked, enables the vectoring point that is to be invoked only when the response is from the origin server.

icap service service_id vector-point respmod-precache

Configuring an ICAP Server for ICAP Service

ICAP servers process HTTP requests from clients based on the ICAP services configured using various vectoring points. ICAP servers perform content adaptation such as request or response modification and filtering of requests or responses based on the configured vectoring points.

You can configure the maximum number of connections and the weight that can be handled by an ICAP server in a cluster of servers. The weight parameter represents the percentage of load that can be redirected to the ICAP server. An ICAP server with a weight of 40 means that this server handles 40 percent of the load. If the total weight of all ICAP servers in a load-balanced cluster exceeds 100, the weight parameter for each ICAP server is recalculated.

Note Always locate the ICAP server on a public LAN and configure its public IP address on the Content Engine. The ICAP server should not be located behind a NAT device.

To configure an ICAP server for a previously configured ICAP service on a Content Engine, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the desired Content Engine. The Content Engine Device Home window appears.

Step 3 In the Contents pane, choose Request Processing > ICAP Services. The ICAP Services for Content Engine window appears.

Step 4 The Yes radio button for aggregate settings is selected by default, meaning that the ICAP services defined for the Content Engine and the device groups to which the Content Engine belongs are displayed. Click the No radio button if you wish to display only the settings defined for the Content Engine.

Step 5 Click the Edit ICAP Service icon next to the ICAP server for which you wish to configure an ICAP service. The Modifying ICAP Service for Content Engine window appears.

Step 6 In the ICAP Servers for ICAP Service section, click the Create new ICAP Server icon in the taskbar. The Creating New ICAP Server for ICAP Service window appears. Table 12-4 describes the fields in this window and provides the corresponding CLI global configuration commands.

Step 7 Enter the host name or IP address of the ICAP server in the Server Host field.

Step 8 In the Service Port field, enter the port number on which the ICAP server is to be configured to process HTTP requests. This step is optional. The default port number for the ICAP server is 1344. Any valid port number can be set. If no port number is specified, the default port number is used for the ICAP server.

Step 9 In the Server Service Name field, enter the path to the ICAP service configured on the Content Engine to be used for the ICAP service using the URL format icap://ICAPserverIPaddress/service-name. The service name entered here must be supported by the ICAP vendor.

Step 10 In the Maximum Connections field, enter the maximum number of simultaneous connections that can be made to this server. This step is optional. The valid range is 1 to 5000.

Step 11 In the Weight field, enter the percentage of load that can be redirected to this ICAP server. This step is optional. The valid range is 1 to 100. Do not leave this field blank if you chose the Weighted load-balancing method.

Step 12 In the Keepalive Interval field, specify the keepalive probe interval (in seconds) for this ICAP server. The default is 60 seconds.

Step 13 Click Submit to save your settings.

Table 12-4 ICAP Server for ICAP Service Settings

GUI Parameter

Function

CLI Command

Server Host

Host name or IP address of the ICAP server.

—

Server Port

Port number on which the ICAP server is to be configured to process HTTP requests.

—

Server Service Name

Path to the ICAP server configured on the Content Engine. Use the URL format:

icap://ICAPserverIPaddress:port/service-
name.

The service name entered here must be supported by the ICAP vendor.

icap service server server server_url

Maximum Connections

Maximum number of simultaneous connections that can be made to this server.

icap service server server server_url max-connections num

Weight

Percentage of load that can be redirected to this ICAP server.

icap service server server server-url weight number

Keepalive Interval

Keepalive probe interval (in seconds) for this ICAP server

icap service server server server_url keepalive-interval seconds

When ICAP processing is enabled and an HTTP browser with a streaming Java applet is opened, several undesirable things occur:

•The data for the Java applet is not updated in the browser. For example, when viewing a stock investment website, a user would not see any streaming stock updates.

•The ICAP daemon on the Content Engine continues to send updates (from the HTTP response) to the ICAP server, thereby overloading the ICAP server.

These conditions occur because the ICAP server is set up to inspect the entire data packet before delivering a response to the client. However, because there is a streaming request, the data continues flowing to the ICAP server indefinitely, deadlocking any response to the requesting client.

Two workarounds are available. You can configure the ICAP server to bypass the scanning process, or you can configure rules on the Content Engine to skip ICAP processing on websites that are known to contain streaming Java applets.

To configure the ICAP server to bypass scanning, use rules such as client_skip_content or server_skip_content.

•The client_skip_content rule bypasses scanning on the basis of an HTTP request. The software looks for patterns in the HTTP header and bypasses all requests that exactly match the patterns specified in the intscan.ini file. For example:
client_skip_content=User Agent: Windows Media Player 9.0.1
•The server_skip_content rule bypasses scanning on the basis of an HTTP response. The software looks for patterns in the HTTP header and bypasses all responses that exactly match the patterns specified in the intscan.ini file. For example:
server_skip_content=Content-Type: X-Dave_Content
Alternatively, you can configure the Content Engine to bypass ICAP processing based on user agents or any of the patterns available in the Rules Template, by using the rule command. In the following example, the Content Engine is configured to bypass ICAP processing on the intranet site cisco.com and on the trusted Internet site datek.com:
CE(config)# rule enable
CE(config)# rule action use-icap-service trend-reqmod pattern-list 1 protocol all 
CE(config)# rule action use-icap-service trend-respmod pattern-list 1 protocol all 
CE(config)# rule pattern-list 1 domain "!(.*cisco\.com|.*datek\.com)"
!
CE(config)# icap apply rules-template
CE(config)# icap service trend-reqmod
 enable
 vector-point reqmod-precache
 server icap://172.19.227.150/REQ-Service
 exit
CE(config)# icap service trend-respmod
 enable
 vector-point respmod-precache
 server icap://172.19.227.150/interscan
 exit
Configuring Service Rules

The Rules Template feature provides a flexible mechanism to specify configurable caching requests by allowing these requests to be matched against an arbitrary number of parameters, with an arbitrary number of policies applied against the matches. You can specify a set of rules, each clearly identified by an action and a pattern. Subsequently, for every incoming request, if a pattern for a rule matches the given request, the corresponding action for that rule is taken.

Requests can be matched against regular expressions symbolizing domain names, source IP addresses and network masks, destination IP addresses and network masks, destination port numbers, MIME types, or regular expressions symbolizing a URL.

You can configure service rules using the Content Distribution Manager GUI or CLI commands. This section provides instructions for using the Content Distribution Manager GUI. For more information on the types of policies that can be applied, actions and patterns, Rules Template processing, and using the CLI to configure service rules, refer to the Cisco ACNS Software Command Reference, Release 5.2.

To configure or modify service rule settings, you need to do the following:

•Enable rule settings for the Content Engine

•Configure service rules for the Content Engine

Enabling Rule Settings

Before you configure service rules, you need to enable rule settings for the Content Engine. To enable rule settings, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine for which you want to enable rule settings. The Content Engine Device Home window appears.

Step 3 From the Contents pane, choose Request Processing > Enable Rules. The Service Rule Settings window appears. Check the Enable check box to enable the use of rule settings.

Step 4 Click Submit to save the settings.

To enable rules using the CLI, use the rule enable global configuration command.

Configuring Service Rules

Configuring a service rule consists of the following tasks:

1. Configuring a pattern list

2. Adding a pattern to an existing pattern list

3. Associating an action with an existing pattern list

An action is a process that the Content Engine performs while processing the request, for example, blocking the request, redirecting the request, and so on. A pattern defines the limits of the request, for example, a pattern may specify that the IP address must fall within the subnet range 10.0.*.*.

To configure service rule parameters, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Device Groups. If you have created device groups, the Device Group window appears.

Step 2 Click the Edit icon next to the name of the device group for which you want to configure pattern lists. The Contents pane appears on the left.

Step 3 From the Contents pane, choose Request Processing > Service Rules.

Step 4 Click the Create New Service Rules icon. The Creating New Service Rules window appears.

Step 5 Configure a pattern list and add a pattern to it.

a. Choose pattern-list from the Rule Type drop-down list.

b. In the Rule Parameters field, configure the pattern list number and the pattern type, following the rules usage guidelines shown in the GUI. (See Table 12-5 for a description of pattern types.)

For example, to create pattern list number 72 with the pattern type domain and the yahoo.com domain as the domain to be acted on by an action, enter 72 domain yahoo.com in the Rule Parameters field. (See Figure 12-3.)

Figure 12-3 Creating a New Pattern List and Defining a Pattern
Table 12-5 Pattern Types
Pattern Type

Description

CLI Command

domain

Matches the domain name in the URL or the Host header against a regular expression. For example, ".*ibm.*" matches any domain name that contains the "ibm" substring. "\.foo\.com$" matches any domain name that ends with the ".foo.com" substring.

In regular expression syntax, the dollar sign "$" metacharacter directs that a match is made only when the pattern is found at the end of a line.

rule pattern-list list_num domain dn_regexp

dst-ip

Matches the request's destination IP address and netmask against the specified destination IP address and netmask. Specify an IP address and a netmask. In proxy mode, the Content Engine does a DNS lookup to resolve the destination IP address of the HTTP request, making the response time longer, and possibly negating the benefit of setting a dst-ip rule. When an outgoing proxy is configured, cache miss requests are forwarded by the Content Engine to the outgoing proxy without examination of the destination server IP address, making the dst-ip rule unenforceable on the first Content Engine.

rule pattern-list list_num dst-ip d_ipaddress d_subnet

dst-port

Matches the request's destination port number against the specified destination port number. Specify a port number.

rule pattern-list list_num dst-port port

groupname

Matches the groupname of the end user (web client that is requesting content) who was authenticated through LDAP or NTLM.

This pattern can be applied only to request authentication for users who have been authenticated through LDAP or NTLM. Supports exact string comparison. The groupname comparison is case insensitive. Maximum length of groupname is 255 characters. Valid characters are an underscore and alphanumeric characters. If the groupname configuration in the Rules Template and the group name-based access list match, then the access list takes precedence.

Tip If you intend to use the groupname pattern, make sure that you set the correct number of maximum group entries in the authentication group cache (the http authentication cache max-group-entries number global configuration command). This number should correspond to the maximum number of groups that could be returned during authorization queries (for example, the total number of groups defined on the AAA server.) The number can be from 500 to 12000. The number of entries in the authentication group cache is dependent on the physical resources available on the Content Engine.

rule pattern-list list_num groupname name
groupname-regex
Matches the group-name of the end user (web client that is requesting content) against a regular expression. Specify a regular expression. For example, use to configure a regular expression-based policy on groupnames or to OR multiple groupnames in the same line of in a single pattern list. For example, to OR three groupnames enter:
ContentEngine(config)# rule pattern-list 1 groupname-regex 
Engingeering|Marketing|Finance\
The specified action is taken if any of the above groupnames matched the one in the request.
rule pattern-list list_num groupname-regex group_name_regexp
group-type

Specifies whether the pattern list is an AND or OR type. The default is OR.

rule pattern-list list_num group-type {and | or}

header-field

Request header field pattern.

Request header field patterns referer, request-line, and user-agent are supported for actions block, reset, redirect, and rewrite. The referer pattern is matched against the Referer header in the request, the request-line pattern is matched against the first line of the request, and the user-agent pattern is matched against the User-Agent header in the request.

rule pattern-list list_num header-field {referer ref_regexp | request-line req_regexp | user-agent ua_regexp}

header-field-sub

Request header field subpattern and substitute replacement pattern.

rule pattern-list list_num header-field-sub {referer ref_regexp ref_sub | request-line req_regexp req_sub | user-agent ua_regexp ua_sub}

icap-attribute

Specifies the attribute and value pair of the ICAP service.

rule pattern-list list_num icap-attribute icap_attribute icap_value

mime-type

Matches the MIME type of the response.

Specify a MIME type string, for example, "image/gif," as defined in RFC 2046 (http://www.faqs.org/rfcs/rfc2046.html). The administrator can specify a substring, for example, "java" and have it apply to all MIME types with the "java" substring, such as "application/x-javascript."

rule pattern-list list_num mime-type mt_regexp

scr-ip

Matches the request's source IP address and netmask. Specify an IP address and a netmask.

rule pattern-list list_num src-ip s_ipaddress s_subnet

url-regex

Matches the URL against a regular expression. The match is case insensitive. Specify a regular expression whose syntax can be found at the following URL:

http://yenta.www.media.mit.edu/projects/Yenta/Releases/Documentation/regex-0.12/.

rule pattern-list list_num url-regex url_regexp

url-regsub

For the rewrite and redirect actions, matches the URL against a regular expression to form a new URL in accordance with the pattern substitution specification. The match is case insensitive. The valid substitution index range is from 1 to 9.

rule pattern-list list_num url-regsub url_regexp url_sub
username
Matches the username of the end user (the web client that is requesting content) who was authenticated through LDAP, NTLM, RADIUS, or TACACS+. Specify the username or usernames. Maximum length of username is 255 characters for LDAP, RADIUS, or TACACS+ authentication. See below for information about the maximum length of usernames for NTLM authentication.

Valid characters are an underscore and alphanumeric characters. The match supports exact string comparison. The username comparison is case insensitive.

To specify multiple usernames in the same line for the same pattern list use a delimiter. For example:
ContentEngine(config)# rule pattern-list 1 username 
jdoe8,dsmith7,jsmith50
By default, the match does not consider the domain name, and matches for username only. To include domain name as well as username in the match, specify domainname\username. For example:
ContentEngine(config)# rule pattern-list 1 username domain 
cisco\jdoe8
For NTLM authentication, the domain\username:password:NTLM string must be 50 characters or less. If this string is greater than 50 characters, the domain name is truncated and the rule username pattern is not matched. An error message is generated in the system log in this situation.

To match all users in a particular domain, enter:
ContentEngine(config)# rule pattern-list 1 username domain 
domainname\*
where domainname is the name of the domain (for example, cisco).
rule pattern-list list_num username user_name
Step 6 Click Submit.

Step 7 Next, associate an action with an existing pattern list.

a. From the Creating New Service Rule window (see Step 1 through Step 4) choose an action type from the Rule Type drop-down list. (See Table 12-6 for a description of rule actions.)

b. In the Rule Parameter field, enter the list number of the pattern list that you want associated with this action.

For example, if you want to block access by any protocol to yahoo.com, then choose block from the Rule Type drop-down list and enter pattern-list 72 protocol all in the Rule Parameters field. (See Figure 12-4.)

Figure 12-4 Associating an Action with an Existing Pattern List

Table 12-6 Rule Actions

Action Type

Description

CLI Command

allow

Allows this request.

rule action allow pattern-list list_num [protocol {all | http | https | mms | rtsp}]

append-username-header

Appends the username in the request sent to the origin server.

rule action append-username-header pattern-list list_num [protocol {all | http | https | mms | rtsp}]

block

Blocks this request.

rule action block pattern-list list_num [protocol {all | http | https | mms | rtsp}]

cache-non-cacheable

Overrides the HTTP response headers and caches the objects.

This rule action caches objects only if they are not authenticated. For authenticated objects, some origin servers do not send the Last-Modified and ETag entity headers, and revalidation of these objects therefore cannot be performed by the Content Engine. These authenticated objects are served only from the origin server.

If the server does send the Last-Modified and ETag headers, then these objects can be cached.

rule action cache-non-cacheable ttl {day days pattern-list list_num [protocol {all | http | https}] | hours hours pattern-list list_num [protocol {all | http | https}] | minutes minutes pattern-list list_num [protocol {all | http | https}] | seconds seconds pattern-list list_num [protocol {all | http | https}]}

cache-only

Caches objects depending on the HTTP response headers. Caches this object only if it is a match and is allowed to be cached by HTTP.

If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check.

If the object does not match any of the selective-cache rules, the object is not cached.

rule action cache-only pattern-list list_num [protocol {all | http | https | mms}]

dscp

Configures the IP ToS or DSCP code point field.

cache-miss—Sets the IP ToS/DSCP code point bits for the client-side connection to the configured value for cache miss responses to the client.

cache-hit—Sets the IP ToS or DSCP code point bits for the client-side connection to the configured value for cache hit responses to the client.

Setting the Type of Service (ToS) or differentiated services code point (DSCP) is called packet marking, allowing you to partition network data into multiple priority levels or types of service. With the ACNS 5.x releases, you can set the ToS or DSCP values in IP packets based on a URL match, a file type, a domain, a destination IP address, a source IP address, or a destination port.

You can set specific ToS or DSCP values for the following:

•Requests from the Content Engine to the server

•Responses to the client on a cache hit

•Responses to the client on a cache miss

The ToS or DSCP can be set based on any of the policies matching the src-ip s_ipaddress s_subnet, dst-ip d_ipaddress d_subnet, dst-port port, domain LINE, url-regex LINE, or mime-type LINE options. In addition, you can now configure global ToS or DSCP settings with the ip dscp command.

The Rules Template configuration takes precedence over the ip dscp command, and 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.

rule action dscp client cache-hit {match-server pattern-list list_num [protocol {all | http | https}] | set-dscp dscpvalue | set-tos tosvalue}

rule action dscp client cache-miss {match-server pattern-list list_num [protocol {all | http | https}] | set-dscp dscpvalue | set-tos tosvalue}}

freshness-factor

Determines the Time To Live if the request URL matches a specified regular expression. The refresh configuration takes priority over freshness-factor configurations.

rule action freshness-factor exp_time pattern-list list_num [protocol {all | http | https}]

insert-no-cache

Inserts a no-cache header in the response.

rule action insert-no-cache pattern-list list_num [protocol {all | http | https}]

no-auth

Does not authenticate.

rule action no-auth pattern-list list_num [protocol {all | http | https | mms | rtsp}]

no-cache

Does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.

rule action no-cache pattern-list list_num [protocol {all | http | https | mms}]

no-proxy

For a cache miss, does not use the configured upstream proxy but rather contacts the server directly.

rule action no-proxy pattern-list list_num [protocol {all | http | https}]

redirect

Redirects the original request to a specified URL. Redirect is relevant to the RADIUS server only if the RADIUS server has been configured for redirect.

rule action redirect url pattern-list list_num [protocol {all | http | https | rtsp}]

redirect-url-for-cdn

Redirects the original request to a specified URL for the ACNS network.

rule action redirect-url-for-cdn pattern-list list_num [protocol {all | http | https | rtsp}]

refresh

For a cache hit, forces an object freshness check with the server.

rule action refresh pattern-list list_num [protocol {all | http | https}]

reset

Issues a TCP RST. This reset request is useful when resetting Code Red or Nimda virus requests.

rule action reset pattern-list list_num [protocol {all | http | https | mms | rtsp}]

rewrite

Rewrites the original request as a specified URL

rule action rewrite pattern-list list_num [protocol {all | http | https | mms | rtsp}]

use-dns-server

Caches this object only if it is a match and is allowed to be cached by HTTP. If one or more rules specify this action, an object is cached if and only if it matches at least one of the selective-cache rules and passes every other caching restriction such as the object-size check and the no-cache-on-authenticated-object check. If the object does not match any of the selective-cache rules, the object is not cached.

rule action use-dns-server {hostname | ip-address} pattern-list list_num [protocol {all | http | https}]

use-icap-service

Applies ICAP processing and uses a specific ICAP service only for those requests that match this Rules Template action.

An ICAP service is a collection of attributes that defines the type of modification to be performed on HTTP requests and responses. If this action is configured, you can allow requests and responses to be processed by ICAP servers for content adaptation.

rule action use-icap-service service-name pattern-list list_num [protocol {all | http | https | mms}]

use-proxy

For a cache miss, uses a specific upstream proxy. Specify the upstream proxy IP address (or domain name) and port number. If both no-proxy and use-proxy are matched, no-proxy takes precedence.

rule action use-proxy {hostname | ip-address} port pattern-list list_num [protocol {all | http | https}]

use-server

Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss.

rule action use-server {hostname | ip-address} port pattern-list list_num [protocol {all | http | https}]

use-xforward-clt-ip

Uses client IP address in the forwarded header for filtering.

rule action use-xforward-clt-ip pattern-list list_num [protocol {all | http | https}]

Step 8 Click Submit to save the settings.

Configuring the Rules Template Using CLI Commands

These sections describe how to configure pattern lists and actions for the Rules Template using CLI commands.

•Configuring a Pattern List

•Adding a Pattern to an Existing Pattern List

•Associating an Action with an Existing Pattern List

Configuring a Pattern List

To create a new pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule enable
Enables the Rules Template.
Step 2
ContentEngine(config)# rule pattern-list 1-512 
Creates a pattern list.
Step 3
ContentEngine# show rule pattern-list 1-512 
pattern-type pattern
Displays the Rules Template configuration.
In the following example, the rule pattern-list command is configured to create a pattern list to block all domains that contain .foo.com in the URL request using the domain \.foo.com pattern.
ContentEngine(config)# rule pattern-list 10 domain foo.com
ContentEngine# show rule pattern-list 10 domain 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Pattern-Lists : 
rule pattern-list 10 domain foo.com
ContentEngine#
Adding a Pattern to an Existing Pattern List

To add a new pattern to an already existing pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule pattern-list 1-512 
pattern-type pattern
Adds a pattern to a pattern list.
Step 2
ContentEngine# show rule pattern-list 1-512 
pattern-type pattern
Displays the Rules Template configuration.
In the following example, the rule pattern-list command is configured to add a pattern to an existing pattern list to perform an action yet to be defined on the destination IP address 172.16.25.25 using the dst-ip pattern.
ContentEngine(config)# rule pattern-list 10 dst-ip 172.16.25.25 255.255.255.0
ContentEngine# show rule pattern-list 10 all 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Pattern-Lists : 
rule pattern-list 11 dst-ip 172.16.25.25 255.255.255.0
rule pattern-list 11 domain foo.com
ContentEngine#
Associating an Action with an Existing Pattern List

To associate an action with an existing pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule action action_type 
pattern-list 1-512 protocol protocol_type | all
Associates an action with an existing pattern list.
Step 2
ContentEngine# show rule action action_type protocol 
protocol_type | all
Displays the Rules Template configuration.
In the following example, the rule action block command is configured and associated with an existing pattern list.
ContentEngine(config)# rule action block pattern-list 10 protocol all
ContentEngine# show rule action block 
Rules Template Configuration
----------------------------
Rule Processing Enabled
Actions : 
rule action block pattern-list 10 protocol all 
ContentEngine#
Verifying an Action Performed on a Pattern List

To verify the response sent by the Content Engine to confirm that a certain action is performed on a pattern list, follow these steps:
Command

Purpose
Step 1
ContentEngine(config)# rule action action_type 
pattern-list 1-512 protocol protocol_type | all
Associates an action with an existing pattern list.
Step 2
ContentEngine# show rule action action_type protocol 
protocol_type | all
Displays the Rules Template configuration after a new action has been added.
Step 3
ContentEngine# show statistics rule action 
action_type 
Displays the local Rules Template configuration statistics after a request is issued on which an action should be performed.
In the following example, the rule action block command is configured and associated with an existing pattern list, which lists as its pattern the domain yahoo.com.
ContentEngine(config)# rule pattern-list 30 domain yahoo.com
ContentEngine(config)# rule action block pattern-list 30 protocol all
ContentEngine# show statistics rule action block 
Rules Template Statistics
-------------------------
Rule hit count = 3 Rule: rule action block pattern-list 30 protocol all
ContentEngine#
In this example, the request to yahoo.com was denied three times.

Configuring URL Filtering

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 section allow the Content Engine to control client access to websites in any of the following ways:

•Deny access to URLs specified in a list (HTTP, MMS, and RSTP traffic).

•Permit access only to URLs specified in a list (HTTP, MMS, and RSTP traffic).

•Direct traffic to an N2H2 server for filtering (HTTP traffic only).

•Direct traffic to a Websense enterprise server for filtering (HTTP traffic only).

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

•Filter traffic with Secure Computing Corporation SmartFilterSoftware, Release 3.2 (HTTP traffic only).

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

Note 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. However, the use of good and bad lists can be applied to the streaming media protocol. The scheme enabled for a particular protocol is independent of that of other protocols.

Custom Blocking Messages

The Content Engine can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML file named block.html. Make sure to copy all embedded graphics associated with the custom message HTML window 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 example shown, a block.html file displays the following 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 shown, 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 that 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.

Configuring URL Filter Settings Using the Content Distribution Manager GUI

To configure URL filter settings for the Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 Choose Request Processing > URL Filter. The URL Filter Settings window appears. (See Figure 12-5.)

Figure 12-5 URL Filter Settings Window

Step 4 Enter information for the general URL filter settings. (See Table 12-7 for descriptions of the filter-setting parameters.)

Step 5 Under the Protocol URL Filter Settings heading, click the Edit icon next to the name of the filter type and enter information for HTTP URL filter settings, RTSP URL filter settings, or WMT filter settings in the appropriate fields. (See Table 12-7.)

Step 6 Click Submit to save the settings.

Table 12-7 URL Filter Settings Window

GUI Parameter

Function

CLI Command

General URL Filter Settings

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

—

FTP Server Username

Name needed to access the FTP server from which the URL filter files are downloaded.

—

FTP Server Password

Password of the FTP server from which the URL filter files are downloaded.

—

Confirm Password

Confirms the FTP server password.

—

Remote Custom Msg File Pathname

Path name of the remote file that contains the custom message directory.

—

Custom Msg Directory

Creates a customized URL blocking message to display to the client. This custom message must be an administrator-created HTML file named block.html.

url-filter http custom-message dirname

Protocol URL Filter Settings for HTTP, RTSP, and WMT

Enable Bad Site Filtering

Enables the use of local list filtering for bad sites.

url-filter http bad-sites-deny enable

url-filter rtsp bad-sites-deny enable

url-filter wmt bad-sites-deny enable

Remote Bad Site File Pathname

Path name of the remote bad site file.

—

Bad Site Filename

File containing URLs to which access is denied.

url-filter http bad-sites-deny file filename

url-filter rtsp bad-sites-deny file filename

url-filter wmt bad-sites-deny file filename

Enable Good Site Allow

Enables URL filtering of the local good sites list over HTTP.

url-filter http good-sites-allow enable

url-filter rtsp good-sites-allow enable

url-filter wmt good-sites-allow enable

Remote Good Site File Pathname

Path name of the remote good site file.

—

Good Site Filename

File containing URLs to which access is permitted.

url-filter http good-sites-allow file filename

url-filter rtsp good-sites-allow file filename

url-filter wmt good-sites-allow file filename

FTP Server Hostname

DNS name or IP address of the FTP server from which the URL filter files are downloaded.

—

FTP Server Username

Name needed to access the FTP server from which the URL filter files are downloaded.

—

FTP Server password

Password of the FTP server from which the URL filter files are downloaded.

—

Confirm password

Confirms the FTP server password.

—

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

Enable N2H2 Allow Mode

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

url-filter http N2H2 allowmode enable

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 | hostname} port 1-65535 timeout

Enable Websense Filtering

Enables the use of a Websense server for URL filtering.

url-filter http websense enable

Embedded

Enables the Websense server on the Content Engine. Ensures that the URL filtering software uses the local Websense server and not a remote host as the Websense server.

websense-server enable

WebSense Server Hostname

Host name or IP address of an 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 {ipaddress | hostname} port 1-65535

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

WebSense Request Timeout

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

url-filter http websense server {ipaddress | hostname} port 1-65535 timeout

Websense Request Connections

Number of persistent connections to the Websense server. The range is 1-250 connections per CPU. The default is 40 connections.

Do not change the default unless you know for certain that a different value is required.

url-filter http websense server {ipaddress | hostname} port 1-65535 timeout seconds connections 1-250

Creating a Text File URL List for URL Filtering

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.

Note The local list file per protocol should not contain URLs that belong to other protocols. For instance, the HTTP local list file should only contain 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 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 its impact on performance.

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 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 http bad-sites-deny file 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 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 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 Only one good sites file or one bad sites file can be active at a time per protocol.

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 from any protocol 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).

URL Filtering with the N2H2 Server

Note URL filtering with the N2H2 server only applies to HTTP, FTP, or HTTPS protocols.

N2H2 is a globally deployed URL-filtering software that can filter HTTP, FTP, 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 using the N2H2 server. (See Figure 12-6.) 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 by sending the URL request to an origin server.

Figure 12-6 N2H2 Filtering

URL filtering using an N2H2 server is applied to HTTP, FTP, or HTTPS traffic before the service rule 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 12-8 lists the N2H2 features supported by the Content Engine. One N2H2 server can support multiple Content Engines simultaneously.

Table 12-8 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 the IFP responses.

Enabling N2H2 Filtering Using the Content Distribution Manager GUI

To configure N2H2 filter settings for the Content Engine, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices. The Devices window appears.

Step 2 Click the Edit icon next to the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 Choose Request Processing > URL Filter. The URL Filter Settings window appears. (See Figure 12-5.)

Step 4 Under the Protocol URL Filter Settings heading, click the Edit Filter icon next to the HTTP protocol. The URL Filter Settings for HTTP Protocol window appears. (See Figure 12-7.) Table 12-9 describes the fields in this window and provides the corresponding CLI global configuration commands.

Figure 12-7 URL Filter Settings—HTTP URL Filter Settings

Step 5 Click Submit to save the settings.

Table 12-9 URL Filtering Using the N2H2 Server

GUI Parameter

Function

CLI Command

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

Enable N2H2 Allow Mode

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

url-filter http N2H2 allowmode enable

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 Configuration Commands

•url-filter http N2H2 enable

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

•url-filter http N2H2 server IP address [port 1-65535] [timeout 1-120]

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

•url-filter http N2H2 allowmode enable

This 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 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

Additional CLI commands to use with N2H2 URL filtering are as follows:

•show url-filter http

This 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#
•show statistics url-filter http n2h2

This 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 stat 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 receiving 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 N2H2, clear statistics urlfilter, and clear statistics all commands.

•clear statistics url-filter N2H2

This command resets the statistics counters for the N2H2 server to 0.

N2H2 Configuration and Restrictions

Only one URL filtering scheme can be active per protocol. 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 (or the GUI equivalent) 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 the N2H2 server uses to listen 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 Websense Enterprise Software

Note URL filtering with the Websense server only applies to HTTP, FTP, or HTTPS protocols.

Websense Enterprise is an Internet filtering software that transparently monitors, reports on, and manages employee use of the Internet. Cisco ACNS 5.2 software supports Websense Enterprise software Version 5.2 on all Cisco Content Engine platforms.

You can configure your ACNS network to use an external enterprise server with Websense Enterprise software installed, or you can enable the Content Engine integrated Websense server, or you can configure both an external and an integrated Websense server for the Content Engine. An external Websense server communicates with the Content Engine over the network, whereas an integrated Websense server runs internally to the Content Engine. Communications between the Content Engine caching processes and an integrated Websense server happen internally to the Content Engine.

To access the set of documents on Websense product setup and implementation, you can access the following URL:

http://www.websense.com/support/documentation/index.cfm

Using a Websense Enterprise Server

Figure 12-8 shows a network configuration that uses a Websense enterprise server as a filtering engine for the Content Engine. The Content Engine enforces the filtering policy configured on the Websense server. Refer to the Websense documentation for further information on Websense filtering policies.

Figure 12-8 URL Filtering with a Websense Server

Using the Integrated Websense Server

The integrated Websense server uses approximately 60 MB to 140 MB of RAM in the Content Engine. We recommend that you run the integrated Websense server on Content Engines with at least 512 MB of RAM for best results.

When the Websense server is enabled and the Websense URL database is downloaded the first time, CPU usage can be very high. Therefore, we recommend that you enable the Websense server during off-peak times or times of low network traffic. Otherwise, other processes running on the Content Engine might be affected. If the Websense server stalls, it restarts automatically.

Websense provides an image of the Websense server that resides in the /local/local1/WebsenseEnterprise directory. All the executables as well as the configuration and logging files are stored in the above mentioned directory. This package requires about 150 MB of disk space in the /local/local1/WebsenseEnterprise/EIM directory. An additional 140 MB of disk space is required at the time of downloading the Websense URL database, increasing the total disk space requirement to 290 MB. To ensure that you have enough disk space to properly download the Websense software, we recommend that you increase the amount of sysfs disk space to be greater than the default sysfs on your Content Engine.

Configuring Ports for the Integrated Websense Server

The integrated Websense process requires that four ports be opened for connections either from processes internal to the Content Engine or from external processes such as the PIX firewall. These four ports and default port numbers are as follows:

•15868—Websense server port

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

•15871—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.

•55806—Configuration server port

This port is required by the Websense GUI to configure the Websense server.

•15869—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. These diagnostics connect to this port.

You can configure these ports by modifying the websense.ini file that resides in the /local/local1/WebsenseEnterprise directory. The Websense server must be restarted so it can pick up the newly configured ports.

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

Note The Websense server must to be disabled and then enabled to pick up the newly configured ports.

About Websense Server Failover

In ACNS software, Release 5.2, the Websense server failover feature was added. This feature allows you to configure a Content Engine to use up to two Websense servers for failover purposes (one primary and one secondary server) for URL filtering. Table 12-10 lists the supported Websense server failover configurations.

Table 12-10 Supported Websense Server Failover Configurations

Supported Configurations

Local (Internal)
Websense Server

Remote Websense Server

Option A

The local Websense server is disabled on the Content Engine.

The primary Websense server is running on an external host (for example, Host A).

The secondary Websense server is running on a second external host (for example, Host B).

Option B

The local Websense server is acting as the primary Websense server.

The secondary Websense server is running on an external host.

Option C

The local Websense server is acting as the secondary Websense server.

The primary Websense server is running on an external host.

The order in which you configure the Websense servers determines which server is designated the primary Websense server. The first configured Websense server is designated the primary server. Configuration of a secondary Websense server is optional. To configure Websense server failover using the Content Distribution Manager GUI, see the next section, "Enabling Websense Filtering Using the Content Distribution Manager GUI."

Enabling Websense Filtering Using the Content Distribution Manager GUI

To enable Websense filtering using the Content Distribution Manager GUI, follow these steps:

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the Content Engine that you want to view. The Content Engine Device Home window appears.

Step 3 In the Contents pane, choose Request Processing > URL Filter. The URL Filter Settings for Content Engine window appears. (See Figure 12-5.)

Step 4 Click the Edit Filter icon next to the HTTP protocol. The URL Filter Settings for HTTP Protocol window appears. (See Figure 12-7.) Table 12-11 describes the fields in this window and provides the corresponding CLI global configuration commands.

Step 5 Check the Enable WebSense Filtering check box to enable URL filtering using a Websense server.

Note You can specify up to two Websense servers. The first server specified becomes the primary Websense server and the second server specified becomes the secondary Websense server. You can configure the integrated Websense server to be the primary server, and an external Websense server to be the secondary server, or vice versa.

Step 6 To configure the Content Engine to use an external Websense server as the primary URL filtering server, enter the server IP address or hostname in the Websense Server 1 Hostname field.

Alternatively, check the Embedded check box to configure the Content Engine integrated Websense server as the primary URL filtering server. The Websense Server Hostname field becomes unavailable. This ensures that the URL filtering software uses the local Websense server and not a remote host as the Websense server.

Step 7 In the Port and Request Timeout fields, leave the default settings as they appear unless different settings are required.

Step 8 In the Request Connections field, leave the default setting at 40 connections per CPU unless you know for certain that a different value is required.

Step 9 To configure a secondary Websense server for the Content Engine, choose either an external server or the integrated server and follow the same steps outlined for configuring the primary Websense server options.

Step 10 Check the Enable WebSense Allow Mode check box to enable HTTP access to a website if the Websense server does not respond.

Step 11 Click Submit to confirm your settings.

Table 12-11 Enabling Websense URL Filtering

GUI Parameter

Function

CLI Command

Enable WebSense Filtering

Makes the WebSense Server 1 and 2 Hostname and Port fields available.

url-filter http websense server

WebSense Server 1 Hostname

Enables the external Websense server specified by the IP address or name of the external Websense server.

url-filter http websense server hostname

Port

Port number on which the Websense server will accept requests from the Content Engine. The default port is 15868.

url-filter http websense server hostname port port_num

Request Timeout

Maximum amount of time that the Content Engine will wait for a response from the Websense server. The default is 20 seconds.

url-filter http websense server hostname port port_num timeout num connections num

Request Connections

Number of persistent connections to the Websense server per CPU.

Embedded

Configures the Content Engine to send URL filtering requests to the integrated Websense server running on the Content Engine.

url-filter http websense server local port port_num

Enable WebSense Allow Mode

Allows HTTP access to a website if the Websense server does not respond.

Permits the Content Engine to fulfill the client request after a Websense server timeout. The Websense server returns its own blocking message when a request is denied. With allowmode disabled, on the other hand, the Content Engine blocks all traffic through the Content Engine. By default, allowmode is enabled.

url-filter http websense allowmode enable

Note To use Websense URL filtering with a cluster of Content Engines, make sure to enable Websense filtering with the url-filter http websense enable command (or the GUI equivalent), and configure the url-filter http websense server command (or the GUI equivalent) on each Content Engine in the cluster to ensure that all traffic is filtered.

Websense Status and Statistics Commands

Additional CLI commands to use with Websense URL filtering are as follows:

•show url-filter http

This command shows the IP address of the local host in the Websense sever IP field when the local host is configured as the Websense server for Websense URL filtering.

The show url-filter http command also 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 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 DISABLED 
ContentEngine#
•show websense-server

This command shows the configuration for the Websense server configured on the Content Engine. The output of the command includes the configured port numbers for the Websense server port, blocked message server port, configuration server port, and diagnostics server port; the Websense server version number; and the maximum number of connections.

•show statistics url-filter http websense

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

•write memory

This EXEC command saves Websense configuration files (websense.init and ws.cfg) modified from the external Websense Manager GUI across disk reconfiguration and ACNS software release upgrades (which might erase disk content).

You must execute this command in order to have the most recent configuration modifications, including websense.ini file modifications and the Websense URL filtering configuration changes.

If the write memory command is not used before reboot but after a disk reconfiguration or an ACNS software upgrade that erases disk content, the Websense configurations that were saved when the write memory command was last used are retained. However, if the write memory command was never used before, then default configurations are applied when the content on /local/local1/WebsenseEnterprise directory is erased.

Websense Configuration and Restrictions

Only one URL filtering scheme can be active per protocol. In order to enable Websense URL filtering, you should first make sure that no other URL filtering scheme is enabled on the same 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] command (or the GUI equivalent) and enabling the Websense server with the url-filter http websense enable command (or the GUI equivalent).

The server IP address and port number configured in the Content Engine must match the IP address of the Websense server and the port on which the Websense server listens to filter requests. If the configuration on the Content Engine does not match the configurations on the Websense 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 SmartFilter Software

Note URL filtering with SmartFilter software only applies to HTTP, FTP, or HTTPS protocols.

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 two end user management tools called the SmartFilter Administration Console and the SmartFilter Administration Server. This GUI components download 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 http smartfilter enable command (or the GUI equivalent) on each Content Engine in the cluster to ensure that all traffic is filtered.

Refer to the SecureComputing website (http://www.securecomputing.com) for documentation regarding SmartFilter.

SmartFilter Software and the Action No-Auth Command Rule Interaction

The rule action no-auth global configuration command permits specific login and content requests to bypass authentication and authorization features such as LDAP, RADIUS, SSH, or TACACS+. In the following example, any requests from the source IP address (src-ip) 172.16.53.88 are not authenticated.
ContentEngine(config)# rule enable
ContentEngine(config)# rule action no-auth pattern-list 1 protocol all
ContentEngine(config)# rule pattern-list 1 src-ip 172.16.53.88 255.255.255.255
If the software is configured for authentication and SmartFilter URL filtering, requests that are allowed to bypass authentication will also bypass the SmartFilter URL filter.

Configuring the Content Engine GUI for Secure or Nonsecure Access

You can configure the Content Engine GUI on a centrally deployed Content Engine for secure or nonsecure access. The secured Content Engine GUI is the default.

Either secure or nonsecure access to the Content Engine GUI is possible but not both. For example, if the secured Content Engine GUI is enabled (for example, https:// access on port 8003), then nonsecure access to the Content Engine GUI (for example, http:// access on port 8001) is not allowed. The port number of the Content Engine GUI is determined when the ACNS software is installed on the Content Engine.

Before logging in to the Content Engine GUI, check that you have the following information:

•Name or IP address of the Content Engine that you want to log in to

•User account (username and password) that you want to log in with. If you do not have a user account, your ACNS system administrator must create one for you.

•Type of access enabled on the Content Engine GUI (secure or nonsecure).

To access the Content Engine GUI, you must enter the URL or IP address of the Content Engine and the port number. The URL (location) of the Content Engine is determined during the installation of the ACNS software. If your network supports DNS and the IP address of the Content Engine has been added to your DNS table, you can access the Content Engine GUI by using the DNS name of the Content Engine.

To configure the Content Engine GUI for secure or nonsecure access, follow these steps:

Step 1 Choose Devices > Devices. The Devices window appears, listing all the device types configured in the ACNS network.

Step 2 Click the Edit icon next to the Content Engine for which you want to enable the graphical user interface. The Device Home for Content Engine window appears.

Step 3 In the Contents pane, choose Request Processing > GUI Server. The GUI Server Settings for Content Engine window appears.

Step 4 Under the GUI Server Settings section, follow these steps:

a. Check the GUI Server Enable check box to enable nonsecure access to the Content Engine GUI.

b. In the GUI Server Port field, specify a port number for the graphical user interface server port. The default port for nonsecure access to the GUI is 8001.

Step 5 Under the Secured GUI Server Settings section, follow these steps:

a. Check the Secured GUI Server Enable check box to enable secure access to the Content Engine GUI.

b. In the Secured GUI Server Port field, specify a port number for the graphical user interface server port. The default port for secure access to the GUI is 8003.

Step 6 Click Submit to save the settings. A "Click Submit to Save" message appears in red next to the Current Settings line when there are pending changes to be saved after you have applied default and device group settings. You can also revert to the previously configured settings by clicking Reset. The Reset button is visible only when you have applied default or group settings to change the current device settings but have not yet submitted the changes.

If you try to leave this window without saving the modified settings, a warning dialog box prompts you to submit the changes. This dialog box only appears if you are using the Internet Explorer browser.

Note When secured access is enabled, unsecured access is automatically disabled.