Chapter 7: Web Content

Overview

In Chapter 6, I talked about some of the advanced filtering abilities of the appliances, including ACLs. One limitation of ACLs is that they can only filter on the network and transport layers of the OSI Reference Model—they cannot filter on content information (information found in the payload). For instance, one type of attack that hackers like to use is to create malicious Java or ActiveX applets that users will download and run. This traffic is downloaded using HTTP port 80. The problem with ACLs is that an ACL can either permit or deny port TCP 80 traffic, which includes the applets embedded within the connection—ACLs cannot filter just the applets themselves.

Likewise, ACLs have issues when dealing with the filtering of web content. Imagine that you have a security policy that prohibits the downloading of pornographic material. Because web information changes all the time, you would have to continually find these sites and add them to your ACL configuration, which is an unmanageable process.

On top of the security problems, an issue with downloading web content is that the process can be bandwidth-intensive, especially if multiple users are going to the same sites and downloading the same content.

The appliances have three solutions to these problems. The first solution is the ability of the appliances to filter on Java and ActiveX scripts that are embedded in HTTP connections. The second solution for filtering content allows the appliances to work with third-party content filtering software to filter HTTP and FTP traffic. The third solution is the included support for the Web Cache Communications Protocol (WCCP), which allows the appliances to redirect web requests to an external web cache server to download the content.

The topics included in this chapter are as follows:

• Java and ActiveX filtering

• Web content filtering

• Web caching

Web Content Filtering

One major concern of many companies connected to the Internet is the type of information that their employees are downloading to their desktops. Quite a few studies have been done, and, on average, 30–40 percent of a company’s Internet traffic is nonbusiness in nature (I’m actually surprised that the statistic isn’t higher). In some instances, the information that employees download can be offensive to other employees. This information can range from pornography to political and religious content. A lot of the downloaded content like stock quotes and audio and video streaming is inoffensive, but can use up expensive bandwidth.

The appliances have limited and nonscalable abilities when filtering web content (I discuss this in Chapter 12). A much more scalable solution is to have the appliances work with third-party products to provide comprehensive web filtering features. The following sections cover how the appliances and web filtering products interact, the third-party web filtering products that the appliances support, and web filtering configuration on the appliances.

Web Filtering Process

To implement web content filtering, sometimes referred to as web filtering, two components are involved:

• Policies must be defined that specify what is or isn’t allowed by users.

• The policies must be enforced.

Two methods that perform these processes are commonly deployed in networks:

• Application proxy

• Modified proxy

The following two sections will discuss these approaches.

Application Proxy

With an application proxy, both components—definition and enforcement of policies—are performed on one server. Either users’ web browsers are configured to point to the proxy, or their traffic is redirected to the proxy.

With an application proxy, the following steps occur when a user wants to download web content:

1. The user opens a web page.

2. All connections are redirected to the application proxy server, which might require the user to authenticate before external access is allowed.

3. The application proxy examines the connection(s) attempt and compares it with the list of configured policies.

4. If the connection is not allowed, the user is typically shown a web page about the policy violation.

5. If the connection is allowed, the proxy opens the necessary connections to download the content. The content is then passed back across the user’s original connections and is displayed in the user’s web browser.

Application proxies work quite well in small environments that have a small number of simultaneous web requests. Remember that downloading each element on a web page, like graphics, applets, and so on, requires a separate connection for each element. Therefore, the more pages that multiple users request, the less throughput occurs through the proxy—it must handle twice the number of connections: from the user to the proxy, and from the proxy to the external web servers. This process can quickly become a bottleneck on the proxy, being CPU- and memory-intensive. And if the proxy is caching information, the process can become disk-intensive.

Modified Proxy

A modified proxy splits out the two policy components: an external server has the list of policies, and a network device implements the policies as web traffic flows through it. The appliances support the modified proxy approach: to filter web content, the appliances must interoperate with an external web content server.

Figure 7-1 shows the actual interaction between the users, the appliance, the policy server, and the external web server. In this example, a user sends an HTML request to an external web server (step 1). The appliance then does two things in step 2:

• Forwards the HTML request (the URL information only) to the web content policy server

• Forwards the HTML request to the actual web server

Figure 7-1: Outgoing and returning web traffic

