Re: Tarpitting and SpamCannibal (was Re: Brainstorming RFROM variants)

What if 89% of your spam comes from other ISP's main MTAs like 
bellnexxia, comcast, videotron, bigpond, bbtec, fuse, earthlink, etc.... 
Do people think these tarpitting approaches would be a good alternative 
(as opposed to blocking the MTAs outright)?
-Carl

PS: I do agree that you need to tarpit before the SMTP host due to 
connection limit and DOSing yourself. We have that same concern.
tim(_at_)schmerg(_dot_)com wrote:

> 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
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Latest draft at http://spf.pobox.com/spf-draft-200405.txt
> Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
> To unsubscribe, change your address, or temporarily deactivate your subscription, 
> please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>  
--
Carl Hutzler
Director, AntiSpam Operations
America Online Mail Operations
cdhutzler(_at_)aol(_dot_)com
703.265.5521 work
703.915.6862 cell