no node= in ausearch

no node= in ausearch

[LC Bruzenak]

Just as an aside, I was sending in the auditctl event because I do not
see the "node=" information in the ausearch results on my collector.
So I wasn't certain which machine might be initiating the event.

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: no node= in ausearch

[DJ Delorie]

> Just as an aside, I was sending in the auditctl event because I do not
> see the "node=" information in the ausearch results on my collector.
> So I wasn't certain which machine might be initiating the event.

Locally generated events won't have the node= (at least, on my machine
they don't).  Remotely generated events should have the node= on them.

Re: no node= in ausearch

[LC Bruzenak]

On Fri, 2008-09-12 at 20:05 -0400, DJ Delorie wrote:
> > Just as an aside, I was sending in the auditctl event because I do not
> > see the "node=" information in the ausearch results on my collector.
> > So I wasn't certain which machine might be initiating the event.
> 
> Locally generated events won't have the node= (at least, on my machine
> they don't).  Remotely generated events should have the node= on them.

I thought there was a distinction as to where it was assigned, as in
auditd.conf vice audispd.conf. The raw data (in the log) does have it
locally.

So anyway, if I see no node= events in the collector I know that it
isn't getting any events. 
Also the sender's audispd sends log messages saying the queue is full
and it must drop the events.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: no node= in ausearch

[Steve Grubb]

On Friday 12 September 2008 19:56:08 LC Bruzenak wrote:
> Just as an aside, I was sending in the auditctl event because I do not
> see the "node=" information in the ausearch results on my collector.
> So I wasn't certain which machine might be initiating the event.

That was fixed yesterday afternoon in:

https://fedorahosted.org/audit/changeset/98

-Steve

Re: no node= in ausearch

[Steve Grubb]

On Friday 12 September 2008 21:40:23 LC Bruzenak wrote:
> > Locally generated events won't have the node= (at least, on my machine
> > they don't).  Remotely generated events should have the node= on them.
>
> I thought there was a distinction as to where it was assigned, as in
> auditd.conf vice audispd.conf.

Yes. For remote logging the one in audispd.conf is used. I'll be unifying 
things sometime in the next few months.

-Steve

audit collection

[LC Bruzenak]

On my F9 machines I still get no events (that I can tell) across.

I have changed to sending from / receiving on 64-bit machines only,
since that's what I have for now.

I have made the "name_format = user", "name = hugo" on the sender in
audispd.conf just to be certain it is unique.

===================
On the sender I see:

messages log (hundreds of these):
Sep 15 11:48:14 comms audispd: queue is full - dropping event

I assume this indicates the problem - sending isn't happening so the
audispd queue fills. I'd have expected an audisp syslog error though.

lsof:
[root@hugo audit]# lsof | grep sdos
audisp-re 5082      root    3u     IPv4              92619
TCP comms:41065->dell1:tsdos390 (ESTABLISHED)

===================

On the collector I see:

[root@dell1 audit]#  lsof | grep sdos
auditd    5790      root    9u     IPv4              34892
TCP *:tsdos390 (LISTEN)
auditd    5790      root   10u     IPv4              35068
TCP comms:tsdos390->hugo:41065 (ESTABLISHED)

and nothing in the messages log.

I'm not seeing any of the events in the collector log from the sender
(reading the audit.log file directly until Steve's ausearch node= patch
is applied). 

I'm also sending between machines with the same MLS policy in permissive
mode. 

Any ideas? I guess I can go check the code where the send happens to see
if there is any debug I can add.

Thx,
LCB.


-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: audit collection

[DJ Delorie]

> Sep 15 11:48:14 comms audispd: queue is full - dropping event
> 
> I assume this indicates the problem - sending isn't happening so the
> audispd queue fills.

Yes, this means nothing is getting across the network.  Have you tried
running tcpdump on the client side?  Or running gdb on the running
audisp-remote to see where it's stuck.

> I'd have expected an audisp syslog error though.

I do log all the errors I could detect, so I don't know what's
happening here.  Those syslog errors are likely from audisp itself,
not the remote plugin.

It would help if you could try it between two 32 bit hosts.  At least
that would remove the "int size bug" possibility.

Re: audit collection

[LC Bruzenak]

On Mon, 2008-09-15 at 13:24 -0400, DJ Delorie wrote:
> > Sep 15 11:48:14 comms audispd: queue is full - dropping event
> > 
> > I assume this indicates the problem - sending isn't happening so the
> > audispd queue fills.
> 
> Yes, this means nothing is getting across the network.  Have you tried
> running tcpdump on the client side?  Or running gdb on the running
> audisp-remote to see where it's stuck.

(gdb) where
#0  0x0000000000892590 in __read_nocancel () from /lib64/libc.so.6
#1  0x00007f25874db914 in main (argc=<value optimized out>, argv=<value
optimized out>)
    at /usr/include/bits/unistd.h:45

I suppose I'd need to run the debug code to get a better analysis.

LCB.


-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: audit collection

[DJ Delorie]

> (gdb) where
> #0  0x0000000000892590 in __read_nocancel () from /lib64/libc.so.6
> #1  0x00007f25874db914 in main (argc=<value optimized out>, argv=<value
> optimized out>)
>     at /usr/include/bits/unistd.h:45
> 
> I suppose I'd need to run the debug code to get a better analysis.

Or build your audisp-remote with -g -O0.