Microsoft Exchange: Fortify and secure your mail server!

So, I just (mostly) finished with writing a blog on how to setup a Postfix Reverse Mail Proxy that works as a SPAM filter for your Exchange Server. A blog I wrote before that was about network architecture that I feel any organization should be able to do, regardless of the size of the company. Those two blogs really had a lot to do with security at the perimeter of the network. I would like to continue working on securing email and increasing the security and reliability of your MS Exchange environment, while at the same time not impeding on usability or scalability.

In this blog we’ll look at securing and fortifying your Exchange Server. If you look at Microsoft’s website, and the people talking out on the “” site, you’ll hear people say asinine things like, “upon installation it’s already secure,” or, “Exchange server comes secure by default,” or something like that. I’m sorry, but any product that you purchase can be made more secure. If that weren’t the case, then why run “Windows Updates”, install patches, configure firewalls or setup SPAM filtering? I don’t care what product you’re talking about, there is ALWAYS something you can do in order to make things more secure.

There are many reasons for wanting to secure your Exchange infrastructure, but the main reason why is for availability. Many organizations rely on email as a backbone to their communications; especially small businesses. If your company lost email communications for even a day, how much productivity would be lost? How much credibility would be lost if outside senders couldn’t get their mail to your organization? But most of all, what if your Exchange server was used as a mass SPAM gateway that caused many other companies, partners or customers to be infected? The cost of cleaning up SPAM, junk, viruses, Malware, or in worst case scenario, a breach, could be in the tens or hundreds of thousands of dollars.

In this economy, no one can afford to go through something like that. It’s not even an option. So in this blog, it is my intention to show you how to effectively secure your Exchange Server(s), increase SPAM fighting ability, lock down users mailboxes, and I’ll do my best at providing some Power Shell Scripts to help out scripting a lot of these tasks. Most of all, I’m going to tell you that over time, this blog will grow to be pretty long. I don’t expect that this blog will just be a “set it and forget it” deal. Exchange administration is an ongoing effort, much like the hacking community. It’s constantly evolving with trying to minimize SPAM, decrease the frontage of your environment, while at the same time, allowing users to Sync with their phones, check web mail on the road, connect with MS Outlook and still receive the same level of service that they would expect from any other company. The last thing I want to hear is that something detailed and outlined on this blog caused an IT guy his job, or got him in trouble, because he implemented something that broke Exchange or caused an outage.

As for this blog, I want to set some barriers on what this blog IS, and IS NOT. If you’re looking for a Windows Server Hardening guide, you’re in the wrong spot. I’m currently working on a Windows Server hardening guide that will take existing MSBs, take the best of breed, and get them into GPOs and scripts that you can use on your Windows Server infrastructure. That blog can be found #here# when it is complete. Until then, what this blog is going to focus on will not be the OS layer. We’re looking at hardening Exchange, and Exchange only!


First thing we’re going to do is provide a brief overview of what’s going on with Exchange from a AD permissions standpoint. Most everything that Exchange does is based on Kerberos tickets, so my biggest suggestion is that you keep time on your domain extremely tightly. A hardware clock on a server can get out of sync pretty quickly, especially if the CMOS battery is going bad, so it’s best to make sure that your Exchange server and your domain controllers are all synced together by an external time source. Another good practice is to designate two (2) or more computers, preferably servers, to host an NTP service that is able to sync with the outside world at a reputable time source like NIST, Microsoft, or NASA. That server should be the only one that can communicate over port udp/123 to the outside world. Then you can allow all your servers, regardless of what network segment you put them in, to talk to your NTP server(s). Refer to my Network Architecture blog for what your forward facing DMZ should look like.

I’m going to skip going through setting up Exchange Roles. Reason being is that in smaller environments it’s really not feasible to delegate administrative access and give certain Admins a read only view, or that group of Admins Exchange Recipient Admins access, and so on. Even in larger companies, you may only have a small handful of Exchange Admins who all have full administration rights. So we wont get into those roles and permissions. It is possible to do that stuff, but at the end of the day, most companies these days do a pretty good job at vetting out who they give administrator rights to, there are signed agreements with those employees, and other mitigating controls. You’re going to have to trust your Exchange Admins. And if you don’t, you better trust your Backup Administrators.

