Why you shouldn’t put an Exchange Server in the DMZ

3 08 2009

The official Microsoft documentation for Exchange Server is contradictory in terms of deploying an Exchange Server into your perimeter network (DMZ). In many cases, it is interpreted that placing an Exchange Server into this zone is a good idea.

This is a myth.

As a standard rule of managing your network, you should never place any machine joined to the domain into the DMZ. Exchange 2000, 2003 and 2007 (with the exception of the Edge Transport role – see below) must all be installed on machines joined to the domain – place them into the DMZ and you break the first rule of firewalls and Active Directory, which I mentioned above.

So why is this a bad idea?

An Exchange Server needs Active Directory to function because most of its configuration information is stored in the directory service. This is the reason why it must be deployed on a domain-joined server.

If you attempt to move an Exchange Server to the DMZ, you will quickly find that Exchange will break. This is because it loses the ability to find and communicate with the Domain Controllers on the private network. In situations like this, you would have to do one of two things:

  • Deploy an additional Domain Controller into the DMZ
  • Allow the Exchange Server access to the DCs on the private network

Completing either of the above tasks requires you to open ports between the DMZ and private network. The list of ports is extensive and includes sensitive services such as DNS, LDAP and NetBIOS. I heard a fellow Exchange Server MVP state the other day while referring to this list of ports: “open these ports and your firewall rules will look like Swiss Cheese”.

The bottom line is this defeats the principle of a DMZ. A DMZ is intended as a ‘safe’ location for machines which are not joined to the domain; you might put public web servers or public nameservers there, for example. In the DMZ, they are protected from the Internet, but anyone maliciously gaining access to those servers cannot cross the firewall into your private network. By opening the Active Directory ports I describe above and by placing a domain-joined machine in this insecure zone, any hacker in control of a compromised machine in the DMZ has a much easier route to access your Active Directory environment, perhaps bringing it to its knees.

Every Exchange MVP I know considers this to be a very, very bad idea. They would not configure an Exchange Server in this way and neither would I.

Any Exchange Server you deploy should always be on the private network. Located there, you can ensure it has access to the Domain Controllers without the need to compromise network security. From the outside, you only ever need ports 25 and 443 open to allow internal email to flow and for users to access Outlook Web Access and Exchange ActiveSync.

But what about Exchange 2000/2003 Front End Servers?

What about them? Again, it is a misconception – probably brought about by ambiguous documentation – that leads people to believe these servers are there for security reasons. They are not. Legacy Front-End Servers are designed for organisations with multiple mailbox servers. A front-end acts as a central connection point for access to OWA, OMA or ActiveSync under a single, common URL – it does not provide security.

If you are deploying a front-end server because you believe it will secure your Exchange environment, think again. Install Vamsoft ORF on a Virtual Machine or use an external spam filtering service as an alternative.

Exchange 2007 Edge Transport

With Exchange 2007, Microsoft have recognised this problem by adding the Edge Transport server role. This is the first time an Exchange Server role has been specifically designed to be located on the perimeter network. It is also the first time such a role exists for security reasons. The Edge Transport machine is designed to be on a workgroup – not a member of the domain – so it does not require sensitive ports to be opened between the DMZ and private network. It maintains its own copy of the Active Directory database using Active Directory Application Mode (ADAM) in Server 2003 or Active Directory Light-Weight Directory Services (AD LDS) in Server 2008.

I personally do not see a requirement for an Edge Transport server in an Exchange deployment, so I never deploy them. They are an unnecessary expenditure. Unlike a 2000/2003 front-end, they only process SMTP email traffic. Requests for OWA or Exchange Activesync still need to be made directly to the Client Access Servers (CAS), which are domain members and therefore still need to be located on the private network.

The minimal security advantage Edge Transport servers provide can easily be achieved directly on the Hub Transport servers – or by deploying a much cheaper Vamsoft ORF virtual server between the Internet and the Hub Transport server.

Conclusion

You should now have a better understanding of why an Exchange Server should not be deployed into the DMZ. I hope this prompts you to review your Exchange configuration and make appropriate changes to further improve your network security.

Illegal breakage found in headernever
Advertisements

Actions

Information

11 responses

3 08 2009
Jake

Good Points! It is also good to know that if you have multiple IP’s assigned to your router you will have to add Route-Maps, since some SPAM Filters require you to have the same source and destination IP Addresses for your SMTP Server.

3 08 2009
tigermatt

Thanks for pointing that out Jake!

Matt

6 08 2009
papandut

I also don’t use edge server. I use other smtp gateway server (also as anti spam) in dmz that only use smtp connection to the hub transport server.

16 08 2009
Shawn Harry

Great blog post. Iv been saying this for years and years that FE servers add zero resilience and are an extra cost that generally unless theirs a clustered or load balanced BE are pointless. In addition placing a domain member in a DMZ?!?!??! I know so many exchange admins that think this is a safe practice and never take a step back to realise one minute im opening a bunch of ports on my firewall just to allow connectivity!?!? How on earth could that ever be secure!!

15 05 2011
James

Great information. Before reading this article I felt the same way you do. But you explain it so well that it fills in the gaps.

14 06 2011
itnewbee

By sticking with ur statement and by placing the exchange server inside the network. One way to access will be by using vpn and connecting to the inside network. Suppose i want to access the mail from the outside world. I mean by using a web browser on any pc in the internet from outside the office. I am a newbee and im trying to think of providing access to email from outside n/w. If an user is able to gain access to the exchange server then he will gain access to the local domain. still not sure where to place the exchange

