tarpit
John Pettitt
>In message <39A0C95F...@cbn.net.id>, you wrote:
>
> >Could we implement this tarpit in postfix?
> >
> >What's tarpitting? It's the practice of inserting a small sleep in an
> >SMTP session for each RCPT TO after some set number of RCPT TOs. The
> >idea is to thwart spammers who would hand your SMTP server a single
> >message with a long list of RCPT TOs. If a spammer were to attempt to
> >use your server to relay a message...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>The way to stop people from using your server to illicitly relay
>messages to other sites is simply not to allow them to do it at all,
>period.
>
>You you don't know how to accomplish THAT, then ask, and I and others
>will explain to you how to do it.
I don't think it's an open relay issue as such.
I think the issues is a legitimate user of an ISP who "goes bad" and
suddenly sends lots of mail - there was a thread about limiting mail volume
a few weeks back that touched on a similar issue.
For a tarpit to be useful it would need to have a mechanism to set the
limits and rates on a per client basis (so legitimate mailing list clients
could be excepted). Even with this change is would be of marginal use
because simply starting a new connection every N messages would unstick the
client.
Whatever you do here it rapidly gets back to the same discussion we had
about the volume limits - the only way to make it work in practice is to
authenticate all clients and keep some sort of database of client activity
- all of this would add a lot of complexity to the system.
A partial solution would be a slow_clients list - any IP on the list would
get an N second delay for all sessions. This would not be noticeable for
most people sending one or two messages at a time but would have an impact
of anybody trying to send lots. It would also not be subject to being
bypassed by generating a new connection.
John
John Pettitt <j...@cloudview.com> AOL-IM: CanisRosa
SigInt bait ;-)
A big hello to the folks at Fort Meade, Menwith Hill and Pine Gap.
Keywords: NSA, Echelon, GCHQ, F83, Magnum, Mentor, P415, STEEPLEBUSH
Ronald F. Guilmette
In message <4.3.2.7.2.200008...@gatekeeper.cloudview.com>, you wr
ote:
>At 11:43 PM 08/20/2000, Ronald F. Guilmette wrote:
>
>>In message <39A0C95F...@cbn.net.id>, you wrote:
>>
>> >Could we implement this tarpit in postfix?
>> >
>> >What's tarpitting? It's the practice of inserting a small sleep in an
>> >SMTP session for each RCPT TO after some set number of RCPT TOs. The
>> >idea is to thwart spammers who would hand your SMTP server a single
>> >message with a long list of RCPT TOs. If a spammer were to attempt to
>> >use your server to relay a message...
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>The way to stop people from using your server to illicitly relay
>>messages to other sites is simply not to allow them to do it at all,
>>period.
>>
>>You you don't know how to accomplish THAT, then ask, and I and others
>>will explain to you how to do it.
>
>
>I don't think it's an open relay issue as such.
>
>I think the issues is a legitimate user of an ISP who "goes bad" and
>suddenly sends lots of mail - there was a thread about limiting mail volume
>a few weeks back that touched on a similar issue.
I know. I started that thread... and I'm still working on the code to
impliment rate limiting for ``authorized'' users who are not really
relaying, per-se, as much as they are just using a mail server in their
own domain, or on their own network to send outgoing mail.
There are really two problems here, and they should not be confused.
The first level problem is making sure that only people who have accounts
with you can send mail, using your server, to other ``remote'' destinations.
The way to accomplish this is either to use ``ordinary'' relaying restrictions
that are available with Postfix (i.e based on the domain name of IP address
of the party requesting the service) or else, if you have to support roaming
users, to use the authenticated SMTP stuff (also available with/in Postfix).
Unfortunately, most people aren't even smart enough to get this first and
most fundamental part of securing the service done properly (and that is
why ecvry day, tons of spam still pass through wide open relays whose owners
are too dufus to even understand the problem, let alone rectify it).
The second level problem... which is only worth worrying about if you have
already secured yourself against first level problem... which, as I say,
most folks still haven't... is the one you noted, i.e. how to keep an
``authorized'' user of the mail server from going totally wild one day.
For that, you have to have some sort of rate limiting code.
I actually have the code to do this already, but I haven't had time to
test it.
If any brave soul wants to help with this project, then please raise your
hand. I'll send you the patches, and you can bring it up on some back
room machine, and then beat on it for awhile and tell me how well you
it seems to be working.
>For a tarpit to be useful it would need to have a mechanism to set the
>limits and rates on a per client basis (so legitimate mailing list clients
>could be excepted).
Tarpitting is actually a rather stupid and futile way to try... lamely...
to control the utilization rate of some resource, specifically a mail server.
The Right Thing To Do is really just to allow only authorized people to use
the thing at all, and to monitor even those authorized people, and if any of
THEM get out of line and star sending massive amounts of stuff, then just
cut them off completely. Why slow them down when you can just terminate
their ability to use the service _completely_?
>Even with this change is would be of marginal use
>because simply starting a new connection every N messages would unstick the
>client.
Exactly. That's why you want to just cut them off. Kinda like ``You're
dead meat. End of story. Hasta la vista baby!''
>Whatever you do here it rapidly gets back to the same discussion we had
>about the volume limits - the only way to make it work in practice is to
>authenticate all clients...
^^^^^^^^^^^^^^^^^^^^^^^^
Yes.
Using authenticated SMTP has _lots_ of advantages, in addition to and on top
of giving you far more and far better control over who can and can't use
your mail server to send outgoing mail. It also let's you monitor how much
each individual user is using. That way you can kill them if they use to
much (i.e. if they are spamming) or you could perhaps even bill them per
kilobyte (or megabyte) of mail sent.
> and keep some sort of database of client activity
Yes.
>- all of this would add a lot of complexity to the system.
No, not really.
I'm doing it with a trivial Berkeley DB file and less than 100 lines of
new code added to the existing smtpd code.
Rafi Sadowsky
> At 09:27 21/08/00 +0300, you wrote:
> >Hi
> > You may want to try reading the doc's before thinking up "new" ideas
> >the default behavior of postfix already comes quite close to what you want
> >
> >See:
> >
> > <http://postfix.openu.ac.il/rate.html#recipients>
>
> hmm, "reading the doc's" I find:
>
> "controls how many recipients a Postfix delivery agent"
>
> but the yhy was asking for the converse: how to tarpit (error-free
> but) multiple RCPT TO:, ie, a "thundering herd", arriving at postfix
> in one SMTP session, like a mailbomb or dictionary attack.
>
> So his idea is "new" to what postfix can do now.
Please combine (1) and (2) below and think about it for a few
seconds/minutes
Hint: try smtpd_recipient_limit=50
(that said an open relay is a *really* bad idea ...)
1) Try reading down an extra few lines in postfix doc:
You may find >>>smtpd_recipient_limit<<< is relevant
Quote---
The smtpd_recipient_limit parameter (default: 1000) controls how many
recipients the SMTP server will take per delivery. That's more than any
reasonable SMTP client would send. The limit exists just to protect the
local mail system against a malicious or confused client. The
smtpd_recipient_limit parameter (default: 1000) controls how many
recipients the SMTP server will take per delivery. That's more than any
reasonable SMTP client would send. The limit exists just to protect the
local mail system against a malicious or confused client.
----
2) Please try reading the next line in my original Email
Which describes tarpitting built-in to postfix
<http://postfix.openu.ac.il/rate.html#slowdown>
Quoted:
-------
Slowing down bad clients
First of all, no defense will protect against an all-out denial of
service attack. I just don't want to raise impossible expectations. But
there are a few simple things one can do in order to deal with confused or
malicious client programs.
Some defenses are part of a more general strategy: for example, how long a
line of text may be before it is broken up into pieces, and how much text
may be carried in a multi-line message header. See the resource controls
documentation for details.
The Postfix SMTP server increments a per-session error counter whenever a
client request is unrecognized or unimplemented, or whenever a client
request violates UCE restrictions or other reasons. The error counter is
reset when a message is transferred successfully.
As the per-session error count increases, the SMTP server changes
behavior. The idea is to limit the damage by slowing down the client. The
behavior is controlled by the following parameters:
smtpd_error_sleep_time (default: 5 seconds)
When the per-session error count is small, the SMTP server pauses only
when reporting a problem to a client. The purpose is to prevent naive
clients from going into a fast connect-error-disconnect loop.
smtpd_soft_error_limit (default: 10)
When the per-session error count exceeds this value, the SMTP server
sleeps error_count seconds before responding to a client request.
smtpd_hard_error_limit (default: 100)
When the per-session error count exceeds this value, the SMTP server
disconnects.
Unfortunately, the Postfix SMTP server does not yet know how to limit the
number of connections from the same client, other than by limiting the
total number of SMTP server processes (see process limit). Things could be
worse: some mailers don't even implement an SMTP server process limit.
That's of course no excuse. I'm still looking for a good solution.
>
> Len
>
>
> http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 installable binary for NT4
> http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways
>
>
>