Configuring SUDO for Effective Activity Monitoring Via Syslog

I have discussed in previous posts the importance of administrators using SUDO to provide individual accountability.  SUDO provides command-by-command accounting of actions performed by administrators, with logs sent as standard syslog events looking like this:

Feb  4 19:23:23 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/bin/ps -x
Feb  4 19:23:34 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/usr/bin/vi /etc/passwd
Feb  4 19:23:59 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/usr/bin/tail -100 /var/log/messages

We can see pretty clearly all the actions I took above: the user “jerry” performed a number of actions, including one that is potentially concerning: vi /etc/passwd.  The action on /etc/passwd requires some investigation.

First, we need to be sure that an administrator can’t cover his tracks by deleting logs.  This is best accomplished by streaming the logs to a hardened syslog server, where the administrator doesn’t have the ability to delete logs. 

Next, we need to ensure that SUDO is configured properly.  Without careful configuration, administrators can easily and inadvertently bypass the logging of SUDO by using SUDO to spawn a root shell.  Users granted permission to “ALL” commands in the sudoers file have the ability to do so easily, in one of two ways:

  1. sudo -s
  2. sudo /bin/sh (or any other shell binary)

Once an administrator launches a root shell using SUDO, command-level accountability is lost.  When an administrator runs “sudo -s”, the only thing appearing in the logs is:

Feb  5 16:29:54 bsd sudo:    jerry : TTY=pts/0 ; PWD=/usr/home/jerry ; USER=root ; COMMAND=/bin/tcsh

despite having run many commands:

> sudo -s
You have mail.
# rm /var/log/messagesYou have mail.
# rm /var/log/auth.log
# vi /etc/passwd

There are two primary ways of preventing administrators from doing this:

  1. Define a set of commands that administrators are able to run in the sudoers file, and configure sudo to only allow administrators to run those commands.
  2. Define a set of shells in the sudoers file, and configure sudo to allow any command to be run, except for the shells.

Defining a restricted set of commands that administrators can execute

Generally, this is not a feasible solution for all administrators, as some of them will at some point or other need to execute a wide range of commands.  The method to implement this is as follows:

/usr/local/etc/sudoers

Cmnd_Alias      ALLOWED=/bin/who, /bin/ls,/usr/bin/more

%wheel ALL = ALLOWED

Now, members of the wheel group are only able run run the commands “who”, “ls”, and “more”.   Attempting to launch a root shell results in:

> sudo -s
Sorry, user jerry is not allowed to execute ‘/bin/tcsh’ as root on bsd.

Defining a set of shells that administrators can not  execute

This is a more practical solution than the previous option for most administrators who need to run a variety of commands.  It essentially prevents direct execution of the shell executable.  The method to implement this is as follows:

Cmnd_Alias     SHELLS = /bin/sh, /bin/csh, /bin/tcsh, /usr/local/bin/bash
Cmnd_Alias     SU = /usr/bin/su
%wheel  ALL = ALL, !SU, !SHELLS

All of the shell binaries on the system will need to be defined in the SHELLS alias for this to be effective. Now, when an administrator tries, he will get this:

> sudo -s
Sorry, user jerry is not allowed to execute ‘/bin/tcsh’ as root on bsd.

It’s important to note that this can be effectively bypassed through two methods:

1. copy a shell to another file – such as “cp /bin/sh /bin/jerrysh”, then running “sudo /bin/jerrysh”

2. creating a script to run all of the commands that the administrator does not want to have logged

Both of these can exposures can be addressed using the “noexec” option in the SUDO config file:

Defaults               noexec

The major down side to doing this is that no script can be executed by an administrator using SUDO with this option enabled, which may be undesirable.

Conclusion

Requiring administrators to use SUDO is a very good practice and allows for proactive monitoring of inappropriate and/or unauthorized activity.  However, care must be taken to properly configure SUDO to ensure administrators can not trivially bypass the accountability and log analysis implemented.  In a future post, I will describe how to structure a proactive monitoring program for SUDO events.