Audit 3.0 and SCAP rule "Encrypt Audit Records Sent With audispd Plugin"

[Jan Cerny]

Hi,

We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
It checks that enable_krb5 = yes is set in /etc/audisp/audisp-remote.conf.
We have found that it doesn't work anymore on Fedora 29 and RHEL 8.

I have found that the audisp-remote.conf has moved to /etc/audit and
that "enable_krb5 = yes" option has been superseded by "transport = KRB5".
I have created a patch [2] that fixes the rule, OVAL, etc.

However, it turned out that 'transport' option can be set also in
/etc/audit/auditd.conf. It's not clear to me if we should check
/etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.

Which of the 2 configuration files is correct to configure authentication
and encryption for remote logging? Does each of the files mean a different thing?

Thank you.

Regards

[1] https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/syste...
[2] https://github.com/ComplianceAsCode/content/pull/3619

Jan Černý
Security Technologies | Red Hat, Inc.

[Steve Grubb]

On Friday, November 23, 2018 8:00:17 AM EST Jan Cerny wrote:
> Hi,
>
> We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> It checks that enable_krb5 = yes is set in /etc/audisp/audisp-remote.conf.
> We have found that it doesn't work anymore on Fedora 29 and RHEL 8.
>
> I have found that the audisp-remote.conf has moved to /etc/audit and
> that "enable_krb5 = yes" option has been superseded by "transport = KRB5".
> I have created a patch [2] that fixes the rule, OVAL, etc.

Yes. This is in preparation for a TLS option since setting up a kerberos 
server is a large task.
> However, it turned out that 'transport' option can be set also in
> /etc/audit/auditd.conf.

This would be for the aggregating server rather than the remote client that 
is sending. Both sides have to agree on what transport will be used.
> It's not clear to me if we should check
> /etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.

On the remote system, check  /etc/audit/audisp-remote.conf and on the server 
check /etc/audit/auditd.conf. Note that all audit configuration is now 
consolidated under /etc/audit/. Also, the server should have some other 
things enabled that should not be enabled on clients such as krb5_principal, 
krb5_key_file, transport, tcp_listen_port, and tcp_listen_queue. On all 
systems you would want to check settings for:

local_events = yes
log_format = enriched
flush = INCREMENTAL_ASYNC
name_format = hostname

on remote client systems, you should check:
remote_server =
port = 60
transport = krb5
mode = forward
queue_depth = 10240 (or larger)
format = managed
krb5_principal =
krb5_client_name = auditd
krb5_key_file = /etc/audit/audisp-remote.key

-Steve
> Which of the 2 configuration files is correct to configure authentication
> and encryption for remote logging? Does each of the files mean a different
> thing?
>
> Thank you.
>
> Regards
>
> [1]
> https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/sys
> tem/auditing/configure_auditd_data_retention/auditd_audispd_encrypt_sent_re
> cords/rule.yml [2] https://github.com/ComplianceAsCode/content/pull/3619
>
> Jan Černý
> Security Technologies | Red Hat, Inc.

[Trevor Vaughan]

Glad to hear that TLS is on its way. Any chance of it being back-ported for
universal consistency?

I don't mind KRB, but I don't see any server guidance in the SSG so it's
been...interesting...to get propagated effectively and, of course, there is
the battle of AD vs IPA vs MIT etc...

