Microsoft KB Archive/842851

From BetaArchive Wiki

Article ID: 842851

Article Last Modified on 12/3/2007



APPLIES TO

  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition



Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry


Technical update: May 10, 2005

Microsoft has released a Microsoft Security Advisory on this issue for IT professionals. The security advisory contains additional security-related information about this issue. To view the security advisory, visit the following Microsoft Web site:

INTRODUCTION

This article discusses Simple Mail Transfer Protocol (SMTP) "tar pitting." The tar pit feature is an SMTP feature that is available on a computer that is running Microsoft Windows Server 2003 Service Pack 1 (SP1). By default, the tar pit feature is disabled. To use the tar pit feature, an administrator must enable the feature by configuring the TarpitTime registry entry.

MORE INFORMATION

What is SMTP tar pitting?

Tar pitting is the practice of deliberately inserting a delay into certain SMTP communications that are associated with spam or with other unwanted traffic. To be effective, these kinds of communications typically rely on generating a high volume of traffic. By slowing an SMTP conversation, you can dramatically reduce the rate at which automated spam can be sent or at which a dictionary attack can be conducted. Legitimate traffic may also be slowed by tar pitting.

The tar pit feature is available in Microsoft Windows Server 2003 and in several third-party SMTP servers. The tar pit feature in Windows Server 2003 works by slowing all responses that contain SMTP protocol 5.x.x error codes. An administrator can configure the delay that is introduced by the tar pit feature. For information about how to configure the delay that is introduced by the tar pit feature, see the "How do I enable the tar pit feature?" section.

How do I decide if I should enable tar pitting?

If you have enabled Microsoft Exchange Server 2003 recipient filtering, you should consider using tar pitting. If you have not enabled recipient filtering, tar pitting is less likely to be of significant benefit for Exchange Server.

If you enable the tar pit feature, you should carefully monitor the performance of your SMTP server. Additionally, you should analyze the traffic patterns on the server to make sure that tar pitting is not disrupting or delaying ordinary traffic.

Tar pitting affects only anonymous SMTP connections. Authenticated sessions are exempt. Therefore, if you regularly exchange lots of SMTP mail with another organization, and you find that tar pitting is affecting that traffic, you can bypass tar pitting for that organization by authenticating SMTP communications.

What is recipient filtering?

Recipient filtering is a new feature in Exchange 2003. Recipient filtering lets you filter or reject incoming mail for specifically defined recipients and for any incoming recipient that is not listed in the Active Directory directory service for your organization.

For more information about how to enable and to configure recipient filtering, see Microsoft Exchange Server 2003 online Help.

After you enable the recipient filtering feature, senders cannot send you mail that is destined for invalid recipients or for filtered recipients. Such mail is rejected early in the SMTP conversation before the body of the mail is transmitted.

This behavior generally reduces the processing demand of dealing with invalid mail on your Exchange server. Not only do you not have to accept and store the mail, but you also are not obligated to send a non-delivery report (NDR) for invalid mail because the mail was never accepted.

If you do not use recipient filtering, mail that is sent to invalid e-mail addresses in your Exchange organization is accepted and is processed by your Exchange server. After the Exchange server processes this mail, it must generate and send an NDR for all invalid mail.

Note NDRs can be suppressed in Microsoft Exchange 2000 Server and in Exchange 2003. However, RFC 2821 states that NDRs must be returned for invalid recipients if you accept the e-mail message. For more information about how to configure NDR suppression, see Exchange Server 2003 online Help.

How do tar pitting and recipient filtering work together?

A disadvantage of recipient filtering is that it increases the efficiency with which an e-mail address harvest attack can be performed against you. In a typical harvest attack, a "dictionary," or a list of likely e-mail names, is used to automatically generate large numbers of e-mail messages to send to your domain. The goal is to have you indicate whether each e-mail address is valid or invalid. The attacker then uses the list of discovered e-mail addresses to send spam or for other illegitimate purposes.

When the recipient filtering feature is enabled, your server will reveal whether an e-mail name is valid or invalid during an SMTP conversation. When the recipient filtering feature is disabled, an attacker will have to wait for the return of an NDR for each guessed name.

When both the recipient filtering feature and the tar pit feature are enabled, responses to invalid e-mail names can be greatly delayed. This behavior can discourage the attack.

Note Because the great majority of attackers log on with a spoofed domain, few spammers or other attackers are likely to actually receive the NDRs that are generated by your server. If an NDR can find the attacker, you can find the attacker. Therefore, the risk of dictionary attack through NDRs is not as great as the risk from disclosure of information during an SMTP conversation.

Why should I not just prevent Exchange from sending any responses that might help an attacker?

You can configure Exchange not to send any responses. To do this, you must disable recipient filtering and suppress NDRs.

As previously discussed, suppressing NDRs is not an RFC-compliant practice. Therefore, suppressing NDRs cannot be generally recommended. Suppressing NDRs also inconveniences the ordinary user who makes a typographical error in the recipient address when he or she sends an e-mail message. The typical expectation of e-mail senders is that unless an NDR is returned, the e-mail message has reached its destination.

If the recipient filtering feature is enabled, you may be more at risk from a harvest attack. However, you are also less susceptible to being used as the vector for an NDR flood attack. An NDR flood attack is where a sender deliberately spoofs the return address for a valid domain and then sends invalid e-mail messages to you purporting to be from that domain. Your server then dutifully floods the victim domain with multiple NDR reports.

E-mail harvest attacks, NDR flood attacks, and even the problem of spam itself rely on features in the SMTP protocol that are useful or required for legitimate e-mail transfer. There are trade-offs that you must consider when you defend against such threats while still letting legitimate traffic continue.

Tar pitting is one more option to defend against the misuse of SMTP while minimizing the effect on legitimate users.

How do I enable the tar pit feature?

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

The tar pit feature can be enabled and configured by setting a registry key. To do this, follow these steps.

Note If the TarpitTime registry entry does not exist, Exchange behaves as if the value of this registry entry were set to 0. When the registry entry has a value of 0, there is no delay when the SMTP address verification responses are sent.

  1. Click Start, click Run, type regedit in the Open box, and then click OK.
  2. Locate and then click to select the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type TarpitTime as the registry entry name, and then press ENTER.
  5. On the Edit menu, click Modify.
  6. Click Decimal.
  7. In the Value data box, type the number of seconds that you want to delay SMTP address verification responses for each address that does not exist. Then, click OK. For example, type 5, and then click OK. This delays SMTP address verification responses for 5 seconds.
  8. Quit Registry Editor.
  9. Restart the Simple Mail Transport Protocol (SMTP) service.

Can I use tar pitting on Windows Server 2003 if I do not use Exchange 2003?

Yes, you can. Tar pitting is a feature of the generic Windows Server 2003 SMTP service. This SMTP service is used by Exchange and can also be used by other applications.

The tar pit feature inserts delays into 5.x.x error responses. If your application can make good use of such delays, you may want to consider enabling the tar pit feature.

REFERENCES

A previous version of this article can be found here:

899492 A software update is available to help prevent the enumeration of Exchange Server 2003 e-mail addresses




The current version of the article was updated with additional explanatory material and new download information. For more information about the recipient filtering feature, click the following article number to view the article in the Microsoft Knowledge Base:

823866 How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003


For more information about suppressing non-delivery reports in Exchange 5.5, click the following article number to view the article in the Microsoft Knowledge Base:

837794 Update available in Exchange Server 5.5 to control whether the Internet Mail Service suppresses or delivers NDRs


For more information about SMTP relaying, another feature that is frequently taken advantage of by an attacker, click the following article number to view the article in the Microsoft Knowledge Base:

304897 SMTP relay behavior in Windows 2000, Windows XP, and Exchange Server


For more information about Microsoft software updates, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates



Additional query words: XADM DHA

Keywords: kbqfe kbhotfixserver kbsecadvisory kbprb kbwinserv2003presp1fix KB842851