Impact mitigation for DDoS attack

[Axel Braun]

Dear all,

I would like to discuss https://bugs.tryton.org/issue5375 with all developers involved.

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.

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. 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.

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

So let me know your thoughts about the proposed patch – which of the two proposals has less impact in case of a DDoS attack?

[1] We are not talking about means to prevent a DdoS, e.g. by a proxy configuration or similar

Thanks
Axel

[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.

> 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...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Axel Braun]

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

The advise from the security team should be considered for a future patch.

[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.

> 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.


PS: Moreover I think such patched Tryton could not complain with the GDRP[1]

[1] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

[Axel Braun]

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)

> > 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.

> PS: Moreover I think such patched Tryton could not complain with the GDRP[1]
>
> [1] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

Where exactly?

[Nicolas Évrard]

* 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.

>> > 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.

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.

--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com

[Sergi Almacellas Abellana]

El 14/02/18 a les 10:27, Axel Braun ha escrit:

> 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)

Will be great if we all pharse our words more politely ;)

In case of flodding, the system can be turned down when the server does
not have enougth capacity to reply all the request. If you get such
attacks, i think it's better to block the correponding ip. Indeed a new
patch have been proposed to improve it:

https://bugs.tryton.org/issue7110

I think this will work better for flooding attacks.

>
>>> 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.

For me the important word on the posted link is *rapid-fire*. On tryton
we have a timeout to prevent the rapid fire. Otherwise it will be
possible to attach the with a brute force attack.

>
> Up to now we have no better patch in place. The proposed patch https://codereview.appspot.com/335550043/ makes thing even worse.

I think it's a sample implementation to show how the session management
can be customized, so you can implement whatever you wan't on third
party packages without patching trytond server. This allow end users to
pick the most suitable solutions for them, which for me is a big benefit.

--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Nicolas Évrard]

* Nicolas Évrard [2018-02-14 10:46 +0100]:

>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.

Another solution would be (as I proposed), to package trytond and the
trytond-with-gnu-health-patch separately. It might be a bit of work.
But in the end I guess you will have to do it given the fact that GNU
Health adds features to the client that might become incompatible in
the future.

[Cédric Krier]

On 2018-02-14 10:48, Sergi Almacellas Abellana wrote:
> In case of flodding, the system can be turned down when the server does
> not have enougth capacity to reply all the request. If you get such
> attacks, i think it's better to block the correponding ip. Indeed a new
> patch have been proposed to improve it:
>
> https://bugs.tryton.org/issue7110
>
> I think this will work better for flooding attacks.

There are many other measures like the size request limitation, the
periodical cleaning of the table, the login size limit etc.
But this is not enough and it will never be enough.

Flooding attack (or DoS) should be fixed at lower level like firewall or
even better at the router level. But Tryton provides enough information
in the log file to let tools like fail2ban to block such IP. Also it is
recommended to put the server behind a proxy which provides all the
tools against such attack.

DDoS attack is even more difficult to counter because at this level it
is a matter of size. You must have a large enough network to absorb the
bandwidth the attacker is sending.

[Mathias Behrle]

* 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

[Cédric Krier]

On 2018-02-14 01:27, Axel Braun wrote:
> 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)

So as it seems argumentations are just ignored. Here is a script that
shows that the "GNU Health patch" solves nothing and make things worst:

#!/usr/bin/env python3
import sys
from concurrent.futures import ThreadPoolExecutor
from requests_futures.sessions import FuturesSession

try:
URL = sys.argv[1]
except IndexError:
URL = 'http://localhost:8000/trunk/'


def payload():
return {
'method': 'common.db.login',
'params': [
'admin',
{'password': 'wrong'},
]
}

session = FuturesSession(executor=ThreadPoolExecutor(max_workers=80))

while True:
session.post(URL, json=payload())