In step 3, the web content policy server compares the URL request with its internal policies and sends back the action to the appliance. The appliance then enforces the action on the returning traffic (step 4). If the web content policy server says to deny the traffic, the appliance drops the returning web traffic. If, however, the web content policy server says to permit the traffic, the appliance forwards the traffic to the internal user (step 5).

As you can see from this explanation, the appliance doesn’t actually filter the outbound connection. This process basically allows enough time for the web content policy server to send back an action to the appliance before the external web server replies to the user, thereby introducing little if any delay in the user’s traffic stream. Unlike with an application proxy, the appliances are not proxying the connections: they’re allowing them outbound and enforcing the policies on the returning traffic. This is much more CPU- and memory-friendly than using a true application proxy. However, if the web content policy server is handling thousands of requests, your users may experience delay in their traffic stream. Cisco does support a limited form of load balancing to split policy lookups across multiple web content policy servers.

Tip

Because the policies are defined externally to the appliance, I recommend that the web content policy server be located close to the appliance. For two reasons, I commonly place the policy server either in a public, or more commonly, a semiprivate, DMZ that is directly connected to the appliance. First, it minimizes delay in getting a policy response from the server, which means the appliance shouldn’t have to buffer connection replies from external web servers. Second, companies commonly purchase a subscription with the web content policy server so that they can get weekly updates about new sites and their classification, like an updated list of pornographic sites, so that administrators don’t have to manually update or define these classifications themselves.

URL Filtering Server

Web content filtering on the appliances allows you to filter web information for users accessing web resources on the outside of your network. Cisco supports two web content policy/filtering products: Websense and Secure Computing’s SmartFilter (formerly N2H2’s Sentian product). The products have the capability of interacting with an external device, like the appliances, in a modified proxy role, or can function as application proxies. These products support policies for HTTP, HTTPS, and FTP URLs.

You must configure two things on the appliance to interact with the web content filtering server:

• Identify the web content filtering server.

• Specify the traffic to be filtered.

You can complete other configuration tasks optionally. The following sections cover the web content filtering commands of the appliances.

Server Identification

The first thing that you need to configure is the identity of the web content filtering server that the appliance will use. This is accomplished with the url-server command. Your product type will determine the parameters available.

Here is the syntax to configure the appliance interaction with a Websense server:

