Trying to understand audisp-remote network behavior

[Lenny Bruzenak]

On 7/11/22 20:14, Ken Hornstein wrote:

>> I know there are people on this list that are using it reliably in
>> production. But, the problems were worked out mostly in the 3.0 release. The
>> kerberos code is donated code. I have not personally tested it myself due to
>> the problems in setting up the infrastructure. But from my review 2 weeks
>> ago, it looks like it would have problems in any error situation. I committed
>> some updates today which should make krb5 support better.
> I would like to speak to those people who use it reliably in production!
> Specifically, do they have heartbeats configured?

Hello Ken, been fielding systems for a very long time now.

Yes. I've always had heartbeats configured on.

>
> As long as I have you ... there is one additional issue I think that
> is worth mentioning.  If you have GSS configured you can hang an aggregation
> server hard by doing:
>
> % telnet aggregation-server 60
>
> The problem is while nearly all of auditd uses a libev event loop, the
> function ar_read() calls read() without a timeout, and it blocks and
> none of the other connections get serviced.  This can happen if you
> are doing something like network scanning, or you have a misconfigured
> audisp-remote client.  I think the only long-term solution there is to
> make sure ar_read (or maybe recv_token()) uses the ev event loop;
> I know that's not easy.
>
>> The non-kerberos code has been heavily tested. You might try that to see if
>> it works better. But if you are on the old code, there were problems fixed in
>> the 3.0 release. I think people using it are not using the krb5 code and
>> create a vpn or ssh tunnel for encryption.
> Well, it's a large effort to use a non-vendor RPM here_and_  the STIGs
> mandate the use of krb5 with audisp-remote (I know people have asked
> for exceptions successfully, but having been involved with that process
> I know the less exceptions you ask for, the better).  Just from my
> analysis the core networking code hasn't really changed in any way that
> would change the basic problem.  Like I said, I am open to being proven
> wrong!  I'd be intersted in hearing from others who have used audisp-remote
> successfully in production, Kerberos or not.

Because ALL our inter-server communication is encrypted with ipsec 
(libreswan), we are not required to add another.

I will say that I've custom-patched the auditd code and the 
audisp-remote  code in ways probably not suitable for general use.

Thx,

LCB

-- 
Lenny Bruzenak
MagitekLTD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20220712/7e4c9aa5/attachment.htm>