If you would like to read the other parts in this article series please go to:
- Hardening an Exchange Server 2003 Environment (Part 1)
- Hardening an Exchange Server 2003 Environment (Part 2)
- Hardening an Exchange Server 2003 Environment (Part 4)
Intelligent Message Filter (IMF)
Intelligent Message Filter (IMF) was introduced to the World in late 2004 as an add-in for Exchange Server 2003. Today this version is no longer supported, it was replaced by version 2 which is installed automatically with Exchange Server 2003 Service Pack 2 (SP2).
IMF is one of the mechanisms native to Exchange Server 2003 that can really help you reduce the amount of unsolicited commercial email (UCE) your Organization receives. Based on the characteristics of millions of messages, Intelligent Message Filter can accurately assess the probability that an incoming e-mail message is either a legitimate message or UCE.
Figure 1: Exchange server topology with Intelligent Message Filter enabled
Intelligent Message Filter is installed on Exchange bridgehead servers that accept incoming Internet e-mail messages to filter incoming e-mail messages.
Based on the probability that the message is UCE, IMF rates it with a property called a spam confidence level (SCL). This rating remains associated with the message when the message is sent to other Exchange servers.
An administrator sets two thresholds that determine how Intelligent Message Filter handles e-mail messages that have various SCL ratings: a gateway threshold with an associated action to take on messages greater than this threshold, and a mailbox store threshold. If a message has a rating that is greater than or equal to the gateway threshold, Intelligent Message Filter takes the action specified. If the message has a rating lower than the gateway threshold, the message is sent to the Exchange mailbox store of the recipient. At the Exchange mailbox store, if the message has a rating greater than the mailbox store threshold, the mailbox store delivers the message to the user’s Junk E-mail folder instead of to the Inbox.
On the client side, Microsoft Office Outlook 2003 and Microsoft Office Outlook Web Access for Exchange Server 2003 let users create a list of safe senders from whom they always want to accept e-mail messages and a list of blocked senders from whom they always want to reject e-mail messages.
Figure 2: Message flow with Intelligent Message Filter and Exchange filtering
If you want to know more about IMF, here are some additional links:
Filtering (Sender, Connection, Recipient)
IMF is a great anti-spam technology, but even before it existed, Exchange Server 2003 already had some native anti-spam mechanisms, namely:
- Connection filtering – Filters inbound messages by comparing their IP address against a block list provided by a third-party real-time block list service. You can also enter your own set of accepted/restricted IP addresses at a global level.
- Sender filtering – By default, SMTP connections that are created by senders on this list are dropped.
- Recipient filtering – Allows you to set global restrictions on mail to specific recipients.
When used together, these 3 filtering techniques can block a significant amount of spam at the perimeter of the organization, thereby reducing costs by rejecting messages at the earliest opportunity. Microsoft has an interesting paper, describing how they manage the large quantities of unwanted e-mail and malware-infected messages in its inbound Internet e-mail traffic: Messaging Hygiene at Microsoft. According to them, the use of these 3 filters blocks almost 95 percent of the incoming unwanted messages.
Figure 3: Spam filtering process used by Microsoft IT
By now you must be saying, “OK, you convinced me, where can I configure these fine filtering mechanisms?”. Wait no more, fellow reader, just open Exchange System Manager, navigate to the Global Setting of your Exchange Organization and right click Message Delivery. Select Properties and you’ll find the tabs with all the configuration options for Connection, Sender and Recipient Filtering.
Figure 4: Message Delivery Properties
One common mistake people tend to do is that they forget to activate the filters after configuring them. In order to do that, you must edit the properties of the SMTP Virtual Server, click Advanced on the General tab and then click Edit again. Difficult enough? Well, you only have to do it one time.
Figure 5: SMTP Virtual Server Properties
Anti Virus
Let’s face it, in today’s reality it’s impossible to live without virus protection on your mail servers. Currently, the primary vehicle for transmission of computer viruses is electronic mail. Most viruses propagate quickly through messaging systems because e-mail clients provide both sending capabilities and programmatic access to address information.
An essential aspect of protecting your messaging system against viruses is preparing an antivirus strategy. Your antivirus strategy should include educating users about viruses, installing antivirus software in the appropriate locations (at the firewall, at the Simple Mail Transfer Protocol (SMTP) gateway, at each Exchange server and client computers), and ensuring that the antivirus software is current. When selecting software, it is important to use antivirus software that has the ability to push updates, such as new signature files, to client computers and servers without user intervention, because such software reduces user responsibility and user error
Exchange Server does not provide built-in protection against viruses, but it does provide a framework for antivirus vendors to develop solutions for Exchange Server – Virus Scanning Application Programming Interface (VSAPI) 2.5.
One common method virus writers use to transport viruses is to include the virus in an attachment. To protect against such viruses, Outlook and Outlook Web Access provide the following attachment blocking features:
- Attachment blocking features in Outlook – Outlook 2002 and later versions include an attachment-blocking feature that blocks the most obvious file types, such as .exe, .bat, and .vbs files.
- Attachment blocking features in Outlook Web Access – Exchange 2000 Service Pack 2 introduced the ability to block attachments by file type and MIME type in Outlook Web Access (OWA). In OWA 200x attachment blocking is enabled by default.
Microsoft recently acquired Sybari, which was known for their suite of anti-virus and anti-spam suite of products, Sybari Antigen. The next version of this family of products will be integrated in future Microsoft releases.
Restrict Distribution Lists
Does your Organization have a Distribution List (DL) that contains the entire GAL? Most of my clients have something similar. And in case you do, is its usage restricted? Most of the Organizations I worked in don’t restrict the possibility of anyone (including external addresses) sending mail to this large Distribution List. Guess what, spammers and bad-intentioned people love this list, with a single message they can reach all your workers. And remember, some DL’s can contain sensitive information in the form of membership data (read Administration Board, VPs, CEO and so on), you probably don’t want these important people to be bothered with some unsolicited commercial email.
Exchange Server has mechanisms that allow you to configure DL permissions, namely:
- Prevent specified users from sending messages and message replies to large DL’s.
- Prevent specified users from sending messages to executive or other confidential DL’s.
- Prevent specified users from seeing the membership of specified DL’s.
- Prevent authenticated users only from sending to DL’s.
It’s so simple to configure security for a specific DL. Just open Active Directory Users and Computers, find the DL, edit its Properties and go to the Exchange General tab.
Figure 6: DL Properties
With this easy step, you can save the people you really don’t want to be bothered by the bad guys from a lot of trouble.
Address Spoofing Protection
OK, some of us, at some times, did send an email to a friend or colleague where we pretended to be someone else. Obviously as a joke and never to compromise security or to obtain privileged information. This is nothing more, nothing less than a common technique some spammers use, address spoofing.
RFC 2821 which defines SMTP protocol clearly states that “SMTP mail is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else”. So, SMTP doesn’t require verification of a sender’s identity. Exchange Server 2003 can provide extra functionality that can protect you against address spoofing.
By default, Exchange 2003 preserves the original SMTP message submission method and does not resolve the sender’s address if the SMTP submission is anonymous. If the original message was submitted without authentication, Exchange 2003 marks the message as un-authenticated and, in this case, the sender’s address is not resolved to the GAL display name (in the From line), instead it is displayed to the recipient in its SMTP format (for example, [email protected]).
However, Exchange 2000 does resolve messages submitted anonymously. Fortunately you can overcome this behavior if you have Exchange 2000 SP1 or higher. Service Pack 1 for Exchange 2000 added the ResolveP2 functionality. The ResolveP2 registry setting contains information that Exchange 2000 can use to “resolve” specified addresses in a mail message body (referred to as “P2”), if those users exist in the Exchange 2000 directory. Knowledge Base article ResolveP2 Functionality in Exchange 2000 Server has additional information and instructions on how to configure this functionality.
Another mechanism you can use is to configure your SMTP virtual server to perform a reverse DNS lookup on incoming e-mail messages, verifying that the IP address and fully qualified domain name (FQDN) of the sender’s mail server corresponds to the domain name listed in the message.
However, consider the following limitations to reverse DNS lookups:
- The sender’s IP address may not be in the reverse DNS lookup record, or the sending server may have multiple names for the same IP, not all of which may be available from the reverse DNS lookup record.
- Reverse DNS lookups place an additional load on the Exchange server.
- Reverse DNS lookups require that the Exchange server is able to contact the reverse lookup zones for the sending domain.
- Performing reverse DNS lookups on each message can result in a substantial decrease in performance due to increased latency.
For more information about using reverse DNS lookup, read Knowledge Base article, “HOW TO Prevent Unsolicited Commercial E-Mail in Exchange 2000 Server“.
Probably one of the most effective techniques against address spoofing is Sender ID. Sender ID was introduced with Exchange Server 2003 Service Pack 2. Sender ID makes spoofing more difficult, because when you enable it, when an e-mail message is received, the Exchange server queries the sender’s DNS server to verify that the IP address from which the message was received is authorized to send messages for the domain that is specified in the message headers. You can see it as a more powerful reverse DNS lookup, but instead of querying reverse zones, it’s a sender policy framework (SPF) record on the forward zone that’s checked. SPF records identify authorized outbound e-mail servers.
Tar Pitting
SMTP tar pitting is the practice of artificially delaying server responses for certain SMTP communication patterns and it’s used to help fight spam attacks, such as Directory Harvest Attack (DHA). In a DHA, an attacker unleashes a program that guesses all the possible e-mail addresses within a domain and attempts to send messages to those addresses. Normally the SMTP server will respond with a “550 User unknown” message to the non-existing addresses, so after a succeeded DHA the spammer will know the valid addresses.
…
MAIL FROM:<[email protected]>
250 2.1.0 [email protected]….Sender OK
RCPT TO: <[email protected]>
550 5.1.1 User unknown
QUIT
A brute force attack such as DHA with 4 characters can be completed in about 20 minutes. By introducing a 5 sec. delay it will now take months.
Enabling Tar Pitting is as easy as changing a Registry value and restarting the SMTP service. For detailed instructions read the Knowledge Base article “SMTP tar pit feature for Microsoft Windows Server 2003”. There are some additional articles that I would like also to recommend:
Summary
The topic I covered in this part is one of the easiest to find additional information about. That’s because it’s a problem every company faces, which led to the development of many products that reduce the risks associated with spam and malware in general.
I strongly advise you to research a little more and, in the event that the tools provided by Microsoft are not enough, try some of the third-party products available publicly.
If you would like to read the other parts in this article series please go to:
