|
|
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 the Content Engines, organizations realize an immediate return on investment as a result of increased productivity and recaptured network bandwidth, while reducing legal liability.
Only one form of URL filtering can be active at a time.
 |
Note The URL filtering feature in ACNS 4.1 software differs from the URL feature in other releases as follows: There is now an enable command option for the good-sites and bad-sites options; the URL list filenames and the customized blocking message directory name are now specified in the command-line interface; you can now use the url-filter local-list-reload EXEC command to dynamically refresh a local URL list; and bad-sites-block has been changed to bad-sites-deny. |
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.
To deny requests for specific URLs, do the following:
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 and good lists, for example, /local1/filtered_urls. |
Step 3 Use the url-filter bad-sites-deny command to point to the bad URL list.
Console(config)# url-filter bad-sites-deny local/local1/badurl.lst
Step 4 Use the url-filter bad-list enable command to actively deny the URLs.
Console(config)# url-filter enable bad-list
To permit specific URLs to the exclusion of all other URLs, do the following:
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 bad and good lists, for example, /local1/filtered_urls. |
Step 3 Use the url-filter good-sites-allow command to point to the goodurl.lst file.
Console(config)# url-filter good-sites-allow local/local1/goodurl.lst
Step 4 Use the url-filter good-sites-allow enable command to actively permit only the good URLs.
Console(config)# url-filter good-sites-allow enable
|
Note When you update the badurl.lst or goodurl.lst file, use the url-filter local-list-reload EXEC command to recopy the URL list file to the Content Engine. |
Use the no form of the command to disable blocking, Websense or N2H2 permission requests (for example, no url-filter bad-sites-deny).
The Content Engine with ACNS 4.1 software can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML page named block.html. Make sure to copy all embedded graphics associated with the custom message HTML page to the same directory that contains the block.html file. To enable the customized blocking message, use the url-filter custom-message command and specify the directory name.
To disable the custom message, use the no url-filter custom-message command.
The url-filter custom-message command can be enabled and disabled without affecting the good-sites-allow and bad-sites-deny configuration.
|
Note Do not use local1 or local2 as directories for custom blocking messages. Create a separate directory under local1 or local2 for holding the custom message file. |
In the block.html file, objects (such as .gif, .jpeg, and so on) must be referenced within the custom message directory string /content/engine/blocking/url, as shown in the example below.
In the following example a block.html file displays a custom message This page is blocked by the Content Engine when the Content Engine intercepts a request to the blocked site.
|
Note Contact your administrator if you have any questions concerning access to the blocked site you requested. |
<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE>
<p>
<H1>
<CENTER><B><I><BLINK>
<FONT COLOR="#800000">P</FONT>
<FONT COLOR="#FF00FF">R</FONT>
<FONT COLOR="#00FFFF">A</FONT>
<FONT COLOR="#FFFF00">D</FONT>
<FONT COLOR="#800000">E</FONT>
<FONT COLOR="#FF00FF">E</FONT>
<FONT COLOR="#00FFFF">P</FONT>
<FONT COLOR="#FF8040">'</FONT>
<FONT COLOR="#FFFF00">S</FONT>
</BLINK>
<FONT COLOR ="#0080FF">Blocked Page</FONT>
</I></B></CENTER>
</H1>
<p>
<p>
<IMG src="/content/engine/blocking/url/my.gif">
<p>
This page is blocked by the Content Engine.
<p>
To disable the custom-message option without disabling URL filtering, enter the URL filtering command without the custom-message option (for example, url-filter good-sites-allow).
If a new block.html file is used it will automatically display its new message without having to renable the url-filter custom-message command.
N2H2 is a globally deployed URL-filtering software that can filter HTTP/HTTPS requests based on destination host name, destination IP address, and username and password. It relies on a sophisticated URL database exceeding 15 million sites and is organized into over 40 categories using both Internet technology and human review.
The Content Engine can perform URL filtering based on the N2H2 server. (See Figure 8-1.) The Content Engine and the N2H2 server use the Internet Filtering Protocol (IFP) Version 1 to communicate with each other. When the Content Engine receives a URL request, it sends an IFP request to the N2H2 server with the requested URL. The N2H2 server does some necessary lookups for the URL and sends back an IFP response. Based on the N2H2 server's IFP response, the Content Engine either blocks the HTTP request by redirecting the browser to a block page or proceeds with normal HTTP processing.
The filtering is applied to HTTP/HTTPS traffic before the Rules Template mechanism is applied, regardless of whether the requested object is in the cache or not. Filtering is applied to these traffic types:
N2H2 supports three filtering methods. Table 8-1 lists the N2H2 features supported by the Content Engine. One N2H2 server can support multiple Content Engines simultaneously.
| N2H2 Feature Name | Description |
|---|---|
Global filtering | Applies filtering to all HTTP/HTTPS requests. |
User-based filtering | Applies filtering to specific users or groups. |
Client IP-based filtering | Applies filtering to specific client IP addresses. |
The url-filter N2H2 server IP address [port 1-65535] [timeout 1-120] command configures the Content Engine to query the N2H2 server. The optional port field specifies the port on the N2H2 server to which the Content Engine should send IFP requests. The default port number is 4005. The optional timeout (in seconds) specifies how long the Content Engine should wait for an IFP response from the N2H2 server. The default timeout is 20 seconds.
This command does not verify whether or not an N2H2 server is accessible at the specified IP address in the current implementation. The configuration can be changed while N2H2 is enabled. The Content Engine will adopt the new configuration at run time.
The url-filter enable N2H2 command enables the N2H2 server as the current URL filtering scheme. The command will not succeed if the server IP address is not configured, or if another URL filter is already enabled with N2H2 or other filtering schemes.
The url-filter N2H2 allowmode enable command allows HTTP/HTTPS requests to pass when the N2H2 server is enabled but the Content Engine has problems communicating with the N2H2 server. With allowmode enabled, if the Content Engine fails to receive responses from the N2H2 server successfully, the Content Engine still allows all traffic through (it proceeds with normal HTTP/HTTPS processing). With allowmode disabled, on the other hand, the Content Engine blocks all HTTP/HTTPS traffic through the Content Engine. By default, allowmode is disabled.
The allowmode option can be configured with or without N2H2 enabled and is independent of the N2H2 server configuration. The Content Engine will adopt the new configuration for allowmode if N2H2 is already running.
The show url-filter command shows the URL-filtering scheme enabled on the Content Engine and the configurations for each URL filtering scheme, such as the configuration data for N2H2.
In this example, the show url-filter command is used to display the URL-filtering schemes presently configured on the Content Engine:
ContentEngine# show url-filter
URL filter is DISABLED
Local list configurations
==================================
Good-list file name :
Bad-list file name :
Custom message directory :
Websense server configuration
==================================
Websense server IP : <none>
Websense server port : 15868
Websense server timeout: 20 (in seconds)
Websense allow mode is ENABLED
N2H2 server configuration
==============================
N2H2 server IP : <none>
N2H2 server port : 4005
N2H2 server timeout : 20 (in seconds)
N2H2 allow mode is ENABLED
The show statistics url-filter N2H2 command shows the request-reply statistics of the communication between the Content Engine and the N2H2 server. These statistics show the number of requests sent, replies received, pages blocked, pages allowed, and failure cases. More detailed URL-filtering statistics are available on the N2H2 server.
whh-590# show statistics url-filter N2H2
N2H2 URL Filtering Statistics:
Lookup requests transmitted = 1021084
Lookup response received = 1021080
Requests BLOCKed by N2H2 = 0
Requests OKed by N2H2 = 1021080
Allow Mode Statistics:
No available connection = 1105
Error sending lookup requests = 4
Error recving lookup responses = 1
Server error in responses = 0
Server Error in Responses:
Error in Filter Server = 0
Error in IFP server = 0
The statistics shown can be cleared using the clear statistics url-filter N2H2, clear statistics urlfilter, and clear statistics all commands.
The clear stat url-filter N2H2 command resets the statistics counters for the N2H2 server. All the statistics counters are reset to 0.
A user can choose N2H2 as the URL-filtering scheme through the Content Engine GUI and configure N2H2 server parameters such as the IP address, port number, timeout, and allowmode option.
Only one URL-filtering scheme can be active at a time. In order to enable N2H2 URL filtering, you should first make sure that no other URL-filtering scheme is configured. You can then configure the server information for N2H2 using the url-filter N2H2 server IP address [port 1-65535] [timeout 1-120] command and enabling the N2H2 server.
The server IP address and port number configured in the Content Engine must match the IP address of the N2H2 server and the port that N2H2 server listens to for IFP requests. If the configuration on the Content Engine does not match the configurations on the N2H2 server, the Content Engine will time out all HTTP/HTTPS requests and either block or allow all HTTP traffic based on the allowmode option configuration.
The Content Engine can use a Websense enterprise server as a filtering engine and enforce the filtering policy configured on the Websense server. (See Figure 8-2.) Refer to the Websense documentation for further information on Websense filtering policies.
To enable Websense URL filtering on the Content Engine, specify the Websense server IP address or host name using the url-filter enable websense command. The timeout option sets the maximum amount of time that the Content Engine will wait for a Websense response. The timeout default is 20 seconds. The port option specifies the port number on which the server will accept requests from the Content Engine (the default port is 15868). Use the no url-filter websense server command to disable Websense URL filtering.
The url-filter websense allowmode enable command permits the Content Engine to fulfill the client request after a Websense server timeout.
The Websense server returns its own blocking message.
To use Websense URL filtering with a cluster of Content Engines, make sure to configure the url-filter websense server command on each Content Engine in the cluster to ensure that all traffic is filtered.
SmartFilter™ software for the Cisco Content Engine provides employee Internet management (EIM) functionality with proxy servers, firewalls, and caching appliances. The integrated Content Engine and SmartFilter product preserves all functionality available in a regular Content Engine. The SmartFilter filtering capability is available as an add-on service on the Content Engine, and the service may be enabled or disabled as desired through the Content Engine CLI or GUI.
The integrated Content Engine and SmartFilter product provides a one-box solution for server functionality. The Content Engine uses a suite of plug-in APIs to allow the SmartFilter software to implement hooks at strategic points during an HTTP transaction and thus provide URL filtering.
The integrated Content Engine and SmartFilter product provides an end user management tool called the sfadmin console. This GUI component downloads configurations into the Content Engine for use by the SmartFilter process.
To use SmartFilter URL filtering with a cluster of Content Engines, make sure to enter the url-filter smartfilter enable command on each Content Engine in the cluster to ensure that all traffic is filtered. Refer to the SmartFilter for Cisco Content Engine User's Guide for more information on how to configure the SmartFilter software in the ACNS 4.1 release.
Posted: Tue Nov 12 15:56:59 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.