The sudo(8) privilege management tool is very admin-friendly in that it logs successes and failures. I don’t really care when my users successfully use sudo. I do care when they use it unsuccessfully, however. A sudo failure indicates that either the user doesn’t know their system password, or they’re trying to use forbidden commands.
sudo keeps logs. The interesting thing is, successful log messages are of priority notice, while unsuccessful attempts are of priority alert. This opens up an easy way to improve security and customer service.
First, a user who cleverly gets root can edit your log files. forward your sudo logs to your logging host. Your users should not have access to your logging host.
First, split your sudo logs out into two logs. You can set sudo’s syslog facility, but as I’m always short on facilities, I tend to break sudo out via program name. Here’s a syslog.conf entry.
!sudo
*.* /var/log/sudo
*.alert /var/log/sudofail
Touch the files, restart syslogd, and /var/log/sudofail will contain only password failures and attempts to run forbidden commands. The two log entries are very different.
Sep 26 10:37:27 caddis sudo: mwlucas : command not allowed ; TTY=ttyp0 ; PWD=/home/mwlucas ; USER=root ; COMMAND=/sbin/reboot
Sep 26 10:53:09 caddis sudo: mwlucas : 3 incorrect password attempts ; TTY=ttyp0 ; PWD=/var/log ; USER=root ; COMMAND=/usr/bin/su
Separating this log out opens some interesting customer service possibilities. If you’re on OpenBSD, you can automatically have newsyslog email you the log of failures. Otherwise, you can set up a separate script to do that, or feed it to your alerting system, or whatever. Then have a helpdesk minion call the user in question and ask what they’re trying to do. Perhaps they’ve forgotten their password. Perhaps someone else got access to their account. Perhaps they’re having trouble. Maybe they need sudo -l explained to them.
The end user will either feel like you’re watching out for them, or realize that your sysadmin group watches the systems very closely.
Even if you don’t take proactive action, having sudo failures logged to a separate file simplifies digging through the logs.
Excellent tip!