Monday 19 September 2016

Logging user activity with pam_tty_audit


A specific components of the audit system uses the pam_tty_audit.so PAM module to enable or disable auditing of TTY input for specified users.
When the user logs in, pam_tty_audit.so records the exact keystrokes the user makes into the /var/log/audit/audit.log file.
This module is flexible in the sense that it allows us to enable or diable logging for specific users.
pam_tty_audit.so captures keystrokes including backspaces etc so we can expect some junk characters in the output.

Since this is a auditd component, we can use the aureport with the -tty parameters to report all record logged by the module.

The set up:


Add the line "session     required      pam_tty_audit.so enable=*" in the following files to enable keystroke logging for all users:
  • /etc/pam.d/password-auth
  • /etc/pam.d/system-auth
  • /etc/pam.d/sshd
The file password-auth/system-auth will be as follows:

[root@centdb pam.d]# cat password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     required      pam_tty_audit.so enable=*
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The /etc/pam.d/sshd file will be:

[root@centdb pam.d]# cat sshd
#%PAM-1.0
auth       required     pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    required      pam_tty_audit.so enable=*
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth
[root@centdb pam.d]#

Restart the auditd service.

We can now view the user keystroke logging reports in aureport/ausearch as well as view logs in /var/log/audit/audit.log.

We can view the terminal logs of users for today as follows:

[root@centdb audit]#  aureport --tty -ts today

TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 09/19/2016 01:14:42 1800 503 ? 211 bash "df -h",<ret>
2. 09/19/2016 01:14:45 1806 503 ? 211 bash "date",<ret>
3. 09/19/2016 01:14:44 1803 503 ? 211 bash "uptime",<ret>
4. 09/19/2016 01:15:00 1810 503 ? 211 bash <^D>
5. 09/19/2016 01:28:16 1869 503 ? 211 bash <ret>,"uptime",<ret>,"date",<ret>,"date",<ret>,"sudo su -",<ret>,"  whoami",<ret>,"w",<ret>,<ret>,<ret>,"echo ??",<backspace>,<backspace>,"$?",<ret>,<ret>,<ret>,"df -h",<ret>,"uname -a",<ret>,"whoami",<ret>,<ret>,<ret>,<ret>,<ret>,<up>,<ret>,<ret>,<up>,<up>,<ret>,<ret>,<ret>,<up>,<up>,<up>,<up>,<ret>,<^D>
6. 09/19/2016 01:33:25 1943 503 ? 214 bash <ret>
7. 09/19/2016 01:33:28 1945 503 ? 214 bash "whoami",<ret>
8. 09/19/2016 01:49:27 1989 503 ? 214 bash <^D>
9. 09/19/2016 01:49:28 1994 503 ? 214 bash <nl>,"df -h",<ret>,"uname -a",<ret>,"date",<ret>,"uptime",<ret>,"sudo su -",<ret>,<^D>
10. 09/19/2016 01:50:29 2054 503 ? 219 bash "uptime",<ret>
11. 09/19/2016 01:50:30 2057 503 ? 219 bash "date",<ret>
12. 09/19/2016 01:50:32 2060 503 ? 219 bash "eit",<ret>
13. 09/19/2016 01:50:35 2068 503 ? 219 bash <ret>,"uptime",<ret>,"sudo su -",<ret>,"exit",<ret>
14. 09/19/2016 01:50:34 2062 503 ? 219 bash "exit",<ret>
15. 09/19/2016 01:51:16 2127 503 ? 221 bash "fdisk -l",<ret>
16. 09/19/2016 01:51:18 2130 503 ? 221 bash <ret>
17. 09/19/2016 01:51:19 2132 503 ? 221 bash "date",<ret>
18. 09/19/2016 01:51:21 2135 503 ? 221 bash <ret>
19. 09/19/2016 01:51:27 2137 503 ? 221 bash "dmesg",<ret>
20. 09/19/2016 01:51:31 2140 503 ? 221 bash "exit",<ret>
21. 09/19/2016 01:51:33 2146 503 ? 221 bash "uptime",<ret>,<ret>,"date",<ret>,"sudo su -",<ret>,"exit",<ret>
[root@centdb audit]#

We can view the logs for a specific time window as well as shown below:

[root@centdb audit]#  aureport --tty -ts 09/19/2016 -te 09/19/2016

TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 09/19/2016 01:14:42 1800 503 ? 211 bash "df -h",<ret>
2. 09/19/2016 01:14:45 1806 503 ? 211 bash "date",<ret>
3. 09/19/2016 01:14:44 1803 503 ? 211 bash "uptime",<ret>


The cool thing I found in the aureport output was that even after I switched to root, the original UID of the logged in user was still retained while running commands.

We can also filter events by a specific user as shown in the following example:

[root@centdb audit]#  ausearch -ui 503 --interpret  | more
----
type=USER_CMD msg=audit(09/19/2016 01:14:41.237:1782) : user pid=58871 uid=test auid=test ses=211 msg='cwd=/home/test cmd=su - termina
l=pts/2 res=success'
----
type=PATH msg=audit(09/19/2016 01:14:41.228:1781) : item=1 name=(null) inode=659194 dev=08:02 mode=file,755 ouid=root ogid=root rdev=0
0:00 nametype=NORMAL
type=PATH msg=audit(09/19/2016 01:14:41.228:1781) : item=0 name=/usr/bin/sudo inode=808774 dev=08:02 mode=file,suid,111 ouid=root ogid
=root rdev=00:00 nametype=NORMAL
type=CWD msg=audit(09/19/2016 01:14:41.228:1781) :  cwd=/home/test

No comments:

Post a Comment

Using capture groups in grep in Linux

Introduction Let me start by saying that this article isn't about capture groups in grep per se. What we are going to do here with gr...