Protect E-Mail with Forefront Security
At a Glance:
- Installing and configuring Forefront Security for Exchange Server
- Multiple scanning engines and scanning policies
- Fighting spam with connection and content filtering
- Configuring and managing FSE using Windows PowerShell
Show Me the Results
The next generation release of Forefront Security for Exchange Server (from here on referred to as FSE) is a premium antimalware (antispam, antivirus, and content filtering) product for protecting e-mail that flows through Exchange server environments. It is integrated with Exchange Server and can scan all e-mail messages that are in transit (moving in, out, or within the enterprise), in use (being read), or at rest (stored in the user's mailbox). The product ships with a default configuration to allow immediate use after installation but can be modified to meet the exact needs of the enterprise.
More information, case studies, and an evaluation version of the product will be available from the Microsoft Forefront Server Security TechCenter after FSE is released later this year.
In this article, I will walk through the features of FSE. I will assume you are familiar with Exchange Server 2007 and look only at the security and content filtering capabilities of FSE installed on the local Exchange Server. I will discuss how you can protect your enterprise from unwanted spam and malware, as well as how to restrict content in your enterprise e-mail using various types of filtering. To navigate through all that technical content, I will use the new simplified management experience for FSE, which is integrated with the upcoming Microsoft Forefront (codename "Stirling") management server. I will not, however, cover Stirling or FSE integration with it.
If you already have Exchange Server set up for your organization, installing FSE is simple. You install the product on the same machine as the Exchange Server; FSE supports the Exchange Edge Transport, Exchange Hub Transport, and Exchange Mailbox server roles. FSE seamlessly plugs into the Exchange environment using the publicly accessible agent architecture and virus scanning API ( VSAPI ). Once installed, the security and filtering policies can be edited via the Forefront Server Security Administrator console, shown in Figure 1. The Navigation pane on the left lets you move to a particular area of the UI to view or edit. The Details pane in the middle displays the configuration information, and the Actions pane on the right is used for executing actions.
Figure 1 The Forefront Server Security Administrator console
Let's look at the Antimalware settings (on the left in Figure 1). In this example, the Antimalware node has three subnodes that can be used to configure the security settings for e-mail at different points:
Mailbox Realtime These settings are for e-mail in use (as it is read). This section is disabled when the local Exchange Server that FSE is installed on is not the Mailbox role. It has been a design assumption for these settings that e-mail is always scanned on its way to the Mailbox, (in transit) using the Hub Transport or the Edge Transport scan settings. But the Mailbox Realtime scan is useful when there is a large lag between the time the e-mail comes into the system and the time the e-mail is read. Since FSE scans malware using AV signatures and heuristics built into the engines, updated engines and updated signatures can make a significant difference in what malware is caught
Hub Transport This section is used for configuring the settings for e-mail in transit (inbound, outbound, and internal). You will see this section only when the underlying local Exchange server has the Hub Transport role deployed. Some enterprises make a decision to forgo the Edge server role and deploy the Hub server role only. Starting with Exchange 2007, all e-mail (inbound, outbound, and internal) is routed through a Hub server. Enterprises that deploy only a Hub server can set all the security settings for e-mail in transit in the Hub Transport section of the Administrator console. Enterprises that deploy both Edge and Hub servers can choose to not rescan e-mail when it gets to the Hub server after passing through the Edge server.
Mailbox Scheduled These are malware security settings for e-mail at rest (e-mail received previously and stored in the user's mailbox). This section is visible only when the local Exchange Server is the Mailbox role. This scan is useful for catching any malware that has slipped through the scans for in-transit mail, as well as for measuring the effectiveness of proposed keyword filter policies. For example, suppose the fictional enterprise Contoso introduces a new policy that prohibits profanity in e-mail. They aren't sure, however, whether this policy is really needed or whether it will be effective. To measure the effectiveness of the policy, the company sets up a keyword filter with FSE and runs a Mailbox Scheduled scan. Then, using this scan, the IT admin scans the e-mail in a few (or many, or all) selected users' mailboxes and generates a report of all the e-mail that would have been in violation of this policy if it was implemented. With this data in hand, Contoso can make a more informed decision regarding the keyword filtering policies for its organization.
Note that there's no Edge Transport node in Figure 1. The Edge Transport section, for configuring the antimalware settings for e-mail in transit (inbound and outbound), is only available when the underlying local Exchange server is the Edge Transport role. In the example in Figure 1, the underlying Exchange server is the Hub Transport role and Mailbox role so the Edge Transport settings are not available. The Exchange Edge role is primarily deployed in the DMZ and used for e-mail hygiene; it is recommended that the security settings be set to the max on this role.
Forefront Security for Exchange uses multiple antimalware engines to find viruses, worms, and spyware. Some engines are signature-based while others have heuristic capabilities. A common request from customers is for guidance on selecting which engines to run for the best detection and performance. With new pre-set options, FSE now makes the process much simpler while also maintaining all the previously available advanced settings for customers who want a higher level of control. You can choose one of the engine-selection policies based on your security vs. performance needs—and all the other engine management settings are automatically decided. Figure 2 describes the different types of scans that the Intelligent Engine Selection section makes available.
|Figure 2 The different scanning policy offerings|
|Always scan with all selected engines||This is the most secure setting. When this is selected, FSE will scan all e-mail with all the engines that are part of the product. In the likely case that any of the engines or signatures for the engines are updating, FSE will block all e-mail until the updates have finished and FSE is able to use the new engine or signature.|
|Scan with the subset of selected engines that are available||This setting is slightly less secure. When this is chosen, FSE will scan all e-mail with all engines that are currently available. If all selected engines are available, the e-mail will be scanned by all of them. However, if one of the selected engines is being updated, e-mail will be scanned with the remaining engines and allowed to pass through if determined to be free of malware.|
|Scan with a dynamically chosen subset of the selected engines||This setting balances between performance and security. A subset of engines will be selected by FSE to scan the e-mail. Choose this setting when you want some extra protection and the value of using multiple engines, but need to take performance into consideration.|
|Scan with only one of the selected engines||This setting should be picked only when performance is critical and the e-mail has been previously scanned. With this choice, FSE will dynamically select one engine to scan the e-mail.|
Enterprises that need precise control over which engines are used for scanning can use the Advanced Engine Management setting at the bottom of the policy page.
Spam continues to be one of the most egregious resource taxes for enterprises in terms of e-mail. A disproportionately large number of e-mails received by most enterprises are spam. FSE offers a new premium antispam solution that takes a two-pronged approach—filtering based on both connection and content.
Connection Filtering Before e-mail gets into the enterprise, FSE can make a reputation assessment based on the IP address of the sender. If the IP address is marked as a known spam sender, the connection is refused and the e-mail never enters the enterprise. The reputation-based assessment is supported by an online service that Microsoft maintains. FSE also recognizes that IT and messaging administrators need to be able to overwrite the reputation assessments that FSE makes, so it provides an IP Allow List and an IP Block List. Any IP address on the IP Allow List will not be assessed and will actually be passed straight to the recipient's Inbox. Any e-mail connections from IP addresses on the IP Block List will be rejected without any reputation analysis. Figure 3 shows the Protection Settings for FSE's connection-based antispam filtering.
Figure 3 Antispam connection fi ltering
Content Filtering After the e-mail goes through the FSE Connection Filtering, it gets a second-level spam evaluation based on the content of the e-mail. FSE integrates an industry-leading third-party antispam engine. When content filtering is enabled, FSE assigns a Spam Confidence Level to each e-mail message it scans. Based on the spam confidence level, enterprises can decide to delete the e-mail, quarantine it, or just mark it and deliver it to the user's mailbox where it will end up in the Junk Mail folder.
There are several types of content filters that can be specified via the FSE administrative console. Figure 4 shows what you would see when specifying the file filter policy, which lets enterprises block e-mails with a specific file type. FSE will detect the file type based on binary inspection rather than the filename to avoid danger if a file extension has been changed. Thus, if the enterprise sets a policy for not sharing executables through e-mail, FSE can block executables—even if the sender attempts to bypass detection by changing the name of the file to something like NotExecutable.txt. In addition to file type filtering, FSE can also block files based on the name of the file or a combination of both.
Figure 4 Configuring the file filter
Show Me the Results
Once your settings are configured, FSE will work in the background. The Monitoring section of the Navigation pane can be used to see everything that has been going on with FSE. The Incident pane (Figure 5) lists of all the security incidents and filtering policy matches. There is also a Quarantine pane that shows all the e-mail quarantined by FSE. You can use this pane not only to see which e-mail was blocked but also to deliver e-mail that was previously quarantined.
Figure 5 Displaying security incidents
FSE implements a new, extensive Windows PowerShell layer. All configuration settings, reports, and other options accessible through the UI are also accessible through this layer. The FSE PowershellSnapIn is available from the Forefront Management Shell. You can view the commands available for FSE by typing
One of the most useful aspects of using Windows PowerShell it that the commands make it easy to establish the configuration settings for FSE on one server and then transfer them to any other server. After configuring one server, you can export the settings using the Export-FSESettings command, then import to another server using the Import-FSESettings.
This article introduces some of the capabilities of the next generation Forefront Security for Exchange Server. With multiple scanning engines and filtering capabilities, the product protects e-mail while allowing you to take performance into consideration. You can also handle configuration and management as you prefer, using either the administration console or Windows PowerShell. I hope this article encourages you to evaluate FSE for yourself.
Neetu Rajpal is the Group Program Manager for the Forefront Sever Security team based in Hauppauge, NY. She has been a software professional for over 13 years and loves building cool software. She spent the early part of her career on all things XML and now works on server-based security software.