find out who used kill command

[pa8700]

Hi can some body help me to find out who used a kill command with timestamp in the past 5 days.

[Prabhi]

You can check in the syslog output

[Torsten.]

This could be hard. Any auditing software running? You can grep all the command history files (shell dependent), but you will not find a timestamp. Maybe the application wrote to syslog? If this kill command requires root, than you can be sure somebody was root - ask yourself who has this privilege ...

[Michael Steele_2]

Hi

This is the reason for sudo, or, adding 'script > output_$DATE' file to the .profile of every user, root leaves no footprint and hasn't since it's creation.

If you add in the script command then users will have to exit twice, once for the script command and once to log off.

You'll also have to tinker with the permissions of the output_$DATE file so each user had write only privilges under user, but only root can modify or delete the file. Start with 702 and adjust from there based upon ownership, which should be root, and maybe setgid on the directory.

[T. M. Louah]

tricks presented above should help, Some system admin tools allows enabling of trusting/Auditing to help you track down who did what/when. Unix provides security mechanisms to prevent unauthorized users from killing other processes. For kill signal to be sent to a running process the user "owning shell where kill is sent from" & "process to be killed" should be the same or a root level user.
without tools or some sysadmin creativity, one would check history file in each user's home directory to see what commands were used at best with no date/time stamp!! now what if you have more than one root user? headache.
t#

[Bill Hassell]

It sounds like a program stopped running unexpectedly. kill is only one way for a program to terminate. It may have terminated due to a program error or bug, or it may have run out of memory or other resource and rather than politely describing the problem in syslog.log, it simply terminated or crashed.

So are these programs owned by root? If so, only someone with a root login can kill these programs. If you have setup .sh_history correctly then anything root types in the shell (like kill 1234) will be logged.

[Steven E. Protter]

Shalom,

It was me.

I could not help myself.

Check your users .sh_history logs.

If that is set up.

SEP

[Michael Sillers]

I've done something with rm that might help here. It won't help with previous kill commands but will in the future...

I've renamed rm to rm.bak then replaced it with a script that logs the user and file removed then calls the renamed rm command.

##########################################
removelog="/var/log/remove.log"
usablepty=$(pty | sed 's/.....//')
rmuser=$(who | grep ${usablepty})

if [ "$LOGNAME" = "root" ] ; then
echo "$(date): ${rmuser}: $@" >> $removelog
fi

/bin/rm.bak "$@"

exit 0
########################################
We have the system set up so you can't log in as root, only su to root so your original login name is the one that is logged.

[pa8700]

Great replays guys ..

Below is the error Provided by Oracle DBA and claims that somebody killed the process.. so the DB crashed....I needed to find out something..


Shutting down instance (abort)
License high water mark = 115
Instance terminated by USER, pid = 10448
Sun Feb 21 19:50:32 2010

Sun Feb 21 19:50:50 2010
ALTER DATABASE OPEN
ORA-1113 signalled during: ALTER DATABASE OPEN...
Shutting down instance: further logons disabled

[Bill Hassell]

> Shutting down instance (abort)
> License high water mark = 115
> Instance terminated by USER, pid = 10448
> Sun Feb 21 19:50:32 2010

> Sun Feb 21 19:50:50 2010
> ALTER DATABASE OPEN
> ORA-1113 signalled during: ALTER DATABASE OPEN...
> Shutting down instance: further logons disabled

Well, you do have some good information. The pid (10448) is of no value since it does not indicate the user name (but probably it was root or oracle). However, you do have the time for the termination: Feb 21 19:50:32. Now use the last command to see who was logged in at that time:

last -R | more

Also look at the sulog in /var/adm/sulog in case someone used su to become root. If you have sudo on your system, look in /var/adm/syslog/syslog.log around time listed above. Since Oracle is probably important, you may have to immediately revoke all root access as well as oracle administrator access until you find the guilty party. It may have been a simple error by a root user trying to kill a process and used the wrong PID -- but the consequences are still bad.