Backscatter is a problem that has been known to the messaging community for a long time. In essence, backscatter is a DSN (Delivery Status Notification) delivered to a recipient who never sent the original mail in the first place. While the DSN itself is perfectly legitimate and valid notification initiated by a reputable MTA, it has been sent to a user who never initiated the original mail transaction. How is this possible? Well, spammers just spoof a valid P1 MAIL FROM: address and an innocent user will get a bounce. Most backscatter victims (bogus bounce recipients) are in the same bucket with the rest of us (we are all humans and not very tech-savvy, are we?) so emotions fly high (“Ahhhh!!!!! I’ve been hacked!!!”, “My mail account is a zombie sending spam behind my back when I sleep!!!”, “Our corporate address book has been leaked!” etc.) These are some of the concerns I’ve heard from the victims after they got bogus NDRs. So what’s going on with this and how to stop it? Here is how the mail flow in a backscatter attack works:
Originally, spammers did not use and did not care much about providing valid P1.MAIL FROM addresses, so backscatter was much less of a problem. As defenses against spam grew, some MTAs deployed a logic that contributed to the backscatter problem in geometrical progression. Particularly, during an incoming SMTP transaction the “callback verification” logic causes the receiving MTA to immediately initiate a connection to the connecting MTA to verify the existence of the P1.MaiFrom address for the incoming e-mail transaction (these MTAs will verify P1.MailFrom on RCPT TO: command). If the address does not exist, the original e-mail transaction gets rejected. While it looks cool, this logic is fundamentally flawed and contributed to the widespread pandemic of backscatter.
Because the MTAs with “callback verification” only verify that the address exists in the org, spammers quickly realized this essential shortcoming and started to spoof legitimate addresses harvested all over the internet. As an example of the headache created by this flawed logic, one of the “Klez” virus iterations spoofed “support at microsoft.com” address to distribute the virus resulting in hundreds of thousands of backscatter messages sent to the Microsoft alias.
The right place to verify the legitimacy of incoming transactions is to plug in e-mail authentication technologies such as SenderID Framework. This is where the authenticity of incoming SMTP transactions should be verified without exercising rude and intrusive behavior that does more harm than good. There are, however, still plenty of MTAs that have been configured with this logic and continue to contribute to the backscatter problem. Sure, these MTAs get onto various DNS Black Lists rather quickly, but they get delisted from there pretty quickly as well after an administrator initiates a complaint and request for delisting.
In many cases backscatter presents serious danger to Exchange organizations, because it will consume significant resources on the backscatter-receiving server. What is even worse is the fact that spammers use social engineering to cleverly craft the backscatter to carry their payload. A few days ago I got a bounce, and my first reaction was “What’s going on???” Then I realized I just eyeballed this bogus NDR and its payload. This is exactly what spammers want – your eyes on their message in whatever form it is, especially an NDR as we are all naturally curious about what happened and why our mail was not delivered. Only after we open the NDR do we realize it’s bogus, but the spammers have already achieved their goal.
It’s been like this for many years without a sign of relief for Exchange users. Finally, with the introduction of Forefront Protection 2010, Exchange administrators will be able to protect their orgs from this vector of spam attacks. In the Forefront Protection 2010 for Exchange server release there is a new filter – the Backscatter Filter. Upon installation of Forefront 2010, the agent is the only agent in the antispam framework that is not enabled by default. If you were asking “What is backscatter anyway?” prior to reading this blog, then most likely you do not need this agent to be enabled. If after reading the preamble you think you are one of the victims, then Forefront 2010 will help you to counter backscatter. Let’s see how to do it.
On the Forefront Protection 2010 Administrative Console you will notice the new Backscatter Filter. Here is what it looks like:
So what’s under the backscatter filter hood? The filter has been implemented based on BATV technology. There are already many implementations/deployments using BATV technology to counter backscatter (for example, Exim, Sendmail, Postfix, Qmail, McAfee, SonicWALL, Panda, Ironport, and others). Forefront is right there and implements BATV in a very simple, flexible, and secure way. In order to use the filter, an admin needs to do the following:
1. Enable the filter
2. Generate a set of Backscatter Keys
3. Transfer the keys to all servers that participate in sending/receiving inbound/outbound mail
4. Start enjoying the benefits of being protected from backscatter attacks/spam!
To successfully implement backscatter protection the administrator must generate the backscatter keys for the filter to use, otherwise protection will fail. While there is no need to re-generate the keys on a daily/weekly or even monthly basis, if the key set is compromised, an administrator can regenerate the set, but only one new set of keys is allowed during a 24hr period.
To generate new keys, you click a button and get yourself a new set. What then? It is imperative to transfer the keys to all hub and edge servers that either send outbound or accept mail from the internet. With the new key set, the filter will start using the keys for generating BATV tokens on outbound mail but will respect the old keys for 24 hrs in order not to lose legitimate DSNs coming to Exchange org.
You might say – “Hey, I’m under backscatter attack, and I explicitly re-generated the keys to prevent bogus NDRs entering my org, but it looks like this is not going to take effect until 24hrs after!” Ahh, this is a case you can accommodate by adding the offending domain onto the antispam filter Reject DSNs from Domains. This will ensure that all NDRs from the attacking domain will get rejected and the rest will come through just fine.
Here is how the backscatter filter works. It has been implemented as two agents:
· An Outbound agent that works inside the CAT (Categorizer)
· An Inbound agent that works inside the SMTP Receive pipeline of Exchange server.
On the outbound side, the agent will stamp outgoing messages with a token (it will add it to the P1.MailFrom address) and on the outbound side, it will verify if the DSN is coming with the token attached and whether the token computes correctly. Every outbound token contains information about the original sender (sender’s address), the key used to compute the token, and the time interval when the token is valid. This means the spammers, even if they get a hold of the token, won’t be able to re-use it because the inbound agent will verify the token for integrity and if it does not compute correctly, will reject the e-mail transaction.
Any of the internal logic protection pieces will contribute to the failure, for example, if a spammer rips the token off and attaches it to multiple recipients. The token also has a limited lifetime so after its expiration the inbound backscatter agent won’t accept incoming NDRs. This is because legitimate MTAs will send their NDRs within a reasonable time interval. For the filter, the life duration of the token is seven days. However, even with all these protection layers there is a possibility of a token replay within seven days of the token origination.
Another possibility to discuss for the administrators is the possibility that the key set may get leaked or stolen (don’t ask me how or why as I believe if a malicious user gets a hold of your server, there are much bigger fish to fry than to steal backscatter keys). Anyway, if you feel your keys have been leaked somehow, you can regenerate a new set and you’re done. Maybe the next step for you would be to look into the problem and investigate what happened and why the keys got leaked/stolen from your server.
Here is a quick “Forefront Backscatter” guide or Q&A about Backscatter Filtering:
Q: Is the filter enabled by default?
A: No, you need to enable it manually.
Q: What needs to be done to get the filter working?
A: Enable the filter, generate the key set, and transfer the keys to all outbound/inbound mail processing servers.
Q: Do I need to restart Exchange Transport services?
A: Yes, you need to restart Exchange Transport manually for the agent to start working.
Q: I have two internet-facing servers in my org. How do I transfer the keys?
A: There are two buttons in the Backscatter area of the Forefront Administrator Console – “Import Keys” and “Export Keys”. When you generate the set on one server, use these buttons to transfer the keys to a file and import them to the second server.
Q: Can I have multiple key sets (one per server)?
A: No, you can’t, because the servers will start rejecting valid DSNs. You must have the same key set on all servers in your org where backscatter protection is enabled.
Q: Do I need to have the filter enabled and keys transferred to the servers that do not send mail outbound or receive directly from the Internet?
A: No, you don’t. Only servers that directly receive from the Internet or send to the Internet must have the filter enabled.
Q: How do I know when the keys were created?
A: the string on the Backscatter Filter UI indicates the creation time as shown below.
Q: I want to use the filter but I need to exclude my partner domain from being tagged with the BATV token. How do I do this?
A: You need to enter your partner’s domain onto the “Excluded Domains” list as shown below. The Outbound agent won’t stamp the P1.MailFrom with the BATV signature, and on the Inbound servers the DSNs coming from your partner domain will be excluded from backscatter processing. The screenshot below shows how to do it (enter the domain name, click Apply and Close and you are done).
Q: I’m under backscatter attack from an MTA that is reputable (not know to send spam), how do I reject DSNs from its domain?
A: Look at the screenshot below – all you need to do is to navigate to the “Reject DSNs from Domains” list, enter domain name sending you backscatter, and click Apply and Close. That’s it.
Q: Will my safe listed IPs be exempted from backscatter filtering?
A: No, but we are rationalizing this for the next release. The right way for you to exempt your safe listed IPs from backscatter processing is to enter their domains onto the “Excluded Domains” list.
Q: What is the logic behind not respecting safe listed IPs?
A: Safe listed IPs might (as legitimate RFC-compliant MTAs) unwillingly participate in backscatter as the mail originally does not originate at the safe listed IP (The safe listed IP will just send an NDR to you and it’s a backdoor for spammers that we are closing).
Q: Are there any shortcomings with the BATV technology?
A: Potential problems with BATV implementation have been listed here and here. Please read them to better understand this technology.
