Exchange and malware protection

Reading Time: 4 minutes

This blog post is something I intended to write for a while now, because it is a question that i get asked a lot. On which Exchange server roles do you need to install the Exchange malware protection software, be it the now no longer for sale Forefront Protection for Exchange or similar products from McAfee, Symantec or GFI and the like.

Why is this IMHO a valid question? Well, if we ignore the Microsoft recommendation to install multi-role servers (meaning the CAS, Hub Transport and Mailbox Server roles), you can take benefit of not needing to install the malware protection software on all servers when it has no or little benefit. Note that I mean Exchange malware protection, I do not mean the file-access server protection. Let's go over the specific Exchange 2007 and 2010 roles:

Client Access Server

On this server there is no mail flow and there are no databases present. In this case no malware protection is necessary or even useful. It only handles client protocols and none of them are scanned by Exchange aware solutions, that I know of.

Hub Transport Server

This server handles all mail routing. Obviously incoming external mail does need malware scanning, so when this server is directly connected to the internet and receives not previously scanned mail, I normally would install a solution on this server role. Even mail from one mailbox to another in the same organization or even the same mailbox database is transported through this role. So, if an user is mailing an infected attachment to a coworker, it should be quarantined or cleaned. Everything that is transported can or will be scanned by your malware protection on the Hub Transport server.

You could however choose to not use on-premises scanning, if you use an Exchange Edge Transport server with malware protection or if you use cloud malware protection such as Forefront Online Protection for Exchange (FOPE), recently renamed Exchange Online Protection (EOP). These vendors generally have very good cleaning ratio and it lowers the load on your administration. Another option is to use on-premises appliances that are your first entry point for SMTP traffic before entering your Exchange Organization.

Mailbox Role Server

This is a tricky one. As said, all mail transported can be scanned via the Hub Transport server. If you have such protection, you could dispense of scanning this role as most infectious malware is received via external mail. But there are cases that an infected mail could end up in a mailbox and thus the mailbox database. A user sends an infected mail to a coworker or to the outside, the recipient does not receive it as it is filtered by the Hub Transport server. However, the mail is already saved in the Sent Items folder of his/her mailbox. With an infected attachment… The same is for writing a mail with an infected attachment and save it as an draft. Again the Hub transport does not get to scan this message and the message will reside in the mailbox database, unless the user or admin deletes this manually.

The only automatic way to get rid of these malicious mails is to do a real-time or regular database scan, which costs server resources especially with real-time scanning. I do not know of any confirmed cases that an Exchange server got infected by infected mail in the mailbox database (or Public Database for that matter). Because of that I feel that it is safe to say that the computers that are at real risk are client computers (or devices). You could argue that these computers are possibly already infected, because how could it allow an infected file to be uploaded? If so, the risk of infection of the client computer is 0% as it probably already is infected. Other client computers (used by the same user with the same mailbox) should be protected by their own virus scanner (perhaps with additional protection via Network Access Protection, NAP), but if this is a risk you are not willing to take you should implement a Exchange malware protection layer on the mailbox server role. But consider that when you have protected the mail flow and all clients, this risk possibly doesn't outweigh the extra cost in resources (IOPS, Memory, software licenses etc.).

If you need as close to 100% protection, you should implement a mailbox role solution. And having said that, consider that sometimes mail does not always origin from clients or via SMTP, but a cross-forest, platform etc. migration could bypass SMTP. In this case, mail (probably) does not get filtered before it is put in your Exchange organization and the only way to filter malware is to scan the databases. You could use a pre-staging Exchange server, a dedicated Exchange server with malware protection that scans all migrated mailboxes. It would clean mail before you move mailboxes to your production environment mailbox servers, which perhaps don't have mailbox server protection. But that is added complexity.

Now note that I'm not advocating the absence of malware protection, but I did want to make an overview of choices one perhaps has to make when (financial) resources are limited or even just to clarify a bit about malware protection in Exchange 2007 & 2010. I hope it helps with your design choices.

To summarize: mail flow should always be protected on-premises or via the cloud with installation on the Hub Transport server has the best change to catch malware in most thinkable scenarios, scanning mailbox database servers is probably less effective but should be done when the highest form of security is required and the loss of resources is acceptable and incorporated in your design.

Exchange 2013 has a changed infrastructure with less roles, no VSAPI on which malware protection suites can latch on and already has a built-in malware scanning module. This is so different and new, that will probably warrant a blog post on it's own. Winking smile

If you have a different opinion or flat out disagree with me, feel free to leave comments!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.