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.
Prev. page
1
[2]
3
next page 
