Publishing and Customizing Web Server Publishing Rules
The key to ISA's HTTP filtering functionality revolves around the Web Server Publishing Rule. What this type of rule does is enable an ISA Server to "pretend" to be the web server itself, while secretly passing the packets back to the server via a separate process. This has the added advantage of securing the traffic by not exposing the web servers to direct attack and by forcing them to first overcome the ISA server before they can overcome the web server.Chapter 7, "Deploying ISA Server as a Reverse Proxy in an Existing Firewall DMZ."All the HTTP-based filtering and functionality is stored within the web publishing rule options, and it is therefore critical to become intimately aware of its capabilities.
Using the Web Server Publishing Wizard
To secure a web server through ISA Server 2004, a basic web server publishing rule must be set up and configured. When this rule is created, it can be modified as necessary to provide for additional filter capabilities and other options. To create a simple rule, follow the instructions outlined in the following steps. These instructions apply to a specific scenario, where a company's public web server, using simple HTTP, is published through ISA.
1. | From the ISA Server Management Console, click on the Firewall Policy node in the console tree. |
2. | From the Tasks tab in the Tasks pane, click the link titled Publish a Web Server. |
3. | Enter a descriptive name for the rule and click Next to continue. |
4. | Under Action to Take, select Allow and click Next to continue. |
5. | Under Computer Name or IP Address, enter the Fully Qualified Domain Name (FQDN) or IP address of the server, using an IP address or name that ISA can use to contact it.NOTEIt is important to note that the ISA server must be able to address the web server directly via the name or IP address entered, which almost always resolves to a separate IP address than the one that is publicly addressable. In certain cases, it may be necessary to "fool" ISA into resolving a Fully Qualified Domain Name into an internal IP address with a hosts file, so as to preserve the host header information for the connection from end to end. This is particularly the case with SSL-encrypted websites, which fail if the host header is not exactly the same. |
6. | Under Path, enter /*, as shown in Figure 14.1, so that the entire site will be published, and click Next to continue.Figure 14.1. Publishing a website. |
7. | Under Public Name Details, choose to accept requests for This Domain Name, and type it into the Public Name field (for example, www.companyabc.com). Leave the Path as /* and click Next to continue. |
8. | Under Select Web Listener, click the New button to create a Listener for the website traffic. |
9. | Enter a name for the Listener, such as HTTP-WWW-Listener |
10. | Select to listen for requests from the external network by checking the box next to it and clicking Next. |
11. | Check the Enable HTTP box, set the HTTP port to 80 (as shown in Figure 14.2), and click Next to continue.Figure 14.2. Creating a Web Listener for a web publishing rule. |
12. | Click Finish to finish creating the Web Listener. |
13. | From the next dialog box, review the Listener properties, and click Next to continue. |
14. | Under User Sets, accept the default of All Users and click Next to continue. |
15. | Click Finish to create the rule. |
NOTEIt is important to note that after the server publishing rule is in place, all HTTP requests sent to the website should point to the IP address of the HTTP Listener on the ISA server itself. This includes publicly accessible websites, which must register the DNS namespace with an IP address on the external interface of the ISA Server.After it is created, the rule itself should be viewed and the administrator should become aware of the different settings and options available for HTTP filtering, as described in the following sections.
Exploring the General Tab Options
Double-clicking on the web publishing rule that was created brings up the Properties dialog box, which allows for the configuration of the HTTP filtering settings. The first tab displayed is the General tab, as shown in Figure 14.3.
Figure 14.3. Examining the General tab on an ISA Web Publishing Rule.
Understanding the Action Tab
Under the Action tab of the web publishing rule, the rule can be set up to either allow or deny traffic. For web publishing rules, this is always set to Allow; there is no reason to create a web publishing rule just to deny access to a web server. In addition, a check box exists on this tab to allow specific log requests to be generated that match the rule.
Exploring From Tab Options
The From tab of a web publishing rule enables an administrator to limit the scope of locations from which the traffic will be allowed to come. For example, a rule could be limited to only those users on a particular subnet, or only a specified list of servers. The Add button can be used to apply specific limitations for the rule.In addition to specifying where the traffic can originate, this tab also enables specific exceptions to be made. For example, if an entire subnet is restricted, specific exceptions can be made.
Outlining To Tab Options
The To tab of a web publishing rule, as shown in Figure 14.4, enables input of information about the particular server that is being published. This includes the FQDN of the server itself, as well as the option to forward the original host header, if necessary.
Figure 14.4. Examining the To tab options on an ISA Web Publishing Rule.
Exploring the Traffic Tab and Filtering HTTP Packets
The Traffic tab looks relatively innocuous, but is actually a launching point to the advanced HTTP filtering options. The basic tab itself shows to what type of traffic the rule applies (HTTP or HTTPS) and provides for the option to inform users to use HTTPS if it is enforced. When using SSL, it also gives the option to require the stronger 128-bit encryption to the traffic, a recommended move in most cases.
Filtering HTTP Traffic
To filter the HTTP traffic, click on the Filtering tab and choose Configure HTTP, which allows for the following HTTP filtering options:Maximum Header LengthRequest Payload LengthMaximum ULR LengthMaximum Query LengthVerify NormalizationBlock High Bit CharactersBlock Responses Containing Windows Executable Content
Customizing Allowed Methods
In addition to these options, the filter definitions also enable specific HTTP methods (such as GET and POST) to be allowed in the particular rule. If specific HTTP methods are restricted, a web server can be made even more secure because many of the exploits take advantage of little-used HTTP methods to gain control of a system. To restrict by a specific HTTP method, take the following steps while in the Methods tab:
1. | Under specific the action taken for HTTP methods, use the drop-down box to specify to Allow Only Specific Methods. |
2. | Click the Add button. |
3. | Enter a name for the HTTP method that will be allowed. For example, enter GET (the method is case-sensitive) and click OK. |
4. | From the dialog box shown in Figure 14.5, click OK to save the changes.Figure 14.5. Customizing HTTP methods. |
Customizing Extensions
The Extensions tab of the Filtering Rules setting allows only specific types of message attachments to be displayed, such as .mpg files, .exe files, or any other ones defined in this rule. It also allows for the reverse, where all attachments except for specific defined ones are. To accomplish this, choose the option Block Specified Extensions (Allow All Others).For additional security, the box on this page can be checked to block ambiguous or ill-defined extensions, which can pose a security risk to an ISA Server.
Blocking Headers
Specific HTTP headers can be blocked on the Headers tab of the filtering options. This allows for HTTP Request headers or Response headers to be blocked, which can be useful in denying certain types of HTTP headers, such as User-Agent or Server, that define what type of HTTP traffic is being used.
Restricting Signatures
The Signature Restriction tab is one of the most important. It is "ground zero" for filtering of HTTP traffic to scan for specific exploits and viruses, such as the signature that is defined to block the Kazaa file-sharing application, shown in Figure 14.6.
Figure 14.6. Blocking Kazaa HTTP traffic by signature.
Understanding Listener Tab Configuration Options
The Listener tab of the web publishing tool, shown in Figure 14.7, allows for the customization and creation of various web listeners. A Listener is an ISA construct that "listens" for requests made to a specific IP port combination. As soon as the Listener receives the traffic, it then processes that traffic back into ISA. Listeners are required for web server publishing rules, and are what enable the ISA server to act as a web server to the requesting client.
Figure 14.7. Viewing the Listener tab settings.
NOTEThe most important thing to remember about Listeners in ISA Server 2004 is that you can have only a single Listener on each IP:Port combination. In cases where additional IP addresses are not a problem, this is a relatively small issue.
Viewing Public Name Options
The Public Name tab on the web server publishing rule, shown in Figure 14.8, enables an administrator to dictate that the traffic to the ISA Server travels with a specific public name. For example, it could be stipulated that access to a website such as www.companyabc.com is granted only to requests made to that website, rather than requests to an internal server such as \\server20. If a user tries to access that site from an IP address, that request fails because the web publishing rule is allowing only traffic sent to the www.companyabc.com website in this case.
Figure 14.8. Viewing Public Name options.
Understanding Paths Tab Options
In the Paths tab, specific external paths can be mapped to different locations on a web server. For example, it may be helpful to send requests sent to http://www.companyabc.com to http://www.companyabc.com/public automatically. The Paths tab offers this type of functionality. To add a path to accomplish what this model illustrates, for example, do the following:
1. | On the Paths tab of the web publishing rule, click the Add button. |
2. | Under Path Mapping, enter /public/*. |
3. | Under External Path, select The Following Folder and enter /*, as shown in Figure 14.9.Figure 14.9. Setting up path mapping. |
4. | Click OK, Apply, and OK to save the changes. |
Exploring the Bridging Tab
The Bridging tab of an ISA web publishing rule, shown in Figure 14.10, gives an administrator the flexibility to send HTTP and/or SSL traffic to different ports on a web server. This concept can help to support those environments that have non-standard ports set up for their web environments.
Figure 14.10. Exploring bridging concepts.
Understanding the Users Tab
The Users tab on a web publishing rule is useful only if the full firewall client is deployed throughout the organization; otherwise rules always are set to All Users. If the Firewall client is installed, however, per-userbased access control can be realized, enabling an administrator to monitor and adjust to traffic and security on a per-user basis.
Outlining Schedule Tab Options
The Schedule tab of a web publishing rule, shown in Figure 14.11, does not require much explanation. Using this tab, an organization can decide at exactly what times the rule will be in effect.
Figure 14.11. Viewing the Schedule tab for the web publishing rule.
Exploring the Link Translation Tab
The Link Translation tab allows for a great deal of flexibility in searching for unique bits of contents and replacing those bits of content with something else. More information on this is included in the section of this chapter titled "Securing Access to SharePoint 2003 Sites with ISA 2004."