Menu

NISPOM

2004-06-15
2012-10-09
<< < 1 2 3 4 (Page 4 of 4)
  • Nobody/Anonymous

    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

     
  • Nobody/Anonymous

    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?

     
    • Jonathan Abbey

      Jonathan Abbey - 2006-06-05

      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.

       
  • Nobody/Anonymous

    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.

     
    • Jonathan Abbey

      Jonathan Abbey - 2006-06-05

      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.

       
  • Nobody/Anonymous

    What operating system are we talking about

     
    • Leigh Purdie

      Leigh Purdie - 2006-06-06

      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.

       
  • Nobody/Anonymous

    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.

     
    • Leigh Purdie

      Leigh Purdie - 2006-06-30

      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.

       
  • Nobody/Anonymous

    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

     
    • Leigh Purdie

      Leigh Purdie - 2006-11-16

      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.

       
  • Patrick T. Rourke

    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

     
<< < 1 2 3 4 (Page 4 of 4)

Log in to post a comment.