On 2018-01-29 12:47, Axel Braun wrote: > I would like to discuss https://bugs.tryton.org/issue5375 with all developers > involved.
All developers have already commented on the issue and we all agree that the proposal is wrong, solves nothing and weakens the brute force attack protection. > In short, what is it about? > In current implementation of the Tryton Server, each failed login attempt is > written to a database table (https://bugs.tryton.org/msg24643) > > As a consequence, in case of a DDoS attack [1], the backend is flooded with > requests, filling the database and exhausting its resources (IO, conn. pool, > memory, transaction logs ..), leading to contention and finally bringing the > system down. This could be proofed with a small script. This is no more true at all. Many improvements have been introduced since. And even, it was never right because there is a limit on the number of concurrent database connections so the script just show this limit and never exhaust all the resources described. More over the script is really a newbie script because it just waits for the answer for 3 seconds (with the bad patch) instead of starting a new connection to try another password. A simple modification to use thread will just flood the server the same way. > In order to mitigate the impact of a DDoS attack, a patch was proposed in > above issue that implements a login timeout similar to the Secure Shell > (SSHD): On a failed login attempt, the a timeout of 3 seconds (by default) on > that session is applied before the next login. This is completely false and stupid as it was explained many times that this behaviour provides no protection at all. But it seems you and Luis can not understand that the sleep is only effective if it applies on bad and succeed tentative. And by the way OpenSSH does not have such protection and if you search the internet a little bit, you will find many advise about using fail2ban or firewall rate limit (which is the solution implemented on Tryton's server). Indeed I guess you are talking about pam_tally2 which uses a similar technic as vanilla Tryton but without the penalty to the attacker. But penalty is important see https://www.schneier.com/blog/archives/2009/01/bad_password_se.html > It also removes the functionality of writing the failed attempt on the > dabasase table, so the IO subsystem on PostgreSQL, FS and network are not > impacted in comparison to the server without the patch. And this is the main problem. This remove the memory from the system about tentative and so prevent to have any brute force attack protection. > As you can see in above issue, the patch was not applied. For openSUSE > packages, I have applied it anyway, as I feel it makes sense. Now I received > the request to remove it again All Tryton's developers are against this change so we should stop promoting the openSUSE packages because they distribute a weakened version of Tryton. > So let me know your thoughts about the proposed patch – which of the two > proposals has less impact in case of a DDoS attack? Any! The only solutions in Tryton against DDoS are the resource limitations like the database connections, the memory cache limit etc. > [1] We are not talking about means to prevent a DdoS, e.g. by a proxy > configuration or similar Too bad because they are the only *real* DDoS protection. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ -- You received this message because you are subscribed to the Google Groups "tryton-dev" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton-dev/20180129222002.GI23162%40kei.
