LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Auditing - Logging all commands and arguments (http://www.linuxquestions.org/questions/linux-security-4/auditing-logging-all-commands-and-arguments-604517/)

humbletech99 12-04-2007 04:50 PM

Auditing - Logging all commands and arguments
 
I want to increase my security and auditing on some systems by adding full logging of every command and all arguments to every command that is typed on any shell used on the system.

I have used sa before this only logs the command program, not the arguments which makes all the difference. Also, I'm not sure it will catch shell built-ins or people truncating files like so "> filename".

I have used snoopy before which I liked and seemed to work quite well although it does not seem to be supported any more since 2004 looking at the sourceforge site. Since this uses execve I'm not sure this will catch shell built-ins either in fact, and nor am I sure about packages/maintainability of doing this, but then considering it has not been updated in 3.5 years I doubt updates will be a problem... (of course this raises issues about security or bugs discovered in it if not maintained).

I've also found sudosh on google but this seems to be an imperfect approach since it requires giving people an alternate shell through sudo. What happens when logging all commands but one command is just "bash" and everything inside that command is a black box?

Ideally I'd like whatever auditing solution I implement to be shell neutral.

Sudo itself if completely inadequate because people "sudo su" and it would be difficult if not impossible to grant people access to only specific commands.


So what do you use for complete command auditing/logging?

unSpawn 12-04-2007 06:25 PM

Quote:

Originally Posted by humbletech99 (Post 2980259)
I want to increase my security and auditing on some systems by adding full logging of every command and all arguments to every command that is typed on any shell used on the system.

I can understand the auditing part (since that falls apart into preventive stuff, making sure all is "sane", like checking with tools like Tiger, L(N?)SAT, env_audit, etc, etc and the post-op stuff like file, threshold, attribute and logchecking, followed by adjusting configuration accordingly) but security I can't fully place though because logging takes place during (or more exactly *after*) the event. If you don't want certain things to happen I'd suggest you start with refining restrictions and then only grant additional (temporary?) rights when necessary: restrict now, suppress later.


Quote:

Originally Posted by humbletech99 (Post 2980259)
I've also found sudosh on google but this seems to be an imperfect approach since it requires giving people an alternate shell through sudo.

Quote:

Originally Posted by man rootsh
Start a shell with logging of input/output. (..) You can run rootsh as a standalone application if you only want to log your own user’s session.


Quote:

Originally Posted by humbletech99 (Post 2980259)
What happens when logging all commands but one command is just "bash" and everything inside that command is a black box?

Code:

rootsh session opened for unspawn as unspawn on /dev/pts/11 at Wed Dec  4 10:11:15 2007
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ echo I am $$ and now I open a subshell^M
I am 15870 and now I open a subshell^M
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ bash^M
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ echo I am $$ and now I open a csh subshell^M
I am 15906 and now I open a csh subshell^M
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ csh^M
[unspawn@hostname ~]$ exit^M^M
exit^M
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ exit^M
exit^M
^[]0;unspawn@hostname:~^G[unspawn@hostname unspawn]$ exit^M
exit^M

*** rootsh session ended by user^M
rootsh session closed for unspawn on /dev/pts/11 at Wed Dec  4 10:11:57 2007


Quote:

Originally Posted by humbletech99 (Post 2980259)
Ideally I'd like whatever auditing solution I implement to be shell neutral.

I'd combine rootsh logging to (remote?) syslog with the GRSecurity patch. It's got all sorts of logging options even without using RSBAC. Turn them all on for a few boxen a few days and you've got some hefty log parsing ahead ;-p

humbletech99 12-04-2007 06:53 PM

Thanks for that. Rootsh looks promising too.

Question, can rootsh be invoked automatically for every shell session? Would this not require making it the default shell for all user account and would that in itself not be bypassable by users simply changing their default shell back to /bin/bash or similar and then logging out and back in?

I'd rather not give users the choice about being logged or even make it obvious in any way. This is one of the things I like about snoopy, it is very inconspicuous.

I 'll check it out.

unSpawn 12-05-2007 04:23 PM

Quote:

Originally Posted by humbletech99 (Post 2980394)
Question, can rootsh be invoked automatically for every shell session?

Why don't you try it yourself? One of the things I like about GNU/Linux is it gives you all the freedom to experiment.


Quote:

Originally Posted by humbletech99 (Post 2980394)
would that in itself not be bypassable by users simply changing their default shell back to /bin/bash or similar and then logging out and back in?

Depends on if your security posture restricts users from using 'chsh'?

chrism01 12-06-2007 12:05 AM

Note that people can only sudo su if you allow that in sudoers file. Normally you wouldn't allow that, just the cmds they need.

humbletech99 12-06-2007 08:08 AM

unSpawn: ok I will but it's not packaged and I hate dirtying up my systems. Also, I didn't have access to my systems at that time and not on linux.


chrism01: Well our devs all "sudo su". It would be difficult if not impossible to have to explicitly grant them perms to every single command in sudoers.

Hence I need the logging of everything to track down who did what when that broken something.

unSpawn: How do you suggest I prevent users from chsh? Remember that the users can "sudo su". At the very least they could just edit /etc/passwd.

unSpawn 12-06-2007 12:31 PM

Quote:

Originally Posted by humbletech99 (Post 2982052)
it's not packaged

What kind of packaging?


Quote:

Originally Posted by humbletech99 (Post 2982052)
How do you suggest I prevent users from chsh?

Look at the permission on the binary and how access to it is governed.


Quote:

Originally Posted by humbletech99 (Post 2982052)
Remember that the users can "sudo su". At the very least they could just edit /etc/passwd.

Make your filesystem integrity checker cover /etc. And iIf you allow them an alias like "sudo rootsh" (and make sure you enabled the binary to log to syslog and file) that should help.


All times are GMT -5. The time now is 07:03 PM.