Monitor the shell activity of a user on your Unix system?

Question

Trust, but verify.

Let's say I want to hire someone a sysadmin, and give them root access to my Unix system. I want to disable X windows for them, only allow shell usage (through SSH, maybe), so that all operations they perform will be through the shell (not mouse operations).

I need a tool that will log to a remote server all commands they issue, as they issue them. So even if they install a back door and cover their tracks, that will be logged remotely.

• How do I disable everything but shell access?
• Is there a tool for instantaneously remotely logging commands as they are issued?

Solution 1

Don't give them root. Give them an individual account and place it in sudoers. Every command they launch with sudo will be put into the log. However, sudo power still allows them to clean up the log, and to log in as root with sudo su -.

The solution is to have the log segregated on another server, with something like syslog-ng. They can turn it off, but their having done so will be recorded and should be a great big red flag. As will su -. I'm guessing you can block that in sudoers with a bit of thought.

Solution 2

Is there a tool for instantaneously remotely logging commands as they are issued?

Sudosh2 ( http://sourceforge.net/projects/sudosh2/ ) will do some of what you want. Here's a description from their website:

sudosh is an auditing shell filter and can be used as a login shell. Sudosh records all keystrokes and output and can play back the session as just like a VCR.

The user executes a command like 'sudo sudosh2', and then they have sudo.

sudosh2 is a sudo shell which will record all keystrokes and log everything from the user session (input, output, errors, etc). You can replay a user session. This can be quite handy.

sudosh2 supports syslog, and you could send this output to a remote server.

This may not do everything you need, but it could help. Some people also use rootsh, but I don't understand how that compares to sudosh.

Solution 3

In theory you can use a ssh proxy (on a system the person doesn't control) to log all traffic between the host and the system. He ssh to the system, you log all data there and forward the connection to the target server. A local logging daemon breaks the basic principle of not giving a user administrative access to the systems expected to restrict him.

In practice it's more or less impossible to read a command log and figure out if the guy did something bad or not. If you can't trust your system administrators you are screwed. I wouldn't bother trying.

Solution 4

For logging everything that somebody types into your console pam_tty_audit is what your after. I'm pretty sure that it logs it output via syslog, so you could just pump that log to another syslog server.

NB, this logs everything, keystrokes (up, down, ctrl, etc) and also will log passwords when they type into password fields.

Solution 5

I agree with Matt. If you can't trust them, they shouldn't have root.

For an audit trail, rootsh can be used. You can only allow them to sudo to rootsh. Combined with this and remote logging, it would be slightly more difficult to stop than simply sudo.

View more solutions

Comments

[Admin]

FYI - If you give them root, they can /install/ X...so I'd focus on either trusting your sysadmins or not having any

[Admin]

Agree with Matt. If you don't trust said person. Don't hire them.

[Admin]

Why? If this is a server that I automatically provision in the cloud, it doesn't matter much. But I would like to be able to monitor the person, regardless. And, yes, they can install whatever, but that command will get logged remotely.

[Admin]

If you've given them root how can you possibly guarantee that they haven't bypassed whatever logging mechanism you have in place, and this is supposed to happen on a cloud based server?

[Admin]

Everybody could be a terrorist, don't trust!!!11!!oneeleven Or a robot... xkcd.com/329

[Admin]

If I give them root, and every time they issue a command, that command is emailed to a remote server, then I can see if they compromised the system. They can't go back in time and reverse the commands being emailed to the other server.

[Admin]

Yeah, sure, till they just disable the emailer.