What is the preferred method to keep track of who is acting as root in the logs when root login is disabled (SSH) but users can run sudo -i
or su -
to become root? I would like to follow every command with the original username as well. RHEL 6 or any Linux rsyslog, etc.
Log all root activity with original username who su’d/sudoed to root
logsroot
Related Solutions
If you take a look at the executable sudo
:
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
You'll notice that it carries the permission bits ---s--x--x
. These can be broken down as follows:
-|--s|--x|--x
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only the setuid bit is enabled for user who owns file
--x - only the group execute bit is enabled
--x - only the other execute bit is enabled
So when a program has it's setuid bit enabled (also referred to as SUID) it means that when someone runs this program it will run with the credentials of the user that owns the file, aka. root in this case.
Example
If I run the following command as user saml:
$ whoami
saml
$ sudo su -
[sudo] password for saml:
You'll notice that the execution of sudo
actually is running as root:
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
setuid mechanism
If you're curious how SUID works take a look at man setuid
. Here's an excerpt from the man page that explains it better than I could:
setuid() sets the effective user ID of the calling process. If the effective UID of the caller is root, the real UID and saved set-user-ID are also set. Under Linux, setuid() is implemented like the POSIX version with the _POSIX_SAVED_IDS feature. This allows a set-user-ID (other than root) program to drop all of its user privileges, do some un-privileged work, and then reengage the original effective user ID in a secure manner.
If the user is root or the program is set-user-ID-root, special care must be taken. The setuid() function checks the effective user ID of the caller and if it is the superuser, all process-related user ID's are set to uid. After this has occurred, it is impossible for the program to regain root privileges.
The key concept here is that programs have a real userid (UID) and an effective one (EUID). Setuid is setting the effective userid (EUID) when this bit is enabled.
So from the kernel's perspective it's known that in our example, saml
is still the original owner (UID), but the EUID has been set with whomever is the owner of the executable.
setgid
I should also mention that when we're breaking down the permissions on the sudo command the second group of bits were for group permissions. The group bits also has something similar to setuid called set group id (aka. setgid, SGID). This does the same thing as SUID except it runs the process with the group credentials instead of the owner credentials.
References
Here's some sample log file output:
Feb 26 23:04:55 pegasus internal-sftp[32524]: session opened for local user joeuser from [123.123.123.123]
Feb 26 23:04:57 pegasus internal-sftp[32524]: opendir "/home/joeuser"
Feb 26 23:04:58 pegasus internal-sftp[32524]: closedir "/home/joeuser"
Feb 26 23:05:01 pegasus internal-sftp[32524]: opendir "/home/joeuser/"
Feb 26 23:05:01 pegasus internal-sftp[32524]: closedir "/home/joeuser/"
Feb 26 23:05:02 pegasus internal-sftp[32524]: opendir "/home/joeuser/upload"
Feb 26 23:05:02 pegasus internal-sftp[32524]: closedir "/home/joeuser/upload"
Feb 26 23:05:07 pegasus internal-sftp[32524]: opendir "/home/joeuser/upload"
Feb 26 23:05:07 pegasus internal-sftp[32524]: closedir "/home/joeuser/upload"
Feb 26 23:05:09 pegasus internal-sftp[32524]: session closed for local user joeuser from [123.123.123.123]
Which user is which?
If you take notice of the output above there is a number between square brackets , internal-sftp[32524]
. The number is 32524. This represents the session ID for user joeuser, so you can use this string together which messages relate to which user's login.
Rotating the logs
You can modify the log rotation schedule for various logs under /etc/logrotate.d/*
. Each log file typically has a corresponding file in this directory. So you could change the syslog
file there, for example or create your own for your sftp.log
logfile.
Also logrotate
has a configuration file, /etc/logrotate.conf
which contains these lines:
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
These are what the files in the /etc/logrotate.d
directory use, if they don't have a setting of their own. So most files are rotated weekly and 4 of them are kept. If you wanted to keep 6 months it would be 4*6 = 24 for the rotate
option to keep 6 months, roughly.
Example
Given you're logging to /var/log/sftp.log
via syslog
you'll need to make your changes in this file, /etc/logrotate.d/syslog
. Your file will look like this after making the required changes:
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
/var/log/sftp.log
{
rotate 24
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
Since you're using syslog
you'll have to rotate all these log files as well, keep 24 weeks worth of these as well. If this is unacceptable then your only other course of action would be to create a separate section in this file, syslog
like so:
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
/var/log/sftp.log
{
rotate 24
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
This has some side-effects, one being that you'll be restarting the syslog
daemon 2 times each week instead of once. But the logroate syntax does not allow for fine granular control of the rotation schedule for certain logfiles while not rotating others, when the log files are being generated by the same service, i.e. syslog
.
Best Answer
The most robust methods seems to be auditd:
Requirement 10: Track and monitor all access to network resources and cardholder data
Auditd basically intercepts all system calls and checks them against your set of rules. So in your
/etc/audit/audit.rules
file you would have something like the following:The last rule being the only non-default rule.
The main drawback with this approach (and the reason I found this question while looking for alternatives) is that the raw log files are pretty cryptic and are only helpful after running the querying program on the raw log file:
ausearch
An example query for that rule would be:
A common sense solution would probably be to create a cron that will query your raw auditd logs and then ship them off to your logging solution.