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).
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/
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.
On a less sarcastic note, remote logging is a very good idea. Security Focus has a new mailing list about Log Analysis that would probably be of some interest to you, as there's been quite a lot of discussion already about remote logging.
You're right about one thing - it does save lots of trees
Outside of a dog, a book is man's best friend. Inside a dog it's too dark to read. - Groucho Marx
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.
/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.
You could have `tail -f` write to a named pipe (FIFO), and a script run every minute or so (crond), reading from the FIFO, and send the mail. `tail -f` would keep writing to the FIFO. Each time `scriptsend.pl` tries to read from the FIFO, it would get all the data, get EOF properly (FIFO gets cleared), send, all the while `tail` keeps writing to the FIFO. On the next run, the FIFO has new data in it for the script to use.
% mkfifo
% tail -f nameoflog.log >
And, every minute:
% scriptsend.pl <
Liberty in your lifetime