Sudo is one of the most used command line tools in the Linux / UNIX / macOS world. It gives users the ability to execute commands as another user. Most often it is used to gain root (administrator) privileges. Sudo was created when there were a small number of independent large systems. Some support for multiple hosts, central management and monitoring were later added to it. These tools do their jobs, however large enterprises require ease of use, reporting and monitoring.

In this blog I will introduce two tools by One Identity, which provide you with tools to more easily manage access to sudo centrally and to monitor sudo users more easily. Safeguard for Sudo adds centralized management and logging to sudo. Safeguard for Privileged Sessions lets you monitor sudo sessions.

If you are surprised to see me write about commercial software on the sudo website, I recommend checking out the first ever sudo blog: https://www.sudo.ws/posts/2019/07/the-first-sudo-blog.../ It’s a bit of history, and it also clarifies how sudo and One Identity are related.

From the user’s point of view, Safeguard for Sudo does not change anything. Users and scripts can use sudo without changing their work flows. The differences are on the management and monitoring side. It provides improved central management, key logging and various reporting capabilities.

Sudo has supported central configuration for quite some time. You can use the same sudoers file on multiple hosts and specify on which hosts a command is allowed to run. This configuration is not managed centrally, for that you can use Ansible, Puppet, and so on. Sudo also has some built-in support for managing the configuration centrally: with some limitations you can store the configuration in LDAP.

One of the main features of Safeguard for Sudo is central configuration management for sudo. One of the complaints about sudo is that privileged users can edit the sudoers file. This problem is resolved if the configuration is stored in LDAP, but a network outage might render sudo unusable. Safeguard for Sudo solves this problem by creating and storing the sudo configuration centrally, so local users cannot edit it. However, there is also a local, read-only, cache of the sudo rules, so sudo works even if the policy server is inaccessible.

Safeguard for Sudo can produce various audit reports. You can review policy changes, who changed what at what time. Commands executed through sudo are also logged in a database which can be queried based on the user, host, command, etc. If you enable keystroke logging, you can also check what happens inside shell sessions.

The main strength of SPS is protocol analysis. It can look inside what is happening in an SSH or RDP session (and many others), record what is happening in a session and in many cases even control what is allowed within a session.

SPS can also collect sudo session recordings. While sudo provides a command line tool to view session recordings, SPS has multiple graphical tools to view recordings. You can view them both on the SPS web interface and using a desktop player. The functionality of the two is almost the same. The desktop player allows you to work with session recordings independent from the SPS appliance.

It is possible to view recorded sessions using sudo’s command line tools, but SPS provides a lot more functionality. SPS not only stores the terminal input and output but also makes the contents searchable. You can list commands executed within a session and jump immediately to the interesting parts.

If you also have a license for Safeguard for Privileged Analytics then SPS can also help you to identify the risk of various sudo sessions. It uses machine learning to create a base-line of normal behavior. It can consider login time, host, commands executed and other factors.

SPS Privileged Analytics helps you prioritize events on your network. While a login failure might create a high alert on an analytics system based on patterns, it might simply be a mistyped password. A successful login might not create a high alert but might be more problematic. If it comes at an unusual time or some unusual commands are executed, SPS gives it a high score. Based on the scores it is easier to decide which events to investigate first.

On the screenshot below you can see SPS analytics in action. All of these are sudo sessions. The third column shows the score. The two sessions, where I ran different commands than in the rest, got a much higher score.

You can learn a lot more about the software mentioned in the documentation, which you can find on the One Identity support site. If you would like to test this software in your own environment, you can download a trial version.

If you would like to be notified about new posts and sudo news, sign up for the sudo blog announcement mailing list.