On Fri, Nov 23, 2018 at 10:29 AM Steve Grubb  wrote:
> On Friday, November 23, 2018 8:00:17 AM EST Jan Cerny wrote:
> > Hi,
> >
> > We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> > It checks that enable_krb5 = yes is set in
>
> /etc/audisp/audisp-remote.conf.
> > We have found that it doesn't work anymore on Fedora 29 and RHEL 8.
> >
> > I have found that the audisp-remote.conf has moved to /etc/audit and
> > that "enable_krb5 = yes" option has been superseded by "transport =
>
> KRB5".
> > I have created a patch [2] that fixes the rule, OVAL, etc.
>
> Yes. This is in preparation for a TLS option since setting up a kerberos
> server is a large task.
> > However, it turned out that 'transport' option can be set also in
> > /etc/audit/auditd.conf.
>
> This would be for the aggregating server rather than the remote client
> that
> is sending. Both sides have to agree on what transport will be used.
> > It's not clear to me if we should check
> > /etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.
>
> On the remote system, check  /etc/audit/audisp-remote.conf and on the
> server
> check /etc/audit/auditd.conf. Note that all audit configuration is now
> consolidated under /etc/audit/. Also, the server should have some other
> things enabled that should not be enabled on clients such as
> krb5_principal,
> krb5_key_file, transport, tcp_listen_port, and tcp_listen_queue. On all
> systems you would want to check settings for:
>
> local_events = yes
> log_format = enriched
> flush = INCREMENTAL_ASYNC
> name_format = hostname
>
> on remote client systems, you should check:
> remote_server =
> port = 60
> transport = krb5
> mode = forward
> queue_depth = 10240 (or larger)
> format = managed
> krb5_principal =
> krb5_client_name = auditd
> krb5_key_file = /etc/audit/audisp-remote.key
>
> -Steve
> > Which of the 2 configuration files is correct to configure authentication
> > and encryption for remote logging? Does each of the files mean a
>
> different
> > thing?
> >
> > Thank you.
> >
> > Regards
> >
> > [1]
>
> https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/sys
> >
>
> tem/auditing/configure_auditd_data_retention/auditd_audispd_encrypt_sent_re
> > cords/rule.yml [2] https://github.com/ComplianceAsCode/content/pull/3619
> >
> > Jan Černý
> > Security Technologies | Red Hat, Inc.
>
> scap-security-guide mailing list --
> [e-mail]
> To unsubscribe send an email to
> [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Steve Grubb]

On Monday, November 26, 2018 8:29:18 AM EST Trevor Vaughan wrote:
> Glad to hear that TLS is on its way. Any chance of it being back-ported for
> universal consistency?

No chance because of the changes to the config files in a shipped product. I 
rushed these changes into place before RHEL 8 ships so that it can be 
delivered later.
> I don't mind KRB, but I don't see any server guidance in the SSG so it's
> been...interesting...to get propagated effectively and, of course, there is
> the battle of AD vs IPA vs MIT etc...

Yep. Hopefully TLS will work better for people with small to medium setups. I 
have also heard of people using libreswan to make a vpn connection to a 
server. To me, that also sounds complicated.

-Steve
> On Fri, Nov 23, 2018 at 10:29 AM Steve Grubb  wrote:
> > On Friday, November 23, 2018 8:00:17 AM EST Jan Cerny wrote:
> > > Hi,
> > >
> > > We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> > > It checks that enable_krb5 = yes is set in
> >
> > /etc/audisp/audisp-remote.conf.
> > > We have found that it doesn't work anymore on Fedora 29 and RHEL 8.
> > >
> > > I have found that the audisp-remote.conf has moved to /etc/audit and
> > > that "enable_krb5 = yes" option has been superseded by "transport =
> >
> > KRB5".
> > > I have created a patch [2] that fixes the rule, OVAL, etc.
> >
> > Yes. This is in preparation for a TLS option since setting up a kerberos
> > server is a large task.
> > > However, it turned out that 'transport' option can be set also in
> > > /etc/audit/auditd.conf.
> >
> > This would be for the aggregating server rather than the remote client
> > that
> > is sending. Both sides have to agree on what transport will be used.
> > > It's not clear to me if we should check
> > > /etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.
> >
> > On the remote system, check  /etc/audit/audisp-remote.conf and on the
> > server
> > check /etc/audit/auditd.conf. Note that all audit configuration is now
> > consolidated under /etc/audit/. Also, the server should have some other
> > things enabled that should not be enabled on clients such as
> > krb5_principal,
> > krb5_key_file, transport, tcp_listen_port, and tcp_listen_queue. On all
> > systems you would want to check settings for:
> >
> > local_events = yes
> > log_format = enriched
> > flush = INCREMENTAL_ASYNC
> > name_format = hostname
> >
> > on remote client systems, you should check:
> > remote_server =
> > port = 60
> > transport = krb5
> > mode = forward
> > queue_depth = 10240 (or larger)
> > format = managed
> > krb5_principal =
> > krb5_client_name = auditd
> > krb5_key_file = /etc/audit/audisp-remote.key
> >
> > -Steve
> > > Which of the 2 configuration files is correct to configure
> > > authentication
> > > and encryption for remote logging? Does each of the files mean a
> >
> > different
> > > thing?
> > >
> > > Thank you.
> > >
> > > Regards
> > >
> > > [1]
> >
> > https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/sy
> > s
> >
> > tem/auditing/configure_auditd_data_retention/auditd_audispd_encrypt_sent_
> > re>
> > > cords/rule.yml [2]
> > > https://github.com/ComplianceAsCode/content/pull/3619
> > >
> > > Jan Černý
> > > Security Technologies | Red Hat, Inc.
> >
> > scap-security-guide mailing list --
> > [e-mail]
> > To unsubscribe send an email to
> > [e-mail]
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedorahosted.org/archives/list/[e-mail]
> > dorahosted.org

