ISA Server 2004's HTTP security filter adds a layer of protection to Web requests, ensuring that the data requested hasn't been hijacked or reassigned. In this article, Tom Shinder shows you what the HTTP security filter is and how it works on ISA Server 2004.
I had the opportunity to discuss the ISA firewall's application layer inspection mechanisms in a recent Webcast I did for Microsoft TechNet. During the Webcast I discussed several features of the ISA firewall's multilayered approach to network security and how the ISA firewall combines its stateful packet inspection, circuit layer filtering, and application layer inspection abilities to provide maximum network protection for organizations of all sizes.
I scheduled seven demonstrations to be done during the event, but unfortunately I was only able to complete five of them. In this two part series on Configuring ISA Firewall HTTP Application Layer Inspection for Outbound Access Control. In this article, I'll recap the discussion, and go over the principles underlying the demonstrations used to highlight how you can use the ISA firewall's HTTP security to maximum security for outbound access control.
If you didn't have a chance to view the presentation live, you can download it for offline viewing at Microsoft's Web Site.
In this, part 1 of the series, we'll discuss the ISA firewall's HTTP Security Filter. The HTTP security filter is a Web filter that binds to the ISA firewall's Web proxy application filter. The HTTP security filter can be configured on any Web Publishing Rule or Access Rule that controls HTTP access through the ISA firewall. In the second part of this series, I'll describe in detail how you can configure the ISA firewall's HTTP security filter to block instant messenger and peer to peer applications.
Overview of the HTTP security filter
The HTTP security filter is applied only to allow rules, since deny rules by definition already deny the connection so there's no reason to expose the connection to additional inspection. The HTTP security filter acts as a governor on an allow rule (either Web Publishing Rule or Access Rule) by enforcing additional security checks against the HTTP protocol before allowing the connection. Therefore, a connection that is allowed by a firewall rule on the ISA firewall could end up being denied based on the ISA firewall's analysis of the HTTP protocol characteristics of the connection.
You can configure the HTTP Security Filter on any Web Publishing or Access Rule that includes the HTTP protocol. Note that all Web Publishing Rules include HTTP protocol traffic (HTTP or HTTPS), while only those Access Rules you explicitly configure to use HTTP will include the protocol.
You'll need to create an Access Rule or Web Publishing Rule to expose the configuration interface for the HTTP security filter. Perform the following steps on an ISA firewall computer to create an Access Rule allowing the HTTP and HTTPS protocols outbound:
- In this ISA firewall console, expand the server name and then click the Firewall Policy node in the left pane of the console.
- Click the Tasks tab in the Task Pane and then click the Create New Access Rule link.
- On the Welcome to the New Access Rule Wizard page, enter HTTP/HTTPS Outbound in the Access Rule name text box and click Next.
- On the Rule Action page, select the Allow option and click Next.
- On the Protocols page, select the Selected protocols option from the This rule applies to list. Click the Add button.
- In the Add Protocols dialog box (Figure A), click the Common Protocols folder and then double click the HTTP and HTTPS entries. Click Close.
- Click Next on the Protocols page.
- On the Access Rule Sources page, click the Add button.
- In the Add Network Entities dialog box, click the Networks folder and then double click the Internal network. Click Close.
- Click Next on the Access Rule Sources page.
- On the Access Rule Destinations page, click the Add button.
- In the Add Network Entities dialog box, double click the External entry and click Close.
- Click Next on the Access Rule Destinations page.
- On the User Sets page, click the All Users entry and then click Remove. Then click the Add button.
- In the Add Users dialog box (Figure B), double click the All Authenticated Users entry and click Close. We want to take full advantage of the ISA firewall's application layer inspection feature set by allowing only authenticated connections outbound through the ISA firewall.
- Click Finish on the Completing the New Access Rule Wizard page.
- Click Apply to save the changes and update the firewall policy.
- Click OK in the Apply New Configuration dialog box.
|The Add Protocols dialog box|
|The Add Users dialog box|
The General Tab
Right click on the HTTP/HTTPS Outbound Rule and click the Configure HTTP command on the context menu. You'll be presented with the Configure HTTP policy for rule dialog box, as seen in figure C.
|The General tab in the Configure HTTP policy for rule dialog box|
On the General tab you can configure a number of parameters related to the length of the URL request and headers. Options include:
- Maximum headers length (bytes): This is a global setting that applies to all HTTP policy across all rules. The controls the maximum length of all HTTP header information and the URL and prevents possible buffer overflow exploits. For outbound access control, the default value is fine. However, you might want to reduce the default to 10,000 bytes if you're using the ISA firewall for only inbound access and then work your way up there are no problems with connecting to resources on the published Web sites.
- Allow any payload length: In the Request Payload frame you configure the maximum size of the HTTP payload, which include the HTTP data. The default setting is to allow any payload length, which is the best setting for an Access Rule. For Web Publishing Rules, you can customize this setting to match the specific characteristics and requirements of your published Web application. The best way to determine the optimal value is to ask your Web application developer. If you can't get this information from the developer, you can perform network monitoring and tracing to determine the optimal setting, or use the default setting. You can also use the setting to reduce the size of POST requests either outbound for Access Rules or inbound for Web Publishing Rules. This is helpful for both reducing overall bandwidth utilization when used for outbound access control, and preventing potential denial of service attacks to published Web servers.
- Maximum payload length (bytes): This option is used when you want to enter a custom setting for the maximum payload, instead of using the default value of any sized payload.
- Maximum URL length (bytes): The maximum URL length is used to control the maximum size of the URL sent to the Web site. For outbound connections you can safely use the default, or you can customize it to allow longer URLs by changing from the default value of 10240. For Web Publishing Rules, you can query your developer or perform network monitoring and tracing to determine the optimal value for your published Web application.
- Maximum query length (bytes) The query portion of the URL includes everything after the question mark. For outbound connections you're safe to use the default; however, you can change this if there are problematic sites. If you do find sites that require exceptionally long query strings in the URL, then you should create a separate Access Rule and configure a custom HTTP policy for that rule, instead of allowing these exceptionally long strings to all sites. Work towards keeping the maximum query length to a minimum required, as this can prevent buffer overflow attacks.
- Verify normalization The verify normalization option checks to see if escaped characters still exist in the URL even after normalization is performed. This protects you again double encoding attacks. Note that some poorly coded Web sites will use double encoded characters and cause users to be denied access to otherwise legitimate sites when this option is enabled. Check the URL used to access the denied site and see if there is a % in the normalized string.
- Block high bit characters This option enables you to block high bit characters used in particular character sets that can be used to execute a buffer overflow attack against a Web server.
- Block responses containing Windows executable content This option enables you to prevent access to Windows executable content. This prevents clients from downloading or launch executable from a Web server. This option looks at the actual content, rather than depending on the file extension of the content requested, by checking for the MZ marker at the beginning of a file image.
The Methods Tab
Click the Methods tab. On this tab you can configure which methods are allowed when connecting to the destination Web server. An HTTP method is an HTTP command (sometimes referred to as an HTTP verb). Examples of such HTTP methods include GET, PUT, and POST. Figure D shows the Methods tab.
|The Methods tab on the Configure HTTP policy for rule dialog box|
You have the options to:
- Allow all methods Use this option when you don't care what methods the client uses to connect to a destination Web site. This is the default setting.
- Allow only specified methods Use this option when you know what methods are required to support the Web application the client connects to. The most common scenario for this is for Web Publishing Rules where you know the precise Web application you're providing external users access to.
- Block specified methods (allow all others) Use this option when you're not sure what the exact methods might be required to access the destination Web site, but you are sure what methods you don't want allowed. This option is commonly used for both Web Publishing Rules and Access Rules. For example, suppose you do not want users on the corporate network to post information on external Web sites. You can block the POST method and prevent this type of information leakage.
The Extensions Tab
Click the Extensions tab (Figure E). Here you can configure what file extensions you want to provide the client access to through the ISA firewall.
|The Extensions tab on the Configure HTTP policy for rule dialog box|
You have the following options on the Extensions tab:
- Allow all extensions - Use this option when you don't care what the file extension is when users access resources through the rule.
- Allow only specified extensions - Use this option when you want to stringently limit what files extensions you want to allow users access to. For example, you might want to limit users access only to .htm and .html pages. While this would significantly limit user access, it does give you a high level of control over the type of content users can access.
- Block specified extensions (allow all others) - Use this option when you want to allow more liberal access to content, but block specific file types. For example, you might want to prevent users from accessing resources with the .exe, .com, .zip and .pif file extensions, but allow access to all other content.
- Block requests containing ambiguous extensions:
I've always found this to be an ironically well named option, since there is no
good official definition of this option. The only definition you'll find of
this option on the Web (or anywhere else) is that allows you to block content
if the ISA firewall can't determine the extension. This type of definition is
known as a tautology,
for which Microsoft Help files have been historically famous. What this option
actually means is that if there is more than one period in the path portion of
the URL, then the connection will be blocked. For example, the URL http://www.microsoft.com/evilfile.exe/default.htm
has more than one period in its path. The path statement in this example is
everything after the http://www.microsoft.com/
portion of the request.
The Headers Tab
Click the Headers tab (Figure F). Here you configure which HTTP headers you want to block, and how the Server and Via headers should be handled.
The Headers tab on the Configure HTTP policy for rule dialog box
On this tab you have the following options:
- Allow all headers except the following. This option allows you to block known HTTP headers used by Web applications. For example, a common HTTP header used by P2P applications is the P2P-Agent header, which you can use to block P2P applications that use this HTTP header. You have the option to block both HTTP request and HTTP response headers.
- Server Header - The Server Header is returned by a Web server in response to a request for Web services. For example, if you publish an OWA Web site using a Web Publishing Rule, the type of Web server will be included in the Server header in the response, such as HTTP: Server = Microsoft-IIS/6.0. You might want to have the ISA firewall change this so that attackers do not leverage knowledge of the type of Web server you're running against you. You have the options to Send original header, Strip the header from response and Modify header in the response. You might send the original header if you're not a fan of security by obscurity. You would strip the header if you don't want a potential attack to get any information at all from the Server Header. Or, you could choose the modify header option and enter a server header from a Web server that is not the same as the actual Web server, such as adding Apache instead of the actual IIS 6.0 Server Header.
- Via Header: The Via header is used to identify the names of the Web proxy servers in the request/response path. By default, the ISA firewall will include its computer name in the Via header. An intruder could potentially leverage this information to attack the ISA firewall or the networks protected by the ISA firewall. You have the options to Send default header or Modify header in request and response. If you want to obscure the name of the ISA firewall that would otherwise be included in the Via header, then you could use the modify option and include a bogus name.
The Signatures Tab
Click on the Signatures tab (Figure G). Here you can create custom signatures that match many different components of an HTTP request.
The Signature dialog box
When you click the Add button on the Signatures tab, you'll see the Signature dialog box, where you have the following options:
- Name: Enter a name for the Signature so you can identify it from the other signatures in the list.
- Description: Enter an optional description for the signature. This is very helpful for some of the more obscure signatures you want to create.
- Search in: This is where you designate what part of the HTTP communication you want this signature to match. You have the following options: Request URL, Request headers, Request body, Response headers and Response body.
- HTTP header: If you select the Request headers or Response headers option in the Search in list, then you enter the HTTP header you want the signature to match in the HTTP header text box.
- Signature: The signature is the text string you want the ISA firewall to match to block the connection request. For example, if you select the Request headers option and then the User-Agent: string in the HTTP header text box, then you might enter MSMSGS in the Signature text box.
Part 1 Summary
In this part 1 of a two part series on how to use the HTTP security filter to control outbound access through the ISA firewall, we went over how the HTTP security filter works with Access Rules to provide a "connection qualify" to an allow rule. The bulk of the article was then dedicated to examining the HTTP security filter options and how to configure them in various scenarios. In part 2 of this series, we'll finish up by demonstrating how you can configure the HTTP security filter to block access to dangerous applications such as instant messengers and peer to peer application. I'll also show you how to use the ISA firewall's integrated log viewer application to analyze the connections blocked by the HTTP security filter.