In Tar Pitting Directory Harvesting Attacks, we discussed the employment of tarpitting as a defense against Directory Harvesting. That article discussed adopting this functionality in
combination with the Exchange 2003 Recipient Filtering. In Exchange 2007 we again find the same functionality. Today we revisit this topic highlighting the
configuration elements relevant to Exchange 2007.
For details on the following points check Tar Pitting Directory Harvesting Attacks:
- Why Recipient Filtering is very useful in blocking spam
- Why Recipient Filtering can expose an organization to directory harvesting attacks
- How tarpitting plugs this weakness whilst retaining the benefits of Recipient Filtering
Recipient Filtering
The Recipient Filtering Agent is one of the anti-spam agents included with the Exchange 2007 Edge and Hub transport servers. These are readily installed
on Exchange 2007 Edge and SBS2008 Exchange 2007 Hub transports.
In case of non-SBS2008 Exchange hub transports the agent may be installed by running:
<Exchange Server dir.>\Scripts\install-AntispamAgents.ps1
To do this, at the Hub transport server, just open the Exchange Shell and run install-AntispamAgents.ps1. On completing, restart the Microsoft Exchange
Transport service.
Configuring recipient filtering is trivial. From the Management Console browse to the anti-spam property page at:
Edge Transport: Microsoft Exchange | Edge Transport | Anti-Spam
Hub Transport: Microsoft Exchange | Organization Configuration | Hub Transport | Anti-Spam
Opening the Recipient Filtering properties we find the same configuration elements we had in Exchange 2003.
At the bottom we have the list of local recipient addresses that won't be allowed to receive external emails. At the top we have the highly useful
'Block messages sent to recipients not listed in the Global Address list'. As discussed in Tar Pitting Directory Harvesting Attacks, this will cause all emails sent to invalid
recipients to be immediately rejected. This is done while relieving us from the overhead of NDR generation.
Before moving to tarpitting it is worth saying something about this text:
Block messages sent to recipients not listed in the Global Address list
The wording of this setting could give the impression that recipient filtering will reject any message containing invalid recipients. This is not 100%
true. Recipient filtering will only reject the non-existing recipients. For those understanding the SMTP protocol, recipient filtering only operates on the
RCPT command. Recipients are rejected with a response:
550 5.1.1 User unknown
If you would like to learn more on SMTP check Telnet Port 25
Let say an email is addressed to a mix of valid recipients (listed in the GAL) and invalid recipients. In this case recipient filtering will only reject
the invalid recipients. The email will still be delivered to the other recipient mailboxes. The only case when the email is entirely blocked is when all
recipient addresses are classified as invalid.
Tarpit Interval
Those who read the Exchange 2003 article already know why we discuss tarpitting and recipient filtering together. Tarpitting is the line of defense that
allows us to employ recipient filtering without exposing ourselves to a major directory harvesting attack.
Tarpitting is so useful that as from Exchange 2007 this is enabled by default. So one can safely enable Recipient filtering and be totally ignorant of
this functionality. However those wanting to have a more intimate understanding of their email transport may wonder why Exchange takes a nap whenever it is
about to reject an email. This is exactly what tarpitting is all about.
Whereas we already explained how and why tarpitting works the way it does in our previous article, today we will fill-in the details of how to control
tarpitting. For example I often disable tarpitting when stress testing IMF Tune for Exchange
2007. In this manner I can achieve the highest email processing load. An administrator may want to fine tune the length of time it takes for Exchange to
return a rejection response.
Tarpitting is mainly intended to control internet originating, incoming emails. Thus quite naturally we configure this at the Receive Connector.
Specifically we are interested in the 'TarpitInterval' property. This is a time value expressed in the format: hh:mm:ss. The maximum allowed value is 10
minutes (00:10:00). To disable tarpitting we just set the interval to zero (00:00:00).
Let's see the default value as configured out-of-the-box. At the shell I feed Get-ReceiveConnector with the connector name and for clarity select to only
return the TarpitInterval value as follows:
Get-ReceiveConnector "Default Internal Receive Connector MELITA" | select TarpitInterval
As we can see the default interval is 5 seconds. This is long enough to render a directory harvesting attack unfeasible.
We could change this to 10 seconds as follows:
Set-ReceiveConnector "Default Internal Receive Connector MELITA" -TarpitInterval 00:00:10
...and to disable it (only do this if you have a very good reason):
Set-ReceiveConnector "Default Internal Receive Connector MELITA" -TarpitInterval 00:00:00
Final Tips
Exchange 2007 carried forward the tarpitting functionality that was made available to Exchange 2003 through a registry hack. Following the secure by
default philosophy, Exchange 2007 starts with a tarpitting delay of 5 seconds. Hopefully this will encourage more organization to immediately reject emails
relieving themselves from the problems related to NDR generation.
References
Tar Pitting Directory Harvesting Attacks
Technet: Recipient Filtering
Technet: Set-ReceiveConnector