[Trevor Vaughan]

Personally, I just shoved it into syslog and let it encrypt from there with
an 'offload prior to local' rule.

I get that audit logs are important but the main syslog subsystem is much
more likely to be monitored and processed in an enterprise environment
(wherever it goes) than a different one-off subsystem with independent
logging.

Trevor

On Mon, Nov 26, 2018 at 8:42 AM Steve Grubb  wrote:
> On Monday, November 26, 2018 8:29:18 AM EST Trevor Vaughan wrote:
> > Glad to hear that TLS is on its way. Any chance of it being back-ported
>
> for
> > universal consistency?
>
> No chance because of the changes to the config files in a shipped product.
> I
> rushed these changes into place before RHEL 8 ships so that it can be
> delivered later.
> > I don't mind KRB, but I don't see any server guidance in the SSG so it's
> > been...interesting...to get propagated effectively and, of course, there
>
> is
> > the battle of AD vs IPA vs MIT etc...
>
> Yep. Hopefully TLS will work better for people with small to medium
> setups. I
> have also heard of people using libreswan to make a vpn connection to a
> server. To me, that also sounds complicated.
>
> -Steve
> > On Fri, Nov 23, 2018 at 10:29 AM Steve Grubb  wrote:
> > > On Friday, November 23, 2018 8:00:17 AM EST Jan Cerny wrote:
> > > > Hi,
> > > >
> > > > We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> > > > It checks that enable_krb5 = yes is set in
> > >
> > > /etc/audisp/audisp-remote.conf.
> > > > We have found that it doesn't work anymore on Fedora 29 and RHEL 8.
> > > >
> > > > I have found that the audisp-remote.conf has moved to /etc/audit and
> > > > that "enable_krb5 = yes" option has been superseded by "transport =
> > >
> > > KRB5".
> > > > I have created a patch [2] that fixes the rule, OVAL, etc.
> > >
> > > Yes. This is in preparation for a TLS option since setting up a
>
> kerberos
> > > server is a large task.
> > > > However, it turned out that 'transport' option can be set also in
> > > > /etc/audit/auditd.conf.
> > >
> > > This would be for the aggregating server rather than the remote client
> > > that
> > > is sending. Both sides have to agree on what transport will be used.
> > > > It's not clear to me if we should check
> > > > /etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.
> > >
> > > On the remote system, check  /etc/audit/audisp-remote.conf and on the
> > > server
> > > check /etc/audit/auditd.conf. Note that all audit configuration is now
> > > consolidated under /etc/audit/. Also, the server should have some other
> > > things enabled that should not be enabled on clients such as
> > > krb5_principal,
> > > krb5_key_file, transport, tcp_listen_port, and tcp_listen_queue. On all
> > > systems you would want to check settings for:
> > >
> > > local_events = yes
> > > log_format = enriched
> > > flush = INCREMENTAL_ASYNC
> > > name_format = hostname
> > >
> > > on remote client systems, you should check:
> > > remote_server =
> > > port = 60
> > > transport = krb5
> > > mode = forward
> > > queue_depth = 10240 (or larger)
> > > format = managed
> > > krb5_principal =
> > > krb5_client_name = auditd
> > > krb5_key_file = /etc/audit/audisp-remote.key
> > >
> > > -Steve
> > > > Which of the 2 configuration files is correct to configure
> > > > authentication
> > > > and encryption for remote logging? Does each of the files mean a
> > >
> > > different
> > > > thing?
> > > >
> > > > Thank you.
> > > >
> > > > Regards
> > > >
> > > > [1]
>
> https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/sy
> > > s
>
> tem/auditing/configure_auditd_data_retention/auditd_audispd_encrypt_sent_
> > > re>
> > > > cords/rule.yml [2]
> > > > https://github.com/ComplianceAsCode/content/pull/3619
> > > >
> > > > Jan Černý
> > > > Security Technologies | Red Hat, Inc.
> > >
> > > scap-security-guide mailing list --
> > > [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines:
>
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
>
> https://lists.fedorahosted.org/archives/list/[e-mail]
> > > dorahosted.org

[Jan Cerny]

Hi Steve,

Thank you very much for clarification.

Regards

Jan Černý
Security Technologies | Red Hat, Inc.

----- Original Message -----
> From: "Steve Grubb" 
> To: "Jan Cerny" 
> Cc: "SCAP Security Guide" 
> Sent: Friday, November 23, 2018 4:28:52 PM
> Subject: Re: Audit 3.0 and SCAP rule "Encrypt Audit Records Sent With audispd Plugin"
>
> On Friday, November 23, 2018 8:00:17 AM EST Jan Cerny wrote:
> > Hi,
> >
> > We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> > It checks that enable_krb5 = yes is set in /etc/audisp/audisp-remote.conf.
> > We have found that it doesn't work anymore on Fedora 29 and RHEL 8.
> >
> > I have found that the audisp-remote.conf has moved to /etc/audit and
> > that "enable_krb5 = yes" option has been superseded by "transport = KRB5".
> > I have created a patch [2] that fixes the rule, OVAL, etc.
>
> Yes. This is in preparation for a TLS option since setting up a kerberos
> server is a large task.
> > However, it turned out that 'transport' option can be set also in
> > /etc/audit/auditd.conf.
>
> This would be for the aggregating server rather than the remote client that
> is sending. Both sides have to agree on what transport will be used.
> > It's not clear to me if we should check
> > /etc/audisp/audisp-remote.conf or /etc/audit/auditd.conf or both.
>
> On the remote system, check  /etc/audit/audisp-remote.conf and on the server
> check /etc/audit/auditd.conf. Note that all audit configuration is now
> consolidated under /etc/audit/. Also, the server should have some other
> things enabled that should not be enabled on clients such as krb5_principal,
> krb5_key_file, transport, tcp_listen_port, and tcp_listen_queue. On all
> systems you would want to check settings for:
>
> local_events = yes
> log_format = enriched
> flush = INCREMENTAL_ASYNC
> name_format = hostname
>
> on remote client systems, you should check:
> remote_server =
> port = 60
> transport = krb5
> mode = forward
> queue_depth = 10240 (or larger)
> format = managed
> krb5_principal =
> krb5_client_name = auditd
> krb5_key_file = /etc/audit/audisp-remote.key
>
> -Steve
> > Which of the 2 configuration files is correct to configure authentication
> > and encryption for remote logging? Does each of the files mean a different
> > thing?
> >
> > Thank you.
> >
> > Regards
> >
> > [1]
> > https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/sys
> > tem/auditing/configure_auditd_data_retention/auditd_audispd_encrypt_sent_re
> > cords/rule.yml [2] https://github.com/ComplianceAsCode/content/pull/3619
> >
> > Jan Černý
> > Security Technologies | Red Hat, Inc.

[James Ralston]

On Fri, Nov 23, 2018 at 8:00 AM Jan Cerny  wrote:
> We have a rule 'Encrypt Audit Records Sent With audispd Plugin' [1].
> It checks that enable_krb5 = yes is set in /etc/audisp/audisp-remote.conf.
> We have found that it doesn't work anymore on Fedora 29 and RHEL 8.

Just out of curiosity, did anyone ever get this working under *RHEL7*,
let alone RHEL8?

The bitter irony is that even if you *are* a Kerberos shop (e.g., we
have full LDAP+Kerberos integration with Microsoft Active Directory
via sssd and gssproxy), configuring auditd for Kerberos is still a
complicated kabuki dance.  I attempted to wrap audisp-remote with
gssproxy, but that doesn't disable audisp-remote's checking the
characteristics of the key file.  Even after I set up everything
properly (or so I thought), audit forwarding worked only
intermittently.

I was going to file a "MAKE THIS WORK DAMMIT" Red Hat support case,
but once I stumbled across this bug, I ran shrieking from Kerberized
audit forwarding:

https://bugzilla.redhat.com/show_bug.cgi?id=1622194

The only explanation why a memory leak like that could persist for
years in the code is because *no one* is using Kerberized audit record
forwarding.  With all due respects to Steve Grubb, how many other
critical bugs (potentially security-related) are lurking in the
Kerberized audit forwarding code that have never been found, simply
because only people who have to care about the RHEL7 STIG even know
that audisp-remote has Kerberized audit record forwarding
capabilities, let alone have attempted to enable it?

"Services that provide core security features" and "extremely
infrequently-used code paths" aren't two great tastes that taste great
together, unfortunately.