Re: [Sqlgrey-users] Throttling again ;-)

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

Le Mercredi 08 Juin 2005 19:26, Lionel Bouton a =E9crit :
>
> Unless a new function we are discussing on the mailing-list is proven u=
seful
> to me shortly, I'm planning to release a 1.6.0 stable version based on
> 1.5.9.=20

After some thoughts, I have a couple more things in favor of "throttling"=
 :

1/ The supplementary SELECT count(*) we perform against the connect table=
=20
before deciding if we will accept or not to add a new entry, which is of =
some=20
performance concern to you, is to some extent compensated by the fact tha=
t we=20
save an INSERT each time we refuse an entry -- and that makes also a DELE=
TE=20
that we save at some point in the future for cleanup.

2/ Throttling can to some extent be considered as "self-dynamic-blacklist=
ing",=20
which looks nice : I see some patterns by looking at my logs, showing tha=
t=20
the same spam sources (Zombie machines used as SMTP relays ? Viruses /=20
worms ?) tend to come back again and again randomly in time, with differe=
nt=20
payloads (sender / recipient). If we use throttling, once they've filled =
up=20
their not-retried "quota" in connect, when they come back again, their ne=
w=20
connection is refused without generating any new entry in connect, which =
in=20
turn reduces the chances that they could possibly defeat the greylisting=20
system by trying to resend (at random) a message with a sender/recipient=20
couple already known to the connect table.

By limiting the number of connect entries we allow for a given (new) sour=
ce,=20
we limit its possibility of passing greylisting by chance. This looks ver=
y=20
interesting to me as it can make greylisting yet more efficient.

So this throttling in connect gives a number of interesting things, besid=
es=20
simply saving entries in connect -- and making impossible a connect-flood=
=20
attack, even if the odds that this happens seem remote.

The more I think about it, the more it seems to me that it can only make =
the=20
system more secure, and certainly not less. And well, anyway, "it doesn't=
=20
hurt" ;-)

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