Filtering Web Traffic


Although often the most attention is paid to the protection of internal servers or clients from external malicious attempts (the main purpose of ACLs), it is sometimes important to monitor and filter outbound connections made by users. One reason for content inspection is if you want to use your firewall to enforce security policies such as an acceptable use policy, which could specify that internal users may not use the company's Internet connection to browse certain categories of Web sites. There are many solutions for achieving this goal, but the most general one is URL filtering, in which the firewall hands each request for HTTP content to a filtering server, which can approve the request or deny access to it. The firewall then acts accordingly: If the request is approved, it is forwarded to the outside server and the client receives the asked-for content; if not, either the request is silently dropped or the user is redirected to a page telling him or her that the request breaches company policy.

Another reason for filtering is to deal with "active content" such as ActiveX or Java applets. This could be important in order to protect internal users from malicious Web servers that embed these executable applets in their Web pages, because such executable content can contain viruses or Trojan horses. The most general solution is content filtering, which scans incoming applets for viruses and denies them when something wrong is found. Unfortunately, the PIX does not support this general solution, and the only thing you can do with it is to strip all active content from incoming Web pages.

Filtering URLs

It is possible to use access lists to permit or deny access to specific Web sites, but if the list of sites grows long, this solution will affect firewall performance. In addition, access lists do not provide a flexible way of controlling access in this case; it is not possible, for example, to permit or deny access to specific pages on a Web site, only to the whole site identified by its IP address. Access lists will also not work for Web sites that are virtually hosted; in this case, there are many Web sites located on the same server and all of them have the same IP address, so it is only possible to deny or permit access to all of them at the same time.

As stated, one general solution moves most of the work to a dedicated URL filtering server, offloading the PIX's CPU and allowing for fine-tuning of Web access controls. The sequence of events is as follows:

  1. A client establishes a TCP connection to a Web server.

  2. The client sends an HTTP request for a page on this server.

  3. The PIX intercepts this request and hands it over to the filtering server.

  4. The filtering server decides if the client should be allowed access to the requested page.

  5. If the decision is positive, the PIX forwards the request to the server and the client receives the requested content.

  6. If the decision is negative, the client's request is dropped.

Figure 10.8 demonstrates this process.

click to expand
Figure 10.8: Interaction Among a Client, a Web Server, PIX, and a Filtering Server

Websense and N2H2

