Web Content Filtering with ISA Server

Your organization might have already made decisions about allowing or denying Internet traffic by protocol. For example, you might allow Web browsing for your user community but block IM traffic. However, what about blocking content within the overall set of protocols that you plan to allow? For example, you might want to let your employees browse the Web, but you don't want them visiting certain Web sites. You also might want to block certain types of content from any Web site (e.g., downloads of executable programs).

These instances point to the need for content filtering: inspecting content as it comes across your firewall and making a decision about whether it should be denied or allowed. Microsoft Internet Security and Acceleration (ISA) Server is not only a stateful packet filter (letting you permit or deny entire protocols) but is also a stateful content filter. It lets you open up the content within packets traveling across your network and make decisions about what to do with them.

You can use ISA Server to enable several types of Web content filtering to improve your network's security. I'll walk you through several blocking exercises: blocking content by DNS name or specific URL path, by specific keywords found within the Web content your users request, and by file type. I use ISA Server 2004 in my examples.

Blocking by URL
To block a specific Web site or set of Web sites, you need to define a URL set as part of a firewall rule within your existing ISA Server configuration. The primary difference between a standard firewall policy rule and this type of content filter rule is the destination type. In a firewall rule, the destination defined in the rule is a network entity—whether an individual host or a range of IP addresses (e.g., the "External" network that ISA Server predefines). When you decide to create a content filter, you define a set of URLs as the destination instead, and you set the policy to deny all traffic.

Let's look at an example. Suppose you decide that no one in your organization should browse the Playboy Web site from your corporate network. (I pick on http://www.playboy.com when I discuss content filtering because it's a widely recognized name in adult content.) You start by creating a typical firewall rule and defining it with the values that Table 1 shows.

Because you'll be creating a URL set for the first time, no options are available under the existing category. Therefore, click New to create a new URL set to apply to this firewall rule. Figure 1 shows the New URL Set Rule Element dialog box.

As you can see, I defined the URL set as containing one path: http:// *.playboy.com. By using the wildcard option (*), I can successfully block all servers within the playboy.com DNS zone. Overall, this approach is better than denying access to specifically listed sites (e.g., www.playboy.com, server1.playboy.com, server2.playboy .com). After you've created your rule, apply the changes to your firewall so that they take effect.

After your new policy is in place, go to a workstation in your organization and attempt to browse one of the Web sites that you've blocked. If everything is working properly, you should see a browser error message stating "The page cannot be displayed." A Technical Information section at the bottom of the error message explains that ISA Server denied the specified URL.

To avoid unnecessary Help desk calls and take the opportunity to remind your user community of your organization's policies about restricted sites, you can assign a custom HTML error page to your URL set deny rule. In the Properties dialog box for the rule, go to the Action tab, which Figure 2 shows, to select the Redirect HTTP requests to this Web page option and specify a URL.

You might want to consider banning other types of Web sites, for other reasons. Some businesses ban fantasy football Web sites. I see an increasing number of organizations blocking the use of Web-based email sites from within the organization because they've found that most virus infections entering their networks come from Web-based email solutions.

Keep in mind that like other ISA Server firewall rules, content-filter rules are processed from first to last. ISA Server attempts to find a match for each request traveling through your network, beginning with rule #1 in your firewall rule set. If no match is found, ISA Server compares the request to rule #2, then to rule #3, and so forth, until it finds a match or the traffic is processed by the Default Deny rule (which should always be at the bottom of your rules). After ISA Server finds a match, no other rules are processed. Therefore, place your rules to deny certain Web sites above the rules that let your users browse the Web.

Also, remember that you can set a content-filtering rule to apply only at certain times. For example, perhaps your organization wants to block fantasy football Web sites only during business hours. In that circumstance, just create the rule as you typically would but apply a schedule to the rule.

Response-String Filtering
Through URL filtering, you can gain a large amount of control over the security of your network. You can even block off entire country top-level domains (e.g., *.cn for China) from your user community. However, in some cases, content filtering based on URL checking isn't enough. You can't know in advance all possible unacceptable URLs. Also, some Web sites with questionable content don't operate on URLs but solely on IP addresses. For those situations, ISA Server provides an additional content-filtering tool in the form of response-string filtering.

Let's look at how response-string filtering works. You might want to ban all Web sites that refer to United States Code 18, section 2257, a common disclaimer-that adult content sites use on their logon page to confirm that they operate within the law. Typically, the notation appears as 18 U.S.C. 2257. If that notation appears on a Web page, the odds are pretty good that the page is part of an adult Web site.

Having ISA Server search for this notation and filter responses accordingly provides additional security for a small effort. The following scenario demonstrates how you can catch 18 U.S.C. 2257 on a Web page and block the content.

The portion of ISA Server that handles this type of content filtering is known as the Web Proxy Filter. The Web Proxy Filter processes requests on behalf of your organization, then filters content that you request. ISA Server's Web Proxy Filter isn't enabled by default. You must activate it.

In your rule set, locate the rule that lets your users browse the Web. I hope that if you allow traffic out of your network on a protocol-by-protocol basis, you have a specific rule allowing HTTP and HTTP Secure (HTTPS). Find that rule, right-click on HTTP, and select Properties.

