1. Overview
When using the sudo command in Linux, we can gain root access to perform certain activities. However, not all users have this access.
When someone attempts to raise their access level without permission to do so, then a report is written. We may wish to customize or review these reports.
In this tutorial, we look at where to find the sudo reports, how we can customize them, and how to send them via email.
2. Typical sudo Incident Reports
Let’s see how a system reacts to a failed executed event. Let’s imagine a user tries sudo without the proper permissions:
[unprivileged_user@host ~]$ sudo ls /root
[sudo] password for unprivileged_user:
unprivileged_user is not in the sudoers file. This incident will be reported.
Here we can see that system denies access and warns that the event is being reported.
We would expect to find the details of the attempt in the logs:
Mar 22 21:51:07 fedora sudo[2866]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/ls /root
Therefore, as an administrator, we can find out who tried to access sudo along with the details of when and how.
3. sudo Logging Reports
There are two places to find the logs of failed sudo attempts: the journalctl service and the rsyslog standard logfiles.
3.1. The journalctl Command
Linux collects logging data from various resources and services. We can access it with the journalctl command, which is part of the systemd-journald.service.
We can invoke the command with no parameters to find all logs. However, for this purpose, let’s apply a filter by specifying the absolute file path of the command we’re interested in:
$ journalctl /usb/bin/sudo
Apr 08 07:07:59 fedora sudo[3567]: unprivileged_user : TTY=pts/0 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
May 11 16:53:11 ubuntu sudo[22373]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/etc/init.d/apache2 start
Even with this filter, the journalctl command might show us events we’re not interested in. Therefore, to focus on errors, let’s add the priority flag -p with value 3 (error status):
$ journalctl -p 3 /usr/bin/sudo
Mar 22 20:08:28 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
Mar 22 23:25:20 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/service httpd stop
3.2. sudo Logfiles
The default log file containing sudo incidents depends on the specific Linux distribution. More specifically, for the most common Linux operating systems, the log files can be found in different files:
- RPM-flavor (CentOS, Fedora) – /var/log/secure
- Debian-Ubuntu flavor (Ubuntu) – /var/log/auth.log
- openSUSE – /var/log/messages
We can customize these log files by editing /etc/sudoers along with the rsyslogd system configuration files.
We start editing the configuration file by invoking:
$ sudo visudo
and then insert the following line to set an alternative event logging file:
Defaults syslog=local1
Next, by using a text editor of our preference, we edit the /etc/rsyslog.conf file (/etc/rsyslog.d/50-default.conf for Ubuntu OS). We need to associate the local1 facility directive with the desired new log file. For this, we add the next line at the top of the other defined logging facilities:
local1.* /var/log/sudo.log
Finally, to activate the changes, we restart the rsyslogd service:
$ sudo systemctl restart rsyslog
4. sudo Reports via Email
If we prefer, we can communicate sudo warnings and generic information by email. We can customize this by editing the /etc/sudoers configuration file.
4.1. Email Options
Let’s try configuring our system to produce a report via email. To start, we define the email account that will collect the final report by adding some directives:
Defaults mailto="ubuntu@localhost"
Defaults env_reset
Defaults mail_no_user
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Now, let’s see what happens when a non-privileged user tester attempts to set up a crontab job:
$ sudo crontab -e
[sudo] password for tester:
tester is not in the sudoers file. This incident will be reported.
As the user tester is not allowed to perform such action, the system launches a warning via email to the mailto email address ubuntu@localhost.
If we access the ubuntu user local mailbox with:
$ mail
then we can read the logged warning:
N 7 tester@ubuntu Wed May 11 19:16 16/581 *** SECURITY information for ubuntu ***
In this email, we are able to read the full log related to this event:
& 7
Message 7:
From tester@ubuntu Wed May 11 19:16:06 2022
X-Original-To: ubuntu@localhost
To: ubuntu@localhost
From: tester@ubuntu
Auto-Submitted: auto-generated
Subject: *** SECURITY information for ubuntu ***
Date: Wed, 11 May 2022 19:16:06 +0000 (UTC)
ubuntu : May 11 19:16:06 : tester : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/usr/bin/crontab -e
Similarly, we can customize an email trigger with alternative options, such as when a user executes a sudo command with an incorrect password (Defaults mail_badpass) or when a sudo user executes commands not listed in the sudoers file entry or explicitly denied (Defaults mail_no_perms).
5. Conclusion
In this article, we saw how to find log entries notifying us about users attempting to use sudo without permissions.
We saw how to use journalctl and how to find the log files. We also looked at how to configure logging and how to trigger email messages on violations of the sudo policy.