Slashdot Mirror
Keeping Audit Trail of Activities from Root Login?
supersam asks: "This question might sound a bit naive, but I am comparatively new at this. So, here goes: on one of my application, based on UNIX platform, I need to implement a mechanism by which, I can trace when an access to ROOT was attempted and what all actions were performed during that session. While info on the first part is probably available through UNIX logs, the second bit is difficult to me. The need is arising because, while it is useful for the support team to know the ROOT password as most of the wonderful things can be done with that access, it also can be a nightmare if something goes wrong and we have to trace the culprit or the root cause of the problem (config files etc...). Is there any way of keeping an audit trail of all activities performed from ROOT login in UNIX which can be traced." Interesting thought. About the easiest way to do this would be to give root it's own custom shell and log everything that shell does. Are there shells that can already do this? Has anyone else implemented such a system? If so, what did you do?
Force people who want/need to have root access to use 'sudo'. It will log all activities using syslog. This also negates the need to give lowlevel admins the root password (yay!).
Sudo is in the ports collection for FreeBSD, no idea about linux though.
"Why do you consent to live in ignorance and fear?" - Bad Religion
This isn't related to the "Handing Over Root Passwords to Consultants" ask slashdot a couple of items below is it? If not there may be a few good suggestions there.
For the second part of your question, you could enable process accounting. Which logs accounting information (including the UID) for every process that successfully terminates. See the man pages for acct(2) acct(5), accton(8), and sa(8).
Linux has Sudoer which you can give root to a user and they use theey're password not root
and you can actually set how much root access
you want them to have
LABTYD
If the system is not accessed physically then you can set up the logs to print out to an old-fashioned dot-matrix printer, even root access can't erase those :-)
Information about sudo, including docs, downloads, and mailing lists, is available at http://www.courtesan.com/sudo/index.html.
There is a "wrapper" library called snoopy that can do this. It logs all commands executed to syslog. You can then let syslog log over the network to a dedicated logging host, to which your users don't have access.
You can find snoopy here:
http://www.citi.umich.edu/u/marius/snoopy/
I'll add these to my list of Things I'd Do If I Had The Time And Weren't A Lazy Fsck.
grep -ri 'should work'
One of the requirements of the higher ratings of the Orange Book is copious logging. Ridiculous amounts of logging.
Vintage computer games and RPG books available. Email me if you're interested.
I'd be carefull with putting the real root into a wrappered shell - too much can go wrong early in the boot process and a wrappered root account might not be functional depending on what pieces parts are borken. I'd create a seperate account for these people and then wrapper that one. The sudu spproach still sounds better to me as more secure in the long run but I don't think the logging was geared towards a malicious root user who would delete the logs, rather it was directed at an incompetent one that would screw the system up then hide to avoid the resulting chaos. In the latter case the wrappered shell would be less work to set up/maintain.
Something else to consider is creating multiple independent root accounts -- such that everyone has their own root account, with a separate password.
As long as they are all UID 0, it will work just fine. Each user can even have their own independent shell and home directory...
This practice, while exposing your system to more risk from password-cracking, helps when you need to disable one person's root access without affecting everyone elses.
Also: Granted anyone capable will turn it off, but consider enabling a high history and saving of history by default. (Say, the last 100,000 commands executed.)
These are some halfway decent ways of tracking what is going on with the root shell. Mind you, they aren't hackproof, but they make decent information for after-the-fact investigation:
Of course, enable your shell history. Also, turn on "lastcomm" so you can at least get the commands (but not the arguments) given at the shell prompt. Finally, more advanced versions of UNIX (I personally know HP/UX and Solaris do this) allow you to turn on snooping to system calls so you can log to disk all the nice commands and their arguments, like fork, accept, all types of disk access, etc.
Solaris has this included in something called "bsm" (basic security module) which comes with the OS. HP/UX you have to put into "trusted" mode and enable it through SAM. The logs it creates are very difficult to make an authentic looking fake for. Possible, though. Yes, syslogging to a remote host is a good idea.
Of course, a nice hacker would simply flood the syslogd that is keeping the logs... but you've got to decide how far you're going to go with all of this.
Also, there are some tools, like Sun's Configuration Service Tracker, which regularly scans the system and logs configuration changes.
Maybe there is a better way of doing all of this. But the layered approach seems to catch a lot of different things at a lot of different levels. All depending on how far you want to dig down into things.
Since this is access for (supposedly) trusted techs, you could simply let them know that they had better have a very good excuse if you catch them invoking a shell and running privlidged commands without logging. Where I work, members of %wheel have an agreement that we use sudo but not 'sudo -s' (unless it's something like 'sudo -u test -s') or 'su', so that an audit log is kept of what commands have been run. More than once the sudo log has been useful for problem hunting.
If you don't trust your techs or you need to give out limited elevated privlidges to untrusted users, then none of what I've said applies.
/etc/shells contains /bin/bash
I help (in spare time) Administer a shell provider (Techcellent.com)
What the admin did was modify bash itself.. Making a small portion of the code log something to a very obscure place that cant be accessed by anyone. Try that!.. But I think the line printer Idea is a Very Good Idea and requires the least effort
This page left intentionally blank.
Keeping track of /var/log/messages and /root/.bash_history works great for me.
The LIDS project (http://www.lids.org/) provides an alternate way logging to an unmodifyable file. By enhancing the kernel's (Linux) capabilites handling, it allows you to make a file "append only" so data may be written to the end but not overwritten or erased. Using Linux capabilities, not even root can modify the file after the kernel is "sealed"; unless a seperate passwd is entered.
This isn't a fullproof solution as the file vulnerable during reboot and does nothing to prevent overflowing the logs.
There are many ways to do so:
Using something like "tail -f nameoflog.log | scriptsend.pl" would work well.
---
Why not include the script command in root's bashrc and name the file name the date and time of the login, or whatever other information that you would want in the name? Put it on some special filesystem and then all is good.
Just a thought?
I can't believe no one has suggested it. Turn on accounting (accton) and *all* commands are logged to /var/db/acct/.... - just grep for the root lines.
Oh, you're probably a linux boy, in which case get FreeBSD
Email every line (with a good filter on your email client or procmail it's easy to manage)
Log on an other server (not with nfs, but anything with "append only" access... a cgi script on the other would work well)
can you tell me what the point of these are?
Why not use the tool that's designed to do the job? (namely, SYSLOG)
Syslog is capable of sending data to another box, without resorting to ugly, inelegant hacks like the ones you suggest. (an email for every line? are you on crack? Do you have any idea how much overhead a TCP session requires? Not to mention the wasted processing power on the mail server.)
Do yourself a favour, and learn a little bit about how Unix works before opening your mouth.
The Bourne shell used by root was modified to log all commands to a number of files in a particular directory (/etc?). The files were written to in a circular fashion - when one file was full, the next would be overwritten.
The really odd thing was that these logs were not written to immediately, but were flushed out sometime in the future, often after the shell had been closed. I never got to find out how this worked, but I assume that the syslog equivalent was responsible.
Of course on this system there were very few tools, and most of them were derived from mid 1980s code. I'm not even sure if it was possible to get a shell from their implemantion of vi - it was a very broken vi implementation.
This logging was pointless, however. The majority of root access was used to query and modify the various security databases via a number of text based tools. If run interactivly these would not log anything.
How can I log so that I have a trail left to examine?
This question is easy to answer: turn on logging as much as possible. The only downside is that anyone with root access can alter or delete those logs. Process accounting as a means for logging what root is doing, is easy to implement but very hard to use. PA only logs when a command finishes, so most of the time you will have all the commands in the reverse order they were executed. And it doesn't log arguments. So it certainly does not give you a bullet proof solution. The best solution here is to try logging to a remote computer, syslog has facilities to do just this. Using sudo, a well known tool on Linux, is also an option. Using sudo however is not that easy as it seems. You have to carefully enumerate the list of commands the user can execute. Enlisting "vim" for instance, opens up sudo to every command since in vim you can start a shell as root in that case.
Another interesting point to mention here is that it is probably better to prevent then to cure. Abuse of the root account, a break in,