NISPOM

[Nobody/Anonymous]

Anyone have an audit.conf that gives NISPOM compliance for a PL-1 system?  Rather than me fighting thru the configurator trying to figure out everything I need to do, if someone else has done it, that'd be real cool.

[Leigh Purdie]

I haven't seen one yet, but I've received feedback from several agencies who are using Snare for NISPOM complience. If anyone has something developed, and is willing to share, please either post it here, or bounce it to the intersectalliance contact email (see www.intersectalliance.com/contact.html), and I'll include it with the next release of the Snare audit daemon package.

Regards,

Leigh.

[Jake Von Slatt]

I'm interested in the same thing.  What I've got so far is quite crude - just a regex that watches the directories listed in ISL 04L-1 as "Security Relevant Objects".

It generates a lot of crap since every attempt to access a file that doesn't exist counts as a failed attempt, but without more concise guidelines then ISL 04L-1 from the DSS I don't know how to comply - other then to just log everything and filter with some sort of post processor.

What we need is an example audit.conf from an accredited installation.

[Kyle Miller]

Ok I have include a first cut at an audit.conf file which I think should give NISPOM compliance for a PL-1 system.    This should cut down on the noise and only keep track of the required items.  Comments on the configuration would be great so it can be improved. 

[AuditType]
    type=Objective

[HostID]

[Output]
    file=/var/log/audit/audit.log
    file=stdout

