|< Day Day Up >|
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.
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.
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.
The security appliance cannot comment out the HTML tags if they are split across multiple network packets.
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.
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 184.108.40.206/27 and destined for the external subnet 220.127.116.11/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 18.104.22.168 255.255.255.224 22.214.171.124 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 126.96.36.199/27 and are destined for external subnet 188.8.131.52/27.
Example 5-19. Java Content Filtering
Chicago(config)# filter java 8080 184.108.40.206 255.255.255.224 220.127.116.11 255.255.255.224
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:
Figure 5-7. URL Filtering
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:
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 18.104.22.168 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 22.214.171.124 timeout 30 protocol TCP version 4
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:
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 126.96.36.199/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 188.8.131.52 255.255.255.224 0.0.0.0 0.0.0.0 allow longurl-truncate cgi-truncate Chicago(config)# filter https 443 184.108.40.206 255.255.255.224 0.0.0.0 0.0.0.0 allow Chicago(config)# filter ftp 21 220.127.116.11 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
|< Day Day Up >|