[prev in list] [next in list] [prev in thread] [next in thread] 

List:       prelude-devel
Subject:    Re: [prelude-devel] xml output from Linux audit plugin
From:       Steve Grubb <sgrubb () redhat ! com>
Date:       2008-01-29 16:42:12
Message-ID: 200801291142.12608.sgrubb () redhat ! com
[Download RAW message or body]

Hello Yoann,

On Monday 28 January 2008 12:25:44 Yoann Vandoorselaere wrote:
> > > [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?

Sound's fine. I changed it.


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

Yes, I'll add some info to a man page to make this clear.


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

I'll put this on a TODO list for the future.


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

I would prefer this


> - Leave tty empty, as a meaning "no terminal associated" or "unknown".

My only issue with this is that if you have fields that appear and disappear 
based on the application being reported, people may think there is a bug in 
the program. This is why we adopted "full disclosure" in the audit logs.


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

Then there is the case of a desktop user that doesn't have tty's unless they 
open an xterm window. But they can do a lot without a tty.

Was the intent of the tty field to be able to identify an action to a login 
session? Recently a patch was submitted to the linux-audit mail list to add a 
real session identifier as a task attribute - not the same as setsid() which 
is used for signals. This would be set at login and would be inherited at 
each fork/clone. This is probably what is really needed, the ability to trace 
a user action back to the login they came from. The patch should be in the 
2.6.25 kernel.



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

Thanks. I'll look into this and make updates or ask questions.


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

Would people feel like there might be a bug in my program if fields are 
reported sometimes and not others? I'd like to prevent bugzilla reports on my 
piece if at all possible.  :)


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

Yes.


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

An URL is not available and the identifier is required to be unique. So, I'll 
use the classification.ident as you suggested.

Thanks for the help!

-Steve

[prev in list] [next in list] [prev in thread] [next in thread]