Previous Section  < Day Day Up >  Next Section

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:

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 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 <!-- and -->. When the browser receives the HTTP packets with <!-- and -->, 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, <!-- and -->. 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:

  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.

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.

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:

Step 1.
Define a filtering server.

Step 2.
Configure HTTP, HTTPS, and FTP filtering.

Step 3.
Buffer server responses (optional).

Step 4.
Enable long URL support (optional).

Step 5.
Cache server responses (optional).

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.

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
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.

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
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 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.

Example 5-25. URL Caching
Chicago(config)# url-cache dst 128

    Previous Section  < Day Day Up >  Next Section