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.
Unlike the other types of server publishing rules, ISA does not need to be installed as a multi-homed (multiple NICs) server to take advantage of web publishing rules. Instead, ISA allows for the creation of web-based publishing rules when it is set up as a uni-homed server, sometimes set up in the DMZ of an existing packet filter firewall. In fact, this setup is a very common deployment model for ISA because there is a strong demand for systems to provide this type of secured reverse proxy capabilities. For more information on this deployment model, see 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.
It 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.
The General tab enables the rule to be enabled or disabled with the check box, as well as for the name to be changed and a description added, if necessary.
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.
It may be advantageous to forward the original host header (which takes the form of the FQDN) in cases where specific websites are being restricted by host headers or when a web-based application is expecting host header traffic.
Another very important option is displayed on this tab: the option determining whether the web traffic sees the traffic as originating on the original client or on the ISA Server computer itself. The option to make the traffic appear to come from the original client can help with auditing the traffic and making sure that user access is properly documented. Changing to make all requests come from ISA makes the web server think that the traffic originates from ISA instead. This option is typically more inclusive, and works in multiple scenarios.
If the ISA Server is deployed in uni-homed NIC mode in a firewall's DMZ, the only option that will work properly is to have the requests appear to come from the ISA Server console. Most firewalls do not allow the ISA server to mimic the packets from an untrusted network, and block the traffic itself.
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:
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:
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.
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.
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.
This dialog box is where the majority of the custom filters can be created and applied. Because so many applications and exploits use the HTTP port to tunnel their traffic, it is extremely useful to configure these settings to block malware, scumware, and any other applications that are not approved by the organization. This allows for blocking of signatures from such applications as Instant Messaging, Gnutella, Kazaa, Morpheus, and many more. For a list of signatures that can be blocked, see the following Microsoft URL:
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.
The existing Listener that was created in the Publishing Rule Wizard can be directly modified if the rule is selected from the drop-down box and the Properties button is clicked. This allows for various settings to be applied, such as the following:
The 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:
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.
For example, an organization may have set up multiple web servers on an internal web server that has a single IP address. Rather than assign multiple IP addresses to that server, the administrators chose to set up different ports for each virtual server and each website. So, internally, users would have to point to http://site1.companyabc.com:8020 and http://site2.companyabc.com:8030, and so on.
The Bridging option in ISA Server 2004 enables end users to not have to enter in strange port combinations to access websites, and instead relies on the Bridging tab of the rule to direct port 80 traffic to the appropriate ports, such as port 8020 or any other defined port.
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."