* Mathias Behrle [2018-02-14 12:17 +0100]:
* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
14 Feb 2018 10:46:38 +0100):
Hi together,
Hello,
I am still missing a thorough handling of the _several_ _different_ involved
issues as proposed in
https://bugs.tryton.org/issue5375 (specifically
https://bugs.tryton.org/msg24691)
Quite frankly I don't think there is much to discuss in this message.
But you might elaborate more on the issue so that I can understand
what should be discussed.
and
https://bugs.tryton.org/issue7111 (specifically
https://bugs.tryton.org/msg38228)
- Session management: there is a recent issue about that
- Login delay: we can discuss it at length, the policy we have
won't change for the reasons exposed by Cédric in another email
But as my review on appspot displays if people want they can use
a different strategy.
- Usability aspects: I don't understand what you mean
- Hardening of trytond against brute force attack: It's linked to
the login delay. If you're able to display another kind of
attack vector please open a security issue
- Hardening trytond agains DDOS attack: we can also discuss it at
length on the mailing list but in the end we all agree that it
involves a lot of different systems and there is not really a
final solution to this issue
- Responsibility about decision taking in the project: It should
be a new thread. Ideally it should be a community decision but
the problem arise when there is no clear consensus, in this case
I see two realms:
- the marketing (website, twitter, etc): the foundation has
the last word
- the code: Cédric has the last word
Since the beginning the project is based on a BDFL style and I
think that's the best way to do it. It's inspired by python
and numerous other projects that work this way.
- Attitude and mindset towards downstream / distribution:
- We could promote more downstream users of Tryton, yet we
have business cases and nothing prevents anyone of
submitting new cases according to our rules. We have one
about coog, I would be delighted to have one about a GNU
Health implementation.
- distribution: The fact that distributions package Tryton is
obviously a good thing. But on the other hand I think we can
not let pass some patches that hinders the security of
Tryton.
Given the discussions we had about this patch and the lack
of understanding from both sides, there is a vote going on
in the foundation to decide what should be the foundation
attitude towards this.
* Axel Braun [2018-02-14 10:27 +0100]:
Am Sonntag, 4. Februar 2018 00:30:05 UTC+1 schrieb Cédric Krier:
On 2018-02-03 07:48, Axel Braun wrote:
Am Montag, 29. Januar 2018 23:25:07 UTC+1 schrieb Cédric Krier:
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.
We had a constructive and friendly discussion about the topic
here: https://bugzilla.opensuse.org/show_bug.cgi?id=1078111
What I read is that more people agree that the applied patch does not
solve any issue and disable the brute force attack protection.
Maybe you should read more carefully: The current implementation in
Tryton, that allows you to bring the whole system down by flooding
the database with login requests is rubbish (OK, the security team
phrased it more politely)
If you've read everything carefully then you will also notice that the
security team does not have all the use cases in mind when it comes to
make a decision. Of course, in a single instance trytond there are
better options available but I am still waiting for a better approach
when taking into account the multi-platform, multi-instance use cases
that we do care about.
I just want to re-throw into the discussion to consider the use of an
in-memory database like redis for session management.
The patch I talk about (and that you mentioned) is going to allow this.
https://stackoverflow.com/questions/10278683/how-safe-it-is-to-store-session-with-redis
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-16-04
https://matomo.org/faq/how-to/faq_20521/
I think we all agree that it is better to catch (D)DoS on the server
level instead of the database level, i.e. when undergoing a DDoS
attack the Tryton server or its authentication backend should catch
the load and eventually go unresponsive, but not the database
backend. I think many of the concerns presented by Luis and by Axel
could be mitigated by the implementation of an optional session
management bypassing the production database.
Thoughts?
I think there is already numerous ways to mitigate the concerns
presented by Axel and Luis. This patch might help a bit too.
The advise from the security team should be considered for a future
patch.
But more importantly, the applied patch on the OpenSUSE package must be
removed ASAP to not expose OpenSUSE users of the Tryton package to brute
force attack against their password.
Dunno if you have read the link you have posted above
(https://www.schneier.com/blog/archives/2009/01/bad_password_se.html)
yourself, but the first comment already describes it pretty well.
Up to now we have no better patch in place. The proposed patch
https://codereview.appspot.com/335550043/ makes thing even worse.
Explain how exactly.
Because for me that would be a solution: instead of patching trytond
with the really bad patch you're using you could just patch GNU Health
(thus not impacting users of trytond) and you're done, this whole
issue become void.
I beg to disagree. There is not this whole issue, but as depicted
above there are several separate issues. Let's identify them and
handle them separately in a clean way. We all will profit from the
results of the then hopefully fruitful discussions.
I am exclusively talking about the "OpenSUSE packaging of trytond
issue".
There are solution for this without the need to discuss the other
issues. It does not mean that the other issues are not worth
discussing or that they should be pushed under the rug. No, I just
want to state that there are other ways to fix this specific issue
then applying a controversial patch to trytond.
--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas.evr...@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/20180214125548.sgk4zirbw2b7me5h%40localhost.localdomain.
