Auditing changes to a single file

[Hash_1]

Can someone explain the following:

1. Enabled auditing of all system calls.
2. groupdel testgroup
3. audsys -f

Looking through the audit file, I cannot see any reference to "/etc/group" file.

Wouldn't an Open syscall need the full path name of that file?

[Dennis Handly]

>so sulog is large, but consistent with previous entries (hence nothing unusual).

You don't just look for unusual, you look for something happening that covers the time frame of the corruption.

>From the audisp of the output files, I was able to see:
cat, /dev/null

This shows you why should use the following instead of cat: > ~/test_file

>2. Using the PID from step 1
>Unless anyone has better suggestions I can use?

This looks fine. Unless there is a creat(2) syscall vs open??

>2. groupdel testgroup
>I cannot see any reference to "/etc/group" file.
>Wouldn't an Open syscall need the full path name of that file?

I would expect so. I wouldn't cd to /etc to open just "group".

You may want to use "tusc -fp" to see the actual syscalls. Then match up with your audit file.

[Roberto Arias]

hello try rcs control. please see man page of rcsintro. You can make alias for vi with ci -l and vi for other users

regards

[Bill Hassell]

There are many ways to null the group file:

> /etc/group
cat /dev/null > /etc/group
vi /etc/group

ans so on. Because only root can change the contents of the file, only root users would be suspect. The above list does not list applications (such as eTrust) or scripts run by root. I think you'll find that because only /etc/group is affected that anything having to do with user account maintenance is suspect. You'll have to turn on paranoia logging for eTrust as well as looking at all root user logins. Run a file size checker every minute in cron and when it falls to zero, immediately dump these items into a logfile:

date
ps -ef | grep root
ll /home/*/.sh_history
tail /home/*/.sh_history

The meticulously compare the time stamp with every log in /var/adm and /var/adm/syslog (not just syslog). Also verify that .sh_history lists from above do not have sudo or su's to root. Look specifically at users where .sh_history has a timestamp similar to the failure period.

You may have to remove eTrust's ability to add/delete users until you solve the problem. Use SAM or useradd/userdel in the meantime.

[Hash_1]

Regarding:

> You may want to use "tusc -fp" to see the actual syscalls. Then match up with your audit file.

and

> try rcs control. please see man page of rcsintro. You can make alias for vi with ci -l and vi for other users

Basically, I have no idea what command/process could have nulled /etc/group, could've been vi, cat, etc...


> You'll have to turn on paranoia logging for eTrust as well as looking at all root user logins.

Yeah, will try and get our Unix Security people to do that, but since we have so many batch jobs that need root access, it's gonna be a nightmare for them.

> Run a file size checker every minute in cron and when it falls to zero, immediately dump these items into a logfile: date; ps -ef | grep root ; ll /home/*/.sh_history ; tail /home/*/.sh_history

I would like to do that, but is there any way I can make sure it doesn't get logged into cronlog? I want other cronjobs logged, but not something running every minute (since account team are really cheap when it comes to storage space), especially since we have experienced the issue around once a month (not consistent times however).

[Dennis Handly · Accepted solution]

>I have no idea what command/process could have nulled /etc/group, could've been vi, cat,

I guess I was suggesting to use it on some sample programs, vi, cat and groupdel to see how the file is opened and changed. Then look for these in your audit logs. So if groupdel issues system calls that aren't even logged, you would know why you don't find "/etc/group".

>but is there any way I can make sure it doesn't get logged into cronlog?

Instead of starting every minute, you can just put a sleep there and have the job run continuously:

while true; do
HOUR=$(date +"%H")
# Ignore from 2000 to 0700
if [[ $HOUR -lt 07 || $HOUR -gt 20 ]]; then
exit 0
fi
Do Bill's stuff here
# wait for 1 min
sleep $((1*60))
done

You can remove the time of day stuff, if you want.

[Roberto Arias]

hi again:


Please check history of user's comands.

If the file is modified by a process p`lease senbd us swlist with sw installed

[Hash_1]

Have checked history, but this system has a lot of users constantly being added and removed weekly (however, group names stay fairly constant).