In the last article on this subject (which is located here) I shared with you some thoughts that I had about how the structure of your Exchange environment can help protect you from SPAM and being an open mail relay. I began to discuss how perhaps these days you are not only at risk from external influences, but how people within your own company can target you, and I started to explain how you can use tools such as the Exchange Server Best Practices Analyser to bench mark your Exchange Server to see how well the configuration stacks up against potential threats.

In this article I would like to go through some steps that you can take to prevent your Exchange server from becoming an “Open Relay” and some settings that you can enable and analyse to derive if you are indeed being used as one.

Enabling and using the tools that can help:

There are a number of features within Exchange (especially if you are running Service Pack 2) that are not enabled by default, but when activated they can actively play a part in diagnosing open relay and indeed a number of settings that can be used to reduce your attack surface, in this article I would like to take you through these features, how you can activate them and how they can be used to diagnose and fix problems.

Enable SMTP Virtual Server Service Logging:

This feature is otherwise known as SMTP Protocol logging. By enabling SMTP protocol logging you can review and trace all commands (SMTP Verbs) that have been issued to and by your Default SMTP virtual server from clients.

It is key to enabled SMTP logging on all servers which are considered “Gateway” facing – e.g. either the first leg in from or last leg to Internet relay. You can enable it on other Exchange servers in your environment, however it serves a better purpose when used with Internet based traffic.

