Re: xml output from Linux audit plugin

Hi Steve,


Le vendredi 25 janvier 2008 à 17:27 -0500, Steve Grubb a écrit :

> 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?

Ah, if that one was coming from the Manager itself, my mistake.

> > [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.

Using "auditd" sound appropriate since the Prelude plugin is really an
interface for the program to access the Prelude reporting capability.
Does that sound ok to you?

[...]


> > >         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.

If the admin can configure the kind of node name being reported, then
this is probably ok: he can then choose the reporting method that suit
him the most, and will know how to read each event from the
visualization interface.

> > 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.

What about adding the feature as an option, disabled by default, only
available for FQDN kind of report?


> > >                 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.

Unfortunately, IDMEF provide no mechanism to distinguish the case where
there is no terminal, and case where the information simply isn't
accessible. My problem using "(none)" as the value is that it is not
normalized. So we get the following solution:

- Standardize on a value meaning "no terminal associated".
- Leave tty empty, as a meaning "no terminal associated" or "unknown".

I'd rather leave this empty for now as this is not standardized (we
didn't pay much attention to this particular field, so it is likely
different products will report different values for the same meaning).
the most common practice currently seem to be setting this value if we
know the terminal, or leave it empty if we don't. Suggestion?


> > >         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?

Are you looking for idmef_impact_set_description()? You can see this
function used in LML file-server.c .

> > 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.

This is correct, IDMEF feature no "unknown" value for impact completion,
but you can accomplish the same by omitting the field, since it is
optional. 

So you probably want to set completion to "succeeded" or "failed" when
possible, and simply leave out the field if you don't know.

[...]


> > 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.

Sound like a good idea! I guess you added those to AdditionalData?


> 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?

I'd suggest using classification.reference, but IDMEF require that you
provide an URL pointing to:

url 
Exactly one.  STRING.  A URL at which the manager (or the human
      operator of the manager) can find additional information about the
      alert.  The document pointed to by the URL may include an in-depth
      description of the attack, appropriate countermeasures, or other
      information deemed relevant by the vendor.

If an URL is not available, and the event ID is truly unique, then I
would suggest using classification.ident.


Keep up the good work!


-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com

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