Message 24678

Author
meanmicio
Date
2016-03-09.12:01:12
Message id
24678

Content

Dear Cedric, dear all 

Just to summarize and keep the focus:

* We all agree that external applications / firewall rules are
  excellent *additional* security measures, and that they should be in
  place, but that is not the subject.

* This vulnerability is a design flaw that allows to write
  anonymously millions of records in a very short time, quickly
  consuming the host resources (CPU, DB ...) . I've provided a solution.
  If you come up with a better one, we will be the happiest, but it has
  to be a solid one, that can not rely on exposing the server to writing
  anonymous requests to a DB table, or having cron job to perdiodically
  "clean up the mess".  

And that is about this vulnerability. Believe me, I am the first one
that does not want to create a separate solution from the standard
Tryton. It's not good to any of our communities, and I am doing
my best to avoid it, so please let's work together. That said, a
solution must delivered ASAP. I also think we need to discuss this with
other core members, and get their feedback and suggestions. Up to now
it's been just Nico, you, Sebas and I who have been discussing it. 

Out of topic / unrelated issues to this vulnerability :

* You have brought the topic of password guessing by brute force
  attacks : This is about implementing good policies, and being
  consistent from bottom up. Let me explain:  The first place where that
  should be imposed is at server level. Currently, I don't see that you
  have taken any measure to avoid brute force attacks in one of the most
  important resources, the server super user password (the owner of all
  databases). No failed login timeout, not good password
  enforcement, nothing.

  In GNU Health, it's been years that have imposed good password
  enforcement using cracklib with the serverpass utility[1]. I have
  recommended the use for the standard tryton installation, but, again,
  has not been adopted. For GNU Health 3.2, we will include this type
  of measures also at user level, along with password expiry rules,
  password minimum length, and so on. I hope this time it can be part
  of the standard.

* Integrating Trytond with PAM[2] . As I mentioned to Nico, for upcoming
  versions, we could investigate intregrating some aspects of Trytond
  with PAM, as sshd, PostgreSQL or Apache do. There even seems to be a
  python_pam module. 

I'll be happy to schedule a conference within this week to find a
solution to this immediate issue, as well as to create a team dedicated
to security both in Tryton and in GNU Health, that can put time into
this very important area.

All the best,

1.- https://en.wikibooks.org/wiki/GNU_Health/Security
2.- http://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html

On Wed, 09 Mar 2016 09:28:07 +0100
Cédric Krier <issue_tracker@tryton.org> wrote:

> Cédric Krier <cedric.krier@b2ck.com> added the comment:
> 
> I don't see how you can say we did not provide solid arguments when
> we provided many times them which were never countered. Now, if you
> want us to name one good alternatives,I will say fail2ban [1]. It
> will be great if someone could provide a good set of rules for
> Tryton. We will be happy to publish them. I will warn you a last time
> to not apply your patch on GNU Health because it will weaken the
> protection Tryton has against brute force attack (as explained many
> times). Finally, I would like to say that trytond has by default a
> limitation on concurrent connections (inherited from PostgreSQL) and
> this limitation can easily be reached and provoke a DoS. It is not
> necessary linked to the login method but to any RPC calls. So I
> recommend to anyone to run trytond in a private network or to use
> external protection. It is not the goal of Tryton to write such
> security tools especially when good one exists and because this can
> not be correctly managed at the application level but only at the OS
> level.
> 
> Maybe we should add a paragraph in the documentation to recommend the
> usage of such protection.
> 
> [1] https://en.wikipedia.org/wiki/Fail2ban
> 
> _______________________________________________
> Tryton issue tracker <issue_tracker@tryton.org>
> <https://bugs.tryton.org/issue5375>
> _______________________________________________
>
History
Date User Action Args
2016-03-09 12:01:14meanmiciosetrecipients: + ced
2016-03-09 12:01:14meanmiciolinkissue5375 messages
2016-03-09 12:01:12meanmiciocreate

Showing 10 items. Show all history (warning: this could be VERY long)