SEMblog

Over the weekend one of my clients suffered an authenticated user attack on the SMTP interface of the Exchange 2003 server. This was detected by the monitoring tool I use, HoundDog (http://www.hounddogiseasy.com/referrer.html?code=YNPX) .

The attack was unsuccessful, as I have all of the authentication options disabled.

However what was interesting was the list of usernames that were tried. Some of them are to be expected, but others maybe not so. I have included the list at the end of this posting.

What this list tells you is the usernames that should be avoided, as some of them may well be used as test accounts, with basic or no passwords and therefore may well be easily compromised.
As authenticated user relaying is enabled by default on Exchange 2000 and 2003, if an account can be compromised, even with limited privileges, it can be used to relay spam through your server.

If you do not have anyone using POP3/IMAP accounts on your Exchange server, then authenticated relaying should be disabled completely. It is not required for the correct operation of Exchange with MAPI, Outlook RPC over HTTPS, Outlook Web Access and Windows Mobile or Blackberry use.
If you do have POP3/IMAP users then lock down the authenticated relay to those specific users only. I have added a link to my article on amset.info with instructions on how to do that below.

If you are a victim of an authenticated user attack then remember that most of them are not against you or your company directly, but a spammer wanting to use your bandwidth to send their messages, whether this is to sell something or a phishing attack.

Related Articles
Securing the authenticated relaying: http://www.amset.info/exchange/smtp-relaysecure.asp
Spam Cleanup: http://www.amset.info/exchange/spam-cleanup.asp

List of Usernames Targeted During Authenticated User Attack

webmaster
service
web
info
root
backup
tech
test
Administrateur
administrator
admin
tunnel
nagios
visitor
access
account
data
server
user

This is for reference really.
The events below are the sequence for a successful Backup of an Exchange database on Exchange 2007. It should apply no matter what backup application you are using, as long as it is Exchange aware.

When the jobs starts, this is logged:

 Event Type:      Information
 Event Source:      ESE
 Event Category:      Logging/Recovery
 Event ID:      210
 Date:            17/04/2009
 Time:            05:13:25
 User:            N/A
 Computer:      SERVER3
 Description:
 MSExchangeIS (3680) First Storage Group: A full backup is starting.

Immediately telling you which database is going to be backed up (you would see one for each database).

 Event Type:      Information
 Event Source:      ESE
 Event Category:      Logging/Recovery
 Event ID:      220
 Date:            17/04/2009
 Time:            05:13:25
 User:            N/A
 Computer:      SERVER3
 Description:
 MSExchangeIS (3680) First Storage Group: Beginning the backup of the file E:\Exchange Databases\First Storage Group\Mailbox Database.edb (size 3206 Mb).

When the backup is complete you get this reference:

 Event Type:      Information
 Event Source:      ESE
 Event Category:      Logging/Recovery
 Event ID:      221
 Date:            17/04/2009
 Time:            05:15:18
 User:            N/A
 Computer:      SERVER3
 Description:
 MSExchangeIS (3680) First Storage Group: Ending the backup of the file E:\Exchange Databases\First Storage Group\Mailbox Database.edb.

With the database backed up, the logs begin. The Exchange backup will include the logs that were generated while the backup was running. This store is quite small, so only a few log files are required:

 Event Type:      Information
 Event Source:      ESE
 Event Category:      Logging/Recovery
 Event ID:      223
 Date:            17/04/2009
 Time:            05:15:18
 User:            N/A
 Computer:      SERVER3
 Description:
 MSExchangeIS (3680) First Storage Group: Starting the backup of log files (range D:\Exchange Transaction Logs\First Storage Group\E0000005127.log - D:\Exchange Transaction Logs\First Storage Group\E0000005136.log). 

If the Backup was successful, then the complete message is logged:

 Event Type:      Information
 Event Source:      ESE
 Event Category:      Logging/Recovery
 Event ID:      213
 Date:            17/04/2009
 Time:            05:15:56
 User:            N/A
 Computer:      SERVER3
 Description:
 MSExchangeIS (3680) First Storage Group: The backup procedure has been successfully completed.

Finally, the committed transaction logs are flushed. You will notice that the last log being flushed is the one immediately before the log backed up earlier in the sequence.

 Event Type:      Information
 Event Source:      ESE BACKUP
 Event Category:      General
 Event ID:      916
 Date:            17/04/2009
 Time:            05:18:16
 User:            N/A
 Computer:      SERVER3
 Description:

Information Store (3680) Deleting log files D:\Exchange Transaction Logs\First Storage Group\E00000050E1.log to D:\Exchange Transaction Logs\First Storage Group\E0000005126.log.

The backup is successfully completed.

When you are setting up your server for SMTP delivery, one of the key things that is looked at is how the server is setup with regards to DNS and how the server announces itself. The latter can be referred to as the SMTP banner or EHLO/HELO.

As such, a number of sites, such as dnsreport.com have popped up which will run tests against your server to ensure that its setup is correct. However with Exchange 2007 you will get inaccurate results.

What Are They Testing?

In short, what these sites do is connect to port 25 on your server and see how the server announces itself. However this is basically incoming email traffic, whereas what you are interested in is outbound email.

What has Changed?

With Exchange 2003 and older, the same SMTP banner was used for both incoming and outgoing email. With Exchange 2007 that has changed. The FQDN values are set separately on the Send and Receive Connectors.
Furthermore, the values you can set for the FQDN on the receive connector is limited in Exchange 2007 SP1 to either blank, the NETBIOS name or the Server's real FQDN. You cannot set them to anything else, such as your public FQDN. If you do try, you will get an error message.
Microsoft actually go as far as to say that you shouldn't change the value at all.

What can you do?

There is little that you can do. Online testing sites cannot test the outbound message appearance because that would mean you would have to initiate the traffic flow.
Simply ensure that  the FQDN set on the SEND Connector for port 25 traffic is set correctly - host.example.com - where host.example.com is the host name that resolves to your Exchange server.

References and Further reading

Receive Connectors: http://technet.microsoft.com/en-us/library/aa996395.aspx
DNS Configuration for Exchange: http://www.amset.info/exchange/dnsconfig.asp

Last year I wrote an article about how spam could not originate from inside your network and go through your Exchange server, because that was simply too much hard work.
You can read the original article here: http://blog.sembee.co.uk/archive/2008/03/13/73.aspx
As a brief summary, I basically said that a spammer needs to get their BOT inside the network, find the Outlook installation and then abuse it, or they could take the simple route of having their own SMTP engine and send email directly.
Remember a spammer doesn't want to be found, and sending a large amount of messages through Exchange will alert network administrators that something is wrong.

Alas despite that posting some people continue to believe that someone who is being flooded with spam in their queues will have a compromised client, despite the changes being very slim.

The purpose of this posting is to help you diagnose whether the message has come from a client inside your network, or not.
Do that, you need the SMTP headers of one of the messages.

Background

First a little bit of background about Exchange and SMTP headers.
When you send a message from a MAPI client (so that is Outlook, Outlook Web Access, a Windows Mobile device using Exchange ActiveSync or a Blackberry using a BES) then the SMTP headers are not actually put on to the message by the client, but by Exchange when the message hits the SMTP server. That is why you do not see any headers on internal email messages or show the internal IP address of the machine that originated the message on external email messages.  

If you send the message via an SMTP client (Outlook Express etc, a PDA with IMAP/POP3 access etc), the SMTP header is generated by the application originating the message.

If you bounce the message off Exchange's SMTP virtual server (relaying) then the header stays intact and  Exchange simply treats it like any other SMTP message that is passing through.

It is the originating application line that will show you whether the message has come from inside.

Getting the Headers

If the server has already been blacklisted, then on many of the blacklists you can see the message that was received, which will show the complete headers.
If you have a large number of messages in the queues, then you simply need to get hold of one of those messages. You will find them in \exchsrvr\mail root\vs 1\queue.
Drop one on to a notepad document, which should open for you.

What you are looking for.

When you can see the raw header, you are looking for something like the below.

If the message originated outside of Exchange, then look for something along the lines of these examples:

• X-Mailer: Microsoft Outlook Express 6.00.2600.0000
• X-Mailer: The Bat! (3.0.2.8) Professional
• User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

If the message originated on Exchange, then you will see something similar to these:

• Exchange 2000:
  X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12
• Exchange 2003:
  X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
  X-MimeOLE: Produced By Microsoft Exchange V6.5
• Exchange 2007:
  Received: from host.domain.local ([fe80:xxx:xxxx:xxxx:xxxx]) by  host.domain.local ([fe80:xxxx:xxxx:xxxx:xxxx]) with mapi;
  Received: from host.domain.local ([123.123.123.123]) by  host.domain.local ([123.123.123.123]) with mapi;

Of course the headers are not completely fail safe. Antivirus and anti spam applications can strip content off the headers, as can other third party tools that will scan SMTP traffic. However the presence of non-Microsoft products in the headers is a clear sign that the message originated outside of your network.

This is another post in my series of articles on why you shouldn't use certain features in Exchange, even though they are there - although in this post is about an Outlook feature - PST files.  

The other articles in this series to date are:

Why you shouldn't use logos in signatures (http://blog.sembee.co.uk/archive/2008/04/14/76.aspx)
Why you shouldn't enable the POP3 Server (http://blog.sembee.co.uk/archive/2008/03/03/71.aspx)
Why you shouldn't use the POP3 connector (http://blog.sembee.co.uk/archive/2006/09/25/28.aspx)
Why you shouldn't use a self generated SSL certificate (http://blog.sembee.co.uk/archive/2006/03/05/9.aspx)
Why you shouldn't put Exchange 2003 in to a DMZ (http://blog.sembee.co.uk/archive/2006/02/23/7.aspx)

In this post I am going to outline why you shouldn't use PST files.

Anyone who has worked with Exchange or Outlook for more than 10 minutes will know about PST files. However despite their numerous flaws, they continue to be in widespread use. Where possible you should ban their use, particularly for archiving purposes.

The main arguments against using PST files are:

Data Loss When They Get Too Large

With Outlook 2002 and older, PST files can go to a maximum of 2gb, but in an annoying flaw, the file will allow you to continue to add data past the 2gb limit. You only get problems when you try to open the file again. Microsoft do have a tool that will allow you to open a file that has gone over the limit, but it simply chops off all data over 2gb - therefore resulting in data loss.

With Outlook 2003 and higher a new format of PST file is used (which is not backwards compatible) which allows PST files to go to 20gb. You cannot convert the old version to the new one. If you have create the wrong type then you will need to create it again and move the content across.

PST files are very fragile things, particularly the larger they get. Many people will suggest a new PST file at 1gb or less to protect the data.

Backup of the Files is Awkward

Microsoft do not support accessing PST files over a network. (http://support.microsoft.com/default.aspx?kbid=297019 and
http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx ).

That basically means they are impossible to backup. You cannot store them locally and backup over a network, and you cannot store them on a network share and access them over the network. Considering how fragile they are this is asking for problems.

Single Point of Failure / Risk of Corruption without Knowing

It is perfectly possible to have a corrupt PST file and not know about it for weeks or months. It is perfectly possible to continue to access and have open a PST file and not know that some of the data has become inaccessible.
Furthermore due to the fact that they are not supported being accessed over a network, that means keeping copies of them is not really practical. You cannot store them in "Read Only" format or access directly from a CD as the file will not open. Outlook needs write access to open the file. That would mean copying the file off the read only source, changing the tag on the file and then opening it. That could cause corruption in the file.

File Bloat

Due to the way that PST files store their data, they will actually use more space than the same data in Exchange - up to three times, and that is not taking in to account the loss of single instance storage.
100mb of email can be as much as 300mb in a PST file.
If ten users were sent a 2mb file in Exchange, then it uses 2mb of space in the store. Extract to PST files that same file would use up to 60mb as each user has their own copy in three different formats.

PST Files are not an Archiving Solution

The above should be enough to know that they are not an archiving solution. If you value your data do not store it in a PST file.
If you need to keep content for regulatory reasons, then a PST file will fail on many counts, such as allowing the user to modify the item after it has been received.

Are there any reasons to use PST Files?

If you aren't connected to Exchange, then you have no option but to use PST files.

With migrations, in some scenarios they are the only option, because they are domain independent. A PST file from one domain can have its contents imported in to another domain. However the same issues with the files remain, so when using them for this type of migration caution must be taken to ensure the data remains intact. 

Conclusion

Hopefully the above will give you some idea why PST files should not be used where there is any value to the data.