lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: security at (Security Administrator)
Subject: Block notification / bounce mails (as in 

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


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

- --
- ------------------------------------------------------------------------------
Joe Saland, CISSP

Encrypted mail preferred
- ------------------------
GPG Key: gpg --keyserver --recv-key 0x89A8BC38
GPG Fingerprint: 5C45 4824 E2F1 AA58 FBDA E388 D9D9 A330 89A8 BC38
- ------------------------------------------------------------------------------

Version: GnuPG v1.2.4 (GNU/Linux)


Powered by blists - more mailing lists