If you run on a vanilla Tryton, of course the system will be slowed down
but users can still use the system because vanilla Tryton does not keep
a connection to the database on login failure. But of course the 'admin'
user can no more login as long as the attack is running (this is what
the common expected behaviour).

If you run on a "GNU Health" patched Tryton, the system is unusable for
every body because very fast all the database connections are hold by
the sleep.

This is just a simple example to show that the "GNU Health patch"
camp is just blinded by a limited vision on the security despite our
countless attempt to explain why their reasoning is wrong.


Now about the brute force attack, the only valid alternative protection
is to always slow any login. Slowing failing login is just useless
because as it leaks information too fast. But having a delay on the
login process is something we can not accept, there are scripts that
login on every call and we do not want to penalize them. Also we always
try to minimize the login time, well because it is the first impression
from the user and it will be bad if he has to wait more than 5 seconds
each time.

[Cédric Krier]

On 2018-02-14 12:17, Mathias Behrle wrote:
> I am still missing a thorough handling of the _several_ _different_ involved
> issues as proposed in

If you have an issue to report, please create it on the bug tracker.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com

[Nicolas Évrard]

* 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.

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.

[Sergi Almacellas Abellana]

El 14/02/18 a les 12:17, Mathias Behrle ha escrit:

> 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/
>

> Thoughts?

I've build a tryton-redis module which use to store the cache on the in
memory database [1]. If somebody is interested on storing the session
details on redis I will be very happy to accept a patch for it.


[1] https://bitbucket.org/pokoli/redis-tryton

[Mathias Behrle]

* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,

14 Feb 2018 13:55:48 +0100):

Hello again,

> * 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.

There are 3 topics explicitely identified. Could you please elaborate what you
don't understand?

>>and
>>
>>https://bugs.tryton.org/issue7111 (specifically
>>https://bugs.tryton.org/msg38228)
>
> - Session management: there is a recent issue about that

To which issue are you refering exactly, a quick search on the bugtracker
didn't reveal any hit [1]?

> - 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.

Thanks for that. It is a bit complicated to find that review under a
totally unrelated topic (Remove openSUSE packages)

https://bugs.tryton.org/issue7111 >
https://bugs.tryton.org/msg38228 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c19 >
https://codereview.appspot.com/335550043/

Wouldn't it be worth to post that example of a possible modification on a more
prominent place?

> - Usability aspects: I don't understand what you mean

You shortened the complete sentence which was
- Usability aspects (as in punishment of wrong password entries and with regard
to distributions in general)

I want to elaborate on the two given examples:
- punishment of wrong password entries
While there was a lot of input and I would say agreement, that there *has* to
be a login delay, there was never agreement about the duration. The
exponential login timeout in terms of brute force attack is fairly oversized.
So when you want to keep that absolutely we comes to usability aspects
in terms of user friendlyness: a well concepted login manager (e.g. on
android) doesn't let the user in the dark, but tells him, that after a
failed login he has to wait for x seconds and then counts them down. The
Tryton GTK-interface instead just goes unresponsive giving the impression of
a hanging application. There is great probability that a half-experienced
user will just hard kill it, because he thinks there is going something wrong.
- and with regard to distributions in general

Speaking with my Debian maintainer hat on I consider the step taken in
https://bugs.tryton.org/issue7111 as regrettably and wrong.
- I can not see how the mere *listing* of distributions on the website
can be considered an *advice*.
- Shouldn't it be just a sign of mutual respect for both sides? Distributions
should be happy about the existence of Tryton and in the same way Tryton
should be glad to be recognized and integrated into the major
distributions. Glad to here your and the general input on this subject.
- Compared to some other security related topics issue7111 is highly
exaggerated. What will the foundation or the maintainer do about sao where
the maintained series will be affected by a security-wise unmaintained
jquery version?
Have a look at https://bugs.tryton.org/issue5925 which was created
at 2016-10-03.16:09:27. The referenced issue [2] to justify the now
impending upgrade dates from 2016-10-06. It was already clear at the time
of the creation of issue5925 that bootstrap 3.3.7 supports jquery 3+,
but there was no action taken. Sao now will suffer in all currently
maintained stable series from the usage of an unsupported jquery version.