You’ve probably noticed that Exchange 2010 permissions have even changed since prior editions. No longer are you setting up Exchange permissions inside the Exchange Management Console. You’ll be taking care of this stuff in Active Directory from now on due to Microsoft’s new security model. They’ve taken the approach of a true Role Based Access Control (RBAC) and they outline all of this information here at their site. The main permission that you’ll be concerned with is the Organization Management role. You can see that all the roles are in the “Microsoft Exchange Security Groups” OU in AD. See below:


Next thing to talk about is your Exchange Server, or at least the Physical- or VM-Server that you have Exchange running on. The underlying setup of this machine is very important to how Exchange will operate. If there are issues with the server getting DNS update mail will stop flowing, if the time is off your admins wont be able to administer the box, if there are errors or warnings in the event logs those need to be fixed, etc… It’s very important to monitor the event logs of your Server(s). While I am not blind to the fact that in the real world there are constantly issues arising on the network, but many issues can be minor issues if they aren’t let go to become large issues. The underlying theme here is to Harden Server 2008. Please go through that blog first, before venturing forward here.


Please go harden you Server 2008 Box before going forward


So now that your Server 2008 box is hardened, we can move on. To be honest, there really isn’t much to do on the Exchange side of the house. If you’ve gotten a SPAM filter sitting in front of your Exchange Servers, as I’ve outlined in my previous Postfix Mail Relay SPAM Filter blog, you’re already doing pretty well. There are many things that a front-end SPAM filter should be doing that Exchange shouldn’t. Exchange is a messaging platform. It’s really good at doing things like delivering email, working with Calendars, scheduling appointments, and keeping lines of communication open. From here on out it’s pretty much just controlling permissions to Exchange, between mailboxes and calendars, etc… There are other tasks such as Microsoft’s Security Configuration Wizard (SCW), granting users access to other mailboxes, creating conference rooms, Federation Services with other domains, ActiveSync controls, remote device wipe, internal and external receive connectors, and Exchange Certificates, that I’ll attempt to cover here.


