Logging a "persons" activity in Linux

5,997

Solution 1

The auditd package is designed for this, you can use PAM to assign each login a session ID so you can track activity on an account back to the original login (and then check the login log to determine where that person logged in from), and use the ausearch command to locate the events you're interested in. You can read a pretty comprehensive guide here though some of the finer details will need to be changed to match your distribution. Redhat has a site with a FAQ and some other docs here.

Since this doesn't rely on trying to log commands typed into shells or record the users' command history, it should log things like opening vi (which could maybe be done over X or in screen), writing a script (maybe one character at a time with vi's cut/paste commands and a few runs of :.!/usr/games/fortune to get some source data that you might not be able to log) then running the :%!/bin/bash command.

Solution 2

There are a variety of tools at your disposal already, which your question (and these answers) hint at like history, snoopy, auditd, sudo logs, etc...but if you have a "Subset of accounts" people are using, there's no way at the server to tell who did what. The only way you can specifically tell who did it is if users have their own computers that they use specifically and use keyloggers to tell what they were physically typing at that keyboard.

Whenever you share accounts you can't tell what was actually going on, since you'd need further proof who was using your root account or bob account or whatever your people were doing. If you're trying to investigate what happened in a specific incident, you may need to review your access policies and procedures, your recovery procedures, and evaluate your employees and/or engage in retraining if necessary (or their trustworthiness with sensitive accounts) rather than directly focus on hunting down who did something, as it may suck up more resources than you stand to gain in finding the person who did it.

Otherwise you might want to look into forensic investigation techniques for tracking down what happened (drive imaging, log tracing, etc.) If you're not investigating an incident, look into reviewing your policies and instituting better tracking and account verification (only you have root, only Bob uses his account using sudo to get access to higher privileges, install and monitor auditd, etc.) and be careful not to make your trusted circle feel like they're being held under a microscope or you might alienate the people trying to get their jobs done (or hinder them from getting their jobs done).

Solution 3

Linux auditd (http://people.redhat.com/sgrubb/audit/) will give you most power in watching who did what. You have more about it in DerfK's answer.

Nothing, however, is going to tell you, who logged in as webadmin, if there are n people who have access to the webadmin account. I would suggest to use named accounts for each user and then either use su - or sudo to run commands from the "function" account.

Share:
5,997

Related videos on Youtube

DRayen
Author by

DRayen

Updated on September 18, 2022

Comments

  • DRayen
    DRayen over 1 year

    So I've read many of the posts related to this and have just come up more confused than before. There are recommendations for various tools including ttyrec, snoopy, acct, rootsh, sudosh, ttyrpld, unix auditing and more.

    In my case, I want to be able to log all commands executed on a system (like history with timestamps enabled), but I also want to know who did what? However, we all log in via ssh to the same small subset of user accounts (depending on what we're doing). How can I get a log of commands including the information a "who" will give me (regarding connection) so I can trace the action to a specific person as a posed to just a generic "user"?

  • DRayen
    DRayen about 13 years
    This is looking the most promising answer... Audit allows you to consistently track a user's actions from login right through logout no matter which identities this user might adopt by using audit IDs that are created upon login and handed down to any child process of the original login process. A little more reading on my part now to work out how to actually implement it. Thanks for narrowing the choice lots!
  • DRayen
    DRayen almost 13 years
    Apologies for it taking so long to mark this answer as accepted.. I was trying it out! Works a dream.. Cheers guys!