Auditing user sessions

In order for businesses to be compliant with certain information security laws in some countries, you need to be able to prove that a user (which user it was becomes important to the business to take action against the user after an event has occurred) took certain actions on systems that caused a significant event to occur. That event could be data loss, data leakage or anything. Therefore, audit policy in some companies requires system administrators to show an audit trail of user's interactions with the shell interface. In other cases, access to production systems should only ever be used by the administrators when there is something to actually be done on them. This helps the business track that this is happening correctly.

When dealing with access control, there are three areas that require focus: Authentication, Authorization and Accounting / Auditing.

Basically the following questions must be answered: 'Who are you?' / 'What are you allowed to do?' / 'What have you done?'

This tutorial aims at answering the last question (for Accounting / Auditing): What have you done?

How we achieve this is by recording how the shell behaves to a user's input.
For example: When a user types a command like 'exit', the shell will echo this message back to the user while it is being typed and it is then recorded.

Note: This process does not record passwords (because the shell does not echo the characters back to the user when passwords are entered) and because of file permissions on /etc/profile, only the root user will be able to change anything about the way this recording happens or where the typescripts get emailed - Generally there will only be one or two very senior administrators that have access to the root account, all other administrators have their own accounts that do not have root access. Selecting the email address that the typescripts get sent to is of paramount importance because anyone who has access to that mailbox will have access to the user's typescript. It is important to take the users privacy into account when implementing any form of auditing of sessions.

In order to achieve this, a few commands are needed, but key to capturing the data is the 'script' command.

The script command is pretty easy to use. It only has a few options and works without relying on much else.
 

1

Install the script command:
The script command should be installed by default, but in case it has been removed or your version of RHEL/CentOS doesn't have it then run the following to install it

  yum install script

The use of yum is the generally accepted way to manage packages (applications) on RHEL. There are several things yum can be used for, but the most popular are to install, update and remove packages.
Install a package - yum install
Remove a package - yum remove
Update a package - yum update
 

2

Test the script command:
To test the script command, all you need to do is run

  script

This should display the words "Script started, file is typescript" and then you will be placed into a shell environment where your session will be recorded.

Once you are finished, exit the shell (Ctrl+d, or type exit). You will be sent back to the shell you originally came from and there will be a "typescript" file in your current directory. This is the typescript of your script session.
 

3

Changing the way the script command behaves:
In order for this tool to be useful to us in this context, we need to be able to create many of these files at once in the same directory. In order to do this, we need to be able to change the filename of the resulting typescript. We also need what is called "timing information" which is used to recreate the session using scriptreply.

Command line we are going to use:
script -t -q  2>

-t = output timing information to stderr.
-q = quiet mode, disable the announcement that we are recording the session
 = make script change the filename of the output typescript file.
2>  = use standard redirection to send all stderr messages to a timing file.
 

4

Other commands we are going to use:
mkdir = create a directory, used here to ensure that the directory we use is created
touch = create an empty file
rm = remove file/directory
chmod = change the file permissions on a file/directory,used here to make typescripts a little more secure
date = display/change the current system time
trap = listens for exit codes, if they match, execute a command (clean_exit in this tutorial)
dig = DNS query tool
rpm = Redhat Package Manager, used here to check if mutt is installed
yum = Package management tool
mutt = email application used here to send the typescript data to an email address
grep = filter data stream
echo = Send text to stdout (used with redirection to send the message body into mutt)
vim = Popular file editing utility
cp = Copy a file
ln = link, used here to setup a symblolic link to a file
 

5

Preparing the system:
In order to be able to email the typescripts to an email address, we need to be able to email using mutt.
check if mutt is installed:
  rpm -q mutt

if it is not installed:
  yum install mutt -y

We need a local MTA running:
By default sendmail is installed but any MTA will work, we just need it to be able to relay an email outbound from the local machine.
Make sure sendmail is started:
  /etc/init.d/sendmail status

If it is not started, start it:
  /etc/init.d/sendmail start

We also need DNS working so that the local MTA can lookup MX records for the destination domain.
Test DNS:
  dig mx experts-exchange.com

lets send a mail to test all the above:
  echo "message body" | mutt -s "subject" you_email_address@your_company.com

Good. If all is working so far then all we need to do is create the directory that we will be using to place our typescript and timing file into for emailing.
  mkdir /tmp/typescripts

We must also make sure all users can write to it and since its in the /tmp directory, mode 777 is ok.
  chmod 777 /tmp/typescripts
 

6

THE WARNING:
Now before you continue I need to warn you!
LEAVE A SESSION OPEN IN ORDER TO BE ABLE TO RECOVER IF THIS FAILS!

This is because we are going to add commands into the /etc/profiles script. Traditionally reserved for setting environmental variables, this is the only way to ensure that it is not bypassed because this script it ALWAYS executed whenever ANY session starts.

IE: IF YOU GET THIS WRONG YOU WILL NOT BE ABLE TO LOGIN - This is why you need a session active so that you can recover from it if you find you can't open new sessions.
 

7

Setting it all up:
The first thing you need to do is backup your /etc/profile file.
  cp /etc/profile /etc/profile.no_audit

You then need to append the contents of the attached file to the bottom of your /etc/profile file.

The easiest way to do this is to run the following command after you have READ AND UNDERSTOOD exactly what the contents of enable_typescripting.txt does and how it works (You may tweak it for your environment BUT BE CAREFUL NOT TO LOCK YOURSELF OUT.
Setup destination email address: (LogMailAddress at the top of the file)
  vim enable_typescripting.txt

Append contents to the bottom of /etc/profiles
  cat enable_typescripting.txt >> /etc/profile

At this point you should setup a way of easily disabling the auditing. Move the /etc/profile file to /etc/profile.audit and create a symlink (symbolic link) to it in the place of the original /etc/profiles file. What this will do is that any attempt to read/write to /etc/profile will be sent to the /etc/profile.audit file instead.
  mv /etc/profile /etc/profile.audit
  ln -s /etc/profile.audit /etc/profile

Now that we are done, try opening a session and closing it, then wait for the email.

If you do not get the email check the /var/log/maillog file for information. Troubleshooting mail issues is not within the scope of this tutorial.
 

8

Using the typescript:
In order to use the typescript and timing file, you will have the PERL interpreter installed to run the scriptreplay file.
To check if PERL is installed run:
  rpm -q perl

In order to run the attached scriptreplay, type the following in the directory where you have placed the file:
  chmod 755 scriptreplay
  ./scriptreplay  

This will display the session exactly the way it happened.

To remove the auditing, simply remove the symlink /etc/profile and create a new symlink to /etc/profile.no_audit
  rm /etc/profile
  ln -s /etc/profile.no_audit /etc/profile

enable-typescripting.txt
scriptreplay