|
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 (mjt
tls.msk.ru)
Date: Mon Feb 02 2004 - 08:32:40 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Orlando Andico wrote:
> On Mon, 2 Feb 2004, Orlando Andico wrote:
> ..
>
>>>I just had the idea to implement a tar-pit flag in the Postfix proxy. If
>>>a filter (e.g. spam-filter or virus-filter) detects a malicious mail and
>>>sets the tar-pit flag for a connection, Postfix would keep the
>>>SMTP-connection for a time specified in TAR_PIT_TIMEOUT in smtpd.conf.
>>
>>it will have the effect of tying up an smtpd process for a long time. i
>
> spoke too soon.. yes, passing the descriptor to another tarpit daemon
> would work (not eat up smtpd's). but you would eventually run out of
> resources due to the tarpit daemon also.. them spammers are nothing if not
> believers in brute-force approaches.
I use the opposite approach here. Another program, the tarpit daemon,
is the one who accepts incoming connections, and spawns real smtpd for
"good" clients, and handles connections from "bad" clients itself
(it also implements per-IP and per-/24 block concurrency limits and
rate limits - sorta like anvil daemon does). For "bad" clients
(badness is determined by another process who watches maillog and
notices either spamware behaviour or number of errors per unit of
time etc, plus local manually-edited blocklist), it simulates very
slow smtp session (accepting HELO, MAIL FROM, RCPT TO and DATA
commands but sending replies with large delay, and replies with
5xx code to the DATA command.
The daemon currently uses epoll() mechanism on linux (and shuld
work with kqueue or /dev/poll or whatever mechanism other OSes have).
On my PII-266 machine with 192Mb RAM, it is able to handle 40K
concurrent connections without any problem or noticeable system
slowdown (provided max-open-files limits are increased appropriately).
It will not handle more than configured amount of connections
(it will just reply with 5xx right at the connect stage when there
are too many connections already opened), and it uses constant
amount of memory (no malloc/free during normal operations, only
at startup), so it will not bring the system down sporadically.
That to say - it's relatively easy to implement safe tarpiting
daemon for this sort of tasks. And my daemon sitting in front
of postfix actually allowed the mailsystem to function here -
before I wrote it, our mailsystem was half-operational, with
about 1000 parallel smtpds running all the time all talking with
various spammers, using all available memory and swap space for
smtpds and cleanups...
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... ;)
/mjt
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]