Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.5 - Chapter 13: Configuring the Rules Template on Standalone Content Engines [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring the Rules Template on Standalone Content Engines

Rules Template Overview

Supported Rule Actions per Protocol

Understanding Actions and Patterns

Supported Rule Patterns

Supported Rule Actions

Example of no-url-filtering Action

Example of use-proxy Action

Example of use-server Action

Example of no-proxy Action

Supported Action and Pattern Combinations

Rules Template Processing Considerations

Rule Command for Converting Hostnames to IP Addresses

Execution Order of Rule Actions

Execution Order of Rule Patterns

Configuring the Rules Template

Enabling Rules Processing

Configuring Rules for Standalone Content Engines

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

Examples of Configuring Rules for Standalone Content Engines

Displaying Statistics for Configured Rules

Clearing Statistics for Configured Rules

Using Regular Expressions for Rules

Special Characters in Regular Expressions

Rules Caveats and Performance Guidelines

Pattern List Group-Type Caveats

Rules Configuration Guidelines for Best Performance

Configuring the Rules Template on Standalone Content Engines

This chapter describes how to configure the Rules Template on standalone Content Engines. The Rules Template specifies the rules by which the Content Engine filters HTTP, HTTPS, and RTSP traffic. These configured rules might rewrite certain headers, redirect the request, or otherwise manipulate the request.

This chapter contains the following sections:

•Rules Template Overview

•Understanding Actions and Patterns

•Configuring the Rules Template

•Displaying Statistics for Configured Rules

•Clearing Statistics for Configured Rules

•Using Regular Expressions for Rules

•Rules Caveats and Performance Guidelines

Note The term HTTP traffic is used to refer to requests over HTTP including HTTP, FTP-over-HTTP, and HTTPS-over-HTTP. The Rules Template is not supported for FTP native requests.

For complete syntax and usage information for the CLI commands used in this chapter, see the Cisco ACNS Software Command Reference, Release 5.5 publication.

Rules Template Overview

The Rules Template feature allows you to specify a set of rules, each clearly identified by a pattern and an action. This feature allows you to configure a standalone Content Engine to use specific rules to filter HTTP, HTTPS, and RTSP traffic. A common use of this feature is to configure a Content Engine to block the spread of Internet worms and viruses within an organization by checking whether a requested web page matches the pattern of a known Internet worm and if so then automatically blocking the request.

If you have enabled rules processing on a Content Engine (enabled the Rules Template feature on the Content Engine and configured rules for the Content Engine), the Content Engine checks every incoming client request to determine if a rule pattern matches the requested content. If a rule pattern matches the given request, the Content Engine uses the specified action (policy) to handle this incoming traffic.

There are two basic types of pattern comparisons: string comparisons and regular expressions. A string comparison requires an exact match. A regular expression comparison searches within a string for a substring match. The regular expression does not have to match the whole string and matching is not case sensitive. (See the "Using Regular Expressions for Rules" section for more information about regular expressions.)

The Content Engine can match incoming requests against the following:

•Patterns in the IP address of the client requesting the content (source IP address), including IP address, network mask, and port list

•Patterns in the IP address of the origin web or media server (destination IP addresses), including IP address, network mask, and port list

•Regular expression of the URL

•Regular expression of the domain portion of the URL

•MIME types of the web object that the client is requesting

•Regular expressions symbolizing domain names

•Headers that are sent in the request, including:

–"User-agent of the request," which indicates which client software is issuing the request

–"Referer," which indicates the web page from which the browser jumped to this link

–"Request Line," which indicates the request line itself

The Rules Template feature is mostly applicable to the HTTP, FTP, and HTTPS protocols. Policies that support streaming media object protocol such as RTSP, in addition to HTTP, FTP, and HTTPS, are indicated in Table 13-1.

Table 13-1 Rules Template Policies

Policy (Action)

HTTP
Requests

WMT
Requests

RTSP
Requests

Allow the request.

See
Table 13-2.

*

*

Append the username to request headers.

Block the request.

*

*

Override the HTTP response header
and cache the object.

Cache the object depending
on the HTTP response header.

Bypass authentication for the request.

*

*

Use a specific object freshness calculation factor.

Reset the request.

Do not cache an object.

Bypass an upstream proxy for the request.

Redirect the request to a different URL.

*

Revalidate the object with the origin server.

Rewrite the URL.

*

*

No URL filtering for the specified HTTP and
HTTPS requests.

Use a specific ICAP server.

Use a specific upstream proxy.

Use a specific server for the request.

Set ToS or DSCP in the response sent to the client.

Set ToS or DSCP in the response sent to the server.

Supported Rule Actions per Protocol

Table 13-2 lists the rule actions per protocol that are supported by standalone Content Engines running the ACNS 5.3.1 software and later releases. An asterisk (*) indicates that a rule action is supported for that particular protocol. WCCP means transparent support. A "*1" indicates that a rule action is only supported for that particular protocol in the ACNS 5.1.5 software and later releases.

For the RTSP streaming protocol, the redirect and the redirect_url_for_cdn rule actions are supported for RTSP requests from RealMedia players but are not supported for WMT. Consequently, these two rule actions are not supported for RTSP requests from Windows Media players. For example, Windows Media Services 9 (WMS 9) supports the block, reset, rewrite, and allow rule actions for RTSP requests, but does not support the redirect and redirect_url_for cdn rule actions for RTSP requests.

Table 13-2 Matrix of Supported Rule Actions Per Protocol

Rule Actions

Protocol

HTTP-
over-
HTTP

FTP^-over-
HTTP

HTTPS^-over-
HTTP

HTTP
WCCP

FTP-
WCCP
(Native FTP)

HTTPS-WCCP

HTTPS-WCCP
(tunneled, only
available
ACNS 5.1.5
Software
or later)

RTSP

allow

*

*

*

*

*

No rule shall apply here.

*

append-
username-
header

*

*

*

block

*

*

*

*

*

*

cache-cookie

*

*

*

cache-non-
cacheable

*

*

*

cache-only

*

*

*

dscp

*

*

*

*

freshness-

factor

*

*

*

insert-no-cache

*

*

*

*

no-auth

*

*

*

*

no-cache

*

*

*

*

no-persistent-
connection

*

*

no-proxy

*

*

*

no-url-
filtering

*

*

*

*

redirect

*

*

*

*1

*

redirect-url-
for-cdn

*

*

refresh

*

*

*

*

reset

*

*

*

*

*

rewrite

*

*

*1

*

use-dns-server

*

*

use-icap-
service

*

use-proxy

*

*

*

use-server

*

*

*1

use-xforward-
clt-ip

*

*

Understanding Actions and Patterns

A rule is specified by a pattern and an action.

•A pattern defines the limits of an incoming request; for instance, a pattern may specify that the source IP address fall in the subnet range 172.16.*.*.

When defining a pattern, you specify the following information:

–The pattern type (for example, "src-ip" for the source IP address)

–The pattern value (for example, "172.16.*.*" to indicate that the source IP address must fall within this subnet range)

–The number of the pattern list to which this pattern should be added (A pattern list is a container list of patterns that is identified by a pattern list number, for example, pattern list 10)

For a complete list of supported patterns, see Table 13-3.

•An action is the policy that is applied to an incoming request if the request matches the specified pattern. An action is something that the Content Engine performs when processing a request, for instance, blocking the request, using an alternative proxy, and so forth. For a complete list of supported actions, see Table 13-4.

Rules can be dynamically added, displayed, or deleted from the Content Engine. The rules are preserved across reboots because they are written into persistent storage such as NVRAM using the appropriate Content Engine CLI commands or the GUI. Because rules consume resources, the more rules there are defined, the more Content Engine performance may be affected. For information about the limitation on the number of rules that can be configured on a Content Engine, see the "Configuring the Rules Template" section.

You can use the Content Engine CLI or the GUI (as shown in Figure 13-1) to specify a pattern and the corresponding action.

Figure 13-1 Rules Template Window

Note To access the Rules Template window, choose System > Rules Templates from the Content Engine GUI. To view detailed information about how to use this window to configure the Rules Template, click the HELP button.

The rule pattern-list global configuration command allows you to create a pattern list and add specific patterns to that pattern list. The patterns within the pattern list can be ANDed or ORed together. After defining one or more pattern lists, you can use the rule action global configuration command to associate specific actions with a defined pattern list. The following example shows how patterns are ANDed by configuring different patterns with the same pattern list number and applying that pattern list to an action:
ContentEngine(config)# rule pattern-list 1 url-regex yahoo
ContentEngine(config)# rule pattern-list 1 dst-port 80
ContentEngine(config)# rule action block pattern-list 1 
The CLI method is used throughout the rest of this chapter to illustrate how to configure the Rules Template on a standalone Content Engine. For more information about how to use the Content Engine CLI to configure the Rules Template, see the "Configuring the Rules Template" section.

Supported Rule Patterns

In the ACNS 5.1 software release, three new rule patterns were added (groupname, username, and groupname-regex). These new rule patterns support access control policies that are based on the group name and username of the authenticated NTLM and LDAP users. Group name-based rules apply to users who have been authenticated through NTLM and LDAP. Username-based rules apply to users who are authenticated through LDAP, NTLM, RADIUS, and TACACS+ (request authentication methods that involve a username for authentication).

The following example shows how to enable rule processing on the Content Engine (using the rule enable global configuration command) and then configure the Content Engine to block all end users in the Engineering group from downloading FTP URLs (FTP requests from a client browser) that contain the expression "java":
ContentEngine(config)# rule enable
ContentEngine(config)# rule pattern-list 1 group-type and
ContentEngine(config)# rule pattern-list 1 groupname Engineering
ContentEngine(config)# rule pattern-list 1 url-regex java
ContentEngine(config)# rule action block pattern-list 1 protocol ftp
Note Authorization through group name-based and username-based rules occurs only after HTTP request authentication and group-based access list authorization have occurred. If the configuration in the Rules Template and the access list match, the access list takes precedence.

Table 13-3 describes the types of rule patterns that you can add to a pattern list.
Table 13-3 Supported Types of Patterns
Pattern

Description

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 be made only when the pattern is found at the end of a line. (See the "Using Regular Expressions for Rules" section for more information about regular expressions.)

Tip This rule pattern can be circumvented by users entering URLs with IP addresses instead of domain names.
dst-ip
Matches the request's destination IP address and netmask against the IP address and netmask specified in the rule. For example, the following command:

CE(config)# rule pattern-list 2 dst-ip 10.255.0.11 255.255.255.255
matches any transparent mode request destination IP address or the DNS-resolved IP address of the domain from the proxy mode URL. This example matches a specific host, but by modifying the mask, you can match entire subnets or groups of IP addresses.

Tip To test this pattern in proxy mode requires that the Content Engine perform a DNS lookup, which can have an impact on performance.
dst-port
Matches the request's destination port number against the port number specified in the rule. For example, the following command:

CE(config)# rule pattern-list 3 dst-port 8083
matches any request destined for TCP port 8083. In proxy mode, this pattern matches the port from the request URL. In transparent mode, this pattern matches the TCP destination port.
groupname
Matches the group name of the end user (the web client that is requesting content), who was authenticated through LDAP or NTLM, against the group name specified in the rule. For example, specify the group name Engineering for pattern list 1, as follows:

ContentEngine(config)# rule pattern-list 1 groupname Engineering
This pattern can be applied only to request authentication for users who have been authenticated through LDAP or NTLM. This pattern supports exact string comparison and is case insensitive. The maximum length of the group name is 129 characters. Valid characters are an underscore and alphanumeric characters and special characters that are accepted by Active Directory. 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.
groupname-
regex
Matches the group name of the end user (the web client that is requesting content) against the regular expression specified in the rule. The maximum length of the group name is 255 characters. For example, the following command:

ContentEngine(config)# rule pattern-list 5 groupname-regex ING
matches request-authenticated users who are members of any group that contains "ING" in its name. In this example, "ACCOUNTING" and "MARKETING" will be matched, but not "CORPORATE".

This rule pattern requires that NTLM or LDAP request authentication is configured and that when a user authenticates, a group name associated with that user is returned to the Content Engine. You can specify multiple groups by using the bar symbol (|) to delimit the string.
group-type

Specifies whether the pattern list is an AND or OR type. This parameter is not actually a pattern, but it defines how to handle multiple patterns in the pattern list. If the group-type is OR, then the action will be performed if any pattern in the list is matched. If the group-type is AND, then the action will be performed only if all the patterns in the list are matched. Pattern lists with multiple patterns default to the OR group-type.
header-field
Request header field pattern. Request header field patterns referer, request-line, and user-agent are supported for the block, reset, redirect, and rewrite actions.

The header-field referer pattern is a regular expression comparison against the Referer HTTP header in the request. For example, the following command:

CE(config)# rule pattern-list 6 header-field referer cisco
matches any HTTP request that has the pattern "cisco" anywhere in the Referer header line.

The header-field request-line pattern is a regular expression comparison against the request line of the request. For example, the following command:

CE(config)# rule pattern-list 6 header-field request-line HEAD
matches any request that contains the pattern "HEAD" in the request line.

The header-field user-agent pattern is a regular expression comparison against the User-Agent header in the request. For example, the following command:

CE(config)# rule pattern-list 6 header-field user-agent layer
matches any request where the User-Agent header line contains the string "layer". For instance, the rule pattern in this example will match "NSPlayer".
header-field-
sub
Matches the pattern in the request header and replaces the text. This pattern contains arguments for referer, request-line, and user-agent.

The header-field-sub referer pattern is a regular expression comparison against the Referer HTTP header that also replaces Referer HTTP header text. For example, the following command:

CE(config)# rule pattern-list 9 header-field-sub referer yahoo google
matches any Referer HTTP header that contains the string "yahoo" and replaces it with "google".

The header-field-sub request-line pattern is a regular expression comparison against the request line that also replaces HTTP request line text. For example, the following command:

CE(config)# rule pattern-list 10 header-field-sub request-line yahoo google
matches any HTTP request line that contains the string "yahoo" and replaces it with "google".

The header-field-sub user-agent pattern is a regular expression comparison against the User-Agent header that also replaces User-Agent header text. For example, the following command:

CE(config)# rule pattern-list 11 header-field-sub user-agent Mozilla NoZilla
matches any request with a User-Agent header that contains the string "Mozilla" and replaces it with "NoZilla".
icap-service-
name

Specifies the name of the ICAP service that should be used.
mime-type
Matches the MIME type of the response from the origin server against the MIME type string specified in the rule. (For an explanation of mime-type, see RFC 2046 at http://www.faqs.org/rfcs/rfc2046.html.) For example, the following command:

CE(config)# rule pattern-list 12 mime-type java
matches any MIME type that contains the substring "java", such as application/x-javascript.
src-ip

Matches the request's source IP address and netmask against the IP address and a netmask specified in the rule.

Tip If this rule is configured on an outgoing proxy, requests will be sourced from a subordinate proxy IP address. For example, the following command:
CE (config)# rule pattern-list 13 src-ip 10.255.11.128 255.255.255.192
matches requests that come from any client on the 10.255.11.128 subnet. It will not match requests from clients on the 10.255.11.64 or 10.255.11.192 subnets.
username
Matches the username of the end user (the web client that is requesting content), who was authenticated through LDAP, NTLM, RADIUS, or TACACS+, against the username or usernames specified in the rule. The maximum length of username is 129 characters for LDAP, RADIUS, or TACACS+ authentication. Valid characters for the username are alphanumeric characters (a-z, A-Z, 0-9) and the following special characters:

! @ # $ % ^ & ( ) - _ { } . ~ `

However, the username cannot contain the following special characters:

\ + = : ; ? < > ,

This pattern supports exact string comparison and is case insensitive.

Specify multiple usernames in the same line for the same pattern list by using a comma-delimited string, as shown in the following example:

ContentEngine(config)# rule pattern-list 1 username jdoe8,dsmith7,jsmith50
By default, the match does not consider the domain name and matches only the username. To include the domain name as well as the username in the match, specify domainname\username,as shown in the following example:

ContentEngine(config)# rule pattern-list 1 username 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\*
domainname is the name of the domain (for example, cisco).
URL-regex
Matches the URL against the regular expression specified in the rule. The match is case insensitive. For example, the following command:

CE(config)# rule pattern-list 14 url-regex cgi-bin
matches any URL that contains the string "cgi-bin".

Tip If the request was made in transparent mode, a proxy mode URL is constructed before the comparison is made.
URL-regsub
For the rewrite and redirect actions, matches the URL against a regular expression and forms a new URL in accordance with the pattern specified. For example, the following command:

CE(config)# rule pattern-list 15 url-regsub yahoo google
matches any URL that contains the string "yahoo" and replaces it with "google". The match is case insensitive. The valid substitution index range is from 1 to 9.
For information about how to use the rule global configuration command to specify patterns for a standalone Content Engine, see the "Configuring Rules for Standalone Content Engines" section.

Supported Rule Actions

To display a list of supported rule actions, enter the rule action ? global configuration command.
ContentEngine(config)# rule action ?
  allow                     Allow the request
  append-username-header    Append the username in the header to the request
                            sent to the server
  block                     Block
  cache-cookie              Cache request containing Cookies
  cache-non-cacheable       Cache this object (Overriding HTTP response headers)
  cache-only                Cache this object only
  dscp                      Set IP TOS/DSCP (Differentiated Services) Field
  freshness-factor          Caching heuristic modifiers
  insert-no-cache           Insert no-cache headers to the response
  no-auth                   Do not authenticate
  no-cache                  Do not cache this object
  no-persistent-connection  Dont use persistent connection to all/client/server
                            connections
  no-proxy                  Do not use any upstream proxy
  no-url-filtering          Do not use URL filtering
  redirect                  Redirect request to rewritten URL
  redirect-url-for-cdn      Redirect alternate url for cdn content
  refresh                   Revalidate the object with the web server
  reset                     Issue a TCP RST
  rewrite                   Rewrite URL and fetch
  use-dns-server            Use a specific DNS server
  use-icap-service          Use a specific ICAP service
  use-proxy                 Use a specific upstream proxy
  use-server                Use a specific server
  use-xforward-clt-ip       Client IP in x-forwarded header will be used for
                            filtering.
Table 13-4 describes the types of actions that you can associate with a defined pattern list.

Table 13-4 Supported Types of Actions

Action

Description

allow

Allows incoming requests that match the pattern list. This rule action can be used in combination with reset or block actions to allow selective types of requests. Allow does not carry any meaning as a stadalone action.

append-username-
header

Appends a Uname HTTP header to the request sent to the server. This action facilitates single sign-on if the web server recognizes the uname HTTP header. This rule action requires that RADIUS, NTLM, or LDAP request authentication be configured.

block

Blocks incoming requests that match the pattern list and allows all others.

cache-cookie

Caches requests with pattern matches that contain cookies. To be effective, this rule action also requires a corresponding rule action refresh if cookies are user-specific. Never configure this action when dynamic content is returned based on the cookie.

cache-non-
cacheable

Overrides the HTTP response headers and caches objects that would not normally be cached.

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 cache-only 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 cache-only rules, the object is not cached.

dscp client

Configures IP Type of Service/differentiated services code point (ToS/DSCP) field responses for the client. Setting the ToS or DSCP is called packet marking, allowing you to partition network data into multiple priority levels or types of service.

dscp client
cache-hit

Cache hit responses to the DSCP client.

dscp client
cache-miss

Cache miss responses to the DSCP client.

dscp server

Configures the IP ToS or DSCP code point field for requests to the origin server.

dscp server
match-client

Uses the client's ToS or DSCP value.

dscp server
set-dscp

Specifies the DSCP value. For a list of DSCP values, see Table 11-1.

dscp server
set-tos

Specifies the Type of Service (ToS) value. For a list of ToS values, see Table 11-2.

freshness-factor

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

insert-no-cache

Inserts a no-cache header into the response.

no-auth

Does not authenticate. (The origin server might still require authentication.)

no-cache

Returns the requested object, but does not cache this object. If both the no-cache and selective-cache actions are matched, no-cache takes precedence.

no-persistent-
connection all

Does not use a persistent connection for the request if the pattern is matched.

no-persistent-
connection client

Does not use a persistent connection to client connections only.

no-persistent-
connection server

Does not use a persistent connection to server connections only.

no-proxy

Does not use an outgoing proxy. (This action does not preclude the request going through a transparent proxy.) For a cache miss, the server is contacted directly rather than using the configured upstream proxy. For an example of how to use this action, see the "Example of no-proxy Action" section.

no-url-filtering

Bypasses URL filtering for HTTP and HTTPS requests. This feature is supported for local list URL filtering (good and bad site lists), as well as Websense, SmartFilter, or N2H2 URL filtering in the ACNS 5.2.3 software and later releases. For an example of how to use this action, see the "Example of no-url-filtering Action" section.

redirect-url-for-cdn

Redirects the original request to an alternative URL (specified in the manifest file using the alternateURL attribute) for ACNS network content.

Note This rule action is only applicable for Content Engines that are registered with a Content Distribution Manager; it is not applicable to standalone Content Engines.

redirect

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

refresh

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

reset

Issues a TCP RST. This reset request is useful as a security precaution to block known virus request patterns, such as Code Red or Nimda virus requests.

rewrite

Rewrites the original request as a specified URL. The Content Engine searches for the rewritten URL in the cache, and then on a cache miss, fetches the rewritten URL and returns the object transparently to the client. It is preferable to use a redirect rule rather than rewrite because of possible performance impacts.

The URL rewrite could change the domain name of the URL, which necessitates a DNS lookup to find the destination IP address of the new server to which the request must be sent. The original IP address derived from the WCCP redirect packet cannot be used.

Note Rules that are checked after the rewrite rule will still use the original URL rather than the rewritten URL.

selective-cache

Caches the object if permitted by HTTP.

use-dns-server

Uses the specified DNS server.

use-icap-service

Uses the specified ICAP service for the specified pattern list.

use-proxy

For a cache miss, uses the specified upstream proxy. Specify the upstream proxy IP address (or domain name) and port number. For an example of how to use this action, see the "Example of use-proxy Action" section.

Note If failover is specified and the proxy connection fails, uses the globally configured http proxy outgoing host. If failover is not specified and the proxy connection fails, no proxy is used.

use-server

Sends server-style HTTP requests from the Content Engine to the specified IP address and port on a cache miss. For an example of how to use this action, see the "Example of use-server Action" section.

Note The request from the client can be a proxy style or server style request.

use-xforward-clt-ip

Uses the client IP address from the X-Forwarded-For HTTP header for content filtering.

Example of no-url-filtering Action

This example shows how to use the no-url-filtering action to bypass URL filtering feature with Websense URL filtering.

Specify the rule action no-url-filtering command and then associate it with a specific pattern list (pattern list 100). Add the domain pattern type to pattern list 100 in order to configure the Content Engine to match requests that have foo.com as the domain. In this example, Websense URL filtering has already been configured and enabled on the Content Engine:
ContentEngine (config)# rule action no-url-filtering pattern-list 100
ContentEngine (config)# rule pattern-list 100 domain .*foo.com
ContentEngine (config)# rule enable
Note The no-url-filtering action supports the following rule patterns: src-ip, dst-ip, dst-port, domain, group-name, groupname-regex, header-field, url-regex, and username. Patterns can be ANDed or ORed by using the group-type pattern (for example, rule pattern-list 1 group-type and). The default is OR.

When the Content Engine receives an HTTP or HTTPS request that has foo.com as the domain, the rule action no-url-filtering rule is matched. Consequently, the Content Engine bypasses URL filtering for that particular request as shown in this partial output of the debug http proxy command:
Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering match 
- Bypassing urlfiltering 
If the rule action no-url-filtering rule is matched and SmartFilter URL filtering is being used instead of Websense URL filtering, the output of the debug http proxy command would be as follows:
Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering match 
- Bypassing SmartFilter processing
When the Content Engine receives an HTTP or HTTPS request for websites other than foo.com (for requests that have www.abc.com as the domain), the rule action no-url-filtering rule is not matched. Consequently, the Content Engine proceeds with Websense URL filtering for that particular request as shown in this partial output of the debug http proxy command:
Oct 28 12:28:06 Content Engine 3: Rule action no-url-filtering not hit - Proceed with 
urlfiltering 
If the rule action no-url-filtering rule is not matched and SmartFilter URL filtering is being used instead of Websense URL filtering, the output of the debug http proxy command would be as follows:
Oct 28 12:25:12 Content Engine 3: Rule action no-url-filtering not hit- Proceed with 
SmartFilter processing
To display statistics for the no-url-filtering action, enter the show statistics rule http action no-url-filtering EXEC command.

To display information about the no-url-filtering action, enter the show run and show rule all EXEC commands.

Example of use-proxy Action

This example shows a typical use of the use-proxy action.

The rule action use-proxy proxy pattern-list number global configuration command can be used to configure only one proxy for a particular pattern list. If you attempt to configure a second proxy for the same pattern list (for example, pattern list 1), you will receive an error message that indicates the rule entry already exists.

ContentEngine12 (config)# rule action use-proxy 10.16.0.0 8080 pattern-list 1

ContentEngine12 (config)# rule action use-proxy 10.77.157.42 8080 pattern-list 1

Rule entry is duplicate

Rule use-proxy exists with IP: 10.16.0.0.Please remove it and reconfigure

When rule action use-proxy is configured with "failover" qualifier, first it would try to connect to proxy configured in use-proxy, if it fails, it would fall back to outgoing proxy, configured through the cli "http proxy outgoing host <host> <port>"

If the use-proxy feature is configured without failover (for example, you have entered the rule action use-proxy 10.16.0.0 8080 pattern-list 1 command), the Content Engine will send the request to the use-proxy (the server with the IP address of 10.16.0.0). If the Content Engine does not obtain a response from the use-proxy, then it will send an error message to the client without failing over to the HTTP outgoing proxy.

If the use-proxy feature is configured with failover (for example, you have entered the rule action use-proxy 10.16.0.0 8080 failover pattern-list 1 command), the Content Engine will send the request to the use-proxy (for example, the server with the IP address of 10.16.0.0). If the Content Engines does not obtain a response from the use-proxy, then it fails over to the specified HTTP outgoing proxy (for example, the server that has been specified as the primary outgoing host with the http proxy outgoing host 10.77.157.42 8080 primary global configuration command). The following example shows a sample configuration in which the use-proxy feature is configured with failover:

ContentEngine 12# show run

Sep 1 06:42:32 ContentEngine 12-admin-shell: %CE-PARSER-6-350232: CLI_LOG shell_parser_log: sh run

! ACNS version 5.4.0

!

!

hostname ContentEngine 12

!

http client-no-cache-request ignore

http proxy incoming 8080

http proxy outgoing host 10.77.157.42 8080 primary

!

ftp-over-http proxy incoming 8080

!

!

< output cut >

!

rule enable

rule action use-proxy 10.16.0.0 8080 failover pattern-list 1

rule pattern-list 1 domain yahoo.com

!

<output cut >

Example of use-server Action

This example shows a typical use of the use-server action. For HTTP requests that match the specified criteria, if the Content Engine needs to contact the origin server (for example, if a cache miss occurs), the Content Engine does not go to the server indicated in the request to retrieve the requested object; instead, it uses a different destination server that is specified in the rule. This feature is primarily used for on-demand requests, and is typically used in reverse proxy deployments.

In this example, the Content Engine is a reverse proxy for www.abcbigcorp.com and is a proxy to the rest of the Internet. The IP address for the company's website (www.abcbigcorp.com) is actually the IP address of the Content Engine, and not the company's web site server. When the Content Engine receives the request http://www.abcbigcorp.com/main.html, its normal processing would be to obtain the IP address of www.abcbigcorp.com and send the request to that IP address. However, in this case, because the IP address of www.abcbigcorp.com is the IP address of the Content Engine, the administrator needs to prevent the Content Engine from sending the request to itself.

Consequently, the administrator of CE1 can configure the following rule that will instruct CE1 to send such requests (for example, cache misses) to the web server for www.abcbigcorp.com:
CE1(config)# rule use-server 1.2.3.4 80 domain www.abcbigcorp.com 
1.2.3.4 is the IP address of the web server for www.abcbigcorp.com.

Note This rule applies to HTTP processing only.

Example of no-proxy Action

The no-proxy action is applicable when the administrator of the Content Engine has configured an outgoing proxy server for the Content Engine. The no-proxy action states that for requests that match the criteria, if a connection with the origin server is needed (for example, because of a cache miss), the Content Engine should not use the specified proxy server to establish the connection with the origin server. This rule is useful if a company has a Content Engine (CE1) at the Internet gateway to cache all Internet content, and a Content Engine at each branch office (CE2, CE3, CE4). In this case, the administrator can configure CE2, CE3, and CE4 at the branch offices to use CE4 as their outgoing proxy server, but set up the no-proxy rule for requests for corporate internal content.

When CE2, CE3, and CE4 receive a client request and the requested content is not already stored in their local caches, they will process the request as follows:

•If the client request is for Internet content, then CE2, CE3, and CE4 should use CE1 at the Internet gateway instead of going to the origin server directly.

•If the client request is for corporate internal content, then CE2, CE3, and CE4 should establish a connection directly with the origin server instead of going to CE1.

For information about how to use the rule action global configuration command, see the "Associating an Action with an Existing Pattern List" section. For a list of supported action and pattern combinations, see Table 13-5 and Table 13-6. For a list of the supported rule actions per protocol, see Table 13-2.

Supported Action and Pattern Combinations

Not all actions support all patterns for request matching because some patterns do not make sense for some actions. See Table 13-5 and Table 13-6 for a list of supported action and pattern combinations.

An asterisk "*"indicates that a particular action and pattern combination is supported in the ACNS 5.2.1 software and later releases.

Table 13-5 Supported Action and Pattern Combinations for Standalone Content Engines—Part 1

Action

Pattern

domain

dst-
ip

dst-
port

header-
field-
referrer

header-
field-
req-
line

header-
field-
user-
agent

header-
field-
sub-
referrer

header-
field-
sub-
req-
line

header-
field-
sub-
user-
agent

mime-
type

src-
ip

url-
regex

url-
regsub

groupname,
username,
groupname
regex

allow

*

*

*

*

*

*

*

*

*

append-
username
header

*

*

*

*

*

*

block

*

*

*

*

*

*

*

*

*

cache-
cookie

*

*

*

*

*

cache-
non-
cacheable

*

*

*

*

cache-
only

*

*

*

*

dscp
client

*

*

*

*

*

*

dscp
server

*

*

*

*

*

freshness-
factor

*

*

*

*

*

*

insert-
no-cache

*

*

*

no-auth

*

*

*

*

*

no-cache

*

*

*

*

*

*

Table 13-6 Supported Action and Pattern Combinations for Standalone Content Engines—Part 2

Action

Pattern

domain

dst-
ip

dst-
port

header-
field-
referrer

header-
field-
req-
line

header-
field-
user-
agent

header-
field-
sub-
referrer

header-
field-
sub-
req-
line

header-
field-
sub-
user-
agent

mime-
type

src-
ip

url-
regex

url-
regsub

groupname,
username,
groupname
regex

no-
persistent-
connection

*

*

*

*

*

*

*