Logging shell history on Solaris.

[reddragdiva]

The audit department wants us to log all shell commands entered by root. So I need to log root's shell history on Solaris 8, in all of ksh, csh and bash.

Has anyone actually done this? Is there a built-in mechanism I've overlooked? Any speculation on how it might be done if you haven't done it? I can't seem to get a named pipe to work.

Comments

[lithiana.livejournal.com]

i believe what you want is "BSM" or "auditing" - i've never played with it, but i think it can do something like this.

[reddragdiva]

"imagine running truss on every single process on the system and saving the resulting output to a file. BSM actually provides even more detailed information than that." Ew. Now all I need is less detail ...

[sinibar.livejournal.com]

Less detail? are you sure?

Surely what an auditing department needs is more detail, much more detail, in fact so much detail that they haven't a hope in hell of sorting the wood from the trees.

Once it's established that auditing never highlights problems that were clearly in the log files they'll be declared ineffective and abolished.

[reddragdiva]

You have much to learn about local government.

[sinibar.livejournal.com]

I assure you I don't!

Although I was being silly about the auditing dept. being abolished, it's more likely to be quadrupled. Still, one can but hope.

[zenmonkeykstop.livejournal.com]

a .login that clears the shell history and a .logout that concatenates the shell history to a file?

[mendel.livejournal.com]

We just exec 'script' from .login/.profile. It's ugly because you get the output of curses-y stuff in the logs, but it's usable for "what the heck did he do?" emergencies and auditing.

[reddragdiva]

Ew, icky. Still, I suppose it'd compress well.

[ewx.livejournal.com]

If you could use ttyrec instead of script then you could view the output with IPBT (http://www.chiark.greenend.org.uk/~sgtatham/ipbt/), taking advantage of all the control codes rather than being annoyed by them. (Not that I've ever tried this.)

sudoscript?

[ewen]

http://egbok.com/sudoscript/

It appears to be the one I saw written up in a Usenix journal a few years back, which basically ran sudo to get root (or whatever) and logged all the shell commands before executing it.

For auditing purposes you'd need to defeat the ability to direcly become root as well. (Including presumably single user mode -- but typically anyone that can reach single user mode can, eg, boot off other media too.)

Ewen

[sbp.livejournal.com]

Set a policy to use sudo? And then ask them if they are going to take full-motion-video of all the windows administrator logins....

If you have all your console serial lines on a console server, you can get the console server to log all serial output to a log server, so you would see all single-user/fsck/reboot stuff that was performed on the console.

[hirez.livejournal.com]

We just turn turn the history on and 1000 lines deep. It's Good Enough, since your average SKiddy won't remember to splat it, and if it is missing that's evidence of Bad Things.

[hirez.livejournal.com]

Or, if you really want to do it right, log everything to console and have a serial printer in a locked room far away.

The Plod like printed things.

[belegdel.livejournal.com]

Yay auditors! *puke*

I take it they've had it explained to them that once someone has root all bets are off? Of course they have and, being auditors, they chose to proceed with wasting everyone's time anyway.

I think the sudo+logging suggestion is the most elegant but it will require a bit of retraining for the sysadmins.

Upgrade everything to Solaris 10 and use RBAC instead - Sun marketing tells me it will abolish child poverty too ;)

[theemptied.livejournal.com]

A remote syslog-ng box, with everything on it firewalled but 514TCP/UDP, does wonders. Sadly, management won't frigging buy me one :(

[ajohnymous.livejournal.com]

The audit department wants us to...

Yeah baby, take it deep.

...I can't seem to get a named pipe to work.

Suffer bitch.

ajohnymous, CISA, CIA

P.S. I also need that log sent real-time to a remote logserver over which no one with root access to the logged box also has root access -- since it doesn't make much sense to log root commands ON a box over which one has root access. After all, it can't be too hard to do something like:
stop logger
vi log (delete, delete, delete)
start logger

Oh yeah, and just in case someone with root access -- who could be inclined to stopping, editing, and restarting the log on the local machine -- might also try to avoid making tracks on the remote logging server by disrupting connectivity to it (say by disrupting a cable, or injecting a misdirecting route or ARP entry somewhere along the network path) , I also need to you set up some sort of perpetual connectivity detection system between the logged box and the logging server. If connectivity is lost between the two for, say five seconds or more, we're going to need some sort of alert to go off down in the audit department -- a flashing light and a noticeable, yet not too annoying tone would do well.

[reddragdiva]

Given the likelihood of anyone who could understand a jot of the logs reading them, I think a script to generate arbitrary quantities of logs would be just as good.

[poggs.livejournal.com]

We had a load of auditors in who were more concerned with the security of our SQL database than our network, promptly plugging their own company laptops in to *our* network.

I shouted at them.

They gave us a good write-up.

So the moral of the story is - show up the auditors to be sloppy and then you don't need to do anything for them ever again.