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