One of the biggest things I hate to see is when you look at the message headers on an email from outside your organization. Hardly anyone updates the info on those things. I know it’s not really that much information, but you can easily divulge a few pretty important pieces of information from email message headers. The main two are your Internal Domain Name and your Internal IP Address space where your Exchange server lives. Especially in small companies, it’s extremely common to see that the server farm sits at either the top or the bottom of a /24 (like What I mean is, these small companies have less than 10 servers most of the time, so you know all of their internal systems are on the same subnet. We want to take those pieces of information out of the header. To do that is very easy, just two or three Exchange PowerShell commands.

The following command, according to Microsoft’s Social pages, “When you remotely connect to PoSh (enter-pssession, invoke-command), unless you specify otherwise, it loads the default PowerShell shell with no added modules. When you run the command from your Exchange 2010 server, you’re probably running the commands from the Exchange Management Shell (EMS) that preloads a bunch of cmdlets in the background — that’s how you get the tip-of-the-day and such.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ea SilentlyContinue


This command will disable ms-Exch-Send-Headers-Routing extended right, which in turn enabled the header firewall. Make sure to change “InternetConnectorName” to whatever your send connector is named.

Get-SendConnector –InternetConnectorName | Remove-ADPermission –User “NT AUTHORITY\ANONYMOUS LOGON”
–ExtendedRights ms-Exch-Send-Headers-Routing


Then to make sure that your settings are taken care of, push a synchronization to your edge servers like this:



After running your commands you can log into a Domain Controller (given that you have the available rights) and check this in the ASDI Editor. You can see that the send connector security has changed. To do this, run ADSI Edit from the Start Menu, then Administrative Tools, ASDI Editor. When that starts up, click on File, then “Connect to” and connect to the configuration naming context (the drop down menu in the center of the screen), as you can see below:

After you get to this point, Expand “Domain Root \ your domain\ Services \ Microsoft Exchange \ {your Exchange organization} \ Administrative Groups \ Exchange Administrative Group (FYDIBOHF23SPDLT) \ Routing Groups \ Exchange Routing Group (DWBGZMFD01QNBJR) \ Connections”. As seen below:

As you see here, you will find the send connectors in the center panel. To verify the security changes have taken effect, double-click on the connector that you are working on and then click the “Security” tab. verify that the “ANONYMOUS LOGON” user has no check boxes enabled except for “Special Permissions” as you can see below:


I don’t know why I am saying this, but I feel that it should be stated that Exchange shouldn’t be running on a Domain Controller. I know Microsoft ships Windows Small Business Server with Exchange and SQL and other technologies built into it, but that is the only exception I’ll be making here. There are many reasons for wanting to separate Exchange services from a domain controller, but I would say the main reasons are, separation of duties and that if your Exchange box gets popped, the attackers already own your DC. Separation of duties is simple; each server in your organization should only be hosting 1 service. We do that for a number of reasons, such as making troubleshooting easier. Also, don’t forget, your Exchange box hosts web mail for your organization. Do you want a website hosted off your DC that is publicly available to everyone on the Internet? I think not.


Another good tool to use is the Exchange Best Practices Analyzer. Pending how large your organization is, this can take a significant amount of time to complete, but the information you’ll get out of it is pretty useful. There are a few different areas you can test in there including, Performance, Permissions, Baseline and a Connectivity Test. I would suggest finding the time to run all of the scans.


Don’t forget to be constantly updating settings in your Exchange Spam Filtering, too. I know what you’re thinking. You’re probably thinking, “This dude just told me that we shouldn’t use the Exchange SPAM filter, that we should be using his Postfix Mail Relay instead.” And you would be right. You should use that. BUT! Everything in moderation, and security in layers. If you put all your faith in any one piece of technology, that’s bad. Like I said before, the day that you can buy one product that will secure everything, is the day that I’m out of a job.

First, if you haven’t already, you’ll have to enable some stuff. Let’s get the SPAM filter enabled.

 cd 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts'
Restart-Service MSExchangeTransport


Once that’s completed, we can tune the SPAM filter that is part of Exchange. You’ll find that in the Hub Transport area of the Organization Configuration in the EMC (seen below):


Make sure to go through all of those Features and set them up the way you want them to work. Some of this stuff overlaps the stuff in the Postfix Mail Relay, but if you aren’t using that go ahead and set them up here. The nice thing about setting up these options in the Exchange Server is that it’s scriptable. I mean, for all intensive purposes, it is scriptable in the Postfix Mail Relay too, but you have the ability to do that here too. Get a couple PowerShell cmdlets together and you can add stuff on the fly to this SPAM filter.

One nice thing here is that if you don’t want to tie your Postfix Mail Relay into Active Directory, you can block the messages here as well. What I mean by that is, Exchange will receive an email, check to see if the person exists in AD, and if they don’t it will block the message. The Postfix Mail Relay has the same capability, but with much more setup work to be done. This is just a simple checkbox, as seen below.


You’ll want to go through the settings in both the Exchange ActiveSync Mailbox Policies, as well as the Outlook Web App Mailbox Policies. There are many settings in there that


Another thing that should be obvious, but I’ll mention anyways, is that POP3 and IMAP should be disabled, and left disabled. There’s no need for that stuff. In Linux you can run DavMail for your local mail proxy, and in Windows and Mac you should be just running MS Office (with some version of Outlook). If you’re running an AD and Exchange environment, most of your users are probably using Outlook anyways, and they should be using Outlook 2007 or 2010 in order to get the most functionality out of Exchange. In all actuality, Even your Linux people really should have a Windows 7 VM running for Outlook, Visio and Office.


I’ll be going through and updating this as I have time… I’m burnt out on all this stuff, so check back periodically for updates!













VN:F [1.9.22_1171]
Rating: 1.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: -1 (from 1 vote)
Microsoft Exchange: Fortify and secure your mail server!, 1.0 out of 5 based on 1 rating
Tagged , , , , , , . Bookmark the permalink.

Comments are closed.