On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote:
> Replication storms. In my opinion the replication of a mod of one or
> two attribute in a entry will be faster than the bind itself.

Think about the amplification effect in an environment with 20 replicas.
1 login attempt -> 20+ replication messages

Now think about what happen bandwidth wise when a few thousand people
all authenticate at the same time across the infrastructure, you deploy
more servers to scale better and you get *more* traffic, at some point
servers actually get slower as they are busy with replication related

Think what happen if one of these servers is in a satellite office on a
relatively slow link and every morning it receives a flooding of
replication data ... that is 99% useless because most of tat data is not
relevant in that office.

>  If an attacker knows all the dns of the entries in a server the
> denial of service could be that it just does a sequence of failed
> logins for any user and nobody will be able to login any more,

This is perfectly true which is why we do not permanently lockout users
by default and which is why I personally dislike lockouts. A much better
mechanism to deal with brute force attacks is throttling, but it is also
somewhat harder to implement as you need to either have an async model
to delay answers or you need to tie threads for the delay time.
Still a far superior measure than replicating status around at all

>  replication would help to propagate this to other servers, but not
> prevent it. This would also be the case if only the final lockout
> state is replicated.

Yes but the amount of replicated information would be far less. With our
default 1/5th less on average as 5 is the number of failed attempts
before the final lockout kicks in. So you save a lot of bandwidth.

> I like the idea of replicating the attributes changed at failed logins
> (or reset) only.

I think this is reasonable indeed, the common case is that users tend to
get their password right, and if you are under a password guessing
attack you should stop it. The issue is though that sometimes you have
misconfigured services with bad keytabs that will try over and over
again to init, even if the account is locked, or maybe (even worse) they
try a number of bad keys, but lower than the failed count, before
getting to the right one (thus resetting the failed count). If they do
this often you can still self-DoS even without a malicious attacker :-/

Something like this is what we have experienced for real and cause us to
actually disable replication of all the lockout related attributes in
the past.


Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to