RE: Block notification / bounce mails (as in DDOS)

["Rainer Gerhards" <rgerhards () hq adiscon com>]

We have also worked around similar situations by setting up new postfix
boxes on a COLO facility. Thus, you direct the excess traffic to the
COLO (you should make sure your plan covers enough traffic allowance,
but this can nowadays purchased *very* inexpensively). Then, on the COLO
server, you configure a quite agressive postfix/spamassasin eventually
virus scanner. For the large bunch in question, configure postfix rules
that work on the envelope ... this is extremely efficient. When done,
change your MX to the colo box. Also make sure that your real mail
server only accepts traffic from the front end box. If you select a good
colo facility, it is hard to envision you will run out of bandwidth just
because of smtp bounce traffic, even when the number is very high.

A collague had a very similar situations where the scenario actually
happened to their low-powered home boxes at low-bandwitdh DSL
(768Donw/128Up) accounts. They received several 10.000 NDRs but the only
annoyance was to delete these, which obviously was done quickly by some
filtering.

Just my 2cts...

Rainer

> -----Original Message-----
> From: Security Administrator [mailto:security () saland us] 
> Sent: Thursday, April 01, 2004 8:44 PM
> To: Koen
> Cc: full-disclosure () lists netsys com
> Subject: Re: [Full-disclosure] Block notification / bounce 
> mails (as in DDOS)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm not sure that saying the server is "dead" is a fair 
> question.  I mean
> if it's dead because of a hardware problem then why ask a security
> professional the question in the first place.  If on the 
> other hand it is
> dead due to the apparent "ddos" attack of incoming mail,  it should be
> possible to disconnect the box from the network,  restore it 
> and add in
> filtering capabilities which alleviate the issue, and then 
> put it back on
> the network.
>
> One option, which has been used to great success under during 
> the serious
> outbreak of Sobig.F last year,  was to use Milter on sendmail.  Using
> Milter it is possible for a sendmail server to match via 
> regex on incoming
> headers on a new incoming message.  This matching can happen 
> as early as
> during the transmission of the envelope and as such can be 
> done in a way
> that the mail server drops the TCP connection before it ever 
> even commits
> the message to disk (the typical problem that actually "kills" a mail
> server in these circumstances is I/O overload).
>
> I have seen a configuration like this,  along with sane sendmail
> configurations, recover a seemingly "dead" mail farm under 
> heavy attack
> from floods of virus mail in conjunction with bounce 
> notifications.  This
> attack was of such a magnitude that multiple sendmail 
> servers, each with
> the capability of handling upwards of a few hundred 
> simultaneous messages,
>  were brought to their knees.  While moving to the above configuration
> obviously didn't restore them to their previous operating 
> capacity,  it
> allowed mail to flow at a decent pace rather then standing still.
>
> If however you have a problem with your network bandwidth 
> being absorbed
> by the incoming connections you would need additional 
> measures,  such as
> upstream filtering by inline devices capable of removing the 
> connection
> attempts before they traverse your WAN link.  There are 
> numerous devices
> that could be employed to alleviate the traffic, with the help of your
> ISP.
>
> Joe
>
> > Luke Norman wrote:
> > > > What do you all suggest to this 'seemingly' DDOS-attack 
> (allthough not
> > > > intended as a DOS)?
> > > Set up a server-side bayesian filter to block all e-mails 
> containing
> > > certain words (such as 'address not found' or similar). I'd be very
> > > suprised if there isn't a filter like this already available if you
> > > google it. Have a look at the 'fighting useless notification mails'
> > > thread from a few days ago, which is a related topic
> >
> > This would be an option if the mailserver is still capable 
> of handling all
> > or
> > some of the mail. As the question was raised, this is not 
> the case. The
> > 'theoratical' situation is that my mailserver is as dead as 
> a doornail
> > (not
> > really crashed but out of oxygen..network-bandwidth).
> >
> > Thanks anyway for the response (and yes, the thread on 
> fighting.... is
> > indeed
> > very helpful for the case where I have some 'spare' bandwidth)
> >
> > Koen
> >
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
> - --
> - 
> --------------------------------------------------------------
> ----------------
> Joe Saland, CISSP
> joe<|at|>saland<|dot|>us
>
> Encrypted mail preferred
> - ------------------------
> GPG Key: gpg --keyserver pgp.mit.edu --recv-key 0x89A8BC38
> GPG Fingerprint: 5C45 4824 E2F1 AA58 FBDA E388 D9D9 A330 89A8 BC38
> - 
> --------------------------------------------------------------
> ----------------
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAbGMJ2dmjMImovDgRAqfUAKCnB8naqadP/5/2kmVDuQXFdLaPJQCeJ7Zh
> 6bqTQLGAaX/hWvrvNL8IHIY=
> =53aQ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html