* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed, 14 Feb 2018 10:46:38 +0100):
Hi together, 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) and https://bugs.tryton.org/issue7111 (specifically https://bugs.tryton.org/msg38228) So I am not really surprised to see the discussion moving in circles. Nevertheless there is work in progress to improve the situation which is (while nto sufficiently discussed and reviewed) probably a good thing: https://codereview.tryton.org/41031002/ https://codereview.tryton.org/39171002/ > * 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. 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? >>>> 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. > Granted the patch is not perfect (a check on the size of the > dictionary and the use of the database name are things that comes to > my mind). But it does what Luis wants so badly: stop anonymous logging > in the database. > -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://www.m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BB -- 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/20180214121746.67cefc26%40monsterix.mbehrle.de.
pgpIafFlcpvEl.pgp
Description: Digitale Signatur von OpenPGP
