* 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 >community. 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.
|2016-03-09 11:32:11||nicoe||set||recipients: + ced, bch, yangoon, sharkcz, meanmicio, smarro, ajacoutot|
|2016-03-09 11:32:11||nicoe||link||issue5375 messages|
Showing 10 items. Show all history (warning: this could be VERY long)