ietf-smtp
[Top] [All Lists]

Re: Proposal: Using Conservative EHLO Response Parser Behaviour For Tarpitting

2007-06-18 15:54:58

Hi Lisa, David and others,

On 18 Jun 2007 at 10:47, Lisa Dusseault <lisa(_at_)osafoundation(_dot_)org> 
said:

On Jun 18, 2007, at 5:41 AM, David F. Skoll wrote:

1) Tarpitting occupies server resources, making it easier to DoS the
server.

It certainly does.  It depends on which position you take as to whether or 
not this is a problem any more than it is already, though; someone 
connecting to a server and simply keeping the connection alive with NOOPs 
or equivalent commands can achieve the same thing if the servers limits 
are within easy reach of the client and/or the implementation lends itself 
to DoS (fork vs events, etc).  The administrator of the server is 
obviously responsible for making the compromise of tarpitting performance 
over immediate mail deliverability (if you use greylisting, you're already 
less concerned about the latter).

The only thing I can think of right now that would make DoS noticeably 
easier is that it now only takes a spammer to somehow entice other 
machines to send mail to a tarpitting host in order to increase the chance 
of DoS at the tarpit (either crashed host due to misconfiguration or 
delayed mail due to limits being exceeded).  The server should obviously 
avoid taking multiple connections from any given IP to cut off the most 
obvious line of attack if that's necessary.  Finally, the problem is only 
there if hosts are sending mail under an attacker's control.  Maybe 
bounces sent by mailers that accept mail before noting delivery problems 
(like qmail) will be an issue here.  Otherwise, the mass source of 
addresses that connect under spammer control is essentially the spambots, 
and those are the very machines you want to hold up for as long as they're 
willing to wait.  Also, every host that passes mustard gets whitelisted, 
so there's a maximum time that the mailer can spend tending to a 
connection.

2) Tarpitting is useless against an attacker with essentially infinite
CPU and bandwidth resources --- and that's the kind of attacker a 
serious spammer is.

I'm aware this is no simple adversary.  (Deploy a dummy SMTP service that 
accepts all commands except RCPT which causes the connection to be closed, 
give it an MX, then spread addresses routable to it.  Then just watch what 
happens.  You'll just see each rejection followed by yet another host 
willing to try.  Fun, but be careful.)  If most spam gets sent to a host 
using this scheme, then most spambots are waiting to deliver mail.  Unless 
spammers exponentially increase their supply of spambots, though, spammers 
will soon hit the impass at the current rate of spambot deployment where 
the number of bots available will simply not be able to get current 
throughput without skipping recipients.  They will have to assign more 
threads/processes to each machine to process the deliveries, which would 
endanger the client host system (to presumably noticeable levels); they 
would slow down if they did things sequentially, and the timeouts unique 
to each host make it impossible for a spammer to plan ahead of time which 
hosts he will target for a full delivery (like greylisting, except that 
this can be defeated by simply running a blast twice, for instance).  That 
assumes spammers adapt, of course; if they don't (or while they don't) 
you'll presumably enjoy a niche privilege.  But the load has to be 
distributed among a finite number of spambots in the end, and if that 
means we can put greater demand on each host while it is doing absolutely 
nothing but reading continuation lines from, I don't know, 50 different 
smarthosts it is planning to slam, then all the better.

3) Relying on "genuine" clients to adhere strictly to RFC-defined  
timeouts
is dangerous.

The five minute timeout is the minimum required, so it would be the 
foreign host in violation.  A zealot wouldn't care, but I would.  This 
idea doesn't use that timeout, though; it sends continuation lines 
periodically at short intervals that all hosts are practically guaranteed 
to tolerate.  My real worry is that a client might close the connection 
before being sent the final line in a sequence; that's obviously a serious 
problem for this idea.

4) It is perfectly possible to delay the client before EHLO.   
That's what
Sendmail's greet_pause feature does.  However, it's *not* designed  to be

Please go back and read my original message again.  I think you missed the 
point.  Pausing at the greeting is not an option because there is no way 
to make the client hold the line at that stage for longer than it wants 
to.  Force-feeding lines to a client which it must read the whole time 
you're doing it without daring to say anything, though, is enough either 
to waste a spammer's time or make it lose patience and incriminate itself 
(either by saying something after what it presumably thinks is a complete 
response or by dropping the connection).  In the former case, multiple 
implementations of the tarpit endanger more bots, and in the latter you 
get less spam!  That's the goal.

a tarpitting mechanism.  Rather, it's designed to detect SMTP clients
that send everything in one burst without waiting for the initial 
greeting (and also to detect clients that use broken proxy servers.)

That's true, although a lot of people reported setting quite insane values 
for greet_pause like a full two minutes, since a lot of spambots will 
indeed have lost interest by then.  Unfortunately, as you remarked, a few 
clients won't use the timeouts given in RFC 2821 and will also have quit 
before then, too.  I'm not sure whether HTTP proxies are in fashion 
anymore; I never see them more often than about twice a month on my 
personal machine compared to the 3000+ aborted attempts.  (But once again: 
this is not the way this proposal functions.)  

adding:
5) If this were standardized or even widespread, spammers would adapt 
easily (much easier than the good actors can change).  It can only be 
useful as a trick that a few systems use.

I agree with all except the last sentence in the long-term, all otherwise. 
 Having deployment is part of the master plan (You can tell I've got a 
real gripe against spammers, can't you? :-) ), but not having more than a 
few is as likely to bring benefits like those of greylisting to those who 
want it while helping to slow down the existing spam-sending client 
population if they choose to wait.  If they don't, you've essentially got 
a safer greet_pause function.

I'm going to put this on the back burner for a while because I'll 
obviously have to test it for myself, and that'll require some coding for 
which I don't yet have the time (probably start with a proxy).  I'd be 
interested in any further comments, though.  The *main* point here is not 
so much the exact specification of an extension (the extension is only 
there so that we can send multiple, delayed lines in response to 
EHLO/HELO), but that client behaviour is, to the best knowledge of people 
here, sufficiently good in all truely robust client implementations to 
support this slight abuse of the characteristics of a linear protocol like 
SMTP with continuation lines.

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399

<Prev in Thread] Current Thread [Next in Thread>