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 operations. 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 times. > 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
