Login failure should be logged with higher level than INFO
Such events should be logged with at least on WARNING level instead of INFO level.
I don't think ERROR level is right because there is no problem in this case in the trytond code.
Activity
added easy trytond type::behavior + 1 deleted label
On Tue, 05 Jan 2016 14:33:44 +0100
Cédric Krier <issue_tracker@tryton.org> wrote:
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
> I don't agree. Login/logout are just method call like any other
> methods. If you want to have them, just run in verbose mode.
>
I don't want verbose mode in production, Cedric. I want to make sure
that I can record who access my Tryton / GNU Health database, and from
where, at anytime, without cluttering the logfile.
If John Doe password gets compromised, then some expert in
computer forensics could check the IP, it's country / city etc... It's
as important, or even more, than the unauthorized access event
logging.
In other words, it's good to know who gets in and out my house, with
or without a key ...
As I said in previous notes, for me, the WARNING level should record :
- Start / stop of the server
- Normal login / logout events
- Unauthorized access events
- All other warnings and error messages from the server
Thanks
> _______________________________________________
> Tryton issue tracker <issue_tracker@tryton.org>
> <https://bugs.tryton.org/#5219>
> _______________________________________________
>Not at all. Syslogs check when someone logs in and out to the Operating System, not what they do... of course, you can activate extra auditing, but always as an option.
Again, please keep in mind that recording who logs in successfully is as important as recording unsuccessful login attempts. Think about the scenario of a distributed, brute-force attack from different IPs and different users/passwds. After several unsuccessful attempts, they finally succeed. They broke into the system, and you never noticed, since you never recorded the last one.
Recording this information has a minimal footprint on the logfile, and the benefits are immense.
BTW, having the verbose / debug in a production server could reveal sensitive information that should __never__ be part of the syslog, so that should never be an option for production databases.
Bests,On 2016-01-05 23:32, Luis Falcon wrote:
> Not at all. Syslogs check when someone logs in and out to the Operating System, not what they do... of course, you can activate extra auditing, but always as an option.
That's not the same. Tryton is a webserver not an OS. login has no more
meaning than performing a request on the server.
> Again, please keep in mind that recording who logs in successfully is as important as recording unsuccessful login attempts. Think about the scenario of a distributed, brute-force attack from different IPs and different users/passwds. After several unsuccessful attempts, they finally succeed. They broke into the system, and you never noticed, since you never recorded the last one.
That has no sense. It is not because you have logged the login that you
will discover the breach. But to the contrary, it is because you will
have logged all the activities that you could detect a strange
behaviour (with software like snorf). And in this regards there are
never enough logs.
> Recording this information has a minimal footprint on the logfile, and the benefits are immense.
I don't agree. But I will not start again the discussion of #5217 (closed).
> BTW, having the verbose / debug in a production server could reveal sensitive information that should __never__ be part of the syslog, so that should never be an option for production databases.
Agreed for debug but not for verbose but any way, it is not the subject
of this issue.On Wed, 06 Jan 2016 00:20:11 +0100
Cédric Krier <issue_tracker@tryton.org> wrote:
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
> On 2016-01-05 23:32, Luis Falcon wrote:
> > Not at all. Syslogs check when someone logs in and out to the
> > Operating System, not what they do... of course, you can activate
> > extra auditing, but always as an option.
>
> That's not the same. Tryton is a webserver not an OS. login has no
> more meaning than performing a request on the server.
>
> > Again, please keep in mind that recording who logs in successfully
> > is as important as recording unsuccessful login attempts. Think
> > about the scenario of a distributed, brute-force attack from
> > different IPs and different users/passwds. After several
> > unsuccessful attempts, they finally succeed. They broke into the
> > system, and you never noticed, since you never recorded the last
> > one.
>
> That has no sense. It is not because you have logged the login that
> you will discover the breach. But to the contrary, it is because you
> will have logged all the activities that you could detect a strange
> behaviour (with software like snorf). And in this regards there are
> never enough logs.
>
To me, it has all the sense in the world. That's why most operating
systems and ERPs like SAP record login / logout activity by default.
> > Recording this information has a minimal footprint on the logfile,
> > and the benefits are immense.
>
> I don't agree. But I will not start again the discussion of #5217 (closed).
>
> > BTW, having the verbose / debug in a production server could reveal
> > sensitive information that should __never__ be part of the syslog,
> > so that should never be an option for production databases.
>
> Agreed for debug but not for verbose but any way, it is not the
> subject of this issue.
>
Ay ! Cedric... unfortunately It seems like we will never come to an
agreement on this topic.
I will create for GNU Health the necessary logging mechanisms to record
this critical info.
Bests,
> _______________________________________________
> Tryton issue tracker <issue_tracker@tryton.org>
> <https://bugs.tryton.org/#5219>
> _______________________________________________
>I don't agree with either of you hehe
IMHO, login failure should be logged with *lower* level than INFO. If an user mistypes his password, that's meaningless to the sysadmin or whoever that watches the production server logs.
INFO should be for server key events only: the start and stop of the server, the load of a module, the beginning and the end of a key process, etc. And should be kept to a minimum.
WARNING should be for exceptional situations that don't break the server but that should be investigated and avoided in the future. A login should not be in there, either failed or successed.
Ideally the production server is minimalistic with only INFO levels (because ideally WARNINGS and ERRORS won't happen)
Yet, it is very reasonable to keep a log of the authentication layer. But to do so don't mix this events in the server log. An specific auth log system could be developed, but the easiest out of the box approach is just to configure a different logger (with its own handler and formatter and filter and loglevel) for the classes that handle the login. So the login events should be recorded at least in a separate file, but the logging handler could be configured to post to an external API or a time-series DB if it fits your needs.
