SMTP bounces can be used in yet another form of Denial Of Service attack. Just imagine what happens when some script kiddie uses a few ten thousand trojaned cable/dsl connected home computers to send email to tens of thousands of domains and they all bounce back to your mail server! Why don't we all just turn SMTP bounces OFF? Like return-receipts, the information content in bounces is very low. A database would be much more efficient if you just want to know wether an email address is spelled correctly. Resending the entire message after adding a few hundred bytes is just idiotic. Escpecially if the attacker only has to send one message to generate 100 bounces. We are currently seeing this first hand: Our real mail.power.net is at 207.151.19.8. The attacker is sending individualized emails with faked headers that contain "mail.power.net (unverified [209.26.14.22])". The recipient computers are dumb enough to send their bounces to the real mail.power.net. This is a DOS because the innocent mail server a) gets millions of bounces and b) might get black listed on various "anti-spam" lists. Dirk Received: from mail.power.net (unverified [209.26.14.22]) by mee.yjapt.co.kr (EMWAC SMTPRS 0.83) with SMTP id <B0000119229@mee.yjapt.co.kr>; Mon, 21 Feb 2000 01:20:18 +0900 Message-ID: <12PAIZTiA2Vyp.5wFyFudzDR_N8@mail.power.net> From: FinancialJobs70972@power.net <FinancialJobs70972@power.net> Bcc: Subject: Private Consultants Needed for Venture Capital Firm Date: Mon, 30 Mar 1998 10:04:48 -0400 (EDT)
At 11:04 AM 2/20/00 -0800, Dirk Harms-Merbitz wrote:
We are currently seeing this first hand: Our real mail.power.net is at 207.151.19.8. The attacker is sending individualized emails with faked headers that contain "mail.power.net (unverified [209.26.14.22])".
The recipient computers are dumb enough to send their bounces to the real mail.power.net.
This is the problem - a mail server stupid enough to send a bounce to an unverified host name, instead of the connecting IP address.
This is a DOS because the innocent mail server a) gets millions of bounces and b) might get black listed on various "anti-spam" lists.
What anti-spam list maintainer would add an unverified host name in a header? Especially when the IP address does not match the hostname?
Dirk
TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)
On Sun, 20 Feb 2000 11:59:42 PST, I Am Not An Isp <patrick@ianai.net> said:
This is the problem - a mail server stupid enough to send a bounce to an unverified host name, instead of the connecting IP address.
Stupid or not, that's required by the RFCs. Take a look at this mail, the original From: points at 'vt.edu', which is MX'ed to mail.vt.edu. However, that's NOT the address that the NANOG mailing list is receiving this mail from. For that matter, did the mail from 'ianai.net' arrive at the NANOG mailing list *from* ianai.net? I see this in the headers: Received: from pgilmore (PIX46.pgexch.com [208.217.23.46]) by pyrite.eod.onyx.net (8.9.3/8.9.3) Hmm.. Must be spam we should have rejected, since there's a case to be made that you shouldn't accept mail you can't send a bounce message back to, and your mail obviously came from an unverified IP address... Be careful what you ask for, you may get it... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
On Sun, Feb 20, 2000 at 03:41:06PM -0500, Valdis.Kletnieks@vt.edu wrote:
On Sun, 20 Feb 2000 11:59:42 PST, I Am Not An Isp <patrick@ianai.net> said:
This is the problem - a mail server stupid enough to send a bounce to an unverified host name, instead of the connecting IP address.
Stupid or not, that's required by the RFCs. Take a look at this mail, the original From: points at 'vt.edu', which is MX'ed to mail.vt.edu. However, that's NOT the address that the NANOG mailing list is receiving this mail from.
For that matter, did the mail from 'ianai.net' arrive at the NANOG mailing list *from* ianai.net? I see this in the headers:
Received: from pgilmore (PIX46.pgexch.com [208.217.23.46]) by pyrite.eod.onyx.net (8.9.3/8.9.3)
Hmm.. Must be spam we should have rejected, since there's a case to be made that you shouldn't accept mail you can't send a bounce message back to, and your mail obviously came from an unverified IP address...
MTA's don't send bounces to host names in Received: headers, they send bounces to RFC 822 envelope sender addresses. (At least, that's what they're SUPPOSED to do.) Some MTA's will barf when given a bogus MAIL FROM ("Sender domain must resolve") but some will not. The server that is getting deluged by bounces is most likely getting them because the senders are using that domain in the envelope sender, not because of the fake insertion into the Received: headers. --Adam
On Sun, 20 Feb 2000 15:57:20 EST, Adam McKenna said:
MTA's don't send bounces to host names in Received: headers, they send bounces to RFC 822 envelope sender addresses. (At least, that's what they're SUPPOSED to do.)
Correct. But the person said we *should* bounce back to the originating IP address, which is what's logged in the Received: header. My point was that if we *did* what he suggested, *his* mail would quite possibly be broken by taking the action. I've seen a number of mail packages (PP from the ISODE comes to mind, but there's others) that refused to accept mail if they couldn't verify at message submission time that they'd be able to send back a bounce message. I'm not saying that's correct EITHER, just that there's sites that do that. The *real* fix is for everybody to refuse to accept mail from spamhauses or identified open relays. Not that *that* approach doesn't break things as well (most notably, you don't accept mail from innocent people who happen to be unlucky/unclued enough to use the same ISP as the spamhaus). If solving spam and DOS problems were simple, we'd all have gotten out our baseball bats and DONE it already..... ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
At 04:07 PM 2/20/00 -0500, Valdis.Kletnieks@vt.edu wrote:
Correct. But the person said we *should* bounce back to the originating IP address, which is what's logged in the Received: header. My point was that if we *did* what he suggested, *his* mail would quite possibly be broken by taking the action. I've seen a number of mail packages (PP from the ISODE comes to mind, but there's others) that refused to accept mail if they couldn't verify at message submission time that they'd be able to send back a bounce message. I'm not saying that's correct EITHER, just that there's sites that do that.
Sorry, guess I misread the original post. I thought he was just sending it to a random hostname in the received headers, not in the from field. Oh, well, just goes to show you cannot trust someone without enable! :)
Valdis Kletnieks
TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)
Not exactly a solution, but a fix is using a program like SpamProtect or SpamControl (even on a server that is not open to relays). Our mail servers will locally blackhole IPs from mail servers sending us far too much mail in far too short a time period. Certain large mail servers have higher thresholds. In the unlikely case a server (or several) are blackholed, our NOC is notified by the mail server for a human-intervention decision. This does not break legitimate SMTP mail, except possibly from the abused mail servers, and is context-sensitive filtering. Deepak Jain AiNET On Sun, 20 Feb 2000, Dirk Harms-Merbitz wrote:
SMTP bounces can be used in yet another form of Denial Of Service attack.
Just imagine what happens when some script kiddie uses a few ten thousand trojaned cable/dsl connected home computers to send email to tens of thousands of domains and they all bounce back to your mail server!
Why don't we all just turn SMTP bounces OFF? Like return-receipts, the information content in bounces is very low.
A database would be much more efficient if you just want to know wether an email address is spelled correctly. Resending the entire message after adding a few hundred bytes is just idiotic. Escpecially if the attacker only has to send one message to generate 100 bounces.
We are currently seeing this first hand: Our real mail.power.net is at 207.151.19.8. The attacker is sending individualized emails with faked headers that contain "mail.power.net (unverified [209.26.14.22])".
The recipient computers are dumb enough to send their bounces to the real mail.power.net.
This is a DOS because the innocent mail server a) gets millions of bounces and b) might get black listed on various "anti-spam" lists.
Dirk
Received: from mail.power.net (unverified [209.26.14.22]) by mee.yjapt.co.kr (EMWAC SMTPRS 0.83) with SMTP id <B0000119229@mee.yjapt.co.kr>; Mon, 21 Feb 2000 01:20:18 +0900 Message-ID: <12PAIZTiA2Vyp.5wFyFudzDR_N8@mail.power.net> From: FinancialJobs70972@power.net <FinancialJobs70972@power.net> Bcc: Subject: Private Consultants Needed for Venture Capital Firm Date: Mon, 30 Mar 1998 10:04:48 -0400 (EDT)
participants (5)
-
Adam McKenna -
Deepak Jain -
Dirk Harms-Merbitz -
I Am Not An Isp -
Valdis.Kletnieks＠vt.edu