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.
