check_second_connection stopping my recovery?

check_second_connection stopping my recovery?

[LC Bruzenak]

It appears to me as though the new connection code in auditd-listen.c
is stopping my recovery actions.
My aggregator is getting a constant stream of:
op=dup addr=192.168.10.10:43546 port=43546 res=no

I was going back through the events on disk, scooping them up and
sending them to the aggregation machine as Steve suggested a long
while back (using an ausearch then piping the results to
audisp-remote).
So it appears to me that this is now prohibited.  Was this intentional?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak

Re: check_second_connection stopping my recovery?

[Steve Grubb]

On Wednesday 18 November 2009 06:01:10 pm LC Bruzenak wrote:
> It appears to me as though the new connection code in auditd-listen.c
> is stopping my recovery actions.

<snip>

> So it appears to me that this is now prohibited.  Was this intentional?

Yes, it was. With the reconnect code its possible to DoS a server, so the 
connections need to be limited. I think the best solution is to make an admin 
tweakable setting that defaults to 1 and you can set it to 2. Your recovery 
technique won't be needed in the long term since its planned to have a store-
and-forward model so nothing is lost and its automatically recovered on start 
up.

-Steve

Re: check_second_connection stopping my recovery?

[LC Bruzenak]

On Tue, 2009-12-01 at 13:10 -0500, Steve Grubb wrote:
> On Wednesday 18 November 2009 06:01:10 pm LC Bruzenak wrote:
> 
> Yes, it was. With the reconnect code its possible to DoS a server, so the 
> connections need to be limited. I think the best solution is to make an admin 
> tweakable setting that defaults to 1 and you can set it to 2. Your recovery 
> technique won't be needed in the long term since its planned to have a store-
> and-forward model so nothing is lost and its automatically recovered on start 
> up.
> 
> -Steve

Steve,

Your call but it may not be worth adding a new setting.
I've already patched it out of my system, and if I'm the only one who
cares then I'd say don't worry about it.  I am aware of a DoS attack but
all senders are locked tight so I feel mitigation is sufficient. In fact
I nearly DoS-attacked myself before restricting the recovery to at most
1 process. :)

The store-and-forward piece will be excellent. It will solve at least a
couple of issues for me: recovery and also forwarding from a DMZ machine
to an internal server which will then forward to an independent
collector.

Thx,
LCB.

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