Publishing and Securing Services in an Existing DMZ
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.NOTEThis 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.
[View full size image]
Figure 7.6. Checking the server publishing name of an OWA publishing rule.
Figure 7.7. Editing a hosts file.
[View full size image]
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.NOTERemember 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.