Home / server / Questions / 70503
Accepted
Carl C
Asked: 2009-10-02 10:14:45 +0800 CST

Exchange 2007 CAS - Advantages of ISA Server over forwarding port 443

  • 772

I'm working on deploying Exchange 2007 into an existing Exchange 2003 environment. Microsoft does not support placing an Exchange 2007 Client Access Server (CAS) in a perimeter/DMZ network. Microsoft instead suggests placing an ISA Server in the perimeter/DMZ network and using it to reverse proxy requests to the CAS server.

What is the advantage of using the ISA server as a reverse proxy compared to forwarding port 443 from the external network through the perimeter/DMZ to the CAS server on the internal network? Will I have SSL certificate issues if I forward the port? Are there other ports that need forwarding?

Update: I found the following two advantages here:

When you publish an application through ISA Server, you are protecting the server from direct external access because the name and IP address of the server are not accessible to the user. The user accesses the ISA Server computer, which then forwards the request to the server according to the conditions of the server publishing rule.

SSL bridging protects against attacks that are hidden in SSL-encrypted connections. For SSL-enabled Web applications, after receiving the client's request, ISA Server decrypts it, inspects it, and terminates the SSL connection with the client computer. The Web publishing rules determine how ISA Server communicates the request for the object to the published Web server. If the secure Web publishing rule is configured to forward the request using Secure HTTP (HTTPS), ISA Server initiates a new SSL connection with the published server. Because the ISA Server computer is now an SSL client, it requires that the published Web server responds with a server-side certificate.

Adding a second part to the question, are these justification for purchasing a second server, licensing, setup, troubleshooting, etc. How have you done this in your environment, especially in small (<200 users) environments?

exchange

3 Answers

  1. Best Answer

    The main advantage in using ISA Server as a reverse proxy is for security, but of course it makes a lot more sense if you have more than a single application to publish; if you only need to make your Exchange CAS server(s) available from the outside, maybe buying, implementing and managing ISA is a bit overkill.

    Using ISA, instead of plainly forwarding TCP port 443, offers the following advantages:

    • Pre-authentication. Users can be authenticated by ISA Server itself, and then the request will be forwarded to the actual published server only if this authentication succeds; this blocks unauthenticated users from even trying to tamper with your web application, saving you f.e. from possible bugs in the application logon.
    • HTTP filtering. Standard HTTPS connections flow through a network firewall without being analyzed at all, because traffic is of course encrypted; with ISA, HTTPS connections are made from the client to the ISA proxy and then re-opened by ISA to the web server, allowing ISA to inspect and sanitize the actual HTTP traffic; this disallows "strange" requests to your published applications, saving you from a whole lot of application bugs (buffer overflows, etc.).
    • URL Filtering. If you open TCP port 80 and/or 443 to an internal web server, a client can ask the web server for anything it wants (domain, site, path, file, etc.); ISA Server can be configured to only accept certain URLs, so if you have a web server hosting multiple sites, or some internal-only web site, or some private storage area, etc., you can be sure only requests like "https://webmail.mydomain.com/owa" can reach it.
    • HTTPS Redirection. Ok, this is not a major issue, but, speaking of URLs, how many users forget to put that "s" after "HTTP"? You can automatically redirect HTTP traffic to HTTPS with ISA.
    • Load balancing. If you have more than one web server for the same application, ISA Server can load balance them as a single published web site, without need for hardware or software network load balancers; this load balancing also happens at the HTTP level instead of the TCP one, so it can better manage client sessions.
    • All other ISA Server features. Of course. But don't overlook them. You can configure your web publishing rules to only allow certain users, only at certain times, only from certain IP ranges, etc.; you also can publish many internal web servers on a single external IP address, etc.; there are lots of things you can do with ISA once you implement it, other than publishing an Exchange CAS server.
    • 2

  2. I personally stopped using ISA a little after 2004 edition came out. While the functionality and "ease" of the integration with MS products is a plus, an existing hardware firewall if configured correctly can be just as secure.

    I had found that ISA in the mix just added another layer of complexity and actually introduced a little bit of slowness as well.

    So my recommendations is to use a MIP (mapped IP) down to the CAS server for just those ports needed (80/443, etc.) for the roles.

    The argument I've heard is that having ISA there in the middle prevents people from trying to hack away at your CAS server, but if your CAS server is setup well and especially if you utilize the SCW for Windows on the CAS server after all is setup and running then you really won't have any more security to be concerned about then if you had ISA in the middle.

    Now...Dr. Shinder and others will disagree strongly and urge you to put an ISA box in, but what I find funny is that most people outside of "Windows Administrators" that are networking/firewall experts simply don't use them...that tells me something.

    • 1

  3. ISA is expensive to deploy and doesn't really make much sense if you're going to use it just strictly for inbound connections.

    It makes a lot of sense for caching 1000 user's outbound requests, especially for high volume pages like Google, MSN, portals, etc. But for inbound you can do just as well for much less cost.

    As TheCleaner mentioned, you can lock down your web server/CAS just fine, regardless of whether it's Windows or *nix.

    It's sensible to ask about the SSL though. Each SSL will need to have its own IP address - reason being that your edge device will not be able to decrypt any host headers, so you need to map any request coming in on your SSL IP to a specific IP address on the CAS so that the CAS will know which certificate to use.

    Basic summary: If you already have a good edge device, don't worry about it. If you don't, then something like pfSense won't take any longer to configure than ISA, has a much smaller footprint (can happily run in a VM with 128Mb of RAM), and you don't need to license Windows and pay an additional license for ISA.

    • 1