Slashdot Mirror

← Back to Stories (view on slashdot.org)

Keeping Audit Trail of Activities from Root Login?

Posted by Cliff on from the keeping-the-admin-bit-trail dept.

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?

10 of 44 comments (clear)

  1. Sudo by ffsnjb · · Score: 5, Informative

    Force people who want/need to have root access to use 'sudo'. It will log all activities using syslog. This also negates the need to give lowlevel admins the root password (yay!).

    Sudo is in the ports collection for FreeBSD, no idea about linux though.

    --
    "Why do you consent to live in ignorance and fear?" - Bad Religion
    1. Re:Sudo by ryants · · Score: 4, Informative
      Sudo is in the ports collection for FreeBSD, no idea about linux though


      There are RPMs or DEBs for sudo... the package name is (originally enough) "sudo".


      sudo pacakges at RPM Find.

      --

      Ryan T. Sammartino
      "Ancora imparo"

    2. Re:Sudo by staplin · · Score: 4, Interesting

      Though you still have to be careful with a few things...

      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.

  2. Related to "Handing Over Root Passwords?" by MrBlack · · Score: 3, Interesting

    This isn't related to the "Handing Over Root Passwords to Consultants" ask slashdot a couple of items below is it? If not there may be a few good suggestions there.

  3. Try process accounting by Anonymous Coward · · Score: 4, Insightful

    For the second part of your question, you could enable process accounting. Which logs accounting information (including the UID) for every process that successfully terminates. See the man pages for acct(2) acct(5), accton(8), and sa(8).

  4. Hard Copy by cehardin · · Score: 4, Insightful

    If the system is not accessed physically then you can set up the logs to print out to an old-fashioned dot-matrix printer, even root access can't erase those :-)

    1. Re:Hard Copy by larien · · Score: 4, Informative
      Until the time he putzes about in root and causes the printer to run out of paper :)


      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.

  5. Sudo Homepage by staplin · · Score: 3, Informative

    Information about sudo, including docs, downloads, and mailing lists, is available at http://www.courtesan.com/sudo/index.html.

  6. Snoopy by Spacelord · · Score: 3, Informative

    There is a "wrapper" library called snoopy that can do this. It logs all commands executed to syslog. You can then let syslog log over the network to a dedicated logging host, to which your users don't have access.

    You can find snoopy here:
    http://www.citi.umich.edu/u/marius/snoopy/

  7. Re:Take the log out the computer by J'raxis · · Score: 3, Informative
    tail -f nameoflog.log | scriptsend.pl
    Be careful with this, if the script is set up naïvely (using <> to grab all input and then send in one command) the script would keep buffering until `tail` exits.

    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 /var/log/fifo
    % tail -f nameoflog.log > /var/log/fifo

    And, every minute:
    % scriptsend.pl < /var/log/fifo
    --
    Liberty in your lifetime