ciscoasa(config)# url-server [logical_if_name] [vendor websense]
                       host server_IP_address [timeout seconds]
                       [protocol {tcp | udp}] [connections #_of_conns]
                       [version {1 | 4}]

If you omit the name of the interface, it defaults to inside. If you omit the vendor parameter, it defaults to Websense. The timeout value defaults to 5 seconds—if the appliance doesn’t get a reply within 5 seconds from the Websense server, it will contact a second Websense server, if you have configured one. You might want to increase this timeout period if the Websense server is located at a remote site from the appliance. The default protocol is TCP, but can be configured for UDP if you are running version 4 of Websense. The default version is 1. The connections parameter allows you to limit the number of lookups to a server, so that you can split lookups across multiple servers.

If you are connecting to a SmartFilter server, the syntax is as follows:

ciscoasa(config)# url-server [interface_name] vendor smartfilter
                      host server_IP_address [port port_number]
                      [timeout seconds] [protocol {tcp | udp}]
                      [connections #_of_conns]

The configuration of SmartFilter is very similar to that of Websense. One difference is that you can specify a port number for the TCP or UDP connection. The default port number is 4005.

Note

You can configure multiple policy servers by executing the url-server command multiple times (up to 16 servers). However, you can only use Websense or SmartFilter—you cannot use both of these on the same appliance.

Traffic Filtering Policies

Once you have identified the web content policy server or servers that your appliance will use, you must now identify which content traffic (URLs) the appliance will forward to the policy servers. The command to identify the traffic to be filtered is the filter command. The command has three variations, depending on the protocol you want to process:

• Clear-text URLs

• FTP URLs

• HTTPS URLs

URL Filtering Verification

Once you have set up your web content filtering configuration, you can use various show commands to verify your configuration. To view the web content filtering servers that you have configured with the url-server command, use the show run url-server command:

ciscoasa# show run url-server
url-server (outside) vendor smartfilter host 10.1.1.5 port 4005
     timeout 5 protocol TCP connections 1500
url-server (outside) vendor smartfilter host 10.1.2.5 port 4005
     timeout 5 protocol TCP

In this example, two SmartFilter filtering servers have been configured on this appliance.

You can see server connection statistics with the following command:

ciscoasa(config)# show url-server stats
Global Statistics:
------------------
URLs total/allowed/denied 993487/156548/837839
URLs allowed by cache/server 70843/85165
URLs denied by cache/server 801920/36819
HTTPSs total/allowed/denied 994387/156548/837839
HTTPs allowed by cache/server 70843/81565
HTTPs denied by cache/server 801920/36819
FTPs total/allowed/denied 994387/155648/838739
FTPs allowed by cache/server 70483/85165
FTPs denied by cache/server 801920/36819
Requests dropped 28715
Server timeouts/retries 567/1350
Processed rate average 60s/300s 1524/1344 requests/second
Denied rate average 60s/300s 35648/33022 requests/second
Dropped rate average 60s/300s 156/189 requests/second
URL Server Statistics:
----------------------
192.168.2.1 UP
Vendor websense
Port 17035
Requests total/allowed/denied 365412/254595/110547
Server timeouts/retries 567/1350
Responses received 365952
Response time average 60s/300s 2/1 seconds/request
192.168.2.2 DOWN
Vendor websense
Port 17035
Requests total/allowed/denied 0/0/0
Server timeouts/retries 0/0
Responses received 0
Response time average 60s/300s 0/0 seconds/request
<--output omitted-->

This example has two Websense servers, where the second is currently down. For the first server, you can see that 365,412 requests were sent to the server, of which 254,595 policy-allow and 110,547 policy-deny actions were received.

If you have enabled caching of URL information on your appliance that it received from the content filtering server, you can view the caching statistics with the show url-cache stats command:

ciscoasa(config)# show url-cache stats
URL Filter Cache Stats
----------------------
   Size :         1KB
Entries :          36
 In Use :          22
Lookups :         241
   Hits :         207

In this example, the cache size has been set to 1KB. The Entries item specifies the total number of cached entries that can fit in the cache based on the configured size. In this example, only 36 entries can be cached. The In Use item specifies the number of entries that are currently cached (22). The Lookups entry specifies the number of times the appliance has looked in the cache for a match, and the Hits entry shows the number of times the appliance found a match in the cache.

To view statistics about URL information received from external web servers that is being temporarily buffered by the appliance, use this command:

ciscoasa(config)# show url-block block stat
URL Pending Packet Buffer Stats with max block   1
-----------------------------------------------------
Cumulative number of packets held:         53
Maximum number of packets held (per URL):   1
Current number of packets held (global):     0
Packets dropped due to exceeding url-block buffer limit: 78
Packets dropped due to
| exceeding url-block buffer limit: | 78
| HTTP server retransmission: | 0
Number of packets released back to client: | 0

As you can see in this example, 53 packets were held up because the appliance was waiting for a response from the web content filtering server. You will want to keep tabs on the number of packets being dropped because they exceeded the buffer limit—if this is continually increasing, you will want to increase the block size for buffering. To clear the statistics, use the clear url-block block command.

The show perfmon command shows you performance information for many important components of the appliance, including web content filtering performance. Here is an example:

ciscoasa(config)# show perfmon
PERFMON STATS:    Current      Average
Xlates               0/s          0/s
Connections          0/s          2/s
TCP Conns            0/s          2/s
UDP Conns            0/s          0/s
URL Access           0/s          2/s
URL Server Req       0/s          2/s
<--output omitted-->

With this command, you should focus on the URL Server Req entry, which displays the number of lookups the appliance forwarded to the web content policy server.

URL Filtering Example

To help illustrate the configuration example, I’ll use the network shown in Figure 7-2. This example uses Websense for a web content filtering solution.

Figure 7-2: Network using Websense

Listing 7-1 focuses only on the filtering commands for this setup.

Listing 7-1: Example of a Websense setup

ciscoasa(config)# url-server (inside) vendor websense
                            host 192.168.1.2 protocol tcp version 4
ciscoasa(config)# filter url 80 0 0 0 0
ciscoasa(config)# filter url 8080-8099 0 0 0 0
ciscoasa(config)# url-cache dst 128

In this example, the url-server command specifies that the server is a Websense server and that the connection is using TCP. Any web traffic on port 80 or port 8080 through 8099 will be examined for filtering. The appliance can cache information returned by the Websense server using 128KB of memory. As you can see from this example, the setup of web filtering on the appliances is easy.