If you are looking for a page on how to put Exchange in to a DMZ, then you have come to the wrong place. This isn't it.
Also I am not posting about deploying Exchange in a secure way - at least not in this post. It just covers Exchange in a DMZ.
I don't deploy Exchange in to a DMZ, never have done, never will do. I discourage anyone who asks about it from doing so.
Yet Exchange in a DMZ is one of the most hotly debated subjects in the Exchange community.
The main "reason" that people want to put an Exchange server in to the DMZ is in the belief that it will increase the security of their network.
However ask yourself this - how does it increase your security? What does putting a member of your production domain in to the DMZ do to increase the security of your production network?
Answer those question with valid reasons, then go ahead and configure Exchange that way. As yet, no one can give me a valid answer to those questions.
Lets look at the reasons why it is a bad idea.
Exchange has to be installed on a domain member. It cannot be installed on a workgroup machine.
Therefore for a member of the domain to work correctly it needs to contact the domain controllers. This means opening ports on your firewall to allow that traffic through.
Furthermore, the Exchange server will talk to any of your domain controllers, and it is good practise not to limit the domain member to talking to just one domain controller. However as you have to allow certain ports through, you will need to change the rules on the firewall to allow the DMZ to talk to a range of IP addresses - even if you subnet it down.
Disabling of Dynamic Ports
Exchange does a lot of communications through dynamic ports. These ports are constantly changing. However to go through a firewall you need to stop it from doing that so that you can open certain ports. That means static ports - which actually reduces the security of your Exchange environment overall.
The change in the port allocation has to be made to all of your Exchange servers - because the front-end machine in the DMZ could talk to any of them. Plus the port has to be opened to all of those servers - making the rules very complex.
Front-end server gets compromised and the attacker walks straight in
As you have changed to static ports and opened the firewall to the the domain controllers, once the machine in the DMZ has been compromised the attacker can walk straight in to your domain controllers. The don't even have to go looking for them. In fact, if they get on to the Exchange server, then they are in already. Exchange will install a copy of Active Directory Users and Computers which the attacker can use to change the password of the administrator account and then has full access.
A Traditional DMZ should be somewhere where you place machines and resources that are expendable
A DMZ exposes machines to the Internet. It is supposed to be a buffer between the production network and the internet. With a domain member in there, it is simply an extension of your production network.
You should be prepared to remove a machine that is in the DMZ with a moments notice. With a domain member and/or an Exchange server you cannot do that. While you can remove an Exchange server instantly, it leaves a mess behind that can take a while to clean up.
A good firewall administrator wants the least number of ports open to the production network.
Having worked with financial institutions, showing them the list of ports that need to be open between an Exchange server on production and one in the DMZ usually means they give up on the idea.
This is the list of ports that need to be open between the frontend server and the production domain to allow all features of Exchange to work. The actual list required can vary from site to site, depending on the features deployed.
- SMTP: 25
- LDAP (DC lookup): 389
- LDAP (GC lookup): 3268
- NetBIOS (ports): 135, 139, 1024+ (default config is usually 6000 something).
- DNS: 53
- RPC: 111, 135, 1024+
- Netlogon: 445
- Kerberos: 88
- OWA: 80 (HTTP), 443 (HTTPS)
- IMAP4: 143, 993 (with SSL) SSL
- POP3:110 995 (with SSL)
The NETBIOS ports (125, 139 etc and 445) are the ones that usually scare the firewall administrators the most as those are frequent targets and the NETBIOS traffic shouldn't be passing over a firewall.
Put all domain members inside the production network and open only the ports that you need to. In many cases this can be two - 25 (SMTP) and 443 (HTTPS).
My company has a policy of no machines on the internal network having direct connection to the Internet.
Valid point and a policy that is to be applauded. However this doesn't make a good reason to put Exchange in the DMZ.
Instead, put an ISA Server in the DMZ, on a machine that is part of a workgroup and publish what you need to through that. Once the machine has been completed, clone it so that if the machine gets compromised you can take down the original, restore the clone, fix the security hole and redeploy (after taking a fresh image). As it is a workgroup machine, there will be no problems with domain membership.
Update 7th March 2006: msexchange.org have just published an article on using ISA and Exchange:
Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 1)
Microsoft have supplied instructions on how to deploy Exchange in a DMZ.
Not really a valid argument. You could probably ask a car manufacturer to give you instructions on how to drive a car off a cliff. They can provide them to - but whether it is a good idea or not is down to you.
Hopefully this posting has given you an idea on why putting Exchange in to a DMZ is a bad idea, and will help you make your own decision when deploying Exchange in a secure way.