The PIX can interact with two types of filtering servers: Websense (www.websense.com) and N2H2 (www.n2h2.com). Websense is supported in PIX v5.3 and later, and N2H2 support was added in v6.2. PIX URL filtering is applied only to HTTP requests; for example, it does not perform any inspections of FTP links. (Although a URL of type ftp://ftp.somedomain.com can be entered in a Web browser, it uses the FTP protocol, not HTTP.) The PIX also does not inspect HTTPS connections.

The steps to configure URL filtering are:

  1. Specify the server to use for URL processing.

  2. Tell the firewall the traffic to inspect—ports and IP addresses.

  3. Optionally configure some server-specific parameters.

  4. Configure filtering rules on the filtering server.

The command for specifying a filtering server for Websense is:

url-server (<if_name>) host <local_ip> [timeout <seconds>] [protocol <tcp> | <udp>  [version 1|4]] 

For example, the following code specifies that the PIX should use a server with IP address 10.0.0.1, which is located on the interface inside, and connect to it using TCP Websense _protocol v4:

PIX1(config)# url-server (inside) host 10.0.0.1 protocol tcp version 4 

Particularly, if_name is an interface on which the server is located, the default here is the inside interface. local_ip is the IP address of the filtering server. The PIX uses timeout (default is five seconds) to decide how long it has to wait for a reply from the server until it gives up and switches to the next configured server or takes a default action if there are no more servers available. It is possible to configure up to 16 servers, but they all must be of the same type; it is not possible to use both Websense and N2H2 filtering servers in the same configuration. The first server configured is a primary filtering server and is contacted first. Protocol type and version parameters specify the Websense protocol that should be used for communication with the server. It can be either TCP protocol v1 (default) or 4, or UDP protocol v4.

The N2H2 server is specified by the command:

url-server (if_name) vendor n2h2 host <local_ip> [timeout <seconds>]  [port  <port_number>] [protocol tcp | udp]

The meaning of parameters is the same. The parameter vendor n2h2 states that the server is an N2H2 filtering server. It is possible to add the parameter vendor websense to the Websense server configuration, but it is assumed by default. N2H2 servers have only a communication protocol version available, so it is not specified. It is possible to configure the port to use for communication with the N2H2 server using the port_number parameter.

Note

If you switch the application type (that is, change from N2H2 server to Websense or vice versa), all configuration of URL filtering is lost and will need to be re-entered.

The next task is to configure the filtering policy itself. The relevant command is:

filter url <port>[-<port>] <local_ip> <local_mask> <foreign_ip> <foreign_mask>  [allow] [proxy-block]

This command specifies port numbers on which HTTP connections should be inspected (with the default of port 80). local_ip and local_mask specify which local clients are subject to monitoring (that is, the requests by the machines from this network will be checked with URL filtering server). The foreign_ip and foreign_mask parameters specify that only requests to a specific set of servers be checked. The allow parameter defines that the PIX should permit traffic through if it is unable to contact the primary URL filtering server. Finally, the proxy-block parameter specifies that all requests from any clients to proxy servers will be denied. For example, the following command defines that all HTTP requests to port 80 will be inspected:

PIX1(config)# filter url http 0 0 0 0  

The following command configures inspection of all HTTP requests to port 8080 from clients on network 10.100.1.0/24 to any server and allows the request to pass through in case a filtering server is unavailable:

PIX1(config)# filter url 8080 10.100.1.0 255.255.255.0 0 0 allow 

Another variant of the filter command allows specifying that some traffic should be exempt from filtering. The format in this case is:

filter url except <local_ip> <local_mask> <foreign_ip> <foreign_mask>

When entered after the filter command, this command excludes specified traffic from the policy. For example, the following sequence of commands means that all HTTP traffic to port 8080 will be inspected, excluding traffic from network 10.100.1.0/24:

PIX1(config)# filter url 8080 0 0 0 0  PIX1(config)# filter url except 10.100.1.0 255.255.255.0 0 0 allow 

Fine-Tuning and Monitoring the Filtering Process

The two commands we just looked at, url-server and filter url, constitute a basic configuration for URL filtering, but some extra parameters might need to be configured. One of these is required to deal with the problem of long URLs, which are common nowadays to store session and other information in the URL itself. A typical long URL could look like this:

http://www.somebettingcompany.com/?action=GoEv&class_id=1&type_id=2&ev_id=4288&clas s_name=%7CFootball%7C&type_name=%7CChampions+League%7C+%7CQualifying+Matches%7C&ev_ name=%7CGenk%7C+v+%7CSparta+Prague%7C

Until v6.2, the PIXs maximum supported URL length was 1159 bytes (for Websense only; N2H2 was not supported at all). In v6.2, the maximum URL length for Websense filtering is 6KB and 1159 bytes for N2H2. Version 6.2 introduced new options to the filter command to configure the firewalls behavior when the URL exceeds 1159 bytes with a Websense server. This syntax of this command is as follows:

filter url [longurl-truncate | longurl-deny] [cgi-truncate]

The longurl-truncate parameter specifies that when the URL length exceeds the maximum, only the IP address or hostname from the request, instead of the full URL, is sent to the filtering server. The longurl-deny parameter specifies that all long URL requests should be dropped. The cgi-truncate parameter specifies that only the CGI script name and its location (the part of the URL before the ? sign) should be passed as the URL to the Websense server. This skips the CGI parameter list, which can be quite long. Without this option enabled, the entire URL, including the parameter list, is passed.

Note

Even in PIX 6.2, the default URL size passed to a Websense filtering server for processing is 2KB. In order to increase this size, use the command url-block url-size <size_in_kb>, where size_in_kb can be from 2 to 6.

There are also commands for fine-tuning performance. The most important is the url-cache command which has the following syntax:

url-cache {dst | src_dst} size <kbytes>

This command is used for tuning the process of caching replies from the filtering servers. By default, the PIX sends requests to the URL filtering server for a decision and to the Web server for content at the same time, and if the Web server replies faster than the filtering server, the Web server's reply is dropped. The Web server is then contacted again if the filtering server permits the connection. In order to prevent these double requests, you might want to store the filtering server replies locally instead of contacting the server every time. The url-cache command enables a cache of kbytes kilobytes for replies of filtering servers based either on destination (that is, Web server address) when the dst option is specified or on both source and destination when src_dst is specified. The first option is recommended when all users have the same access privileges (so there is no need to identify clients), and the second is recommended when different users have different access privileges. The statistics of the caching process, including the hit ratio, can be viewed by executing the show url-cache stat command. For example, the following command enables a cache of 32KB for all outgoing HTTP requests:

PIX1(config)# url-cache dst size 32 

The following are cache statistics:

PIX1# show url-cache stat URL Filter Cache Stats ——————————— Size : 32KB Entries : 360 In Use : 200 Lookups : 2000 Hits : 1000

Another option for overcoming slow filtering server response is to cache Web server replies in advance and pass these replies to the client after the filtering server permits it. This feature is configured on the PIX using the following command:

url-block block <block_buffer_limit>

This command configures the size of the reply cache. The block_buffer_limit parameter can be any number between 1 and 128 and defines how many blocks of memory will be used. Usage statistics for this memory pool can be viewed by using the show url-block block stat command. For example:

pix(config)# show url-block block stat     URL Pending Packet Buffer Stats with max block           1 ——————————————————————————- 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 Packet drop due to retransmission:                       0 

The total amount of memory used for storing URLs and pending URLs (the ones for which no response from the filtering server has yet been received) is configured with the command:

url-block url-mempool <memory_pool_size>

The size of the allocated memory pool is defined by a number from 2 to 10240, the number in KB. Other commands for viewing the configuration of URL filtering are show filter, show url-server, and show url-server stats.Here is some example output from these commands:

PIX1# show url-server url-server (outside) vendor n2h2 host 192.168.2.17 port 4005 timeout 5 protocol TCP url-server (outside) vendor n2h2 host 192.168.2.10 port 4005 timeout 5 protocol TCP PIX1# show filter filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 PIX1# show url-server stats URL Server Statistics: ——————————— Vendor n2h2 URLs total/allowed/denied 2556/2000/556 URL Server Status: ————————— 192.168.2.17 UP 192.168.2.10 DOWN

show perfmon, show memory, and show chunks can also be used for monitoring the performance of the URL filtering process:

Active Code Filtering

As mentioned, active content in Web pages could be considered undesirable from a security point of view. Fortunately, there is a rather easy and effective way to prevent this content from reaching clients. In HTML, active content is denoted by two types of tags. The first is:

<object> … </object> 

These tags are more common for ActiveX content, but they also can be used by Java applets. There are also Java-only tags:

<applet> … </applet>

When configured to look for active content, the PIX simply comments out both of these tags inside a TCP packet and the content between them, so they are simply skipped by the client's browser and embedded code is not run. The only problem with this approach is when the first tag is in one packet and the closing tag is in another packet, the PIX cannot perform this operation and the Web page is passed as is. For example, the HTML code inside an incoming packet might be as follows:

<td width="185" height="68" valign="top">   <applet codebase="/classes/" code="tscroll.class" align="absbottom"         width="185" height="68">     <param name="bgcolor" value="8,51,128">     <param name="enddelay" value="4000">     <param name="scrolldelay" value="25">     <param name="scrolljump" value="5">     <param name="speed" value="2">     <param name="size" value="11">     <param name="hlcolor" value="255,0,0">     <param name="centertext" value="false">   </applet> </td>

After being transformed by PIX, it becomes the code in the following output.

<td width="185" height="68" valign="top">   <!-- <applet codebase="/classes/" code="tscroll.class" align="absbottom"       width="185" height="68">     <param name="bgcolor" value="8,51,128">     <param name="enddelay" value="4000">     <param name="scrolldelay" value="25">     <param name="scrolljump" value="5">     <param name="speed" value="2">     <param name="size" value="11">     <param name="hlcolor" value="255,0,0">     <param name="centertext" value="false">   </applet> --> </td> 

Now the Web browser ignores everything between the <td> and </td> tags.

Filtering Java Applets

To configure filtering of Java applets, use the following command:

filter java <port>[-<port>] <local_ip> <mask> <foreign_ip> <mask>

Here is an example:

PIX1(config)# filter java 80 0 0 0 0 PIX1(config)# filter java 80 192.168.2.17 255.255.255.255 0 0 

The first command configures the PIX to drop all Java applets from incoming Web pages; the second prohibits only one host 192.168.2.17 to download Java applets. The port parameter, as usual, specifies the TCP port on which to perform the inspection.

Filtering ActiveX Objects

Java has a more or less robust security model for its active code (there has been only one big security issue with it, and that was due to the poor implementation of this model in some versions of Netscape), but ActiveX objects have almost unrestricted access to the client's machine.

The command to configure filtering of ActiveX code (and all active content that is embedded in "object" tags) is very similar to Java filtering:

filter activex <port>[-<port>] <local_ip> <mask> <foreign_ip> <mask>

Here is an example:

PIX1(config)# filter activex 80 0 0 0 0 

This command configures the PIX to comment out all pairs of object tags from all incoming Web pages, disabling ActiveX and some Java applets.




The Best Damn Firewall Book Period
The Best Damn Firewall Book Period
ISBN: 1931836906
EAN: 2147483647
Year: 2003
Pages: 240

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net