Options For User Auditing On Linux Platforms

A variety of methods exist for auditing user activity in UNIX and Linux environments. Some of them come preinstalled within common distributions, some can be downloaded as freeware, and some are commercially available products. Here are some of the most popular methods for auditing. Each method is described, along with tips for how to make the best use of each method. In addition, guidance is provided to show what type of auditing each method is best suited for. The auditing methods covered include:

script
screen
sudo auditing
Native audit facility (auditd, auditctl, etc.)

Scenario 1: Auditing using script(1)

How script is setup and started:

‘script’ is a well-known tool used for basic auditing. In many installations, it comes preinstalled. When not, it can be added to any Linux environment with no additional configuration is required. Using script will start auditing as soon as a user types the command ‘script’.

What script records:

All the typing activity and screen I/O is recorded once the script command is given. Content is saved in a default file named ‘typescript’, or in additional files if desired.

Security and audit implications:

Using script is quick and easy, but script is easy to circumvent, and so is difficult to enforce reliably. For example, one can bypass it simply by deleting the output typescript file, or by exiting out of the script session. Additionally, script only displays interactive activity. It does not detail what might be taking place underneath the hood in system calls or processes spawned by an interactive command.

Screenshot: recording started by typing in ‘script’

When to use script:

The best and most common use for script is to record and audit your own sessions. This is due to the fact that it is cumbersome to configure it as a reliable security auditing tool for other users. Other methods described below are better suited for monitoring other users.

Scenario 2: Auditing Using screen(1)

How screen is setup and started:

‘screen’ is not provided with Linux by default, but can be downloaded and installed easily. As with sudo and script above, screen is not a dedicating auditing tool: Its original purpose is to be used as a multiplexing tool to connect various users to one session for collaboration. However, this very concept can be used for auditing as well.

Launching screen after login

Screen can be combined with SSH to force launching of screen immediately upon login, by creating an entry in authorized_keys: (Edit authorized_keys, determine whether there is any screen executable and associate it with the screen script.) In the example below, the script called ‘wrapper’ is used for this purpose.

Script named ‘wrapper’ uses screen to record what the user types

What screen records:

In the example configuration above, whenever the user enters any command, the command is run through the ‘wrapper’ script as an invariant variable ‘SSH_ORIGINAL_COMMAND’, and is logged by screen.

Security and audit implications:

Screen allows live monitoring of user activity, without buffering. It allows you to connect to the session from another session, with the second window exactly duplicating the original. However, it must be used in read only mode otherwise the second window will reflect typing in the original window and the user will become aware that of the auditing activity in real-time. You can also disconnect from the session without terminating it, and return to it later. The live monitoring and the disconnect/reconnect abilities make screen an improvement over script. But similar to script, screen does not record internals (spawned processes / commands). Only the interactive session is logged. An SSH key can be used to login to the session to authenticate that screen is running.

Live monitoring: first screen duplicated in second screen

When to use screen:

Screen is best for auditing purposes that require interactive collaboration. For example when the user knows that s/he is being monitored and the auditor provides feedback on actions being done within the session. Screen bridges a gap between a subset of security audit requirements and user training requirements.

Scenario 3: Auditing using sudo

How sudo auditing is setup and started:

As we all know, sudo is not an auditing tool by nature. Its core purpose is for enabling non-root users to run root commands. But sudo can be used for auditing as well, by configuring it to record the session and store it. ‘sudo’ comes preinstalled in Linux [sudo(8)]

What sudo can record:

sudo can record the entire interactive session by logging all the commands used, and can store the session info in a home directory or remote machine, for future viewing/auditing.

Security and audit implications:

The entire session can be replayed later in both normal and fast forward modes, using sudoreplay. This shows exactly what happened in the session and also shows who the specific user was. However, you cannot see the underlying system calls and you also do not get information about whether each command succeeded, unless there is explicit screen output that says so. More importantly, sudo bash can be used to bypass sudo (or ‘fool’ the audit), so it is not entirely reliable.

When to use sudo:

This method is very effective for answer the question ‘Who is using / abusing sudo’. In other words, if you have specific issue only surrounding root activity of non-root users, then sudo is effective. If you need a more holistic audit that also covers actions of normal users, you’ll need to merge multiple audit sources.

Scenario 4: Auditing using the native auditd audit facility

How auditd is setup and started:

The native audit facility is preconfigured in Linux [auditd(8)]. Configuration of the audit facility can be done via the graphical application under X Windows, via the auditctl utility or directly via configuration file modification.

Audit facility configuration in X Windows

Once installed, it is easy to use and automatically starts with each user session in Linux.

What auditd records:

The audit facility records data from the kernel, included the system calls, user ID and process ID. It captures all the low-level internals with a high level of granular detail. The information can be stored locally or sent to a central server.

Example of information captured using the native audit facility

Security and Audit Implications:

Configuration allows you to determine what events or system calls should be recorded. These are recorded directly from the kernel and are highly-reliable. The events can be tagged so that they are easy to sort through, but the huge amount of data often makes it difficult to locate what you are looking for. Unlike script and screen, auditd will capture the deep internals. However, it has the opposite problem because it does not capture screen I/O. The audit data is of a very technical nature, and does not necessarily state what the user was doing. (i.e. It will show actions spawned within a script, but does not show the script being run or the interactive command launched.)