Good tool for countering Bounce Bombs (aka: backscatter)

[metoometoo]

First I am not affiliated in any way with the producers of the tool listed below, just a user that got "Bounce Bombed" to its knees during the past weeks, and could not find any other practical solution to stop the attack.

If you are on the wrong end of one of these attacks you know how destructive it can be. It can bring down your server to a halt beacuse is a form of DDOS attack. I recommend you configure DNSBL on your email servers to query: "ips.backscatterer.org" ASAP.

See Backscatterer.org for more information. In may case it just stopped the attack on its tracks, and they also seem to test (not sure) any IP addresses submitted for this vulnerability, so it really works, and it's FAST.

As you may well know, "Bounce Bombs" (aka: backscatter) is a technique used by spammers and/or email harvesters, to take advantage of poorly configured email servers and virus scanners by including the email addresses of the victims (YOUR EMAIL ADDRESSES), as the return address on the emails they send, thus causing an enormous amount of bounced emails back to your servers when the (poorly configured) system fails to direct the emails to valid users.

Simply put "poorly configured" systems in this case, means email servers and virus scanners set to reject ALL invalid emails back to the forged return addresses. To configure email servers and virus scanners not behave this way is as simple as having them DROP invalid emails, and to never bounce or soft-bounce.

Yes you may say this (rejecting) is the standard protocol, and you are doing nothing wrong by issuing rejects, BUT that comes from a time when the email systems worked on the assumption that this feature will never be abused as it is these day.

Hope someone will find this information useful, and please forgive my ignorance, or lack of technicality of some of the terms used.

[Farelf]

Thanks metoometoo, I've seen that organisation cited elsewhere as a useful resource for information and, no doubt, anyone afflicted with an unusual amount and duration of backscatter might seriously consider adding the bl to their armoury. A problem with the present state of the internet is the increasing uncertainty of delivery with more and more blocking based on numerous and often compounding criteria being instituted on servers up and down the communications chain. In that context, the qualification you make (my emphasis - I guess I'm turning it into a qualification that you may not have intended)

If you are on the wrong end of one of these attacks you know how destructive it can be. It can bring down your server to a halt beacuse is a form of DDOS attack. I recommend you configure DNSBL on your email servers to query: "ips.backscatterer.org" ASAP.

... is important, IMO. In other words, application in the absence of specific need might not be advisable. If others are already using the bl, their experience might indicate otherwise?

[turetzsr]

<snip>

Simply put "poorly configured" systems in this case, means email servers and virus scanners set to reject ALL invalid emails back to the forged return addresses. To configure email servers and virus scanners not behave this way is as simple as having them DROP invalid emails, and to never bounce or soft-bounce.

<snip>

...Elsewhere in the SpamCop Forums, I have seen the suggestion to reject the message during the SMTP handshake with a 5xx (reject) message. That way, the actual source of the spam (not the forged return addresses) receives a message that tells her/him that something is wrong. Dropping the invalid e-mail provides no such feedback and is therefore a problem in the case of an e-mail falsely identified as invalid.

[metoometoo]

...Elsewhere in the SpamCop Forums, I have seen the suggestion to reject the message during the SMTP handshake with a 5xx (reject) message. That way, the actual source of the spam (not the forged return addresses) receives a message that tells her/him that something is wrong. Dropping the invalid e-mail provides no such feedback and is therefore a problem in the case of an e-mail falsely identified as invalid.

Yes turetzsr, I stand corrected, I should have better explained what I am doing, but you are partially right, when you say all dubious messages should be rejected with a 5xx code during handshake. The problem is that this proposition is not valid for all conditions, such as stopping spam or abuse in the form of a DDOS attack.

In the case of massive abuse or attacks from well established sources, the customary procedure is to have the email server configured to issue 554 (Service unavailable) such as is the case with rejects used at entry point to your email servers by using DNSBL services.

On the other hand when it comes to spam and viruses identified by such programs as Antiviruses and Antispammers, is better to issue a Drop or Discard, since if you do not do this then you will be flooding someone else's server with Bounced Emails (Bounce Bombing), and you could easily become part of the problem, not the solution. Remember that there is no easy way to determine the legitimacy of the return address, which is often forged.

IMO, The beauty of using a anti-backscatter BL such as "ips.backscatterer.org" is that you are only using rejects to servers that are well known to be active Mass Bounce Bombers, and additionally the inclusion of their IPs on the black Lists is temporary; after 4 weeks the offending IPs are automatically removed from the list, unless the problem persists. A few bounced emails here and there do not grant automatic inclusion in their BL, so you still get back legitimate bounces.