Will that lead to a big fat warning on the website or to the removal of sao
<= 4.6?

> - 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

I would have prefered to have the discussion at discuss.tryton.org or at
least bugs.tryton.org. Unfortunately the further discussion of this topic
happened on the OpenSUSE tracker.The last comment is
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c22
with the proposal of a patch that is uncommented so far.

> - 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

A lot of different systems involved, true. Especially when Tryton loads off the
resource limits to the database backend. Unfortunately the interest of the
maintainer to put that load off to other configurable backends seems to be
non-existent. This is at least what I got for a proposal pointing this way
earlier in this thread: nothing.

> - 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.

My personal view from reading the foundation statutes [3] is that the
foundation is empowered to much more than just marketing. I will appreciate a
public statement of the foundation which responsibilities are covered by its
work.

> - 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.

You want a business case about GNU Health *on the website*, but you exclude the
OpenSUSE packages *from the website*, because they applied a patch coming from
the GNU Health side? I feel that to be highly contradictory.

For the role of distributions in general: they are just other downstreams like
consumers, developers. They have exactly the same right to change and
distribute the code under the GPL licence of the project. It is completely
understood that distributions adapt upstream software to fit into the
distribution and to do whatelse they deem to be necessary. There is absolutely
no mean and there shouldn't even be the intention to take responsibility about
changes made to the code. When indeed you think 'we can not let pass some
patches that hinders the security of Tryton' you are severely out of control and
you want Tryton to have a different licence.

Let me cite from COPYRIGHT:

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


In this light the decision taken at https://bugs.tryton.org/issue7111 is
defintely the wrong way and is just the beginning of taking a responsibility
that the project shouldn't want neither will be able to fulfil at any time.

Which patch are you exactly refering to?

Anyway happy to see that you seem to agree on the usefulness of a separate
authentication backend like redis.

AFAIS there are several related issues that led to the application of the said
patch on the OpenSUSE side. Thus it is not just one issue. The situation is
more complex than that (as we all can see) and there are several issues to be
clarified from which issue6711 depends. issue6711 was now decided without caring
for the pre-located issues. I don't expect this decision to be a satisfying
solution on the long run.

Regards,
Mathias



[1]
https://bugs.tryton.org/issue?%40search_text=session+management&title=&%40columns=title&keyword=&id=&%40columns=id&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&priority=&%40group=priority&status=&%40columns=status&assignedto=&%40columns=assignedto&type=&component=&reviews=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search
[2] https://github.com/twbs/bootstrap/issues/16834
[3] http://www.ejustice.just.fgov.be/tsv_pdf/2012/11/29/12193839.pdf

--

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 BBF

[Nicolas Évrard]

* Mathias Behrle [2018-02-16 16:22 +0100]:

>* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,

> 14 Feb 2018 13:55:48 +0100):
>
>Hello again,

Hello Matthias,

>> * 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.
>
>There are 3 topics explicitely identified. Could you please elaborate
>what you don't understand?

According to me those three topics are either already discussed (the
delay and the vulnerability) or I don't see what you want to discuss
about those (the password security).

>>>and
>>>
>>>https://bugs.tryton.org/issue7111 (specifically
>>>https://bugs.tryton.org/msg38228)
>>
>> - Session management: there is a recent issue about that
>
>To which issue are you refering exactly, a quick search on the bugtracker
>didn't reveal any hit [1]?

issue7134

>> - 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.
>
>Thanks for that. It is a bit complicated to find that review under a
>totally unrelated topic (Remove openSUSE packages)
>
>https://bugs.tryton.org/issue7111 >
>https://bugs.tryton.org/msg38228 >
>https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 >
>https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c19 >
>https://codereview.appspot.com/335550043/
>
>Wouldn't it be worth to post that example of a possible modification
>on a more prominent place?

