Just curious about one thing. Snare seems to present audit logs when you try to remove a file or directory that is restricted. However, it does not create an audit log when you try to open a restricted file (e.g. using vi) or traverse a restricted directory. Is this simply a glich on my configuration, or is this normal behavior?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Snare lets you configure whether you want auditing on all syscalls, or only on those syscalls that fail, and according to the identity of the user (root, non-root, specified user, etc.)
I expect you have it set to log only failed access attempts, which is what NISPOM Ch. 8 seems to call for.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is correct, I do have it configured to log only failed attempts. But shouldn't this create an audit entry when, as a normal user, I try to read a restricted file using vi (like /var/log/audit/audit.conf) and am denied? It seems that trying to delete files and directories causes an audit entry, but not when I try to read a file that I am not permitted to read.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would expect it would audit properly if you have it configured to log failed file opens, yes, but that's assuming that vi is actually attempting to open the file.
If vi first stats the file and detects that you shouldn't have permission to view the file, and refuses to attempt to open the file on that basis, you wouldn't see it in the audit logs.
I know that vi does a stat so that it can show whether the file is read-only or not, I don't know whether it refuses to attempt to open a file based on the results of that stat, though.
Whatever vi does, make sure that you've got Snare set up to audit failed file open/file read attempts.. that's a different audit objective than file writes/file deletes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Linux and solaris in this particular thread, but the Snare agents are available for Solaris, Windows, Linux, AIX, Irix, Tru64, plus a bunch of other audit-generating applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having a similiar problem with Snare 0.98 for RHEL 3 Update 5. It is not logging, the OPEN event. If I try to delete the file, it definitely logs the event as UNLINK. But if I try to CAT, VI, or MORE the file, it does not log the event.
Again, I assume that "open" is the right command to monitor, but all variations of syntex of open with wildcard on all matches never get logged. I have tried:
rhel4 LinuxAudit objective,warning,Wed Jun 14 04:14:00 2006,A failed attempt was made to open the file /etc/shadow (read only) by the user red event,open(O_RDONLY),Wed Jun 14 04:14:00 2006 user,red(500),red(500),red(500),red(500) process,11085,11058,cat path,/etc/shadow return,-13,1 sequence,7
As such, I suspect that something has gone slightly screwy in the RHEL3 patch process. Can anyone else confirm that this is failing on RHEL3, but working on RHEL4?
Regards,
Leigh.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new Snare for Linux 1.0 beta works nicely on fedora core 5 (and RHEL4). It also includes a built-in 'NISPOM' configuration that can be activated via the tiny embedded webserver.
Unfortunately, the native audit subsystem (on which Snare relies to do it's work) doesn't report login/failed login data, so I've had to build an interface into the 'last' and 'lastb' commands into the web server - at least that way we'll have the data available to cover the key NISPOM requirements.
The beta-6 version is available from the intersectalliance.com web site at the moment. Once we reach full 1.0 status, I'll upload it to sourceforge also.
Hope this helps,
Leigh.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to set up a Yellow Dog-based workstation for NISPOM PL-1. Is the current version of Snare able to log all the required data (i.e., is the problem Mr. Purdie refers to in his November message fixed)? Have folks had success compiling Snare for Yellow Dog?
Thanks,
P. T. Rourke
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is about a nightmare.
http://rpm.pbone.net/index.php3/stat/4/idpl/1951816/com/kernel-2.4.20-43.9.legacy.snare.i686.rpm.html
download that..then.. (you can download snare patch from intersect alliance website
rpm -ivh kernel<src>.rpm
cd /usr/src/redhat
rpmbuild -bp SPECS/kernel-2.4.spec
cd /usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20
patch -p1 < /tmp/Snare-2.4.20-43.9.patch
cd /usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/
make mrproper
make clean
cp /boot/config-2.4.20-43.9.legacy.snare .config
make oldconfig
make dep < this creates include/linux/version.h
vi include/linux/version.h chnage #define UTS_RELEASE to match your uname -r
Hi John,
Just about any fedora mirror should have the file, with a little luck..
Here's one:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/kernel-2.4.20-43.9.legacy.src.rpm
Regards,
Leigh.
Just curious about one thing. Snare seems to present audit logs when you try to remove a file or directory that is restricted. However, it does not create an audit log when you try to open a restricted file (e.g. using vi) or traverse a restricted directory. Is this simply a glich on my configuration, or is this normal behavior?
Snare lets you configure whether you want auditing on all syscalls, or only on those syscalls that fail, and according to the identity of the user (root, non-root, specified user, etc.)
I expect you have it set to log only failed access attempts, which is what NISPOM Ch. 8 seems to call for.
That is correct, I do have it configured to log only failed attempts. But shouldn't this create an audit entry when, as a normal user, I try to read a restricted file using vi (like /var/log/audit/audit.conf) and am denied? It seems that trying to delete files and directories causes an audit entry, but not when I try to read a file that I am not permitted to read.
I would expect it would audit properly if you have it configured to log failed file opens, yes, but that's assuming that vi is actually attempting to open the file.
If vi first stats the file and detects that you shouldn't have permission to view the file, and refuses to attempt to open the file on that basis, you wouldn't see it in the audit logs.
I know that vi does a stat so that it can show whether the file is read-only or not, I don't know whether it refuses to attempt to open a file based on the results of that stat, though.
Whatever vi does, make sure that you've got Snare set up to audit failed file open/file read attempts.. that's a different audit objective than file writes/file deletes.
What operating system are we talking about
Linux and solaris in this particular thread, but the Snare agents are available for Solaris, Windows, Linux, AIX, Irix, Tru64, plus a bunch of other audit-generating applications.
I am having a similiar problem with Snare 0.98 for RHEL 3 Update 5. It is not logging, the OPEN event. If I try to delete the file, it definitely logs the event as UNLINK. But if I try to CAT, VI, or MORE the file, it does not log the event.
Again, I assume that "open" is the right command to monitor, but all variations of syntex of open with wildcard on all matches never get logged. I have tried:
event=open
event=open(.)
event=open(O_.)
event=open(O_WRONLY,O_RDWR....etc...)
Looking at the list of events available, I do not see any other event that would associate with cat, vi, or more except for open.
My question is that if the event names has changed, and open is no longer applicable.
I've tested this on RHEL4, and opens seem to log fine:
[red@rhel4 ~]$ cat /etc/shadow
cat: /etc/shadow: Permission denied
tail /var/log/audit/snare.log
rhel4 LinuxAudit objective,warning,Wed Jun 14 04:14:00 2006,A failed attempt was made to open the file /etc/shadow (read only) by the user red event,open(O_RDONLY),Wed Jun 14 04:14:00 2006 user,red(500),red(500),red(500),red(500) process,11085,11058,cat path,/etc/shadow return,-13,1 sequence,7
As such, I suspect that something has gone slightly screwy in the RHEL3 patch process. Can anyone else confirm that this is failing on RHEL3, but working on RHEL4?
Regards,
Leigh.
Has anyone had luck with auditing functions (especially failed log-ins) with Linux Fedora 5? We aren't getting the required DSS auditing features.
Kim
G'day Kim,
The new Snare for Linux 1.0 beta works nicely on fedora core 5 (and RHEL4). It also includes a built-in 'NISPOM' configuration that can be activated via the tiny embedded webserver.
Unfortunately, the native audit subsystem (on which Snare relies to do it's work) doesn't report login/failed login data, so I've had to build an interface into the 'last' and 'lastb' commands into the web server - at least that way we'll have the data available to cover the key NISPOM requirements.
The beta-6 version is available from the intersectalliance.com web site at the moment. Once we reach full 1.0 status, I'll upload it to sourceforge also.
Hope this helps,
Leigh.
Hi, folks.
I have to set up a Yellow Dog-based workstation for NISPOM PL-1. Is the current version of Snare able to log all the required data (i.e., is the problem Mr. Purdie refers to in his November message fixed)? Have folks had success compiling Snare for Yellow Dog?
Thanks,
P. T. Rourke