6:56 p.m.
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(a)magitekltd.com
7:05 p.m.
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.
8:40 p.m.
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(a)magitekltd.com
7:20 a.m.
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
12:15 p.m.
New subject: audit collection
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(a)magitekltd.com
12:24 p.m.
New subject: audit collection
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.
12:35 p.m.
New subject: audit collection
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(a)magitekltd.com
12:48 p.m.
New subject: audit collection
(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.
7:18 a.m.
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
6109
days inactive
6112
days old
linux-audit@lists.linux-audit.osci.io
8 comments
3 participants
participants (3)
-
DJ Delorie -
LC Bruzenak -
Steve Grubb