spf-discuss
[Top] [All Lists]

Tarpitting and SpamCannibal (was Re: Brainstorming RFROM variants)

2004-05-22 05:06:45

On Saturday 22 May 2004 00:54, Seth Goodman wrote:
The qsmtpd list has had much discussion of the "spamcannibal" approach
in which your MTA informs your firewall to drop a random half of the
packets arriving on this eschewed connection.
Sounds interesting.  What can you tell us about this?

I sort of started it off by suggesting a change to qpsmtpd to add a "tarpit" 
return code that would bog down the sender (originally the idea was just to 
sleep for a while between replies to slow down the sender). Unfortunately the 
way qpsmtpd is typically run with tcpserver or the like (which puts a limit 
on the number of concurrent connections), this isn't such a great idea (you 
end up DOS'ing yourself), so Matt Seargeant suggested instead passing the 
offending socket to a seperate daemon (quoting some Stevens code to do this) 
which would just tarpit all the sockets it received and throw the data away.

Then someone suggested the more sophisticated SpamCannibal 
(www.spamcannibal.org) which I looked at, and is nice but has a very specific 
setup, but basically it builds a database of offending source IP numbers 
(including reading black hole lists), and then uses iptables to tarpit any 
new connections from those IPs: it filters the initial TCP connect and, in 
completing the handshake, it sends back flow control flags that set the 
packet data and packet window to very small numbers, and then it throws away 
any packets received on that connection without ACKing them (and they never 
get to your SMTP server). In this way SpamCannibal itself is stateless and 
requires very few resources but the sender is bogged down sending packets 
that never get ACK'ed, the author claims to have tarpitted certain single 
connections for 3 months before the spamming software gave up.

The problem is that you can't do this part way thru a connection with 
SpamCannibal, so I thought I'd adapt qpsmtp so that you can soft-fail a 
connection (replies with a "try again" error code and closes the socket) when 
you figure they're a spoofing spammer, but at the same time you add the 
offending IP to SpamCannibal (or a reduced copy of the key items of 
SpamCannibal) for new connections in, say, the next 24 hours.

But my setup here is a bit screwed with respect to iptables and a few other 
things SpamCannibal needs, so this has moved down the queue until I get a 
weekend to get the prerequisites in and working.

To my mind this sits very well with SPF - I'm happy to blindly tarpit any IP 
that spoofs a sender name, whereas I wouldn't want to blindly tarpit hosts 
that send me spam or else I'd be forever blocking hotmail, aol, yahoo etc. 
etc.

Cheers

--
Tim