[Objectives]
    criticality=2    event=open(.*),mkdir,mknod,link,symlink    return=Failure    user!=root     match=^/etc/shadow$
    criticality=2    event=open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink    return=Failure    user!=root    match=^/etc/passwd$
    criticality=2    event=open(.*),mkdir,mknod,link,symlink    return=Failure    user=!root match=^(/var/log|/etc)/audit.*
    criticality=4    event=open(O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink,rename,unlink    return=Failure    user!=root    match=^/(sbin|usr/sbin|bin|usr/bin|usr/X11R6/bin|usr/bin/X11)/.*
    criticality=2    event=execve,exit    return=Failure    user=.* match=^/bin/su$
    criticality=3    event=open(O_TRUNC|O_APPEND),chmod,rename,reboot,truncate,truncate64,chown,lchown,chown32,lchown32,unlink    return=Failure    user!=root    match=^/etc/.*
    criticality=2    event=execve,exit    return=Failure    user!=root match=.*newgrp.*
    criticality=3    event=rmdir,unlink    return=Failure    user!=root match=^/etc/.*
    criticality=2    event=open(.*),mkdir,mknod,link,symlink,rename,unlink     return=Failure    user!=root match=^/var/log/.*
    criticality=1    event=mount,umount    return=Failure    user!=root match=.*
    criticality=0    event=chroot        return=*    user=.*    match=.*
    criticality=0    event=reboot        return=*    user=.*        match=.*

[Leigh Purdie]

Looks great!

I've added a slightly extended version of this to the default audit.conf that will come with the next version of snare, and I've also made a couple of small corrections to the suggested config above (a duplicated trucate, the removal of the *32 system calls, which are no longer required for 0.9.6+, killing the reboot reference associated with /etc/ opens):

L.

[AuditType]
type=Objective

[HostID]

[Output]
file=/var/log/audit/audit.log
file=stdout

[Objectives]
criticality=2 event=open(.*),mkdir,mknod,link,symlink return=Failure user!=root match=^/etc/shadow$
criticality=2 event=open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink return=Failure user!=root match=^/etc/passwd$
criticality=2 event=open(.*),mkdir,mknod,link,symlink return=Failure user=!root match=^(/var/log|/etc)/audit.*
criticality=4 event=open(O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink,rename,unlink return=Failure user!=root match=^/(sbin|usr/sbin|bin|usr/bin|usr/X11R6/bin|usr/bin/X11)/.*
criticality=2 event=execve,exit return=Failure user=.* match=^/bin/su$
criticality=3 event=open(O_TRUNC|O_APPEND),chmod,rename,truncate,chown,lchown,unlink return=Failure user!=root match=^/etc/.*
criticality=2 event=execve,exit return=Failure user!=root match=.*newgrp.*
criticality=3 event=rmdir,unlink return=Failure user!=root match=^/etc/.*
criticality=2 event=open(.*),mkdir,mknod,link,symlink,rename,unlink return=Failure user!=root match=^/var/log/.*
criticality=1 event=mount,umount return=Failure user!=root match=.*
criticality=0 event=chroot return=* user=.* match=.*
criticality=0 event=reboot return=* user=.* match=.*

[Nobody/Anonymous]

Is it your interpretation that you track reboots, chroot, mount and unmount, or is there a specific place in the NISPOM PL-1 requirements that state these need to be tracked?

Specifically, I wonder if all these objectives are truely needed or are just interpretations:

criticality=2 event=execve,exit return=Failure user!=root match=.*newgrp.*
criticality=1 event=mount,umount return=Failure user!=root match=.*
criticality=0 event=chroot return=* user=.* match=.*
criticality=0 event=reboot return=* user=.* match=.*

[Leigh Purdie]

The *newgrp* one can be killed. I added that in response to a reported buffer overflow in RH9 many months back - it was a handy test case.

Although chroot's are useful, I doubt that there's a specific NISPOM requirement (comments from anyone who's impementing nispom?). Ditto with reboots & mounts.

L.

[Paul Kronenwetter]

Mounts I agree can go.  However, reboots are specifically identified in the NISPOM as needing to be captured.

[Nobody/Anonymous]

Shouldn't you also track /dev raw disk writes, which could subvert all your other file system based checks by writing the filesystem directly on the disk?

Classic VMS problem: lots of privilege bits but PHYIO (physical IO) gave you indirectly everything.

[Jonathan Abbey]

Actually, NISPOM Ch. 8 specifically acknowledges that a privileged (root/superuser) account will be able to bypass all auditing requirements on a PL-1 system.  The auditing requirements are really for those users who can be audited, that is, the non-superuser accounts.

With Snare on Linux generally, the root user can simply kill the audit daemon at any time, making any pretense to audit the root user pretty pointless.  Something like TripWire, with its cryptographically signed report database, is necessary if you want to be able to detect tampering by a root user.

[Leigh Purdie]

Agree entirely with Jon's reply. Here are a couple of additional factors for consideration though:
* There generally needs to be someone or something on the other end to review the data - and many of our users are already collecting GIGabytes per day. File-read auditing is likely to exponentially increase that figure.
* If you have a setup whereby audit events are forwarded back to a central 'audit server', there may be a chance that you'll detect the compormise-related events that lead UP to turning off the audit daemon - so some root-level auditing may be useful (eg: Who su'd to root just before the audit daemon stopped sending events?)

Regards,

Leigh.

[Nobody/Anonymous]

Leigh,

Would you post your final audit.conf file?

Thanks!!!

[Leigh Purdie]

This is the current [Objectives] section in the development version of 0.9.7. Not yet the final version, but it's something to work with.

L.

[Objectives]
        criticality=4   event=open(.*),mkdir,mknod,link,symlink return=Success
user!=root      match=^/etc/shadow$
        criticality=2   event=open(.*),mkdir,mknod,link,symlink return=Failure
user!=root      match=^/etc/shadow$
        criticality=4   event=open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink   return=Success  user!=root      match=^/etc/passwd$
        criticality=2   event=open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink   return=Failure  user!=root      match=^/etc/passwd$
        criticality=2   event=open(.*),mkdir,mknod,link,symlink return=Failure
user=.* match=^(/var/log|/etc)/audit.*
        criticality=3   event=open(.*),mkdir,mknod,link,symlink return=Success
user=.* match=^(/var/log|/etc)/audit.*
        criticality=4   event=open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND),mkdir,mknod,link,symlink   return=Success  user!=root      match=^/(sbin|usr/sbin|bin|usr/bin|usr/X11R6/bin|usr/bin/X11)/.*
        criticality=1   event=execve,exit       return=Success  user=.* match=^/bin/su$
        criticality=2   event=execve,exit       return=Failure  user=.* match=^/bin/su$
        criticality=3   event=open(O_TRUNC|O_APPEND),chmod,rename,truncate,chown,lchown         return=Failure  user!=root      match=^/etc/.*
        criticality=2   event=open(.*),mkdir,mknod,link,symlink,rename,unlink
return=Failure  user!=root match=^/var/log/.*
        criticality=1   event=mount,umount      return=Failure  user!=root match=.*
        criticality=0   event=chroot            return=*        user=.* match=.*        criticality=0   event=reboot            return=*        user=.*
match=.*
        criticality=1   event=accept            return=*        user!=root
match=.*
        criticality=1   event=mount,umount      return=*        user=.* match=.*

[Nobody/Anonymous]

Leigh,

Thanks for the update!

-R

[Nobody/Anonymous]

Leigh,

Do you forsee any reason this configuration would not work with 0.9.6? (I've been working with Jon's FC2 build)

-R

[Leigh Purdie]

Nope,

The only change in the config file between 0.9.6 and 0.9.7 at this stage, is the support for MD5-based passwords in audit.conf.

No changes to the objectives at this point in time, though, we're likely to add 'general match' exclusion at some point, as one of our Solaris customers has requested the capability - and the changes will flow over to Linux.

eg: match!=^/usr/lib/.*

L.

[Daniel Levine]

Hey guys,

I'm using the Fedora Core 2 version 0.9.6B for kernel 2.6.7-1.  I noticed that if I use this configuration file and bring up the GUI, most everything changes to the an execvp objective.  I assume that it is because of the GUI's lack of granularity for the things you've defined to audit.  Have I missed something?

Should I just not use the GUI when running the NISPOM configuration?  It sorta defeats the purpose of having the nice GUI.  Perhaps there's a more advanced objective mode that I haven't discovered yet.

Otherwise it seems fine (except for the already documented unlink report problem).  To satisfy NISPOM, I also check to see if passwd or yppasswd are executed so I can track successful and unsuccessful password changes.  I was under the impression this is required as well.  However, I do not track ALL successful and unsuccessful command executions.  I strive for empty logs unless something nasty is going on. :-)

