Re: [Sqlgrey-users] [Patch] Tarpitting / Throttling

[Michel B. <mi...@bo...>]

Le Lundi 06 Juin 2005 21:44, Lionel Bouton a =E9crit :
>
> Thousands of entries shouldn't be a problem (there are configurations
> out there with 10s of thousands of entries in the connect table). In
> fact hundreds of thousands of entries should be common on big
> configurations.

Thousands of entries shouldn't be a problem =3D> On "fast machine with bi=
g disk=20
at big ISP".

I think SQLgrey is not made only for "big ISP with big server", but can a=
lso=20
be used at "small regional office with small email gateway with slow=20
processor, little RAM and little disk" (i.e. OpenBrick with VIA processor=
),=20
isn't it ?

> Today an attack on the connect table is mostly theoritical. To do such
> an attack, the attacker must :
> - know at least one valid rcpt address (on configs that don't use
> "reject_unlisted_recipient" before greylisting, they should do so),

Some configs may prefer to use greylisting _before_ recipient check to pr=
event=20
possible dictionary attacks to be able to determine which email addresses=
=20
exist or not at a given domain, before the mail comes back a 2nd time...

The nice thing with greylisting is that it can be used in a number of=20
different ways which provides different "features" ;-)

> - make hundreds of thousands of SMTP transactions to Postfix with
> different "FROM" headers. On most configurations you probably can't mak=
e
> more than 10s of such transactions/s.

NOT ONLY FROM, "RCPT TO:" is enough. ONE message with ONE "MAIL FROM:" an=
d 50=20
different "RCPT TO:" makes 50 new entries in connect... With this diction=
ary=20
attacks or random recipient attacks can fill a connect table with junk qu=
ite=20
fast (and I have experienced it for real).

> >and B3/ the connect table wouldn't grow too big on disk
>
> True, but mostly connected to B1 (disk space is cheap).

Assertion #1: Disk space is cheap (true)

Assertion #2: One given disk doesn't grow by itself (true)

Assertion #3: The bigger disk you have, the faster you tend to fill it up=
 with=20
junk (and the less housekeeping you do) (true)

Assertion #4: Although regrettable, quite a number of servers out there r=
un=20
with little left free disk space (true)

Assertion # 5: Any given disk has a natural tendancy to get full at some =
point=20
in time (true)

So taking care of not wasting precious disk space still makes sense ;-)

> I'm not yet convinced this would be really useful, probably harmless
> though.

Well, rather than discussing for ages whether the idea would be good or n=
ot,=20
I'm for the experimental method ;-)

So I've written a patch to include tarpitting / throttling in SQLgrey, wi=
th=20
the already discussed "refinements".

Please find it attached, and feel free to test for yourself if this bring=
s an=20
improvement or makes things worse...

My first tests tend to make me think that it works nice, but I'm definite=
ly no=20
Perl expert, so feel free to double-check the code.

I suggest adding the following paragraph to sqlgrey.conf :

## Throttling too many new entries from new host
# Setting this optional parameter will refuse an excessive number of
# new entries in the connect table from the same host, in the following
# manner:
# - If there are already "connect_src_throttle" entries in the connect
#   table from the same host (e-mails which have not been retried yet)
# - And there is NO entry for this host in domain_awl
# - And there are LESS than "connect_src_throttle" entries in the
#   from_awl table for this host
# THEN further incoming connections from this host will be (temporarily)
# refused without new entries being created in the connect table (until
# some already waiting entries have been successfully retried).
# This feature may prevent the connect table from growing too big and
# being polluted by spambots, viruses, zombie machines and the like.
# If set to "0" (default), this feature won't be used.
connect_src_throttle =3D 0

# connect_src_throttle =3D 5


Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E