You can do whatever you want with this review.

>> - Usability aspects: I don't understand what you mean
>
>You shortened the complete sentence which was
>- Usability aspects (as in punishment of wrong password entries and with regard
> to distributions in general)
>
>I want to elaborate on the two given examples:
>- punishment of wrong password entries
> While there was a lot of input and I would say agreement, that
> there *has* to be a login delay, there was never agreement about
> the duration. The exponential login timeout in terms of brute force
> attack is fairly oversized.

What makes you think so?
I think it's a pretty clever way to delay brute force attacks.

> So when you want to keep that absolutely we comes to usability
> aspects in terms of user friendlyness: a well concepted login
> manager (e.g. on android) doesn't let the user in the dark, but
> tells him, that after a failed login he has to wait for x seconds
> and then counts them down. The Tryton GTK-interface instead just
> goes unresponsive giving the impression of a hanging application.
> There is great probability that a half-experienced user will just
> hard kill it, because he thinks there is going something wrong.

That might be a good idea, any patch implementing this would be
welcome.

>- and with regard to distributions in general
>
> Speaking with my Debian maintainer hat on I consider the step taken in
> https://bugs.tryton.org/issue7111 as regrettably and wrong.
> - I can not see how the mere *listing* of distributions on the
> website can be considered an *advice*.

Just like debian cares about the security of its users, we should care
about the security of ours.

This patch was hindering the brute force protection mechanism. We had
the option of not saying anything, warning our users or remove the
package. The foundation opted for the last choice. Not everybody
justified their vote but I can tell you why I voted this way: I didn't
want to shame the maintainer of the package because of a choice he
made. So the least impactfull solution was to remove the package.

> - Shouldn't it be just a sign of mutual respect for both sides?
> Distributions should be happy about the existence of Tryton and
> in the same way Tryton should be glad to be recognized and
> integrated into the major distributions. Glad to here your and
> the general input on this subject.

We're happy to be packaged of course but when there is a choice to be
made between the security of our users or the distribution, I will
always put the priority on our users.

> - Compared to some other security related topics issue7111 is highly
> exaggerated. What will the foundation or the maintainer do about
> sao where the maintained series will be affected by a
> security-wise unmaintained jquery version?

Are you comparing a brute force attack to a bug filled 18month ago
about a library that was not at that time deprecated? Seriously?

> Have a look at https://bugs.tryton.org/issue5925 which was created
> at 2016-10-03.16:09:27. The referenced issue [2] to justify the
> now impending upgrade dates from 2016-10-06. It was already clear
> at the time of the creation of issue5925 that bootstrap 3.3.7
> supports jquery 3+, but there was no action taken.

This bugs is apparently very important for you. You can be sure any
patch migrating to jquery 4 you will submit will be taken into account.

> Sao now will suffer in all currently maintained stable series
> from the usage of an unsupported jquery version.
>
> Will that lead to a big fat warning on the website or to the
> removal of sao <= 4.6?

Of course not. Just like there is no warning on the debian website
about using GTK2.

>> - 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
>
>I would have prefered to have the discussion at discuss.tryton.org or at
>least bugs.tryton.org. Unfortunately the further discussion of this topic
>happened on the OpenSUSE tracker.The last comment is
>https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c22
>with the proposal of a patch that is uncommented so far.

The patch is uncommented indeed. I have other things to do than
comment on everything the day after it has been posted, I hope you can
understand that.

I took a quick look at the patch. It removes the exponential wait
which is already a bad sign. Moreover it does nothing that couldn't be
done by overriding LoginAttempt in GNU Health.

We have differing opinions about the severity of the issue. Mechanisms
have been put to diminish even further its severity. And unfortunately
I don't think those opinions can be reconciled.

