Re: Trying to understand audisp-remote network behavior

> 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?

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.