In general, there are few differences involved when securing various services in a unihomed server configuration. In most instances, the main difference in the rules that are set up relates to the networks from which the specific HTTP or HTTPS listeners will listen to requests, shown on the Networks tab of a specific listener, such as what is illustrated in Figure 7.4.
For a standard (multi-homed) ISA server, different listeners listen for connections from various networks, depending on the particular rule and functionality required. For example, an OWA publishing rule may listen to requests from the External network (the Internet) and publish the server on the internal network. Because the unihomed ISA server doesn't know the difference between all networks, it is important to make the change to the particular listener and adjust it to listen to All Networks for the rule to work properly.
This is an important concept to understand. Throughout this book, the assumption is made that a multi-homed server is set up. When the step-by-step guides in those chapters get to the point where the listening network is set up, simply change it to All Networks and configure the rest of the rule the way that the rest of the procedure lists. This ensures that web rules will work for a unihomed ISA configuration.
Configuring a Unihomed ISA Server to Reverse Proxy Exchange Outlook Web Access
Of special note is securing Outlook Web Access with a unihomed ISA configuration because this type of scenario is very popular and very common. Aside from the same listener network consideration previously mentioned, one more very important step must be taken on ISA servers to allow the OWA Publishing rules outlined in Chapter 12, "Securing Outlook Web Access (OWA) Traffic," to work. The unihomed ISA server must resolve the Fully Qualified Domain Name (for example, mail.companyabc.com) to the internal web server when SSL encryption is in use, to ensure that the full host header is properly passed through the entire SSL chain.
To explain further, when the client on the Internet sends a web request to go to https://mail.companyabc.com, external DNS servers point the client to an IP address on the external firewall, shown in Figure 7.5. The firewall, configured with the rules mentioned in the preceding section, forwards the HTTPS request to the ISA Server, which then decrypts it and repackages it as an SSL packet to send to the OWA server on the internal network.
Figure 7.5. Understanding the SSL-to-SSL bridging issue.
The tricky part is when this packet gets repackaged and sent back to the OWA server. Many administrators have made the mistake of simply selecting to forward the traffic to the internal name of the OWA server, such as server20.companyabc.com. The problem with this is that the SSL traffic then arrives at the OWA server without the proper host header (mail.companyabc.com). This causes the communications to fail, and the client to receive an HTTP error that says the "Target principal name is incorrect."
The key to fixing this is to make sure that the OWA publishing rule is configured to publish the server name the same way that the SSL Certificate is configured, such as what is shown in Figure 7.6.
Figure 7.6. Checking the server publishing name of an OWA publishing rule.
Or course, the real catch to all of this is that the FQDN of the original host header will either be found unresolvable by the ISA server or end up forwarding the traffic back to the external interface, which is definitely not wanted. Instead, the traffic needs to be redirected to point to the Internal OWA server through the use of a hosts file on the ISA server itself. This may be just the internal IP address, if a route relationship is set up between the DMZ and the internal network, or it may be the NAT IP address that the packet-filter firewall has configured for the OWA server, as shown in Figure 7.6.
In either case, the hosts file should be modified to enter the appropriate information. The hosts file is located in the following directory on the ISA server:
It can be modified in a text editor such as Notepad, as shown in Figure 7.7.
Figure 7.7. Editing a hosts file.
The lines beginning with # are comments, and can be removed if desired. A host file works when an IP address is entered on the first part of the line, a tab is inputted, and then the fully qualified domain name that will be associated with that IP address is entered. A host file will always override what is in DNS, so it is important to document the setting if the IP address of the OWA server is ever changed.
After the hosts file is modified, traffic will point to the proper server immediately, and the entire SSL chain will use the proper host header information.
Configuring a Unihomed ISA Server to Reverse Proxy Web Services
Reverse proxy of a web server is almost exactly the same on a unihomed server as a multi-homed one, just as it was with the OWA publishing rules. The same issues regarding host headers and end-to-end SSL encryption apply as well, and should be taken into account. For step-by-step guides to securing web traffic, see Chapter 14.
Remember that an ISA Server should never have any IIS components (except for the SMTP service) installed on it, even when it is providing reverse-proxy capabilities for web traffic.
Configuring a Unihomed ISA Server to Act as an SMTP Smarthost
Aside from HTTP Reverse Proxy filtering, one additional piece of functionality can be derived from a unihomed ISA Server in the DMZ of an existing firewall. When the SMTP service is installed and the SMTP Screener component configured, the ISA Server can be configured to be an SMTP Smarthost, which can be configured to relay mail to outbound hosts or to accept mail for inbound hosts.
The SMTP Screener component also allows for a basic level of content filtering and message screening capabilities, which can be extended further to perform proactive antivirus or antispam capabilities on mail traffic with a third-party add-on to ISA.