From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 85D94C43334 for ; Tue, 12 Jul 2022 15:23:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657639423; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=K1c27O4ZgRwOvRX8/aXV+cFjvH0Q+YfRzCReN53w3XM=; b=DEWp8pxLO5nqZ8pV1dWKFtszr0RpZYHaUp8DK1upQ3mjchsVAsebRg9BBt/FUp5v6WWljw XQoXViO81SdDe/3HHGtjhXmJSCZrB3hxGAAo51d/MbXHSP1Wmi5zxF6h4Xf5zV1+vYErxn 6JC+wWNOLeMJTxf1CzNNUyZtO0hQLCY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-500-7-Ne6hI2MUKaK9kOhL0dzA-1; Tue, 12 Jul 2022 11:23:27 -0400 X-MC-Unique: 7-Ne6hI2MUKaK9kOhL0dzA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 62A2B85A581; Tue, 12 Jul 2022 15:23:25 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id E2E9E492C3B; Tue, 12 Jul 2022 15:23:22 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id BFADA194705E; Tue, 12 Jul 2022 15:23:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 4BDD71947058 for ; Tue, 12 Jul 2022 15:23:21 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 17A22C202C5; Tue, 12 Jul 2022 15:23:21 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast08.extmail.prod.ext.rdu2.redhat.com [10.11.55.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 13371C04482 for ; Tue, 12 Jul 2022 15:23:21 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E877F38041DA for ; Tue, 12 Jul 2022 15:23:20 +0000 (UTC) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-513-lMDSJwV9MZK_PmfmNZBEsA-1; Tue, 12 Jul 2022 11:23:12 -0400 X-MC-Unique: lMDSJwV9MZK_PmfmNZBEsA-1 Received: by mail-ot1-f49.google.com with SMTP id a14-20020a0568300b8e00b0061c4e3eb52aso3895758otv.3 for ; Tue, 12 Jul 2022 08:23:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=pTct3xKYy8g20ASkiW+VgFQw0b0EI9Nu5AKrZwDgwoY=; b=M08z0fSPQNt447c+RUQIQOLCNzyBpiWKxMkxT1nI2QYun/gfzw2A9KwnhkG34dcxZP Qbs04SM1zB8sdSyNtOxhrH7Ac3xcvaX5Ajh5KHkgEQyUG8FSmMNAidX097kZZ85pCrWC ZTTYK0wXdgctB0Be2SCXGqZCotZvB4kpUvpW8cNK7p9RJ8XzP/M7GEcIkFG7H6CAOWM1 8qnGXeRhLy2Y9poh2kD+VfTWa4BJGI1r1eK76T8S1F56fcs3jN/5/0X6JW5tdahmCUJF y3LAboQ4uc2wXpRWEOq5zVNZu+Q7J38p1zpdrUpt6alkadtk++/g2aHI97e+PYsKt60T X2KA== X-Gm-Message-State: AJIora8MK1BwsyR3YtXnwvbZ50MoMTOuhyukSCrKTz7X0Q3j/ekyemH0 SEoJc67W3JcoaGG/JeIlYmIDe+P2+A/Zwf0K X-Google-Smtp-Source: AGRyM1s/b2YHJ4oFC0w3cDHrXSFLa6jIUo6Xr+vQ7ed4t4n7UFo+wbyqH0nVKmhfafTc5e/XI1Bxsw== X-Received: by 2002:a05:6830:268c:b0:618:5cc0:417d with SMTP id l12-20020a056830268c00b006185cc0417dmr9515836otu.196.1657639391702; Tue, 12 Jul 2022 08:23:11 -0700 (PDT) Received: from [192.168.0.143] ([206.85.149.8]) by smtp.gmail.com with ESMTPSA id g20-20020a4ad854000000b0041bcce4bd85sm3860400oov.2.2022.07.12.08.23.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 08:23:11 -0700 (PDT) Message-ID: <45c7c87e-9f16-d094-eabf-bc619d10f501@magitekltd.com> Date: Tue, 12 Jul 2022 09:23:10 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Trying to understand audisp-remote network behavior To: linux-audit@redhat.com References: <20220707040529.DFABD138817@pb-smtp1.pobox.com> <13478993.uLZWGnKmhe@x2> <20220712021441.1075B12DBDC@pb-smtp1.pobox.com> From: Lenny Bruzenak In-Reply-To: <20220712021441.1075B12DBDC@pb-smtp1.pobox.com> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: multipart/mixed; boundary="===============1645176994968908281==" This is a multi-part message in MIME format. --===============1645176994968908281== Content-Type: multipart/alternative; boundary="------------5KJrET09uDz993d3TBnB0NN0" Content-Language: en-US This is a multi-part message in MIME format. --------------5KJrET09uDz993d3TBnB0NN0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------5KJrET09uDz993d3TBnB0NN0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Re: Trying to understand audisp-remote network behavior

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
--------------5KJrET09uDz993d3TBnB0NN0-- --===============1645176994968908281== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit --===============1645176994968908281==--