OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Feature Suggestion: Tar-Pit flag in Postfix 2.1 proxy

From: Michael Tokarev (mjttls.msk.ru)
Date: Mon Feb 02 2004 - 12:35:14 CST


Orlando Andico wrote:
> On Mon, 2 Feb 2004, Andrzej Kukula wrote:
> ..
>
>>>P.S. Don't ask me for code - it's something written in 2
>>>hours without much thinking, it's a pile of mess.. Maybe some
>>>day... ;)
>>
>>Hey! Do share the code please. There are some people eager to see such a
>>solution. I have been thinking about it a long ago, but (being lame :) I
>>couldn't do it myself. And I still can't... :(
>>
>>Besides, knowing your previous experience, I seriously doubt the above
>>is true.

What did you mean?

> Yeah! we'd love to see that code! I'm doing the firewall thingie because
> we had the same problem --- hundreds of parallel smtpd's and no mail
> getting delivered.
>
> Question: how would the tarpit daemon handle SMTP Auth? this is a feature
> we need to support.. yes the thought of using epoll() also occurred to
> me.. perhaps if you released the source it could be improved on? :)

The process that listens the network and handles connections from "bad"
guys does not handle "good" sessions: it *spawns* new SMTPD, it does
no proxy-connection. So the whole thing is completely transparent for
"good" sessions.

As of how it works - try it out going from any DSBL-listed open proxy
to our MX.

And no, I don't want to share the code now. The main reason is
that it is not correct. It uses local DNS blocklist to descide
whenever to tarpit the connection or to pass it to real smtpd.
And the problem is that the DNS query is NOT asyncronious, it is
done using gethostbyname(). It's ok for locally-running nameserver
(well almost anyway), but it will not work with any other "remote"
blocklist. And I don't want to made such bad descision public,
so that others will start repeating the same mistakes. Once I'll
complete some sort of async stub resolver (maybe based on djbdns,
maybe something other that fit nicely within some sort of "async
event" library), that will be possible to made the whole stuff
public. Either way, the program is very small right now, about
30 Kb of C source (w/o any comments ;)

/mjt