This service I think also gives oneself and others some flexibility, in case (god forbid) one's servers temporarily become the "active" source of such attacks, the fact of not being permanently added to a Black List somewhere, gives some peace of mind. The keyword here is temporarily, since these sort of attacks do not stay localized at determined IPs or servers for very long, nor do the owners of such servers are willfully involved in these activities.

[StevenUnderwood]

On the other hand when it comes to spam and viruses identified by such programs as Antiviruses and Antispammers, is better to issue a Drop or Discard, since if you do not do this then you will be flooding someone else's server with Bounced Emails (Bounce Bombing), and you could easily become part of the problem, not the solution. Remember that there is no easy way to determine the legitimacy of the return address, which is often forged.

You seem to be confused about how 5xx rejections work. These rejects do not use the forged return address at all. The sending server gets the 5xx message but knows which authenticated user it received the message from and delivers it that way. Most spammer/virus software has it's own SMTP engine and would not understand the 5xx reject. Either way, the message trail ends with the 5xx reject.

[metoometoo]

You seem to be confused about how 5xx rejections work. These rejects do not use the forged return address at all. The sending server gets the 5xx message but knows which authenticated user it received the message from and delivers it that way. Most spammer/virus software has it's own SMTP engine and would not understand the 5xx reject. Either way, the message trail ends with the 5xx reject.

Yes I admit, I am way over my head in this one, I know enough as to get in deep trouble , BUT I am using amavisd-new tied to spamassassin and Clamav, and the recommended selection is to D_DISCARD spam and viruses. Really do not know why that is, but is the way it works. Me thinks it has to do with the messages already being accepted for delivery, and later realizing it contains spam or viruses.

BTW, it's impressive how fast the Bounce Bombers fix their servers once they realize they are on a Black List. Before adding the DNSBL (ips.backscatterer.org) no amount of reporting would make them even consider a fix. Now after two days the mail logs on my servers do not show a single hit from them ... I am a very happy camper indeed.

[Farelf]

...BTW, it's impressive how fast the Bounce Bombers fix their servers once they realize they are on a Black List. Before adding the DNSBL (ips.backscatterer.org) no amount of reporting would make them even consider a fix. Now after two days the mail logs on my servers do not show a single hit from them ... I am a very happy camper indeed.

Impressive indeed but I wonder if it's just about being on a bl? Wouldn't have thought listing on ips.backscatterer.org by itself would be much of a burden for them. If it's the usual, impersonal, incidental occurrences, the 'runs' end soon enough anyway, even without LARTing the multitude of indolent providers responsible.

Maybe the quality and persuasiveness of the explanations and pointers to the fixes that go with the "package" (SpamLinks) have more to do with it? Concentration on a single, relatively easily addressed issue undoubtedly helps. The relative ease of delisting (with the inevitability of relisting if behaviors not actually changed). And the absence of "baggage" - people have all sorts of weird ideas about (for instance) SpamCop, expectations, etc. And SC's broad-base coverage of multiple internet ills perhaps makes it 'hard' for admins to focus on the necessary fixes while the potecy of the SCbl (fairly broad user base) adds some urgency/panic.

Anyway, glad you are happy with it and undoubtedly others would/will be too. If it is so effective, the 'product life' should not be overly long, I would think - there are only 'just so many' of the clueless admins to be educated, moreover the fixes tend to be permanent/long-lived. Whatever. We're each of us grateful for anything that seems to work for us, when it is needed. If 99.9% of what is hitting your account is spam and backscatter (as is the case in a backscatter run) some help may well be needed. But if that is happening often, it is probably time to abandon your email address (or just use it as some sort of spam trap) because it sure isn't serving its intended purpose any more.

[washmail]

We're 'resellers' - we use an SP (service provider) to supply all the domains and email boxes, so we don't work at server level.

One of our clients had a huge spam problem; 200 - 300 a day. I took it upon myself to sweat out a few days of intensive SC reporting on their behalf, only to end up having them intensely bounce bombed for 3 days.

We now know that we could in future turn to our SP for assistance, but I'm wondering if anyone knows if any private-use software is available for dealing with such at the end user level?

Also, is this a standard service usually offered by ISPs/SPs etc., or is it another hole of concern in the general system?

[Farelf]

...but I'm wondering if anyone knows if any private-use software is available for dealing with such at the end user level?...

