Bug 1127312 - confusing audit trail for unsuccessful logins
Summary: confusing audit trail for unsuccessful logins
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.6
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: Stanislav Zidek
URL:
Whiteboard:
Depends On:
Blocks: 1153397 1159820 1159926
TreeView+ depends on / blocked
 
Reported: 2014-08-06 15:48 UTC by Ondrej Moriš
Modified: 2015-07-22 06:45 UTC (History)
5 users (show)

Fixed In Version: openssh-5.3p1-105.el6
Doc Type: Bug Fix
Doc Text:
Non-existing users logging in with ssh triggered two different audit messages in the log, which was not expected behavior. With this update, when a non-existing user attempts to log in using ssh, only one audit message is triggered. This message records a login attempt from an unknown user as expected.
Clone Of:
Environment:
Last Closed: 2015-07-22 06:45:59 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1335 normal SHIPPED_LIVE openssh bug fix and enhancement update 2015-07-20 17:52:59 UTC

Description Ondrej Moriš 2014-08-06 15:48:09 UTC
Description of problem:

When logging in using ssh two following cases might occur:

 a) existing user but wrong password,
 b) non-existing user.

PAM/ssh react in these cases by generating audit events USER_LOGIN. In the first case, event is generated correctly. But in the second case, two events are generated:

 * first event for unknown user (which is ok),
 * second event for invalid user (which is wrong, confusing).

This situation cause aulast to report as follows (for (b) case):

# aulast --bad
(unknown ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)
(invalid ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)

Version-Release number of selected component (if applicable):

audit-2.3.3-4.el7
openssh-6.4p1-8.el7
pam-1.1.8-9.el7

How reproducible:

100%

Steps to Reproduce:

1. Empty audit.log (or use checkpoints).
2. Try to log-in via ssh as existing user with wrong password.
3. Try to log-in via ssh as non-existing user.

Actual results:

Three audit events generated, first is correct, second is correct but the last one is redundant and confusing (invalid user).

# ausearch -ts recent -m login,user_start,user_end,user_login
----
time->Wed Aug  6 17:35:09 2014
type=USER_LOGIN msg=audit(1407339309.512:261): pid=27004 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed'
----
time->Wed Aug  6 17:35:21 2014
type=USER_LOGIN msg=audit(1407339321.301:266): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed'
----
time->Wed Aug  6 17:35:26 2014
type=USER_LOGIN msg=audit(1407339326.268:272): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed'

# aulast --bad
root     ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)
(unknown ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)
(invalid ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)

Expected results:

# ausearch -ts recent -m login,user_start,user_end,user_login
----
time->Wed Aug  6 17:35:09 2014
type=USER_LOGIN msg=audit(1407339309.512:261): pid=27004 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed'
----
time->Wed Aug  6 17:35:21 2014
type=USER_LOGIN msg=audit(1407339321.301:266): pid=27009 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=::1 terminal=ssh res=failed'
# aulast
# aulast --bad
root     ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)
(unknown ssh          ::1              Wed Aug  6 17:35 - 17:35  (00:00)

Additional info:

See also https://bugzilla.redhat.com/show_bug.cgi?id=922508#c14. I am not sure if this is a problem in pam or openssh but it is definitely not a bug in audit. Please feel free to change the component if needed.

Comment 1 Tomas Mraz 2014-08-07 07:12:41 UTC
This audit record is created by sshd directly and not PAM. However I suspect that its generation is triggered by sshd trying to make indistinguishable from the client side whether known or unknown user is trying to login and so I do not expect it to be easily fixed.

Comment 2 Steve Grubb 2014-08-07 14:06:51 UTC
There is no requirement to obfuscate the user on unsuccessful logins. You can use acct="unknown" if you prefer to. Currently, acct="(unknown user)" is used which gets hex encoded because of the space in the value and causes it to take up more log space.

The major problem is the second entry under acct="(invalid user)", this one should not be sent at all. The AUDIT_USER_LOGIN event should be sent only 1 time and it is the summary decision of all the authentication/account attempts. A couple examples: If 3 password attempts fail, only 1 USER_LOGIN event should be sent saying login failed. If authentication was successful and pam_acct says no because too many sessions/wrong time of day, then only 1 is sent saying login failed. HTH.

Comment 3 Eduard Benes 2014-10-30 13:35:56 UTC
This issue has been now reported against RHEL 7 as bug 1158521

Comment 4 Petr Lautrbach 2014-11-03 14:50:29 UTC
Would be acceptable to change this during late rhel-6 release cycle? Could the change break some existing configurations?

Comment 5 Petr Lautrbach 2014-11-03 15:40:00 UTC
The mentioned change would be similar to https://bugzilla.redhat.com/show_bug.cgi?id=1158521#c2

Comment 6 Steve Grubb 2014-11-04 13:25:30 UTC
It is acceptable to change this during RHEL6 because what is in RHEL6 is breaking the analysis or perhaps making it harder.

Comment 10 errata-xmlrpc 2015-07-22 06:45:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1335.html


Note You need to log in before you can comment on or make changes to this bug.