http://bugzilla.opensuse.org/show_bug.cgi?id=1078111
http://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c9
Axel Braun
(In reply to Matthias Gerstner from comment #7)
We also have to keep in mind that trytond can run in multiple environment: Linux, BSD and there might be even few people using Windows ; of course this doesn't concern openSUSE but it concerns us.
I understand. This is easily forgotten but I know myself how difficult cross platform development can be.
Would you accept a configurable approach? Keep the default as it is but allow users or integrators that run Linux to select a different behaviour that avoids the discussed effect on the databse?
Well, for us the main issue with the patch applied is the removal of the brute force protection. And according to us, this protection is more important than the protection against a potential DDOS (because against DDOS you have to act on multiple levels thus somehow we are less concerned about that).
Here we had the agreement that we keep the existing functionality of failed login timeout of 2^(failed_logins - 1) as default, and add a parameter that allows the admin to override this with a default of n seconds.
And of course, if SUSE wants to add a patch that protects its users better without hindering the base protection that we give. This is fine for us too :).
A solution to mitigate the growth of the LoginAttempt table might be to keep track of the IP making the attempt and keeping at most X attempts from the same IP. In fact after some research it seems that it is the solution that drupal chose:
If it works for Drupal then it may be the right thing to do. A quick research suggests there are also some pitfalls here like multiple users sharing the same IP or using proxies to circumvent the protection.
Drupal is probably one of the few examples that allows an anonymous write to the database, which is in general the wrong approach - see comment 4. I have not seen this in one of the big ERP implementations like SAP or Oracle, and I bet those (Oracle) DB experts know their job. This is the main performance obstacle that is seen in the current implementation, and where we should get rid of. For sure x-platform development makes live harder, but all of the mentioned systems have logging facilities, may it be systemd, /var/log/messages or c:\TEMP\trytond.log. Most likely the different ways are already handled in the python system abstraction layer.
Cédric created a bug regarding this issue: https://bugs.tryton.org/issue7110
When we discussed it we talked about a configuration parameter that would allow to define the size of the subnet that would be banned. The number of failed attempts will also be a configuration parameter.
That looks exactly like https://bugs.tryton.org/msg24643 and https://bugs.tryton.org/issue5375 , with which the discussion started. So we should close 7110 as duplicate, reopen 5375, and in this bug remove the DB logging, enable the exponential brute-force protection and add the configuration parameter.
In fact providing a patch for this issue will only reduce slightly the attack surface but I am afraid that against DDOS trytond can not handle everything by itself.
True. But we should target a minimal impact in case the system-measures fail
I'm sure all of you can work out a solution that addresses both concerns.
I sure hope that we can. Thank you very much for stepping in into this debate it helps to have the opinion of other (somehow less concerned) developers.
I think both parties can agree upon that there is an attack surface here but also that it can't be fixed so simply (with regard to the proposed patch). While OS level DoS protection is certainly best practice, an improved implementation would benefit tryton and serve as a defense in depth measure.
We all agree on that I think. But putting the cursor on the right level of protection is difficult and a subject of heated debate as you saw.
Indeed, that was very helpful to get an external view of independent security expert. Thanks again! -- You are receiving this mail because: You are on the CC list for the bug.