User-level implementation? That just keeps the stuff out of the user's Intray, leaves the stuff to be dealt with/disposed of in isolation. But, washmail, (ahem) MailWasher is one such application IIUC ("Origin of spam" tool) - http://wiki.castlecops.com/MailWasher_Pro_Filters - just turn off the 'bounce'/fake NDN feature and use the list ips.backscatterer.org, content filtering, whatever. I do have details of another user's recommendations on another computer which I will add when I have access.

...Also, is this a standard service usually offered by ISPs/SPs etc., or is it another hole of concern in the general system?

Providers seem to be increasingly filtering user accounts like mad (using various tools and with variable results), both inwards and (less often admitted) outwards and 'dropping' the adjudged dross 'on the floor' - that is without notification or hope of retrieval of any false positives. I don't believe users know the full extent of this, the average user wouldn't even be aware or care.

This filtering is, no doubt, *the* cost-effective solution for providers and (for outwards filtering) advances a minimal or demonstratable measure towards controlling the transmission of spam which many of them are now required to do under the locally-applicable regulations/guidelines. Backscatter is still believed to be exempt by many (because it is 'required by rfc822'). Those (providers) that are aiming to grow their businesses - as opposed to pumping numbers preparatory to selling at a fabulous profit - should be amenable to considering other solutions for a higher fee. Or you can put an edge transport server between the exchange server and the internet - http://searchexchange.techtarget.com/gener...1262402,00.html - which might be an option in a large organisation.

[washmail]

But, washmail, (ahem) MailWasher is one such application IIUC ("Origin of spam" tool) - http://wiki.castlecops.com/MailWasher_Pro_Filters - just turn off the 'bounce'/fake NDN feature

Yep, you caught me out - we're huge fans of Mailwasher, don't know what we would do without it - hence my SC name.

Never really looked at their filters. Haven't been much into that - we've usually just identified manually, and now found our SP filters to be very efficient. But bounce bombs are a different matter...

Off subject a bit, I've been communicating with Mailwasher's creator with a number of suggestions. One he plans to impliment (hopefully shortly) is IMAP access for other-than-inbox folders, I.E. access to one's spambucket!!

Providers seem to be increasingly filtering user accounts like mad (using various tools and with variable results), both inwards and (less often admitted) outwards and 'dropping' the adjudged dross 'on the floor' - that is without notification or hope of retrieval of any false positives. I don't believe users know the full extent of this, the average user wouldn't even be aware or care.

I caught our ISP out doing all these things, and collected undeniable evidence! They're responsible directly or otherwise for the vast majority of our country's email traffic. Only when I threatened them with the press did they make efforts to correct some of it, but we're still waiting to see user-accessable spambuckets.

Thanks for the info!

[Farelf]

...Thanks for the info!

You're welcome.

Advice from Kevin A. on the News Server Temporary Gateway Newsgroup grc.spam, thread Bounced spam (A repected poster throughout GRC News and whose website includes Information Sources - spam)

Depending on the capabilities of your mail filtering you could also set up a few rules to delete most of them. Be sure to take the rules out when the run is over or you could lose legitimate bounces.

/<>$/f will catch Null Return Paths, which bounces should have.

Filtering for that and subjects containing 'verification', 'Out of Office', 'undeliverable', 'failure notice', 'returned mail' and 'returned email' gets well over 99% of them here. Filtering for subjects containing 'Considered UNSOLICITED BULK EMAIL' will get most of the bounces from Barracuda spam Firewalls.

Also see http://www.dontbouncespam.org for a little background

...and

Of the ones I've checked a little over 50% are listed there (Ed. - ips.backscatterer.org). If I'm reporting backscatter I try to look them up there because I think it helps impart a clue if I can _show_ the sending server admin that their backscatter has got them listed on a blocklist. :-) Even if it's just that list. But often if they're listed there, they're listed on others as well.

...

K9 does an amazing job with bounces here. It tags virtually all of the backscatter, and doesn't flag the very rare legitimate delivery failure notice that I get. :-)

...Only when I threatened them with the press did they make efforts to correct some of it, but we're still waiting to see user-accessable spambuckets.

If a false positive falls in a bit-bucket and no-one hears it fall, does it make a sound? Which might be paraphrased as "A false positive unseen is a false positive deniable." When all this filtering business started running rampant, a few incidental players were claiming "0% false positives" which is patently absurd. Or they use =ROUND(x,-1)