Publishing Exchange services with a single NIC ISA 2006 Server....
A few weeks ago I received an email with the following question.....
I want to publish an internal Exchange 2k3 server through ISA 2006. The ISA server is not multi-homed. Is it possible to allow full publication of my Exchange server ( = SMTP inbound and outbound, and OWA)?
The short answer to this is - Yes, you can - but only for OWA. Not for inbound Exchange services. Two things come to mind.
First, when it comes to network security, I am a big fan of full network segmentation. I have my own OWA and Outlook Anywhere (RPC over HTTP in Exchange 2003) services placed behind and published through my multi-homed ISA 2006 server. For my particular network configuration it just makes sense to have everything behind ISA. I also designed my network so that ISA 2006 is doing "edge" firewalling. But ISA 2006 does introduce some improvements in the web proxy filter that can be used to publish web-based Exchange services and even SharePoint sites securely. It may make sense for your configuration to have a single homed ISA machine and use it to publish OWA & RPC/HTTP.
Second, the whole point behind publishing with ISA server is the security it can provide. I personally think that application publishing should ALWAYS be phrased as secure application publishing because that is what everyone really wants and it is what ISA Server does when deployed/configured properly. Placing the Exchange SMTP services behind a multi-homed ISA server allows you inspect the traffic going both directions and make use of the SMTP filter built into ISA. It also forces all of that SMTP traffic to go through ISA without providing another path (more on this below).
There is substantial difference between web-based OWA & RPC over HTTP access which should always be an authenticated connection and server to server SMTP communications which is generally unauthenticated, anonymous communications. The former requires some sort of credentials verification whether that be via forms based authentication, LDAP or some other security measure. You can talk directly to the mail server (Exchange in our case) or allow ISA to authenticate and inspect the traffic. Exchange alone doesn't do any payload inspection so ISA provides a measurable benefit when publishing Exchange web based services. ISA can even terminate SSL connections, inspect the payload, and then repackage it and send it on it's merry way via SSL if everything is ok. Another benefit ISA provides is the web-based traffic can be cached, providing a better experience for the client and reducing traffic on the network.
When it comes to anonymous SMTP connections it would seem to make more sense to just let the servers connect directly to each other (or even client to server). But again, ISA can act as the gatekeeper here and make use of its built in SMTP filter to inspect the incoming SMTP commands. The SMTP filter can check to make sure the SMTP commands are valid and accepted; and are the correct length (to protect against buffer overflow attacks). If things are not up to snuff, ISA can drop the connection to protect the Exchange server and log the information which can also be used to generate alerts to notify you of an attempted compromise. But SMTP connections cannot be cached like web based connections. We don't use Web Publishing rules instead we use Server Publishing Rules which are Firewall Policies designed for specific services.
The rule of thumb is that Firewall Policies require two network interfaces. It is possible to configure a single NIC ISA machine and bind "internal" and "external" IP addresses to it and work around physical segmentation but it also compromises the bulk of the security that ISA can provide with a true physically segmented network.
Think of it this way.....
A single NIC ISA server is comparable to a movie theater where the ISA Server is the ticket booth. The goal is to get in to see a movie. Movie goers are supposed to go to the ticket booth and purchase a ticket which grants you entry to the theater. However, it is possible with a little creativity and social engineering to bypass the ticket booth all together and get into the theater unbeknownst to the ticket booth(or so I have heard). The line between the inside and outside is a little fuzzy because you only have to pass by the ticket booth to gain entry. (I think the reason movie theaters are relatively lax in this area is because they are still going to get your $20 for the soft drink and the popcorn!)
A properly configured multi-NIC ISA server is like your house where ISA is the locked front door. The goal is to get into the house. If you are outside and you want in, you have to have a key to the house. You have to pass through the door. You don't just pass by it as you can with the movie theater ticket booth. There is a definitive inside and outside. You can't walk past the booth and duck under the rope to get in.
None of this is to suggest that a single-NIC ISA system is a wide open door. It's just that ISA was not designed to be configured as a Firewall nor as a Secure Application Publishing platform using a single NIC. Single-NIC ISA 2006 systems are great for publishing web based information. There are a number of improvements over ISA 2004 that provide a greatly enhanced level of flexibility for this very purpose. Using multiple physical interfaces for firewalling and application publishing lets ISA work the way it was designed to work and will ultimately be easier to configure and maintain as well as give you all of the security features you paid for.
Repeating to emphasize - In a multi-NIC configuration there is a physical separation of the network segments. You have to pass through the ISA machine to get from one side to the other. There is no other route. This allows ISA to authenticate (if necessary) and inspect traffic dropping the undesirable stuff, log and fire off alerts if configured. With a single NIC ISA Server, the single NIC still has to be connected to a hub/switch/router that connects to the two network segments. That other device provides another path for the traffic to move along without absolutely requiring any communication with ISA.
If you would like to read more about the security model that ISA 2006 provides and recommended configurations, I suggest the following --
Cheers!