Exchange 2010 CAS in the DMZ

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Exchange 2010 CAS in the DMZ

L4 Transporter

Aside from being not supported by Microsoft, has anyone placed an Exchange 2010 CAS server in a DMZ? It looks like the reasoning behind it was because you'd have to punch so many holes in the firewall, it wasn't worth it. But since the PAN has a little more flexibility, I wouldn't think it would be a problem.

3 REPLIES 3

L3 Networker

I only had to create two rules, one was for port 25 and the other was for webmail.   I am using Exchange 2007 with all the Windows 2003 and Exchange 2007 updates.  Are there that may changes in 2010 compaired to 2007?

Now I did create a few more rules to stop all pop3 (printers trying to call home for someone set them up for pop3) and smtp traffic unless it comes from the Barrcuda Email and Spam firewall which only accepts mail for our Exchange CAS server.

L4 Transporter

umphmharding wrote:

Aside from being not supported by Microsoft, has anyone placed an Exchange 2010 CAS server in a DMZ? It looks like the reasoning behind it was because you'd have to punch so many holes in the firewall, it wasn't worth it. But since the PAN has a little more flexibility, I wouldn't think it would be a problem.

Hi.

We went through this entire scenario (and I'm not real happy with Microsoft's stupid reasoning behind not supporting a CAS in a DMZ), and it's difficult to make work.

The PA identifies *MOST* of the applications involved - activesync, ms-exchange, ms-netlogon, ms-ds-smb, kerberos, SSL, dns, LDAP, ping & msrpc are the commonest ones, there *are* some "unknown tcp" transactions, and even worse some "incomplete" transactions reported - which makes it hard to setup decently.

That's metric buttload of applications to put in a security policy and still not catch 'em all. The "unknown" and "incomplete" sessions are a worry because they seem to be on random, varied ports, which makes it worse to try and write an application override to catch them.

I've ended up putting in a temporary "allow all" from the CAS server to the DC's and MBX server inside, but I'll be switching to the M$ "recommended" method of inbound NAT for Activesync and ssl/web browsing and moving the CAS inside.

I'll also have to put in a a U-Turn NAT for Activesync devices which access from inside - because the DNS record for our Activesync server returns a public IP address in my DMZ and, guess what, it's the one I NAT from the outside to inside - it doesn't physically exist in the DMZ.

I'm not reaql happy about it from a security point of view - I *shudder* at letting NAT'd traffic originated from outside back in, but Microsoft's "alternative" of putting in an IAS (sorry, "Threat Detection Server") is even worse - put in a server with two NIC's, one in the DMZ and one inside, so you can just concentrate on compromising the IAS server and then have full access to the inside network - so there's not much other option.

My choice would be to tell Microsoft to take Exchange and show it firmly where the sun doesn't shine, then put in a nice *nix based mail server, but unfortunately the executives don't agree with me, so I'm stuck with it.

Cheers.

Microsoft isn't the only one who makes HTTP application firewalls. You can even find dedicated hardware based appliances. F5's ASM actually includes prebuilt modules for OWA so deployment is pretty easy.

  • 3106 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!