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

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 the <OBJECT ID> and </OBJECT> 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

For Java-based content filtering, the security appliance looks for <applet and </applet> tags in the HTML data packets. Without Java filtering, the client browser tries to execute the code specified in <applet which begins with a 4-byte header, ca fe ba be. Therefore, to block Java applets, the security appliance searches for the <applet and </applet> tags and replaces them with the comment tags, . Additionally, it blocks the applets if it sees the ca fe ba be string embedded in the packet.

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:

Table 5-7. Syntax Description for filter java and filter activex Commands
Syntax	Description
filter	Keyword used to enable content filtering.
activex	Keyword to enable ActiveX filtering.
java	Keyword to enable Java filtering.
port[-port]	TCP port number(s) for the security appliance to inspect HTTP packets. This can be either a single port or a range of ports. Typically, it is TCP port 80.
local_ip	Host IP or subnet address of the inside hosts where the connection originated.
local_mask	Subnet mask of the local host IP or subnet address.
foreign_ip	Host IP or subnet address of the outside servers to which the connection is made.
foreign_mask	Subnet mask of the outside host IP or subnet address.

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.

Example 5-18. ActiveX Content Filtering

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

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:

A web client (Host A) opens a browser application for Server 1.
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).
The filtering server analyses the URLs and sends a permit or deny message back to the security appliance.
The web server sends a reply destined for Host A.
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.

Note

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

Note

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

Configuring URL Filtering

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

Table 5-8. url-server Command Syntax and Description
Syntax	Description
url-server	Keyword used to enable URL filtering.
if_name	Specifies the interface toward the URL filtering server.
vendor	Keyword used to identify the vendors.
websense	Keyword to specify Websense as the URL-filtering server.
host	Keyword used to specify a host address for the filtering server.
local_ip	Specifies the IP address of the filtering server.
timeout	Keyword to specify the maximum idle timeout before the security appliance switches over to the next URL-filtering server.
seconds	The actual idle timeout in seconds. The default is 5 seconds.
protocol	Keyword to specify the protocol to be used for communication. The default is TCP.
TCP	Keyword to specify the TCP protocol to be used.
UDP	Keyword to specify the UDP protocol to be used.
version	Keyword to specify the version of protocol to be used when Websense server is set up as the filtering server.
1	Specifies version 1 for TCP protocol communication. This is the default.
4	Specifies version 4 for TCP or UDP protocol communication.
N2H2	Keyword to specify N2H2 as the URL-filtering server.
port	Keyword to specify the port number for the security appliance to communicate with the N2H2 server.
number	The actual port number. The default is port 4005.
connections	Keyword to limit the maximum number of connections permitted to a URL-filtering server.
num_cons	Specifies the maximum number of connections permitted.

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

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:

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

Table 5-9. filter Command Syntax and Description
Syntax	Description
filter	Keyword used to enable content filtering.
url	Keyword to enable HTTP filtering.
port[-port]	TCP port number(s) for URL filtering. The security appliance inspects packets on this port(s). This can be either a single port or a range of ports.
local_ip	IP/subnet address of the inside hosts where the connection originated.
local_mask	Subnet mask of the local IP/subnet address.
foreign_ip	IP/subnet address of the outside servers to which the connection is made.
foreign_mask	Subnet mask of the outside IP/subnet address.
allow	Allows the response from the content server if the filtering server is not available.
proxy-block	Denies requests going to the proxy server.
longurl-truncate	Truncates URLs that are longer than the maximum allowed length before sending the request to the filtering server.
longurl-deny	Denies outbound connection if the URLs are longer than the maximum allowed length.
cgi-truncate	Truncates long CGI URLs before sending the request to the filtering server, to save memory resources and improve firewall performance.
https	Keyword to enable HTTPS filtering.
ftp	Keyword to enable FTP filtering.
interact-block	Denies interactive FTP sessions that do not provide the entire directory path.

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

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

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

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

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 address�based 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.