Use of sudo commands on a server
The sudo command provides authenticated users elevated access to the system. This access might result in undesirable changes leading to an incident or outage. You want the ability to see which sudo commands were executed on the server prior to an incident, and by whom, so you can quickly identify root cause or determine who to consult for further investigation.
Data required
Procedure
- Install the Splunk Add-on for Unix and Linux.
- Run the following search. You can optimize it by specifying an index and adjusting the time range.
sourcetype=linux_secure process=sudo COMMAND=* host=* |rex "COMMAND=(?<raw_command>.*)" |eval COMMAND=coalesce(raw_command, COMMAND) |table _time host USER PWD COMMAND
Search explanation
The table provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.
| Splunk Search | Explanation |
|---|---|
|
|
Search only the |
|
|
Return all |
|
|
Capture the entire command text and name it |
|
|
Return commands that are set in different ways than key-value pairs. These two rex commands are an unlikely usage, but you would want to capture this kind of command if it occurs. |
|
|
Display the results in a table with columns in the order shown. |
Next steps
The resulting table shows which users ran which command with administrative privileges. Knowing this information can identify problems with the system that are the result of system configuration changes. For example, if user Tom used sudo to edit important config files found in the /etc, you might be able to confirm those changes caused a service to malfunction.
_time |
host |
user |
pwd |
commmand |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that the above sample output shows two instances of root as a user, which indicates direct root access to the system. It is a best practice to not allow direct root access to the system but rather to always require sudo to gain access to privileged functions. In the case above, we have no idea what identity was behind the root user who logged in to 10.2.1.35. However, we do for host 10.2.3.35 and for 10.2.1.33. This makes it possible to trace back privileged actions to known users on the system rather than unknown users who gain direct access as root but know the root password.
The above report is also useful for compliance because many controls, such as the CIS Controls, state that an organization must show controlled use of administrative privileges. Sudo is one way to control such privileges and the report generated by this search can be used to discover and give attestation to compliance to the control. Controlling administrative privileges is not only a security measure but also an aid in root cause for misconfigurations.
The data in this example is usually found in the Linux auth.log and is given the sourcetype of linux_secure by the Splunk add-on. Below are some sample full events.
|
|
|
|
|
|
Interesting fields that are extracted by the add-on include dest (destination), pid (process id), process (process name), src_port (port of the authentication process), sshd_protocol, and user. These fields can be used to analyze other authentication related metrics, such as users logged in at the same time from multiple remote locations.
Finally, you might also want to look at other similar searches to this in our article Managing *nix system user account behavior.