When you configure Protocol logging you have a number of options of how you can store the log data – which are as follows (I have included definition links to Technet so you can read more about the logging type but if you would like to read the full overview please have a look at the Log File Formats article on Technet – http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/bea506fd-38bc-4850-a4fb-e3a0379d321f.mspx?mfr=true:

• W3C Extended Logging Format – this is a text based format which logs data about a single SMTP Virtual Server, it contains a number of options which can be customised according to need
• IIS Log File Format – a text based format with set fields which can log data about a single SMTP Virtual Server instance
• NCSA Common Log File Format – rarely used format which is text in composition using fixed fields and will log data about a single SMTP virtual server
• ODBC Logging – Fixed field format which will log data about a single SMTP virtual server to a ODBC compliant Database (Access or SQL for example)

Each format has it advantages and disadvantages – however in the example that I going to give below I will be using an Access Database to store the logging data. My reason for this is that it will can cut out a number of conversion processes that are normally associated with the normal W3C Extended Logging Format (e.g picking up the file and then exporting it into a Excel sheet) and makes the logs ready for up-sizing to SQL and indeed can allow for like minded people to write their own custom reports.

At the end of the example I will briefly go through W3C Extended Logging Format – as it is the normal form of logging for SMTP Virtual Servers under Exchange – and – I wish to go through some of the 3^rd party products that can be used to interpret the logs.

Now the following Knowledge Base article explains how you can create a SQL database instance which can be used by IIS SMTP (or indeed an Exchange SMTP Virtual Server instance) for use with protocol logging http://support.microsoft.com/kb/303738 however I have provided a down-loadable Access database with the table pre-created with the correct fields: 

SMTP-Log.mdb [233KB] – Access 2000 – 2003 Format

In order to enable SMTP Protocol logging using the above Database please complete the following steps:

• Download the above database to a location on your Exchange Server (I recommend a path away from the your transaction logs and databases perhaps in a folder entitled <Drive Path:\SMTP\Logs\>
• Navigate to [ Start -> Programs -> Administrative Tools -> Data Sources (ODBC) ] which will open up the following dialog box:

Click on the “System DSN” tab and click the “Add” button which will display the following dialog box:

From the “Create New Data Source” dialog – choose the “Microsoft Access Driver (*.mdb)” and click on the “Finish” button which will open the following dialog box:

Provide a name for the DSN (in my example I have used “SMTP” and provided a description (optional) and then click on the “Select” button which will open up the following dialog box:

Click on “OK” and then “OK” again.

• On your Exchange server open the Exchange System Manager and navigate to the following location [ Administrative Groups -> First Administrative Group -> Servers -> <Your Server> -> Protocols -> SMTP -> <The SMTP Virtual Server> ] – right click on the Virtual server that you wish to work with and from the context menu that appears choose the “Properties” option.

The following is a visual example of the above:

• When you have completed the above you will be presented with the following dialog box:

From the “Enable Logging” section of the dialog box – change the “Active log format” to read “ODBC Logging” and click on the “Properties” button which will open up the following dialog box:

In the ODBC properties dialog under the “ODBC Data Source Name (DSN)” section provide the name of the system DNS that you created earlier (in my example it was SMTP) – after you have done this you will need to provide the name of the table in the database which will hold the SMTP Virtual Server data – if you downloaded my copy of the database above the name of the table is “Inetlog” when you are don click on the “OK” button twice.

From the Start menu choose “RUN” and then type “CMD” then click on the “OK” button. Then from the command line type in the following commands:

• net stop SMTPSVC <press enter>
• net start SMTPSVC <press enter>

When the SMTP service restarts it will begin to log all transactions into the database that you have just configured.

How do I view the Records?

What I typically do is map a network drive to the location in which the database is located and then when you wish to inspect the contents TAKE A COPY of the database down to your local machine and open it up in Access, if you open the Database up directly up on the server you will prevent the SMTP service from writing data to the logs.

Ok, how do I interpret the logs – do I have an issue?

Consider the following example from the logs on my test server (which also is a den of hybrid spam inequity – deliberately done, honest) – please note I have removed some of the fields from the log as they do not actually provide any additional value to the example that I am going to give;

 

From the log entry above you will see that a host located at IP Address “204.202.241.5” initiated contact with my SMTP server and issued the extended SMTP “Hello” verb “EHLO”, it them issued a “MAIL FROM” verb with a blank sender “<>” – my Mail Server accepted this as OK and then the connecting SMTP host issued a desired recipient “RCPT TO:“ of “akstcgaellimnsdgs@gaelli.ch” – now this is interesting as my mail server does not service this domain, therefore the conclusion that I can arrive at here is that I am being used as an “Open Relay” – bear in mind that my server passed the BPA “Open Relay” test.

Reviewing the transcript of the conversation the host server issued the SMTP verb “Data” (e.g body of message) and then queued the message for delivery and closed the transmission.

Now the above is an example of how to determine if you Exchange SMTP Virtual server is being used to relay mail from and to other domains other than the Authorative domains that it is responsible for – therefore in terms of Open relay you are looking for entries in your events logs which correspond the following criteria:

• Contact is initiated from an host that is external to – or perhaps in side your IP ranges
• Is using either a blank Send  – or – a unknown Sender from your domain
• Here is the Key: where the recipient is not located in your domain

Ok, so I have an issue like the above, and my Exchange installation passed the BPA – what can I do?

The first thing to do is install Exchange 2003 Service Pack 2 (if you haven’t already – without it you are missing a whole raft of mail security enhancements which can serious benefit your Exchange installation not least of which is an enhanced IMF), the following assumes that you have Service Pack 2 installed).

Preventing bogus recipients from being sent from your mail server

On your Exchange server open the Exchange System Manager and navigate to the following node: [ Global Settings -> Message Delivery ] – right click on “Message Delivery” and choose the “Properties” options – see the example below:

The following dialog box will open – click on the “Sender Filtering” tab:

From this tab tick the following check boxes;

• Filter messages with blank senders
• Drop connection if the address matches filter

When you done here click on the “Recipient Filtering” tab which will look like the following:

Check the “Filter recipients who are not in the directory” box and then click on OK.

When you are done here navigate to the following location in the ESM [ Administrative Groups –> First Administrative Group -> Servers -> <Your Server> -> Protocols -> SMTP -> Default SMTP Virtual Server ] right click on the virtual server and choose the “Properties” options – see below:

When you have clicked on the “Properties” option you will be presented with the following dialog box:

Click on the “Advanced” Button which will present you with the following dialog box:

You should notice that the column entitled “Filter enabled” is set to “No” click on the “Edit” button which will present you with the following dialog box:

Check the following boxes:

• Apply Sender Filter
• Apply Recipient Filter

When you are happy with your options click on “OK” three times to return you to the ESM.

From configuring the above settings you have told Exchange to complete the following tasks:

• If the sender is blank – drop the connection
• If the recipient is not in your organisation do not allow the transaction to continue

After configuring these settings you may start to see entries in the Application Event Log on your Exchange server which look like the following two examples:

Both of which indicate that a connection attempt was made to your server to send to someone in your domain whom doesn’t exist – or – an attempt was made to send to someone using your Exchange server whom is elsewhere – these messages mean that your server did not carry out the action.

Below I have provided a video of my Exchange SMTP Virtual Server configuration which show the message delivery configuration and the SMTP virtual configuration which will “harden” your server from being used as an “Open Relay” – as always in order to extract the video your will need a copy of WinRAR or 7–Zip:

OpenRelay-Final.rar [282KB – Compressed – 21.9 MB – Expanded]

As you know we have used a database in place on the normal “W3C Extended Log File Format” which is the default form of logging for Virtual SMTP servers under Exchange. For further information on configuring and using that logging format have a look at this article here: http://www.msexchange.org/tutorials/Logging_the_SMTP_Service.html over on MSExchange.org – it take you through how you can use Excel to query the W3c Log files in the same way as I have gone through here.

3rd Party Offerings:

Now the above example has shown you how you can use Access to query your logs (and if you have looked at the article on MSExcgange.org you will have an idea on how to use Excel – but there are a number of companies out there that offer solutions where a lot of the interpretation is done for you – some of which are:

• Quest Message Stats
• Hypersoft Omni Analyser (Tracking Logs only)
• GFI Events Manager

The suggestions above range from the most expensive to the cheapest (therefore Large Enterprise, down to SME) – but, if you don’t feel like doing the analysis yourself then they are worth a look.