Microsoft Exchange and Blackberry Server Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Mentioned in EE Newsletter Again

Yet another mention in the Experts Exchange Newsletter. This is starting to get embarrassing.
See the original here: http://www.ee-stuff.com/Newsletter/022806newsletter.htm
However here is the quote:
Kudos: There aren't enough superlatives to describe what Sembee has accomplished since he joined EE a little over two years ago. First he makes Rookie of the Year, and follows that up as Expert of the Year. Then he becomes the first EE member to crack the 7,000,000 point level; 5.8 million of those points -- more than all but five members have in total are in the Exchange Server topic area. It's a race to see whether he or objects will be the first to reach 6,000,000 in a single topic area.

Why you shouldn't put Exchange 2003 in a DMZ

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.

New Articles on amset.info

A couple of new bits and pieces for my technical web site amset.info

The articles on working with Distribution lists have been grouped together and can be found here:
http://www.amset.info/exchange/groups.asp

This was caused by the publication of three new articles...
Creating a moderated distribution group:
http://www.amset.info/exchange/groups-moderated.asp
How to make your distribution lists appear at the top of the Global Address List (which is actually quite old, but was buried on another page)
http://www.amset.info/exchange/groups-top.asp
And how to hide the membership of a group, or even the existence of a group from the GAL. http://www.amset.info/exchange/groups-hidemembers.asp

Elsewhere, two pages have been added to the Pocket PC section, which may be of interest to Exchange Server administrators.
Working with SSL Certificates deals with getting SSL certificates on the handheld devices. If you are deploying OMA or Exchange Active Sync then this could be of interest to you.
http://www.amset.info/pocketpc/certificates.asp
Using the Windows Mobile 5.0 Emulator could also be of interest as it lets you simulate what the users are doing with their devices can aid support of those devices by your support team.
http://www.amset.info/pocketpc/wm5emulator.asp

Many of the articles on the web site are reviewed frequently, as I update the techniques or correct errors, so please check back often!

Blogging

Well I thought it might be time to join the ranks of the bloggers.
Not going to bore you with personal stuff though... this will be a technical blog.

Who am I?
Simon Butler, aka Sembee. At the time of writing (early February 2006) I was the lead expert on Experts Exchange with in excess of 7 million points. I have over 5 million in the Exchange Server topic area alone.
Expert of the year and most answered questions on that site in 2005. In 2004 I was Rookie of the year. I reached the top of the tree in less than two years, only actively posting for just a little over 18 months.
You will also see me contributing to other forums and email lists, mainly on Exchange server topics.
I was awarded the MVP status in Microsoft Exchange server in April 2005.

The Blog?
You will probably find opinion pieces and technical snippets that aren't really suitable for the main web site at amset.info.

For the technical howtos you should still look at http://www.amset.info/ and if you want to hire me to work on your Exchange project (UK only though) then you need to go to http://www.amset.co.uk/

Comments and ratings are currently turned off while I get to grips with these things. If you want to ask me a question about Microsoft Exchange server and you aren't a client, then put it on one of the forums or email lists where it will be picked up. Business proposals need to go through Amset (see above).