OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: SMTP stutter (simulated tar pit) to fight spam

From: mouss (mlist.onlyfree.fr)
Date: Mon Jan 07 2008 - 08:49:43 CST


Bernhard Reiter wrote:
> There is a method proposed to reduce spam:
> Simulate a tar pit so that spammers will give up,
> by stuttering the first n bytes of an SMTP connection.
>

few comments:

- like some other approaches, this is only effective if a lot of sites
implement it. otherwise, spammers have a lot fo available resources.

- Beating this is not hard. a concurrent client can talk to other places
instead of waiting for the response.

- you need to know whom to tarpit. if you use your own logs, it may be
too late (the same client won't necessarily connect again to your
server). if you use "public" lists, you need to update regularly (I know
of no list with rsync access, so you're gonna download a full list all
over again).

- if you tarpit based on infos such as rdns, DNSBL, helo, ... etc, then
the simplest approach requires that you be ready to greylist legitimate
clients (the alternative being a proxy that hands good connections to
the MTA, but you either need to do some checks in the proxy, or
implement XCLIENT).

> I have just read an article by Thomas Eggendorfer
> in the German Linuxmagazin (02/08 pages 74ff.).
> Eggendorfer published about this a lot, see
> http://www.unibw.de/inf3/institut/personen/wimis/eggendorfer/eggendorfer_publ .
>
> I have not yet found an English paper which would be openly accessible,

http://spamlinks.net/filter-server-tarpit.htm

some numbers can be seen on the whitepapers available at
http://www.mailchannels.com/

> [snip]
>
> Having a stuttering postfix seems attractive. ;)

not "directly". because when an smtpd process pauses, it does nothing
else. so if you are tarpitting N clients and N is the number of smtpd
processes, then I'd call this "self DoS". ifconfig down is probably more
effective :)

you can redirect the flow coming from a "bad" client to a tarpit daemon.
This requires having a list of bad clients (which you can regularly
download from some sites, and/or enrich by log parsing...).

if using *BSD, you can try pf with (OpenBSD) spamd (not to be confused
with the spamassassin daemon with the same name).

<grin>
given how pf mailing list is filtered, I'd think ten times before buying
in this. I hate spam, but I still want some mail ;-p
</grin>