In the Application Filters area at the bottom of the HTTP Properties dialog box, you should see a number of available filters, all of them unselected. Find and select the Web Proxy Filter, then click OK. Click Apply to commit the changes to the firewall. You should now have HTTP filtering enabled. Let's look at some of the rules you can create.

Right-click the name of the rule that lets your users access the Web. You should see a new option for this rule: Configure HTTP. This option lets you define advanced HTTP filters for requests going in and out of your network. When you first select Configure HTTP, you see the five-tabbed Configure HTTP policy for rule dialog box. The HTTP policy applied to your rule has five main sections that correspond to the tabs: general, methods (e.g., GET/POST), file extensions, headers, and signatures.

The settings that you apply within the HTTP policy are specific to the individual ISA Allow rule with which you're working. Because of this specificity, you can create different sets of HTTP filters based on firewall rule criteria. For example, you can let some users but not others download executable files.

To filter Web pages that contain the string 18 U.S.C. 2257, select the Signatures tab in the Configure HTTP policy for rule dialog box. This tab lets you perform advanced string and signature filtering on HTTP requests and responses. Obviously, the dialog box is initially blank, which would allow everything to get through. To start adding content to this dialog box, click Add. You can now add a new signature, as Figure 3 shows.

To enable parsing a Web page for a specific string, you select Response body as the area to search, then put the actual text in the Signature space. Doing so lets ISA Server know that if it finds that string in the HTTP response (within the boundaries of the byte range) a Web server provides, it should block the page. The default byte range typically starts at 1 and ends at 100. You should probably increase the upper value of this range so that the filter will actually parse the entire page. However, because searching larger portions of a requested page incurs a performance penalty, you must weigh the benefits and the costs. As you can see in Figure 3, I've set the upper value to 4096 bytes.

When users stumble (knowingly or unknowingly) across a page that contains the restricted signature, they receive a "The page cannot be displayed" error message in their browser. The Technical Information section at the bottom of the error page explains that the HTTP filter rejected the request to the target Web site.

Signature Matching
Although filtering on keywords within the body of an HTML page is useful and improves your organization's security, one of the most powerful ways to use HTTP signatures is to block malicious code embedded in Web pages by directly matching a signature to it.

One example of hostile code to block is download.ject. This threat propagated itself to Web browsers by sending improper data in the response headers of an HTTP request (not in the body of the page itself), which the computer browsing the associated page then processed.

Thomas Shinder, ISA Server expert and Web master for ISAserver.org, wrote an article documenting how to set up ISA Server's HTTP filter to capture the hostile code embedded in the HTTP response and reject it accordingly. The method involved creating a signature based on the response headers (not the body) and entering C: as the signature to match, as Figure 4 shows.

Malicious coders continue to focus their efforts on port 80 whenever they can (Code Red I and Code Red II were examples of port-80 attacks), knowing that nearly every organization must allow traffic through port 80. Although typical stateful-inspection firewalls simply make a yes/no decision for traffic based on the addresses and ports involved, application-layer filters such as ISA Server can look into the application layer and protect your organization based on code embedded in HTTP requests and responses.

Blocking File Downloads by File Type
Let's consider another HTTP filtering option that most administrators will find useful: blocking file downloads based on file type (extension). From the Configure HTTP policy for rule dialog box, select the Extensions tab that Figure 5 shows.

The dialog box lets you define any number of file extensions to either allow or block, depending on how you want to create your rules. For example, if your organization's security policy indicates that users should be downloading documents only (never anything else), you can set Specify the action taken for file extensions to allow specified extensions only and populate this page with the types you want to allow (e.g., .doc, .xls, .ppt, .pdf, .rtf, .txt).

Figure 5, however, shows the opposite approach. Users behind this ISA Server can download any file type except the ones I specifically blocked: several executable content types (.exe, .pif, .scr) and .zip files. After the rule is in place, any attempt to download a file with one of the specified extensions results in an error message that explains that the HTTP filter rejected the request.

Let me list common file types that many organizations filter either through their mail server or through a Web proxy filter such as ISA Server. You'll find it worth your while to add many of these file types to an HTTP filter applied to your general user community's traffic. Your headaches will be reduced if users aren't allowed to download questionable content or have their browsers tricked into doing so.

I strongly recommend that you block the following attachment types:
.com, .bat, .chm, .cmd, .eml, .dll., .exe, .js, .msi, .pif, .scr, .shs, .vb, and .vbs. You should also consider blocking the following attachment types: .asx, .ade, .adp, .bas, .bin, .cpl, .crt, .hiv, .hlp, .hta, .inf, .ins, .isp, .jse, .jtd, .mht, .msc, .msp, .mst, .nws, .ocx, .oft, .ovl, .pcd, .pl, .plx, .sct, .sh, .shb, .sys, .vbe, .vss, .vst, .vxd, .wsc, .wsf, and .wsh.

ISA Server has the ability to filter specific types of content within the protocols on which most organizations must depend. ISA 2004's application-level content filtering is a breeze to set up, and it raises the security capabilities of organizations that use it to previously unattainable levels.

Editor's note: This article is excerpted from Keeping Your Business Safe from Attack, which is available at http://www.windowsitpro.com/ebooks.