SUMMARY:finding who removed a directory

From: Darrell King <darrellk_at_apion-ti.com>
Date: Mon, 02 Feb 1998 12:47:56 +0000

hello Managers,

Sorry about this its about 2 months old at this stage,
again thanks to all who replied.
************original message*************************************
   hello managers
somebody deleted a whole directory either yesterday or today.
1) Is there some way of finding out who deleted this directory
2) Any way of recovery other than backup.
**********************************************************************
Alan Davis :>
If this level of security is required for your system,
the C2 and auditing features will allow you to track
this type of information. The Polycenter Security Intrusion
Detector product may also be of help.

Brenda S Ramsey:>
You can use the lastcomm command and grep for rmdir. (# lastcomm|grep
rmdir) This will not help much if you have a lot of people logging in as
root, but combined with the information you get from 'last', you might get
closer.

Bryan Hodgson:>
Around here, we've replaced (rm, mv) with the following script (after doing
the appropriate mv's on the originals):
# cat /bin/rm
:
#echo "`date` `whoami` `pwd` $_at_" >> /astea/log/.rmlog
wai () { if [ -x /usr/bin/whoami ] ; then
                whoami
         else
                echo "no whoami"
         fi
        }
if [ -f /astea/log/.rmlog ] ; then
  echo "`date \"+%D %T\"` `wai` `pwd` $_at_" >> /astea/log/.rmlog
else
  echo "`date \"+%D %T\"` `wai` `pwd` $_at_" >> /tmp/.rmlog
fi
/bin/rm.orig "$_at_"
So we get a log of who nuked what. Might be useful for you next time.
(Probably oughta add tty to it also, so that we can compare to wtmp).

Eric Mermelstein:>
One thought on this problem. You could replace the /bin/rm file with a
shell script that would either
log delete info to a log file or move the deleted file/dir to a "trashcan".
The first option doesn't
provide any protection again data loss, but at least it would allow you to
keep track of who does
what. With the second option, if you move the "deleted" file, create a cron
job that cleans up the
trashcan directory at regular intervals. This allows users to "undelete"
files but it also requires
extra disk space. (Remember to rename rm so that the cron job can call it
to really delete the
files.)

Paul W Grant:>
If you had used a journalled file system then there are options where you
can mark directories to manage undo versions. This I believe is based on a
directory by directory basis (Digitial UNIX ADVFS) and does have an obvious
overhead.....

Jim Belonis:>
If you have accounting enabled, you can use the
acctcom command to see who executed the 'rm' command or 'rmdir' command.

Kurt Carlson:>
*If* you have auditing enabled you can tell who deleted it.
Auditing isn't for the faint-of-heart, it must be set up
properly (if you take the defaults, I guarantee you'll fill
your var filesystem and lock your system up). It requires
tuning the auditable events to a tolerable level and ensuring
you have procedures to roll the logs. These requirements
aren't brain surgery, but they are non-trivial.
There are some example event files and analysis techniques in:

ftp://raven.alaska.edu/pub/sois/README.UA_DUtools
  kit: ftp://raven.alaska.edu/pub/sois/UA_DUtools-v1.8.tar.Z

snkac_at_java: uals -E UA_DUtools/du/doc/analysis/*audit*
970417.1208 UA_DUtools/du/doc/analysis/audit.example_rm
970313.1306 UA_DUtools/du/doc/analysis/audit_setup
970313.1308 UA_DUtools/du/doc/analysis/audit_stats.ksh.doc
970313.1309 UA_DUtools/du/doc/analysis/audit_tool.doc
970310.1403 UA_DUtools/du/doc/analysis/ua_audit_events
The audit.example_rm is exactly what you were asking about.
Regards, Kurt (one additional comment added below)

And some other suggestions:
Avoid use of g+w on directories which would allow this to occur.
You didn't say whether the file was removed by a user or an administrator.
Assuming it is an administrator (somebody with root authority), you
can manage this by use of 'sudo'. Any command issued with sudo is
logged, and you can check the sudo log for who did what.
sudo will allow the root password to be un-shared (unknown is best)
and if done properly you can avoid root shells altogether.

Spalding, Stephen:>
*****a note on this, if your using NIS then make it lookin your
/var/yp/src/passwd file and if like on our server not all users are in
/usr/users then make necessary changes. You could just tail all
.bash_history files to give the last few commands.
******
Here is a short script which I wrote which makes it easier to look through
someones .sh_history:
hscheck.ksh

#set -x
#
#############################################
#hscheck - History Check
#This proc is designed to display the last
#few commands that the specified user typed
#in. This proc is meant only for use by root.
#Written 1/1/98 - StephenS
#############################################
#
# Define all variables
#
user=$1
number_of_commands=$2
#
# Usage message
#
echo "" >
/usr/tmp/hscheck_usage_message.txt
echo "Usage:" >>
/usr/tmp/hscheck_usage_message.txt
echo "" >>
/usr/tmp/hscheck_usage_message.txt
echo "#hscheck <username> <number of commands>" >>
/usr/tmp/hscheck_usage_message.txt
echo "" >>
/usr/tmp/hscheck_usage_message.txt
echo "example:" >>
/usr/tmp/hscheck_usage_message.txt
echo "hscheck sspaldin 10" >>
/usr/tmp/hscheck_usage_message.txt
if [ x"$user" = x"" ]; then
   echo "You must specify a user"
   cat /usr/tmp/hscheck_usage_message.txt
   rm /usr/tmp/hscheck_usage_message.txt
   exit
fi #if [ x"$user" = x"" ]; then
if [ `grep -c $user /etc/passwd` = 0 ]; then
   echo "The specified user does not exist"
   cat /usr/tmp/hscheck_usage_message.txt
   rm /usr/tmp/hscheck_usage_message.txt
   exit
else
   if [ x"$2" = x"" ]; then
      number_of_commands=10
   fi #if [ x"$2" = x"" ]; then
   if [ $number_of_commands = 0 ]; then
      number_of_commands=10
   fi #if [ $number_of_commands = 0 ]; then
   tail -n $number_of_commands /u04/home/$user/.sh_history
   rm /usr/tmp/hscheck_usage_message.txt
fi #if [ `grep -c $user /etc/passwd` = 0 ]; then
exit #END


Darrell King
SysAdmin
6142430
darrellk_at_apion-ti.com
Received on Thu Dec 03 1998 - 12:45:32 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT