[Freeipa-devel] global account lockout

Wed Apr 9 14:04:26 UTC 2014

On 04/09/2014 07:57 AM, Petr Spacek wrote:
> On 9.4.2014 15:50, Ludwig Krispenz wrote:
>>
>> On 04/09/2014 12:31 AM, Simo Sorce wrote:
>>> 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.
>> ok, lets leave it with that, there might be scenarios where it becomes
>> unacceptable and as long as we have an acceptable solution we need 
>> not enforce
>> full replication
>>>
>>>>   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.
>> yes, that could be a good solution, but not trivial
>>>
>>>>   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.
>> But also here it can get complicated, we cannot really use 
>> failedlogincount
>> and replicate it, eg if it is "2" on each server an their are 
>> parallel login
>> attempts, we would increment it to "3" and replicate, so we would 
>> have 3 on
>> all servers, not what we wanted.
>
> Maybe it is totally of topic, but ... could something like
> Modify-Increment Extension
> http://tools.ietf.org/html/rfc4525
> help?
>
> (I don't know how replications works, this would help only if it 
> replicates operations and not only results of modifications.)

Replication does replicate the operation.  It essentially just 
"forwards" the modify operation received by the initial server, along 
with some replication meta-data.

>
> I meant - it would replicate an command to increment the value by 1 
> instead of replicating the new value.

The problem is that servers would quickly get out of sync.  I'm not sure 
how we would ensure eventual convergence.

>
> Petr^2 Spacek
>
>> We could replicate changes to lastfailedauth and when receiving an 
>> update for
>> this attribute locally increase failedcount, but it would also have 
>> to be used
>> for resets (deleting lastFailedAuth), but there could also be race 
>> conditions,
>> maybe there are other local attrs needed.
>>
>> And the bad news: I claimed that the replication protocol ensures 
>> that the
>> last change wins except for bugs, and looks like we have one bug for 
>> single
>> valued attributes in some scenarios. I have to repeat the test to 
>> double check.
>> The update resolution code for single valued attrs is a nightmare, 
>> Rich and I
>> several times said we need to rewrite it :-(
>>
>> PS: Martin, if you are looking for subjects for a thesis, maybe some
>> theoretical model for replication update resolution and what is required
>> history could be a challenge.
>>>
>>> Simo.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel