Content and URL Filtering

Traditionally, the firewalls block data packets by inspecting the Layer 3 and/or Layer 4 information in the packets. Cisco ASA can enhance this functionality by inspecting the content information in many Layer 7 protocols such as HTTP, HTTPS, and FTP. Based on the security policy of an organization, the security appliance can either pass or drop the packets if they contain content not allowed in the network. Cisco ASA supports two types of application layer filtering:

• Content filtering
• URL filtering

Both are discussed in turn in the following sections.

Content Filtering

Enabling Java or ActiveX in the production environment can cause naive users to download malicious executables that can cause loss of files and corruption in the user environment. A security network professional can disable Java and ActiveX processing in the browser, but this is not a very scalable solution. The other option is to use a network device such as Cisco ASA to remove the malicious content from the packets. Using the local content-filtering feature, the security appliance can inspect the HTTP header and filter out ActiveX and Java applets when the packets try to traverse through from nontrusted hosts.

Cisco ASA can differentiate between friendly applets and untrusted applets. If a trusted website sends Java or ActiveX applets, the security appliance can forward them to the host requesting the connection. If the applets are sent from untrusted web servers, the security appliance can modify the content and remove the applets from the packets. This way, the end user is not making decisions regarding which applet to accept or refuse. They can download any applets without being extra cautious.

ActiveX Filtering

As mentioned in the preceding section, ActiveX can cause potential problems on the network devices if malicious ActiveX code is downloaded on the machines. The ActiveX code is inserted into the web page by using theand HTML tags. The security appliance searches for these tags for traffic that originated on a preconfigured port. If the security appliance finds these tags, it replaces them with the comment tags . When the browser receives the HTTP packets with , it ignores the actual content by assuming that the content is the author's comments.

Note

The security appliance cannot comment out the HTML tags if they are split across multiple network packets.

Java Filtering

Configuring Content Filtering

Local content filtering on the security appliance is set up by using the filter command followed by the content name to be removed. The following shows the complete command syntax:

filter activex | java port[-port] local_ip local_mask foreign_ip foreign_mask

Table 5-7 lists and describes the arguments used in the filter commands.

In Figure 5-6, the security administrator of an appliance in Chicago has set up a content-filtering policy to remove ActiveX objects from the HTTP packets (TCP port 80). The policy will be enforced if packets originate from the inside subnet 209.165.202.128/27 and destined for the external subnet 209.165.201.0/27. If traffic originates from or is destined for a different host, the security appliance will not filter ActiveX content.

Figure 5-6. ActiveX-Based Content Filtering

The relevant configuration is shown in Example 5-18.

Example 5-18. ActiveX Content Filtering

Chicago(config)# filter activex 80 209.165.202.128 255.255.255.224 209.165.201.0 255.255.255.224

In Example 5-19, the security appliance is set up to filter Java applets from the TCP packets received on TCP port 8080. The Java applets will be removed if packets originate from the inside subnet 209.165.202.128/27 and are destined for external subnet 209.165.201.0/27.

Example 5-19. Java Content Filtering

Chicago(config)# filter java 8080 209.165.202.128 255.255.255.224 209.165.201.0 255.255.255.224

URL Filtering

Traditionally, corporations monitor and control user Internet access by filtering questionable content. This prevents users from accessing sites that are deemed inappropriate based on the organization's security policies. Additionally, employees do not waste network resources by sending traffic to the blocked Internet sites, which results in lower bandwidth usage and increased employee productivity. Cisco ASA can delegate packet-filtering responsibilities to an external server, such as N2H2 or Websense. The URL-filtering process follows this sequence of events, shown in Figure 5-7:

1. A web client (Host A) opens a browser application for Server 1.
2. The security appliance forwards to the filtering server the URLs that the inside hosts try to reach. At the same time, the security appliance also forwards the original request to the external content server (Server 1).
3. The filtering server analyses the URLs and sends a permit or deny message back to the security appliance.
4. The web server sends a reply destined for Host A.
5. If the filtering server allows the connection, the security appliance forwards the response packet from the content server to the client. If the filtering server denies the connection, the security appliance drops the response packet from the content server and sends a message indicating a failed connection.

Figure 5-7. URL Filtering

Note

The inside users may experience longer access times if the response from the filtering server is slow or delayed.

Cisco ASA supports two external filtering servers:

• Websense An external server that can filter HTTP, HTTPS, and FTP requests from the client machines based on many attributes, including destination host name, destination IP address, and username. The Websense Enterprise server can organize a list of Internet URLs into different categories and subcategorizes, including MP3, gambling, shopping, and adult content, for the ease of management. For more information about Websense and its features, visit http://www.websense.com.
• N2H2 Another external server that allows the security appliance to filter HTTP requests from the web clients when they try to access the web servers on the less-trusted network. With a huge database containing URLs organized into different categories, the N2H2 server ensures that users do not access restricted websites. For more information about N2H2, visit http://www.n2h2.com.

Note

N2H2 has been acquired by Secure Computing Corp. The product name has been renamed to Sentian.

Configuring URL Filtering

You can configure URL filtering as follows:

These steps are described in more detail in the sections that follow.

Step 1: Defining a Filtering Server

An external filtering server is defined by using the url-server command. The complete command syntax to specify a Websense server is

url-server [<(if_name)>] [vendor websense] host <local_ip> [timeout <seconds>] [protocol TCP | UDP] [connections num_conns] [version 1 | 4]

To define an N2H2 server, the command syntax is