-Dan

[BryanJ]

In addition to unlink not being audited, mknod, chown, chmod, link, and truncate also don't work in v0.96.  None of the auditing works for a chroot process (ftp server for instance).

For a path-name rule-based auditing scheme like snare, any hard links to an interesting file will bypass the auditing scheme, so for link to not be audited means you really have no auditing at all of a knowledgable hacker.

Note also that a snare design decision allows you to attempt access to interesting files through a symlink, and, so long as you delete the symlink right away, your access attempt will hardly ever be audited.

Other than that, snare mostly works real nice.

[Jonathan Abbey]

Link, chmod, chown, and the rest aren't audited?  Since when?  They are certainly meant to be, at least when the proper objectives are set in the snare configuration file.

Of course, in the link case, that means that you'd have to specify objectives to require logging of any link activity involving a file of interest, and you'd then be dependent on noticing the link audit record on an external analysis pass, which would be exceedingly difficult to carry out properly, particularly in the event of truncated logs.

What kernel are you testing that leads you to think that link, chmod, and the rest aren't audited?

Also, drop me an email at jonabbey@arlut.utexas.edu if you'd be interested in participating in a linux audit mailing list among some of the interested developers.  I don't know how wide open the list is intended to be, but it sounds like you may have some good insights into the problem domain.

Thanks,

Jon

[Leigh Purdie]

> In addition to unlink not being audited, mknod, chown, chmod, link, and truncate also don't work in v0.96

They are audited, but don't report the correct filename at the moment unfortunately. This has been fixed in 0.9.7 (or at least, should be.. I still have to stabilize the code).

(Jon: I think I need a new set of eyes - I've been trying to get audit_mount to stop killing my system for a couple of weeks without much success. It's probably something really obvious I'm missing - interested in having a look at 0.9.7 to see if you can catch it?)

> For a path-name rule-based auditing scheme like
> snare, any hard links to an interesting file will bypass
> the auditing scheme, so for link to not be audited
> means you really have no auditing at all of a
> knowledgable hacker.

Correct. However, you _can_ catch the original link/symlink call. So, when monitoring access to /etc/passwd (for example), you can catch the link from /tmp/blah to /etc/passwd, but not catch subsequent file reads for /tmp/blah.

Ideally, snare would resolve the link/symlink file back to the original inode, but I suspect that this would be way too big a change to the kernel to contemplate.

L.

[Jonathan Abbey]

Sure, Leigh, I'd be happy to.  Is this mount problem something that's amiss in 0.9.6 as well, or just in the 0.9.7 CVS stuff?

I'm afraid I have to report that I've not looked at anything out of CVS yet, even after having been the one to hound you into getting it set up.  Very sorry about that.  I'm actually a little unclear as to how one would even manage CVS for a patch against a kernel.. I guess you check in the patch as a single file, and then whenever something changes, you rediff to generate a new version of the patch, and then check in the new patch on top of the old one?

Perhaps that's a topic better suited for discussion in email, so I'll bring that up on snare-devel@lists.sourceforge.net.

To the latter point about tracing a file operation all the way back to the inode, that makes perfect sense indeed, and I think that's sort of the gist of the SELinux attributes discussion under way on the linux-audit@redhat.com list, yes?

I tend to agree that trying to properly treat the topic is likely a greater effort than we'd want to undertake, given that in the long run, everyone's interests would be best served by getting the Snare userland tools on board with a consensus auditing effort in the mainline linux kernel.

Jon

[Leigh Purdie]

> Sure

Thanks for this. I'll bundle up some stuff tonightish.

> Is this mount problem something that's amiss in 0.9.6
> as well, or just in the 0.9.7 CVS stuff?

Just in 0.9.7 - and it's driving me bananas. :)
I've been ignoring it over the course of the last couple of days, and have worked on other stuff instead, in the hope that it might go away... but that's had about as much effect as you'd expect.

> I'm afraid I have to report that I've not looked at
> anything out of CVS yet, even after having been the
> one to hound you into getting it set up. Very sorry
> about that.

*laugh* No worries. :) I haven't been all that good at updating cvs either (particularly the kernel side)

