Exchange Server and the Reverse Proxy - Part 2

In March this year I wrote a post entitled “Exchange Server and the Reverse Proxy”. I had many similar conversations with peers and customers about the topic, and at the time my intention was twofold:

  1. Question the ‘old school’ notion that Exchange services published to the internet are only secure if a reverse proxy is used;
  2. Provide a high-level list of potentially suitable solutions for customers planning new deployments who felt they still needed a reverse proxy.

I’ve received many comments and emails about that post and have been planning to put together this follow-up for some time now so it was a happy coincidence when the ever entertaining (and deceptively brilliant!) Greg Taylor recently posted about the same topic on the Exchange Team blog. I’m sure he won’t mind me ‘borrowing’ some of this content, it is not my intention to take anything out of context so feel free to read this entire post here. A couple of things that really stand out in his post are:

“Here are some interesting Exchange-related facts to help further cement the idea I’m eventually going to get to.

  1. We do not require traffic to be authenticated prior to hitting services in front of Exchange Online.
  2. We do not do any form of pre-authentication of services in front of our corporate, on-premises messaging deployments either.
  3. We have spent an awfully large amount of time as a company working on securing our code, writing secure code, testing our code for security, and understanding the threats that exist to our code. This is why we feel confident enough to do #1 and #2.
  4. We have come to learn that adding layers of security often adds little additional security, but certainly lots of complexity.
  5. We have invested in getting our policies right and monitoring our systems.”

“Do I think everyone should throw out that TMG box they have today and go firewall commando? No. not at all. I think they should evaluate what it does for them, and, if they need it going forward. If they do that, and decide they still want pre-auth, then find something that can do it, when the time to replace TMG comes.

You could consider it a sliding scale, of choice. Something like this perhaps;”

TMGScale

The recent release of Windows Server 2012 R2 Preview brings with it the new Web Application Proxy role. Web Application Proxy is a new Remote Access role service in Windows Server 2012 R2 Preview that provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy. My esteemed colleague Marc Terblanche has put together a couple of great posts on the Kloud Solutions blog about the Web Application Proxy role, check them out here:

I also wanted to post an update on the Apache/mod_proxy solution I mentioned in my previous post. Free time (aka lab time) has become somewhat limited lately so I haven’t been able iron out all the issues with the solution yet, but I recently came across an open source project that looks very promising. The guys at Vulture seem to have created exactly what I was trying to do in a much more elegant way. They’ve put together a web application firewall using open source components like Apache and mod_security and have even added a configuration web gui to it. Vulture does pre-authentication using a number of authentication providers and also provides other features like load balancing. I have not tested it myself (yet!) but if this interests you, check it out here: http://www.vultureproject.org/ – The documentation is in French but seems to translate reasonably well..