Re: xml output from Linux audit plugin

Hi,

Thanks for the feedback. I'm working through it so that I can send updated 
samples later.

On Thursday 24 January 2008 10:23:11 Yoann Vandoorselaere wrote:
> Le mercredi 23 janvier 2008 à 13:50 -0500, Steve Grubb a écrit :
> > version:
> > heartbeat:
> >         analyzer(0):
> >                 analyzerid: 3752076040279179
> >                 name: prelude-manager
> >                 manufacturer: http://www.prelude-ids.com
> >                 model: Prelude Manager
> >                 version: 0.9.10
> >                 class: Concentrator
> >                 ostype: Linux
> >                 osversion: 2.6.23.8-63.fc8
> >                 process:
> >                         name: prelude-manager
> >                         pid: 8303
> >                         path: /usr/bin/prelude-manager
>
> In the first heartbeat emitted, the auditd analyzer entry is missing. I
> guess the analyzer object was not associated early enough (before
> calling prelude_client_start).

Did that one come from prelude-manager?


> [here's the second heartbeat, this time with the auditd analyzer]
>
> >         analyzer(1):
> >                 analyzerid: 3188026575230221
> >                 name: audisp-prelude
>
> Usually, we use the sensor name as the default analyzer name, so here
> I'd simply use "auditd".

OK, I was using the plugin's program name. Auditd starts audispd which starts 
its individual plugins. In this case it is /sbin/audisp-prelude. Do you think 
auditd is more appropriate given these details? I am willing to change it to 
whatever is best.


> >                 model: linux-audit
>
> Should be the same as analyzer name (this one is static, while the user
> might choose to change analyzer->name through manual configuration).
> Additionally, you might want to use an uppercase here: "Auditd".

OK, I was trying to identify what the source of the data is. I'll sync this 
with whatever we decide on the previous issue.


> >                 class: Software Monitoring
>
> Use HIDS as the class for now

Fixed.


> >                 process:
> >                         name:
> >                         pid: 8308
>
> The process name is missing, how is prelude_init() called?

prelude_init(NULL, NULL);

I was looking at the code in Linux-PAM.


> Would it be possible that you provide the argc / argv argument to the
> initialization function?

I suppose I could pass it.  Fixed.


> >         classification:
> >                 text: MAC Violation
> >         detect_time: 23/01/2008 12:43:41.0 -05:00
> >         analyzer_time: 23/01/2008 13:46:01.573345 -05:00
> >         source(0):
> >                 spoofed: unknown (0)
> >                 node:
> >                         category: hosts (6)
> >                         name: centaur
>
> Would it be possible that you work on a function to resolve the name,
> and then use the result to populate node.address(*).address ?

That may be tricky. The audit daemon allows a system admin to use one of four 
node names in the audit trails: host name, FQDN, Address, or a custom admin 
selected name. I am picking this out of the audit stream. In this case it was 
a hostname. This host has 3 addresses. None of which are probably associated 
with the name. My goal was to try to match the audit trail. 

I just tried using "domainname -i" on that machine. It shows 127.0.0.1 as the 
address. I'm really not sure how I could do this based on audit trail 
information.


> Additionally, getting the FQDN for this host into node.name would be
> nice.

I worry about doing a 9-10 second lookup on a realtime system. Hmm...I'll 
ponder it.


> >                 user:
> >                         category: application (1)
> >                         user_id(0):
> >                                 type: original-user (0)
> >                                 tty: (none)
>
> The "(none)" value look like invalid.

This is actually correct. There is no tty associated with the daemon. In this 
particular case, my prelude plugin triggered a AVC denial. I had logged in 
and started the daemon. So this is showing that I started the daemon as it 
has my loginuid associated with it, but it had detached from all terminals, 
so there is no tty. This is exactly what the audit trail shows, too.


> Above comments concerning the source.node object apply.
>
> >                 user:
> >                         category: application (1)
>
> No user object should be set within the message if there is not at least
> one user_id associated with it.

OK, I'll take that out of the target for SE Linux AVC reporting.


> >                 file(0):
> >                         name:
> >                         path: /var/spool/prelude/audisp-prelude/global
> >                         category: (null) (0)
>
> Name is missing and should be "global" here.
> Category is required to be set, use either "original" or "current".

OK


> >         assessment:
> >                 impact:
> >                         severity: low (2)
> >                         completion: (null) (-1)
> >                         type: other (0)
>
> An impact description, if you have access to one, would be nice!

Is there an example program that I could look at to see how that might be 
generated?

> Additionally, the '-1' value used for completion is invalid.

Aha! This is one of the things I was talking about on IRC that I feel I cannot 
express the true state of the system. Right now, there is success - yes/no. 
But there is a 3rd state which is "indeterminate" or "unknown".

When an SE Linux AVC comes across the wire it will say denied or granted. You 
have to look at the syscall record to see if they actually succeeded. 
However, you only get a syscall record if audit is enabled and there is more 
than 1 audit rule (performance optimization). For the average user, they do 
not have a audit rule loaded. So all I have is the AVC record to look at.

If you have SE Linux in permissive mode, the message does not change even 
though the syscall succeeds. So, you are faced with this:

If you have an AVC and it says denied, and the syscall record says its denied. 
You can say success=no. If you have an AVC it says denied and there is no 
syscall record, you don't know if it succeeded or failed. There simply isn't 
enough evidence to make a conclusion. So, I feel like I'd want to say that "I 
don't know" if the source was successful in accessing the target.

Maybe I'll take this up with the SE Linux people, too.

> >         target(0):
> >                 decoy: unknown (0)
> >                 node:
> >                         category: hosts (6)
> >                         name: centaur
> >                 user:
> >                         category: application (1)
> >                         user_id(0):
> >                                 type: original-user (0)
> >                                 tty: sshd
> >                                 name: sgrubb
>
> Shouldn't type be 'target-user'?

OK, will fix.


> Also, the tty value look like invalid compared to the alert that follow.

This is because the first event authentication failed and a tty never got 
assigned. It is common for pam to use a daemon's name to fill in pam_tty 
settings when stdin is not a tty (a file or special character device 
like /dev/null). In the second one, authentication succeeded and a real tty 
was assigned to the user.


> >                 process:
> >                         name:
> >                         pid: 7775
> >                         path: "/usr/sbin/sshd"
>
> Missing process name, should be parsed to "sshd".

For logins, yes. I'll see what I can do.

I was trying to use a generic function that picks this out for many types of 
alerts. The problem is that you could have a python based program when the 
linux kernel decides that it needs an interpreter and launches it. So the 
audit records could show a command name, but the actual exe 
is /usr/bin/python, or /bin/bash. In some cases the audit records do not know 
the command that was typed, but only the exe. In other cases it knows the 
command name but not its path.

I was only filling in what was in the audit stream. I'll see what I can do, 
but its really not simple.  :)


> The following alert look like a duplicate, is it expected?

One was a failed login, the other a successful one. 

I'll do some fixups and try again. I've also added some additional fields to 
help convey some detail about the nature of the alert. For SE Linux AVC's it 
has the full AVC text.

I was also trying to figure out how to get the audit log's event ID into the 
prelude alert so that an ISSO can lookup exactly the original audit event 
that caused the alert if they needed additional information during their 
investigation. Is there a standard way to add this cross-reference 
information?

Thanks again for the feedback.

-Steve
_______________________________________________
Prelude-devel site list
[email protected]
http://www.prelude-ids.org/mailman/listinfo/prelude-devel