EXCHANGE域用户收到其他域用户的SPAM邮件

userA说收到userB的spam email， 实际上userB没有发送该信。初步判断exchange的relay设置有问题。

REF:

http://www.vamsoft.com/authattack.asp

http://www.5dmail.net/html/2003-11-3/2003113101711.htm

SMTP Auth Relay Attacks

What Is an SMTP AUTH Relay Attack?

Spammers often use open relay mail servers to hide their identity. These servers does not have proper limitation on relaying, they accept mails from everyone and deliver to everyone.

Most mail servers on the Internet are secured against unauthorized relaying using IP-based relay restrictions, but many of them still allow authenticated users to relay. This is the default setting on Exchange 2000/2003 servers and it is not a security risk as long as the user accounts are protected.

Starting from July 2003 we received a number of reports from ORF users complaining about unexpected authenticated sessions showing up in the ORF logs, increased network traffic and unwanted relaying.

Soon after the first reports we realized that spammers invented a new technique to hijack mail servers: they search for weakly protected user accounts by SMTP authentication attempts and use the accounts discovered to get relay rights. Once they successfully authenticate using the user credentials, they are granted to relay via the server, which is then used to send spam.

How Can I Protect My System?

Securing user accounts
First check that you do not have the Guest user enabled. This user account has no password by default, so most of the successful attacks are carried out against this account.

Spammers might attack any other user accounts. According to Usenet posts, the typical account name attempts are: abc, web, admin, www, administrator, data, server, backup, master, test, root and webmaster.

In the cases we investigated the account passwords were blank, but spammers may use a dictionary for discovering the password for the account, so strong/complex passwords are recommended (as always).

Disable relaying for authenticated users
If you can restrict relaying based on IP addresses (i.e. there are no relay users with dynamic IP address), you can disable relaying for authenticated users in the IIS/Exchange SMTP configuration.
Open the SMTP virtual server properties, select the Access tab, click Relay in the Relay restrictions group. Clear the Allow all computers which successfully authenticate, regardless of the list above checkbox.

I Am under Attack, What Can I Do?

If you already disabled the Guest account, your passwords are strong enough, the IP-based relay restrictions are properly configured and you still relay spam, you need to find out which user account has been hijacked by the spammers. There are multiple techniques for this.

• Set Transport Logging to Minimum. This way the SMTP service will log a 1708 Information event which tells you which client computer authenticated, which login method they used, and which user account was used. You can use the Event Viewer to view these event log entries, filter for event ID 1708 in the Application Log.
• Enable Local Policies / Audit policy / Audit account logon events in the Global Policy and you will see which users have authenticated successfully. This information can be viewed in the Windows Event Log (Security log). This log will include other authorization events, so check only those events where the mail send times coincide with the successful account logons.
• If you find these above methods too complex, you can install the trial version of ORF, which logs the authenticated user name.

Once you have the account name, disable it or change the password.

Do not be surprised if your server still generates hundreds of undeliverable NDR's, which fills your Badmail folder. When your server cannot deliver the spam to the recipient, it generates a bounce report (NDR) and tries to deliver it to the message sender. As the message sender is fake in most cases, Exchange puts the undeliverable NDR to the Badmail folder. To avoid generating futher NDR's, empty the outgoing message queue.

As a temporary solution, you may want to disable sending NDR's as described in the Microsoft Knowledge Base Article Q294757: How to control non-delivery reports when you use Exchange 2000 or Exchange 2003.