> I'm actually a little unclear as to how one would even
> manage CVS for a patch against a kernel.

Very hard. At the moment, I have two cvs repositories - one that contains the files (in full) that have ANY changes to them made by snare, and another that contains the original (unmodified) files. That way, someone can grab both repositories, and do a diff to determine the bits that are specific to snare. Not pretty though. And only really effective with one particular version of the kernel. I haven't worked out an easy way to maintain different versions.

I wonder what an ideal small-scale collaborative kernel development model would look like? Perhaps two VMware boxes that people can ssh into.. one would have the kernel source, the other would have the source mounted across, and would be responsible for compiling & testing the stuff. The vmware console would be visible remotely too (vnc?) (for kernel debugging).

Wouldn't scale well, but would probably be reasonable for small projects.

.. anyway, as you said, we can probably take the topic elsewhere. :)

> To the latter point about tracing a file operation all
> the way back to the inode, that makes perfect sense
> indeed, and I think that's sort of the gist of the
> SELinux attributes discussion under way on the
> linux-audit@redhat.com list, yes?

Pretty much, yeah. The link situation is something that the SELinux guys have to deal with, so it would save us a bit of effort if we piggy-back on their solution. However, there's so much other 'baggage' that comes with selinux (useful for acl, but not much for auditing), that it might not be worth going down that path.

>I tend to agree that trying to properly treat the topic is
> likely a greater effort than we'd want to undertake,
> given that in the long run, everyone's interests would
> be best served by getting the Snare userland tools
> on board with a consensus auditing effort in the
> mainline linux kernel.

Agree. Once we have a way forward for that, we can start thinking about appropriate transitional stages to help current snare users migrate across to the new system with minimal effort. Until that happens though, development... while not exactly in limbo, is a little hindered by trying hard not to get too far away from what 'might' be coming along. :)

BTW: Don't think I've mentioned it yet, but I LOVE the apt/yum repo. :)

L.

[Jonathan Abbey]

Ugh, that sounds horrifically complicated.  I know BitKeeper is used by a lot of the Linux kernel developers because it allows for granular patch-tracking, but I think they all just keep full copies of the Linux tree in their system.  Doing a partial repository as you describe must be a bloody pain.

Re: the apt/yum stuff.. thanks, I like it too, it's a very simple and technically sweet solution in a lot of ways.  Unfortunately, it seems that I put out a broken kernel for the last FC2-derived kernel release I put out.

It'd be nice to just try again with 0.9.7.. are you basing your work on the old Red Hat 9 era 2.4 stuff, or are you working with 2.6?

Jon

[Leigh Purdie]

Heya Dan,

The GUI is pretty inflexible with it's audit configuration. If a particular objective doesn't fit into one of it's 'categories' exactly, then it gets confused, and defaults to 'exec'.

This is why we recommend that people either use the GUI, or edit the audit.conf directly, but not do both.

However, you have a great point.. distributing an audit.conf file by default that the GUI barf's on is pretty silly.

> However, I do not track ALL successful and
> unsuccessful command executions. I strive for empty
> logs unless something nasty is going on. :-)

Smart move. :)
One of the things we tend to tell audit users is "If you're not going to be reading it, why the heck are you collecting it?". Fair enough, 'forensics' is a reasonable response to this question in some circumstances, but the goal for minimal, but targetted, audit data is a good one.

> (except for the already documented unlink report problem)
.. and If I could just get 0.9.7 to stop crashing my kernel at disk mount time, I think I would have this one licked too....

L.

[Nobody/Anonymous]

Is there any way to get snare to report logins?