When you start using Web applications like Outlook Web Access for Exchange, you open your network up to new avenues of attack. Here's how you can defend your network using ISA Server 2004.
The ISA firewall's HTTP security filter is a software add-on to the ISA firewall's core firewall infrastructure. In fact, the HTTP security filter is a Web filter that hooks into the ISA firewall's Web proxy filter, which is an application filter that hooks into the ISA firewall service. It's important to note that both the Web proxy filter and the HTTP security filter are extensions of the ISA firewall's core firewall functionality and therefore are fully protected by the firewall's core stateful packet inspection engines.
Unlike ISA Server 2000, the ISA 2004 firewall is a firewall first, last and always. In ISA Server 2000, the Web proxy component was a dedicated service that provided forward and reverse Web proxy features. In ISA 2004, the Web proxy filter is just one of many application filters included with the ISA firewall and is always managed by the ISA firewall's firewall service.
The role of the HTTP security filter in publishing Web sites
The HTTP security filter can be configured on any rule allowing HTTP/HTTPS communications through the ISA Firewall. This includes both Access Rules and Web Publishing Rules. All Web Publishing Rules must process HTTP communications, so the HTTP security filter is available to all Web Publishing Rules. Its important to note that each Web Publishing Rule can have is own custom HTTP security filter configuration. This provides you very granular control over how HTTP sessions are inspected. We'll take advantage of this feature when we create separate publishing rules for OWA, OMA/ActiveSync and RPC/HTTP.
Application layer inspection using the HTTP security filter applies to allow rules only. The reason for this is that deny rules already block the traffic, so there's no reason to subject the connection to further processing overhead if its already been denied. When an allow rule enables HTTP traffic through the ISA firewall, the firewall engine passes the HTTP communications to the Web proxy filter and then up to the HTTP security filter. The HTTP security filter then checks the HTTP communications against the HTTP policy configured for that rule (HTTP security filter settings are referred to as the rule's HTTP policy). If the connection conforms to the parameters set by the HTTP security filter, then it continues through the ISA firewall to its destination. If the connection does not meet the HTTP security filter's requirements, then it is dropped.
This makes the HTTP security filter a "governor" or "qualifier" on HTTP allow rules. An Access Rule or Web Publishing Rule might allow a particular connection, but only if that connection meets the additional requirements set by the HTTP security filter.
When you create a Web Publishing Rule, as we will do later when configuring the OWA, RPC/HTTP and OMA/ActiveSync Web Publishing Rules, you will right click the rule and click the HTTP Policy entry in the context menu to bring up the Configure HTTP policy for rule dialog box.
In the following sections we'll take a look at the details of the HTTP security filter. We'll specifically discuss options on the following tabs:
- The General tab
- The Methods tab
- The Extensions tab
- The Headers tab
- The Signatures tab
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 A.
|The General tab|
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. This controls the maximum length of all HTTP header and URL information and prevents possible buffer overflow exploits. For Web publishing scenarios, might want to reduce the default to 10,000 bytes and then work your way up if 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 includes the HTTP data. 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 this setting to reduce the size of POST requests. This is helpful for 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 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. Work towards keeping the maximum query length to a minimum required when configuring this setting for Web Publishing Rules, 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. Since we're confident that you won't be publishing poorly coded Web sites, you probably won't need to configure this setting for your Web Publishing Rules.
- 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. This should not be enabled for OWA Web Publishing Rules, since its impossible to tell in advance what character sets will be used in e-mail messages sent to your users.
- 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 published 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 B shows the Methods tab.
|The Methods tab|
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 published 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 you're publishing. The most common scenario for this is you know the precise Web application you're providing external users access to, which will be the case for your Exchange Web services Web Publishing Rules.
- 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 C). Here you can configure what file extensions you want to provide the client access to through the ISA firewall.
|The Extensions tab|
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 published resources.
- Allow only specified extensions - Use this option when you want to stringently limit what files extensions you want to allow users to access on the published Web server. 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 accessible to remote users.
- 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 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 (http://dictionary.reference.com/search?q=tautology), which Microsoft Help files have been historically famous for. 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. Such ambiguous extensions can be used by dangerous sites to compromise the user's machine. Unfortunately, there are a number of popular Web sites, which are poorly coded from a security viewpoint, that employ such ambiguous extensions. Yahoo is just one of this sites.
The Headers tab
Click the Headers tab (Figure D). Here you configure which HTTP headers you want to block, and how the Server and Via headers should be handled.
|The Headers tab|
On this tab you have the following options:
- Allow all headers except the following - This option allows you to block known HTTP headers that are not required to access the features provided by your published Web application. 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 E). Here you can create custom signatures that match many different components of an HTTP request.
|The Signatures tab|
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. This feature can be used to block headers that are not required by your published Web application and could potentially be used to attack your published Web site.
- Signature: The signature is the text string you want the ISA firewall to match to block the connection request. This feature is very useful to blocking known strings that can be used to attack your published Web site.
ISA Server 2004 is a stateful packet and application layer inspection firewall. The ISA firewall provides application layer inspection security through application layer inspection extensions to the core firewall service infrastructure. The HTTP security filter is a plug-in to the Web proxy filter extension. The HTTP security filter enables the ISA firewall to inspect HTTP commands and data moving through the ISA firewall. You can create customized HTTP filter configurations that allow only legitimate traffic to the published Web site. In the next, and final article in this series, we'll see how to perform custom configurations of the HTTP security filter to publish OWA, OMA/ActiveSync and RPC/HTTP sites on a front-end Exchange Server.