auditd/aureport --auth not recording/reporting username of failed su root attempts
This document (7015230) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)
Situation
When auditing is enabled (auditctl -e 1), and an end user ssh's into the server, auditd records the ssh attempt. If the user then su's to the root user and an aureport --auth is run, the report does not report which user su'd in, if the wrong password is provided for the root user, it does not report which user attempted to authenticate with the bad password.
For example:
1. ssh to the server as a non-root user.
2. su to root.
3. Provide an invalid password for the root user.
4. su to root (again).
5. Provide the correct password for the root user.
6. Run aureport --auth
The output will look similar to this:
and /var/log/messages shows:
audit.log will contain the full sshd session creation but skipping forward to just before the failed use of su we see the following (Note: For the example case below, jdoe's auid is 1000, but for the failed su attempt no username is shown, only an auid):
As can be seen, /var/log/messages provides the username that attempted and failed to su as root whereas the audit --auth shows no user identity and the /var/log/audit/audit.log data shows only the uid or auid as the identity of the failed su attempt.
For example:
1. ssh to the server as a non-root user.
2. su to root.
3. Provide an invalid password for the root user.
4. su to root (again).
5. Provide the correct password for the root user.
6. Run aureport --auth
The output will look similar to this:
=====================================================================================
# Date Time Acct Host Terminal Executable Success Event
=====================================================================================
334. 06/16/2014 11:02:18 jdoe 192.168.2.28 ssh /usr/sbin/sshd yes 84
335. 06/16/2014 11:02:18 jdoe 192.168.2.28 ssh /usr/sbin/sshd yes 87
336. 06/16/2014 11:02:26 root ? pts/1 /bin/su no 98
...
340. 06/16/2014 11:02:35 root ? pts/1 /bin/su yes 103
and /var/log/messages shows:
Jun 16 11:02:18 slert11sp3 sshd[10044]: Accepted keyboard-interactive/pam for jdoe from 192.168.2.28 port 48097 ssh2
Jun 16 11:02:26 slert11sp3 su: FAILED SU (to root) jdoe on /dev/pts/1
Jun 16 11:02:35 slert11sp3 su: (to root) jdoe on /dev/pts/1
audit.log will contain the full sshd session creation but skipping forward to just before the failed use of su we see the following (Note: For the example case below, jdoe's auid is 1000, but for the failed su attempt no username is shown, only an auid):
type=CRED_ACQ msg=audit(1403100799.008:43): user pid=10047 uid=0 auid=1000 ses=10037 msg='op=PAM:setcred acct="jdoe" exe="/usr/sbin/sshd" (hostname=192.168.2.28, addr=192.168.2.28, terminal=ssh res=success)'
type=USER_LOGIN msg=audit(1403100799.008:44): user pid=10044 uid=0 auid=1000 ses=10037 msg='op=login id=1000 exe="/usr/sbin/sshd" (hostname=137.65.165.129, addr=192.168.2.28, terminal=/dev/pts/2 res=success)'
type=USER_START msg=audit(1403100799.008:45): user pid=10044 uid=0 auid=1000 ses=10037 msg='op=login id=1000 exe="/usr/sbin/sshd" (hostname=137.65.165.129, addr=192.168.2.28, terminal=/dev/pts/2 res=success)'
type=USER_AUTH msg=audit(1403101400.648:52): user pid=10103 uid=1000 auid=1000 ses=10037 msg='op=PAM:authentication acct="root" exe="/bin/su" (hostname=?, addr=?, terminal=pts/2 res=failed)'
As can be seen, /var/log/messages provides the username that attempted and failed to su as root whereas the audit --auth shows no user identity and the /var/log/audit/audit.log data shows only the uid or auid as the identity of the failed su attempt.
Resolution
In order to obtain the username for the audit data you need to use the following command:
Output will look similar to the following:
Note the event column at the end of each line, the same event ID is used in the aureport --auth output and by linking the event IDs on the two reports the auid for the failed su attempt in the first report can be obtained from the second report. If this is then looked up in /etc/passwd the username will be found. Such a process can be performed using a relatively simple shell script.
aureport --user
Output will look similar to the following:
User ID Report
============================================================
# date time auid term host exe event
============================================================
...
31. 06/18/2014 08:15:01 0 cron ? /usr/sbin/cron 95
32. 06/18/2014 08:15:01 0 cron ? /usr/sbin/cron 96
33. 06/18/2014 08:15:01 0 cron ? /usr/sbin/cron 97
34. 06/18/2014 08:23:20 1000 pts/2 ? /bin/su 98
35. 06/18/2014 08:30:01 -1 cron ? /usr/sbin/cron 99
36. 06/18/2014 08:30:01 -1 cron ? /usr/sbin/cron 100
37. 06/18/2014 08:30:01 0 ? ? ? 101
38. 06/18/2014 08:30:01 0 cron ? /usr/sbin/cron 102
Note the event column at the end of each line, the same event ID is used in the aureport --auth output and by linking the event IDs on the two reports the auid for the failed su attempt in the first report can be obtained from the second report. If this is then looked up in /etc/passwd the username will be found. Such a process can be performed using a relatively simple shell script.
Cause
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7015230
- Creation Date: 18-Jun-2014
- Modified Date:03-Mar-2020
-
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
