Message 24677

Message id


* Luis Falcon  [2016-03-09 00:24 +0100]: 

>Very sorry to hear this reaction and the lack of solid arguments, and
>lack of good alternatives.

I'll try to sum up the arguments because everybody accuses everybody
of not having solid arguments and that's getting on my nerves.

To sum up your argument: a table is filled with data coming from
unsuccessful attempts to authenticate a user in the system. This will
fill up the disk and thus make the system unusable.

To sum up our argument: DoS can not be mitigated at the application
level but should be managed on the IP level. Moreover the path
supplied do not fix anything on the DoS level because a smart attacker
would send an authentication request and drop the connection WITHOUT
waiting for the 3 seconds and do that a thousand of time.

So we're talking about a network kind of DoS while you're talking
about another kind of DoS attack.

About this second kind of DoS attack (the filling the disk one), my
opinion is that it's not a real problem. 

Either the attacker tries to go unnoticed and fills the database with
records with a script generating gigabytes of data in a few hours,
this will not work because the 'add' method of the LoginAttempt object
removes every stalled record present since longer than 'delay()'
(which is the session timeout).

Either the attacker wants to fill the disk in less than 'delay()' (by
default 10 minutes), so he will have to generate several gigabytes per
minute. He will have to hit hard the server. And this is exactly the
same as the networking DoS that we are talking about. You can only
prevent that by monitoring your system and using (for example
fail2ban). Moreover keep in mind that the number of concurrent request
on tryton in limited by the number of concurrent request to the
database, so even distributing the attack will hit this wall and won't
be able to multiply its attack vector.

>Not applying the patch (or an acceptable alternative) certainly makes
>Tryton vulnerable, which forces us to create a security advisory for
>GNU Health, along with the currently proposed patch. Not the ideal
>situation, but I have the moral duty to protect the GNU Health

Of course, we do understand your duty to protect GNU Health from what
you perceive as an DoS attack vector. But I don't think Tryton is
vulnerable to the attack you're describing (as I explain in the
paragraphs above) and moreover the proposed patch soften the brute
force attack mitigation in place.
Date User Action Args
2016-03-09 11:32:11nicoesetrecipients: + ced, bch, yangoon, sharkcz, meanmicio, smarro, ajacoutot
2016-03-09 11:32:11nicoelinkissue5375 messages
2016-03-09 11:32:09nicoecreate

Showing 10 items. Show all history (warning: this could be VERY long)