Keeping Audit Trail of Activities from Root Login? 44
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?
Sudo (Score:5, Informative)
Sudo is in the ports collection for FreeBSD, no idea about linux though.
Re:Sudo (Score:4, Informative)
There are RPMs or DEBs for sudo... the package name is (originally enough) "sudo".
sudo pacakges [rpmfind.net] at RPM Find.
Re:Sudo (Score:2, Informative)
http://www.courtesan.com/sudo/
Re:Sudo (Score:4, Interesting)
like "sudo sh" or "sudo su" where the only log you get is that a particular person ran sh/su, but not what they did after that point.
But IIRC, you can configure sudo access to specific programs/commands, and can block access to ones that cause problems like this.
And as long as you send your syslogs to a remote/secure machine you don't have to worry about a sudoer editting the logs to cover up after themselves either.
Re:Sudo (Score:2)
not only that, but there's a million other programs out there that allow for access to the shell. less, for instance. it could look like somebody is innocently reading a config file as root (well, innocent as long as that's part of their job...) but they could use shell escapes to do just about anything. before you give anybody access to anything using sudo, think about how it could be used to obtain a root shell.
and i'm not talking out of my ass here. i've run into situations at work a couple times when i couldn't find the full time admin and needed to get something done, so i used my sudo access to get a root shell. (of course i had been given permission to root our boxen in case of emergency)
Re:Sudo (Score:1)
Yeah, that's the problem with sudo. If you configure it so anyone can do any measure of useful work, then they can also crack root with it.
Of course that's just re-affirming the "golden rule of Unix", don't give root access of any sort unless someone needs it and can be trusted with it.
We use it here mostly as a nice convinience, so we don't have to su back and forth (we also set it up so we can use rpm through sudo without a password - again convinient, but not secure).
Policy solution (Score:1)
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.
Re:Sudo (Score:1)
Re:Sudo (Score:1)
Re:Sudo (Score:2)
That's fiendishly difficult to do. Let me give you an example, what could be more innocent than the "cat" command, so a user can read the syslog for debugging? Well, "sudo cat" can be used to view or rewrite
The problem really is deeper, in the Unix "philosophy" itself. You're either uid 0 who can do anything, or a regular user. There's no notion of really fine-grained access control. Wouldn't it be great, for example, to be able to grant a group of users the right to bind to port 80 (for example) without having to be root in the meantime? Or to create a group of users who can start and stop sendmail/popper without being able to read mail spools? There's simply no elegant way to do this - the users/groups r/w/x mechanism on the file systems just isn't flexible enough. VMS solved this problem decades ago, but its access control lists (on file system objects and system privileges) never cross-pollinated into Unix, similarly processor quotas and many tuning parameters.
The only way to log what root does is to use a packet sniffer on a box that the root user does not have a login on, and physically secure this machine, and the main servers so they cannot have their keyboards accessed. In this case, even the use of SSH would have to be a "warning flag" that something suspicious was happening. You can't even rely on a kernel mod to track root, since the kernel can easily be replaced.
Re:Sudo (Score:2, Interesting)
There's also the good ol'
Re:Sudo (Score:2, Informative)
2. how you will record when they type "sudo su" ?
3. use process accouting programs, every distro have it
i
Related to "Handing Over Root Passwords?" (Score:3, Interesting)
Try process accounting (Score:4, Insightful)
Re:Try process accounting (Score:2)
Re:Try process accounting (Score:1)
Sudoer (Score:1)
and you can actually set how much root access
you want them to have
Hard Copy (Score:4, Insightful)
Re:Hard Copy (Score:4, Informative)
However, it is a valid method of logging to have syslog print to a printer; it means that if a cracker breaks into your system, you still have a log even if he deletes/modifies the log files.
Gives me an idea.... (Score:1)
I'll add these to my list of Things I'd Do If I Had The Time And Weren't A Lazy Fsck.
Re:Gives me an idea.... (Score:1)
Cryptnotic
Re:Gives me an idea.... (Score:2)
On a less sarcastic note, remote logging is a very good idea. Security Focus [securityfocus.com] has a new mailing list about Log Analysis [securityfocus.com] 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
Re:Gives me an idea.... (Score:1)
Re:Gives me an idea.... (Score:1)
Sudo Homepage (Score:3, Informative)
Snoopy (Score:3, Informative)
You can find snoopy here:
http://www.citi.umich.edu/u/marius/snoopy/
Use a secure unix (Score:2)
shell (Score:1)
Some fairly simple ways. (Score:2)
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.
Modify Bash itself. (Score:2, Interesting)
I help (in spare time) Administer a shell provider (Techcellent.com [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
Re:Well uhm.. (Score:1)
In addition to
Take the log out the computer (Score:1)
There are many ways to do so:
Using something like "tail -f nameoflog.log | scriptsend.pl" would work well.
---
Re:Take the log out the computer (Score:3, Informative)
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 <
Re:Take the log out the computer (Score:1)
Include 'script' (Score:1)
Just a thought?
Re:Include 'script' (Score:1)
I'm hoping to do something like this to see what our DBA (who works directly for the client) is doing on the Sun server which I administer. She keeps changing things without telling us and it is getting annoying. Unfortunately, she knows about
Modified shell writing all to syslog. (Score:1)
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.
Or try another approach ... (Score:1)
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,