url-server [<(if_name)>] vendor n2h2 host <local_ip> [port <number>] [timeout <seconds>] [protocol TCP | UDP] [connections num_conns]]

Table 5-8 lists and describes the arguments used in the url-server command.

The url-server command does not verify whether a Websense or N2H2 server is reachable from the security appliance. You can specify up to 16 filtering servers for redundancy. If the security appliance is not able to reach the first server in the list, it tries the second server from the list, and so on. Additionally, Cisco ASA does not allow setting up both N2H2 and Websense servers at the same time. You must delete the Websense server before you can use an N2H2 server, and vice versa.

In Example 5-20, the administrator has defined a Websense server located on the inside interface. The IP address of the server is 209.165.202.132 using TCP protocol version 4 with the timeout value of 30 seconds.

Example 5-20. URL Filtering Using Websense

Chicago(config)# url-server (inside) vendor websense host 209.165.202.132 timeout 30 protocol TCP version 4

Note

The security appliance does not allow multiple N2H2 URL servers to use different port numbers.

Step 2: Configuring HTTP, HTTPS, and FTP Filtering

After identifying the URL server, the security appliance can forward the HTTP, HTTPS, and FTP requests to the appropriate filtering servers. In the current implementation, Cisco ASA supports HTTP, HTTPS, and FTP packet filtering on the Websense server and HTTP filtering on the N2H2 server. If the filtering server allows the connection, the security appliance forwards the response from the web and/or FTP server to the client host. If the filtering server denies the connection, the security appliance server drops the response and takes one of the following actions:

• Redirects the HTTP or HTTPS connection to a blocked page. The URL of the blocked page is returned by the filtering server.
• Returns "code 550: Directory not found" error message to the FTP client.

The command syntax to enable HTTP filtering is

filter url port[-port] local_IP local_mask foreign_IP foreign_mask [allow] [proxy- block] [longurl-truncate] [longurl-deny] [cgi-truncate]

The command syntax to enable HTTPS filtering is

filter https port[-port] local_IP local_mask foreign_IP foreign_mask [allow]

The command syntax to enable FTP filtering is

filter ftp port[-port] local_IP local_mask foreign_IP foreign_mask [allow] [interact-block]

Table 5-9 lists and describes the arguments used in the filter command for URL filtering.

In case a URL-filtering server is not available, the security appliance drops the response from the content (web or FTP) server. You can change this default behavior by specifying the allow keyword at the end of the filter command.

In Example 5-21, the Cisco ASA in Chicago is set up to filter HTTP, HTTPS, and FTP packets if the connections originate from 209.165.202.128/27 and are destined for any outside network (represented as 0.0.0.0 0.0.0.0). If the URL server is not available, the inside hosts are allowed to connect to the content servers. For the HTTP packets, the security appliance truncates CGI scripts and the long URLs. For the FTP connections, the security appliance restricts users to change directories without specifying the complete directory path.

Example 5-21. Filtering of HTTP, HTTPS, and FTP Packet Content

Chicago(config)# filter url 80 209.165.202.128 255.255.255.224 0.0.0.0 0.0.0.0 allow longurl-truncate cgi-truncate Chicago(config)# filter https 443 209.165.202.128 255.255.255.224 0.0.0.0 0.0.0.0 allow Chicago(config)# filter ftp 21 209.165.202.128 255.255.255.224 0.0.0.0 0.0.0.0 allow interact-block

Step 3: Buffering Server Responses (Optional)

Using the URL-filtering feature, the security appliance sends the client request to the outside content server and simultaneously makes a URL lookup request to the filtering server. If the content server's reply arrives prior to the URL-filtering server's response, the security appliance drops the packet. This default behavior can be changed by buffering the response packets from the content server until a reply is received from the filtering server. The command to enable packet buffering is url-block block followed by the number of blocks to be buffered. In Example 5-22, the security appliance is set up to buffer up to 128 blocks in the HTTP response.

Example 5-22. Buffering of Server Responses

Chicago(config)# url-block block 128

Step 4: Enabling Long URL Support (Optional)

The security appliance identifies a URL greater than 1159 bytes as a long URL. You can change this behavior if a Websense server is deployed for filtering purposes by using the url-block url-size command followed by the size of the maximum long URL in kilobytes. In Example 5-23, the security appliance is set up to change the HTTP long URL size from 2 KB to 4 KB.

Example 5-23. Configuration to Enable Long URL Support

Chicago(config)# url-block url-size 4

When the security appliance receives a URL longer than 1024 bytes, it breaks the URL into multiple IP packets and copies the TCP payload, the content of the URL, into the buffer memory chunk. Each memory chunk is 1024 bytes, and the security appliance allocates another memory chunk for a URL longer than 1024 bytes for optimized memory management. Example 5-24 shows how to increase the allocated memory available for long URL support and packet buffering to 100 KB.

Example 5-24. Configuration to Increase the Memory for Long URL Support

Chicago(config)# url-block url-mempool 100

Step 5: Caching Server Responses (Optional)

The security appliance can cache the responses from the filtering servers for a certain period of time based on the destination and/or the source IP addresses. This way, when a user tries to access the same URL again, the security appliance does not forward the request to the filtering server but consults its local cache before allowing or denying the packets. Use the url-cache command to enable caching of server responses followed by the addressing policy. For destination addressbased caching, use dst as the keyword in the url-cache command. If you prefer caching URL responses based on the source and destination addresses of a connection, use src_dst with the url-cache command. In Example 5-25, the security appliance allocates 128 KB of memory for destination-based URL caching.

Example 5-25. URL Caching

Chicago(config)# url-cache dst 128