>> - 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
>
>A lot of different systems involved, true. Especially when Tryton
>loads off the resource limits to the database backend. Unfortunately
>the interest of the maintainer to put that load off to other
>configurable backends seems to be non-existent. This is at least what
>I got for a proposal pointing this way earlier in this thread:
>nothing.

As I said: people can override LoginAttempt and define their own
add/count/etc methods. It's already there.

>> - 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.
>
>My personal view from reading the foundation statutes [3] is that the
>foundation is empowered to much more than just marketing.

It's in French:

La fondation a pour but la protection, la promotion et le
développement du logiciel libre dénommé Tryton.

Afin de réaliser ce but, la fondation aura principalement pour
activités:

- l'organisation de conférences, colloques ou tout autre
événements (etc)
- l'organisation de la communauté de sympathisants (etc)
- la gestion de l'ensemble des outils collaboratifs (etc)
- la gestion de l'administration permettant la promotion et la
pérennisation de la marque déposée Tryton.

La fondation peut accomplir tous les actes se rapportant
directment ou indirectement à son objet.

So it's mainly organizing the community, promoting tryton and managing
the infrastructure and trademark.

>I will appreciate a public statement of the foundation which
>responsibilities are covered by its work.

I think the status defines broadly what the foundation do.

>> - 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.
>
>You want a business case about GNU Health *on the website*, but you
>exclude the OpenSUSE packages *from the website*, because they
>applied a patch coming from the GNU Health side? I feel that to be
>highly contradictory.

People using GNU Health don't have to apply this patch you know.

And of course, I still consider GNU Health as a valid usage of Tryton.
I disagree with Luis about a patch that he's applying but the overall
functionality seems sound and an excellent exemple of what Tryton is
able to do.

>For the role of distributions in general: they are just other
>downstreams like consumers, developers. They have exactly the same
>right to change and distribute the code under the GPL licence of the
>project. It is completely understood that distributions adapt
>upstream software to fit into the distribution and to do whatelse
>they deem to be necessary. There is absolutely no mean and there
>shouldn't even be the intention to take responsibility about changes
>made to the code. When indeed you think 'we can not let pass some
>patches that hinders the security of Tryton' you are severely out of
>control and you want Tryton to have a different licence.

Not at all. You're putting thoughts on my mind without asking me.

People can do whatever they want with the code as long as they follow
the GPL. But we don't have a duty to reference them on our download
page either. And if we find that the patches that are applied by a
distribution is harmful towards our users then we have the right to
remove this distribution from the download page.

The distribution have some liberties, but we as a project we also some
liberties.

>Let me cite from COPYRIGHT:
>
>This program is distributed in the hope that it will be useful,
>but WITHOUT ANY WARRANTY; without even the implied warranty of
>MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>GNU General Public License for more details.
>
>In this light the decision taken at https://bugs.tryton.org/issue7111
>is defintely the wrong way and is just the beginning of taking a
>responsibility that the project shouldn't want neither will be able
>to fulfil at any time.

You're interpreting this decision wrong.
We just don't want to put on the download page distributions applying
patches harmful for our users.

>>>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.
>
>Which patch are you exactly refering to?

The patch overriding LoginAttempt.

>Anyway happy to see that you seem to agree on the usefulness of a
>separate authentication backend like redis.

redis is not an authentication backend.
I won't code an authentication backend on redis for you neither.
If you want one, code one.

>> 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.
>
>AFAIS there are several related issues that led to the application of
>the said patch on the OpenSUSE side.

I don't know I am not in their mind.

>Thus it is not just one issue.

The fact is that it is just one issue. One patch that Luis thinks
should be applied on trytond while we think it should be solved by
overriding LoginAttempt.

Then the way I see it is that from this issue there has been some
agenda pushing: to remove the OpenSUSE package, to discuss the role of
the foundation, etc.

I tried to keep in my mind the good of our users and to solve the
issue and the discussions that arose from the issue for them.