11 08 2011
Andrea Wilcinski

Thanks for taking the time to discuss this, I feel strongly about it and enjoy studying more on this topic. If possible, as you acquire expertise, would you consider updating your blog with more news? This can be very helpful.

22 09 2011
exchangewizard99

I just wanted to comment on this article.

first, placing your exchange server in a DMZ by nature of its design is far more secure than leaving on your LAN. here is why.

a DMZ is nothing more than a double firewalled network which will always provide you better protection than a single firewalled)
WAN–>DMZ allow smtp, https
DMZ–>LAN allow ldaps, DNS, other various NT Domain login services.

the only attack point from the internet is through SMTP/https which is the same attack point you would have if you publish your exchange server from WAN–>LAN ( which most people do anyway)

if the box is compromised, its compromised, and in both scenarious ( LAN or DMZ deployment) it would allow an attacker access to your AD.

but what the DMZ provides than simple LAN deployments do not ,is protection from internal threats, ie infected PC’s on the LAN which are far more dangerous and vulnerable.
so if the server is in the DMZ, it is firewalled from your LAN as well as the WAN. whether or not your firewall rules look like swiss cheese or not is irelevant, those rules are there to protect your servers.

Most current firewalls allow custom rules to control source and destination traffic, so you are not simply opening ports to your LAN,
you are allowing specified traffic to and from pre defined network objects, there is a big difference. open ports are no doubt dangerous,
but there is no reason to do such a thing.

so if you are like most SMB’s and have one maybe 2 exhange servers and you publish a rule on your firewall to allow SMTP/HTTPS to your exchange server and think that is safe, you need to think again.
reverse proxies ( ISA among some) and mail exchangers can provide enhanced security but in no way does it protect your exchange server or your AD or any other computer on your LAN. if that exchange box is comprised, it can “see” everything on your network and attack everything on your network . If your exchange is in a DMZ at least if its compromised, it cannot use NON Exchange ports to attack your network. it can only use ports defined by your firewall ( smtp/https/DNS ). an Intrusion prevention appliance can further protect this traffic by inspecting it for threats.

while you will never fully protect any server , besides cutting it off from the internet altogether, do yourselves a favour and put your critical servers in a DMZ ( exchange/SQL/AD

19 10 2011
Anonymous

exchangewizard99,

How long have you worked with Exchange? SQL? AD?

Most of the comments you have posted above actually go against your arguement.

The point is that if Exchange is in a DMZ you have a domain member in the DMZ, you then have to FIX the ports Exchange uses for client operations for internal use (as outlook uses random ports) making it less secure.

Exchange installs by default Active Directory Users and Computers and in later versions the ADMT toolkit. This means if you have it in your DMZ it is LESS SAFE than it is on your internal network, because you don’t actually have to breach the boundary of the firewall to get access to the Active Directory.

Active Directory, other than ADLDS where ET role is concerned, should NEVER be placed in a DMZ if it is a part of your production network. There may be reasons why you may have a completely seperate domain in your DMZ, but never a DC from your production network.

I have worked with Exchange for over 15 years and have never, and would never place an Exchange Server other than an Edge Transport server in the DMZ.

Even Microsoft don’t recommend it, they used to, but then they re-visited their recommendations and it is now an unsupported configuration.

Publishing port 443 (and possibly 25) to an internal server is far safer than opening ports for GC, DC, RPC & DNS lookups. And is completely unnecessary.

demazter

18 09 2012
Benjamin

“placing your exchange server in a DMZ by nature of its design is far more secure than leaving on your LAN. here is why.

a DMZ is nothing more than a double firewalled network which will always provide you better protection than a single firewalled)
WAN–>DMZ allow smtp, https
DMZ–>LAN allow ldaps, DNS, other various NT Domain login services.

the only attack point from the internet is through SMTP/https which is the same attack point you would have if you publish your exchange server from WAN–>LAN ( which most people do anyway)

if the box is compromised, its compromised, and in both scenarious ( LAN or DMZ deployment) it would allow an attacker access to your AD.”

There really is no arguing with the above logic. No matter what – the exchange server has to be compromised via the ports allowed from the WAN zone.

As I see it, the root problem lies in the design of exchange server itself…

The security risks created by the dependency upon Active Directory in an email server (which should always be in the DMZ) is the actual problem. In this design, Microsoft has created (yet another) security problem by forcing people to place servers that should be in a DMZ into their LAN zone. But don’t worry….they’ve never actually had a security vulnerability…. *facepalm*

15 10 2012
Admin

Hi i think, the author as well as exchangewizard99 are partially right.

The function of DMZ is to secure the servers, which must be available from wan (smtp, https), from outside and if the dmz-servers are compromised, to secure the lan from dmz and outside.

In addition, the dmz secures partially the dmz-servers from inside, but thats not the main function. This can also do an host-based firewall on the servers in the inside lan.

Servers in the inside lan have NOT to be available from outside. NEVER.

So in my opinion, the exchange server has to be in the inside lan.
The smtp traffic from and to the exchange server is realized through an mailgateway in the dmz, forwarding smtp traffic.

To access the exchange server via html (outlook web access/ active sync) you have 2 possibilities.
1 and most secure: Access through SSL-VPN
2: Access through Reverse Proxy paired with a good IPS (intrusion prevention system)




%d bloggers like this: