Re: [tryton-dev] Impact mitigation for DDoS attack
* 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.1
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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 e
Re: [tryton-dev] Impact mitigation for DDoS attack
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 -- Sergi Almacellas Abellana www.koolpi.com Twitter: @pokoli_srk -- 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/290e75b8-48fb-d4db-d870-058fc90ad74c%40koolpi.com.
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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 a
Re: [tryton-dev] Impact mitigation for DDoS attack
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.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/20180214113337.GA24410%40kei. signature.asc Description: Digital signature
Re: [tryton-dev] Impact mitigation for DDoS attack
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 - 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/20180214112837.GZ24410%40kei.
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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
Re: [tryton-dev] Impact mitigation for DDoS attack
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. -- 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/20180214100433.GY24410%40kei.
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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. -- 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/20180214095901.eb4jvpifkcdgeh4d%40localhost.localdomain.
Re: [tryton-dev] Impact mitigation for DDoS attack
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 -- 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/49f0c960-cfab-0cda-7734-a62bae3889f8%40koolpi.com.
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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.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/20180214094638.z2ov6fgrzokmssy6%40localhost.localdomain.
Re: [tryton-dev] Impact mitigation for DDoS attack
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? -- 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/1d16943d-95f3-4fb0-acf3-d306c4c281c0%40googlegroups.com.
Re: [tryton-dev] Impact mitigation for DDoS attack
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.
[tryton-dev] Impact mitigation for DDoS attack
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 -- 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/3166c2c9-58b3-4eec-92ab-136a74d6948c%40googlegroups.com.
