6-4. Filtering Content A firewall normally allows outbound HTTP or HTTPS connections to any URL, provided that the outbound access list permits the connection. An audit trail of URL activity is available only through the firewall Syslog records, using Syslog message 304001 at the default severity level, 5 (notifications). Cisco firewalls can use third-party web content-filtering applications to enforce URL policies. These content filters run on a local server but download periodic updates of web content databases. Web content is categorized, and content rules can be applied to corporate users or groups of users. When a user sends a URL request, the firewall relays the request to the content-filtering server. If the server determines that the user is allowed to view the URL and its content, the firewall permits the connection to proceed. If the content-filtering server denies the URL request, the firewall redirects the user's browser to a "block" page, indicating that the server blocked or denied the request. The content-filtering server can apply its policies on a per-user basis if necessary. It obtains the user's credentials (username, IP address, destination URL, and address) directly from the user's host PC. This also provides an accounting log of user activity. The following commercial content-filtering applications are compatible with Cisco firewalls: Configuring Content Filters You can use the following steps to configure content filtering on a Cisco firewall. The command syntax is basically the same across the FWSM, PIX 6.x, and PIX 7.x platforms, so only a single syntax form is shown for each command. TIP Content filtering is triggered by the HTTP inspection engine, which must be enabled before any content servers can be contacted. If you are about to configure content filtering, make sure you have the fixup protocol http (FWSM 2.x or PIX 6.x) or inspect http (PIX 7.x) command in the running configuration. Likewise, if this command is disabled, Websense and N2H2 content filtering is disabled too.
1. | Identify the filter servers:
Firewall(config)# url-server [(if_name)] vendor n2h2 host local_ip [port number] [timeout seconds] [protocol {tcp | udp}]
or
Firewall(config)# url-server [(if_name)] vendor websense host local_ip [timeout seconds] [protocol {tcp | udp} version]
The filtering server is located on the firewall interface named (if_name) (the parentheses must be included) at the IP address local_ip. By default, the inside interface is assumed. For security best practice, the server should not be located on the outside or a public interface.
By default, N2H2 uses TCP/UDP port 4005 to filter information exchanges. You can specify a nondefault port number with the port keyword.
You can repeat this command to define up to 16 servers using the same filtering software. The firewall waits until a timeout period of seconds expires (the default is 5 seconds) if a filtering server doesn't respond. In that case, the same request is sent to the next server configured.
TCP connections are used by default for both N2H2 and Websense servers. You can use either tcp or udp, depending on your requirements. Websense also allows a software version to be specified: 1 (using TCP or UDP) or 4 (using UDP only).
Beginning with PIX 7.0, you can add connections num_conns after the tcp keyword. This limits the number of simultaneous TCP connections the firewall can open to the content filter server to num_conns (1 to 100; the default is 5).
| 2. | Define a filtering policy:
Firewall(config)# filter url [http | port[-port]] local_ip local_mask foreign_ip foreign_mask [allow] [proxy-block] [longurl-truncate | longurl-deny] [cgi-truncate]
You can define one or more broad filtering policies with this command and then make specific exceptions in the next step. Web traffic is defined as http (port 80), port (a single port number), or port-port, a range of ports.
You can provide the local (source) and foreign (destination) IP addresses and subnet masks. When web clients using local addresses send HTTP requests to web servers with foreign addresses, those requests are subject to filtering. In most cases, you can define the policy to use any local address and any foreign address. To do this, specify the local and foreign values as 0s (0 0 0 0).
For example, you could use the following command to filter the content of HTTP connections from inside hosts on the 192.168.100.0/24 subnet destined for any outside address. Here, the "any" destination address is given as 0 0:
Firewall(config)# filter url http 192.168.100.0 255.255.255.0 0 0
By default, if none of the filtering servers is available, the HTTP requests are dropped. This assumes that the filtering policies must be strictly enforced, requiring filtering servers to make decisions at all times. If this is too restrictive for your environment, you can add the allow keyword so that HTTP requests are allowed by the firewall if no filtering servers respond.
To prevent web clients from using an HTTP proxy server to relay HTTP requests, add the proxy-block keyword.
You can also define how the firewall reacts when very long URLs (longer than the URL buffer defined in Step 7) are used in HTTP requests. The longurl-truncate keyword sends only the source address or host name to the filtering server. The longurl-deny keyword causes the firewall to reject the HTTP request directly, without consulting the filtering server. In the case of CGI scripts, the cgi-truncate keyword causes CGI scripts to be sent to the filtering server as regular URLs. In other words, the CGI portion of the original URL is removed from the filtering server's decision process.
| 3. | (Websense only) Define a filtering policy for HTTPS:
Firewall(config)# filter https dest-port local_ip local_mask foreign_ip foreign_mask [allow]
You can also allow HTTPS traffic to be filtered by a Websense server. Identify the HTTPS port as dest-port (usually port 443). Connections that are subject to filtering have clients using local (source) addresses defined by local_ip and local_mask and web servers using foreign (destination) addresses defined by foreign_ip and foreign_mask.
Add the allow keyword if you want the firewall to go ahead and allow connections when all the Websense servers are unresponsive. Otherwise, HTTPS connections are dropped if they are not explicitly allowed by a filtering server.
| 4. | (Websense only) Define a filtering policy for FTP:
Firewall(config)# filter ftp dest-port local_ip local_mask foreign_ip foreign_mask [allow] [interact-block]
If you have a Websense server, you can filter FTP connections based on GET commands. The FTP port is given as dest-port (usually port 21).
Add the allow keyword if you want the firewall to allow FTP connections when all the Websense servers are unresponsive.
The interact-block keyword causes connections coming from interactive FTP clients to be rejected. In an interactive FTP client, a user can initiate the connection and then change directories at will. When files are requested from the FTP server, the full path name is not sent in the request. The filenames are relative to the current directory path, so the filtering server can't correctly determine if the user is requesting something that should be denied.
For example, you could use the following command to require Websense approval for all FTP GET commands initiated through the firewall. Interactive FTP clients are blocked:
Firewall(config)# filter ftp 21 0 0 0 0 allow interact-block
| 5. | Make exceptions to the filtering policy:
Firewall(config)# filter {url | https | ftp} except local_ip local_mask foreign_ip foreign_mask
You might have some web clients, users, or automated processes that need to send different types of requests without a filtering server's inspection or intervention. You can define exceptions to the overall filtering policy by giving the protocol (url, https, or ftp), as well as the local (source) and foreign (destination) addresses and subnet masks.
Clients using a matching local address are allowed to complete a transaction with a server using a matching foreign address. You can use 0 to indicate an "any" or wildcard-matching condition for any of the address and mask values.
For example, inside host 10.10.1.100 and hosts on the entire 10.10.2.0/24 subnet should be exempt from HTTP (URL) filtering. Inside host 10.10.3.14 also should be exempt from FTP filtering. You could use the following commands to accomplish this:
Firewall(config)# filter url except 10.10.1.100 255.255.255.255 0 0 Firewall(config)# filter url except 10.10.2.0 255.255.255.0 0 0 Firewall(config)# filter ftp except 10.10.3.14 255.255.255.255 0 0
| 6. | (Optional) Use an HTTP response buffer to return web content faster:
Firewall(config)# url-block block block_buffer_limit
When a web client requests web content from a foreign site, the firewall relays the request toward the website and sends a request to the filtering serverall in parallel. By default, if the web server responds before the filtering server, the content is dropped at the firewall. If the filtering server responds first with its permission data, the web content is allowed through when it arrives.
You can use an HTTP response buffer in the firewall to store web content until the filtering server has time to respond. As soon as the server approves the URL for the web client, the buffered contents are read and relayed to the client.
The HTTP response buffer can be enabled to store up to block_buffer_limit (0 to 128) 1550-byte blocks in memory.
| 7. | (Optional; Websense only) Adjust the maximum acceptable URL length.
Buffer URLs before sending Websense requests: Firewall(config)# url-block url-mempool memory_pool_size
By default, a firewall accepts URLs that are up to 1159 bytes long before sending a request to either Websense or N2H2. You can adjust the URL buffer so that several large URLs can be gathered and sent to a Websense server. The URL buffer limit can be set to memory_pool_size (2 to 10240 kilobytes). Set the maximum acceptable URL length: Firewall(config)# url-block url-size long_url_size
To allow URLs longer than 1159 bytes to be sent to a Websense server, set the URL length to long_url_size (2, 3, or 4 kilobytes). You need to adjust this limit only if you have cases in which very long URLs (greater than 1159 bytes) are being rejected.
| 8. | (Optional) Use a cache to store filtering permissions:
Firewall(config)# url-cache {dst | src_dst} kbytes
As a firewall sends requests to a filtering server, it can also cache the results that are returned. For subsequent requests for the same web client and target website, the firewall can quickly retrieve the cached permissions rather than waiting for the filtering server to respond again.
By default, the URL cache is disabled. The firewall sends each request to the filtering server and waits for each response before passing the return web content.
You can use the dst keyword to cache permission results based on the URL destination address only. If every web client behind the firewall shares the same policy on the filtering server, there is no need to cache the source information too. If web clients have different policies on the filtering server, you should use the src_dst keyword to gather source and destination information in the cache.
You can also set the size of the URL cache to kbytes (1 to 128 kilobytes).
TIP During normal requests to the filtering server, the server keeps a record of user activity in its accounting logs. When a URL cache is used (except with Websense version 1), these logs can still be collected, because the firewall still sends each request to the server, even though it might have a matching entry in its cache. The filtering requests and cache lookups happen in parallel so that a cache hit produces a quick permission result. In this case, any reply from the server is simply dropped. If an entry is not in the cache, no time is wasted, because the filtering server will have already sent a reply. You can monitor the status of the URL cache with the show url-cache statistics command. If the cache is performing efficiently, you should see a large percentage of hits in relation to the number of lookups. For example, the following output shows that 432 URL lookups occurred; 396 of those resulted in a cache hit, where the result was already in the cache. This represents a high hit percentage, indicating that the cache is doing its job. Firewall# show url-cache statistics URL Filter Cache Stats ---------------------- Size : 128KB Entries : 219 In Use : 105 Lookups : 432 Hits : 396 Firewall#
| 9. | (Optional; PIX only) Filter ActiveX content:
Firewall(config)# filter activex port[-port] local_ip local_mask foreign_ip foreign_mask
ActiveX objects that are found on connections using destination port number port (or a range of ports port-port) are subject to being blocked by the firewall. The connections must be initiated by clients using matching local (source) addresses toward servers using matching foreign (destination) addresses. You can substitute 0s as a wildcard "any" for any address or mask field.
The firewall blocks ActiveX objects by looking for the HTML <object> and </object> tags. The tags are commented out before the content is forwarded to the client. The client can't interpret the result as a valid ActiveX object. Nested objects are also blocked, because the first-level objects are commented out.
| 10. | (Optional; PIX only) Filter Java content:
Firewall(config)# filter java {port[-port] | except} local_ip mask foreign_ip mask
Java applets that are found on connections using destination port number port (or a range of ports port-port) are subject to being blocked by the firewall. The connections must be initiated by clients using matching local (source) addresses toward servers using matching foreign (destination) addresses. You can substitute 0s as a wildcard "any" for any address or mask field.
The firewall blocks Java objects by looking for the HTML <applet> and </applet> tags. The tags are commented out before the content is forwarded to the client.
You can also use the except keyword to define address pairs where Java filtering should not be performed.
|
TIP You can monitor the performance of the URL buffer with the show url-block block stats command, as in the following example: Firewall# show url-block block stats URL Pending Packet Buffer Stats with max block 0 ----------------------------------------------------- Cumulative number of packets held: 0 Maximum number of packets held (per URL): 0 Current number of packets held (global): 0 Packets dropped due to exceeding url-block buffer limit: 0 HTTP server retransmission: 0 Number of packets released back to client: 0 Firewall#
If you are using content-filtering servers, you can monitor their activity with the show url-server stats (PIX 6.x) or show url-server statistics (PIX 7.x) command. In the following example, two Websense servers are used. A total of 447,869 URL requests have been sent to the servers, 394,410 of those were permitted, and 53,459 of them were denied because of the local content policies configured on the servers. Notice that one server is up, but the other is unresponsive. Firewall# show url-server stats URL Server Statistics: ---------------------- Vendor websense URLs total/allowed/denied 447869/394410/53459 URL Server Status: ------------------ 172.16.10.50 UP 172.16.10.55 DOWN
You can also get an idea about the rate at which the firewall is sending URL requests to the content-filtering servers. Use the show perfmon command, and look for the URL Access row to see how many new URLs are being requested per second. The URL Server Req row shows the rate at which the requests are being sent to the content-filtering servers. Firewall# show perfmon PERFMON STATS: Current Average Xlates 39/s 0/s Connections 110/s 1/s TCP Conns 80/s 0/s UDP Conns 29/s 0/s URL Access 57/s 0/s URL Server Req 50/s 0/s TCP Fixup 5033/s 0/s TCPIntercept 0/s 0/s HTTP Fixup 2293/s 0/s FTP Fixup 4/s 0/s AAA Authen 0/s 0/s AAA Author 0/s 0/s AAA Account 0/s 0/s pix#
Content-Filtering Examples A corporation has two Websense servers located on the firewall's DMZ interface at 192.168.199.10 and 192.168.199.11. The firewall intercepts every HTTP request and relays them to the Websense servers. If neither server responds within the default 5-second period (for each server), the firewall allows the request. The only exceptions to this policy are with all hosts on the 192.168.4.0/24 subnet, which are allowed to request any URL with no Websense intervention. Inside host 192.168.7.33 is allowed to request any URL as well. Inside host 192.168.7.40 is allowed to request URLs from outside server 172.24.1.10 without Websense intervention. If the inside host requests URLs from any other address, Websense is consulted. All HTTPS and FTP requests are subject to the local Websense server policies. To improve filtering server response, 128 blocks of memory are dedicated to buffering web content that arrives before the filtering server can respond. A cache is also configured so that repeated URL requests can be serviced immediately without waiting for further filtering server replies. This cache uses 128 KB of memory and is based on the source and destination address combinations. The configuration for this example is as follows: url-server (dmz) vendor websense host 192.168.199.10 protocol TCP version 4 url-server (dmz) vendor websense host 192.168.199.11 protocol TCP version 4 filter url http 0 0 0 0 allow proxy-block filter url except 192.168.4.0 255.255.255.0 0 0 filter url except 192.168.7.33 255.255.255.255 0 0 filter url except 192.168.7.40 255.255.255.255 172.24.1.10 255.255.255.255 filter https 443 0 0 0 0 allow filter ftp 21 0 0 0 0 allow url-block block 128 url-cache src_dst 128
|
