<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Re: Trying to understand audisp-remote network behavior</title> </head> <body> On 7/11/22 20:14, Ken Hornstein wrote: <blockquote type="cite" cite="mid:20220712021441.1075B12DBDC@pb-smtp1.pobox.com"> <blockquote type="cite" style="font-size: large; color: #007cff;"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">I would like to speak to those people who use it reliably in production! Specifically, do they have heartbeats configured?</pre> </blockquote> Hello Ken, been fielding systems for a very long time now. Yes. I've always had heartbeats configured on. <blockquote type="cite" cite="mid:20220712021441.1075B12DBDC@pb-smtp1.pobox.com"> <pre class="moz-quote-pre" wrap=""> 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. </pre> <blockquote type="cite" style="font-size: large; color: #007cff;"> <pre class="moz-quote-pre" wrap="">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. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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.</pre> </blockquote> 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 <pre class="moz-signature" cols="72">-- Lenny Bruzenak MagitekLTD</pre> </body> </html>