All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: "Worsham, Michael" <mworsham@scires.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
Date: Tue, 4 Oct 2011 09:18:24 -0400	[thread overview]
Message-ID: <201110040918.24551.sgrubb@redhat.com> (raw)
In-Reply-To: <F52537DA8635C941B5CB6455ACA1EA581AA1238BE1@chsex02-srv>

On Monday, October 03, 2011 10:36:31 PM Worsham, Michael wrote:
> About the rule that’s 'killing' us (which I totally agree it is), this is
> what the stig.rules project says about it (GEN002720):
> 
> 78    ## (GEN002720-GEN002840: CAT II) (Previously G100-G106) The SA will
> 79    ## configure the auditing system to audit the following events for
> all 80    ## users and root:
> 81    ##
> 82    ## - Logon (unsuccessful and successful) and logout (successful)
> 83    ##
> 84    ## Handled by pam, sshd, login, and gdm
> 
> But here is what the latest version of the Unix checklist says the
> vulnerability is, and how to check if its mitigated:
> 
> Unix Checklist v5r1-30 20110729
> 3.2.1.119
> PDI:  GEN002720   – Audit Failed File and Program Access Attempts
> PDI Description: The audit system is not configured to audit failed
> attempts to access files and programs. Reference: UNIX STIG: 3.16
> -  Linux

I'll have to double check the numbering. Things may have shifted since I wrote the 
stig.rules file.


>    For LAUS:
>    # grep “@open-ops” /etc/audit/filter.conf
> 
>    For auditd:
>    # grep “-a exit,always –S open –F success=0” /etc/audit.rules

This would appear that you are using an old stig.rules file. You might want to update 
it.
 
 
> The two don’t seem to jibe as to what the vulnerability is. I’m not sure
> how login, sshd, etc, can give information about failed attempts to access
> files.

The rules file is listing several requirements which has the rules in-between the 
requirements. The first part is to satisfy the logon/off requirements. Farther down is 
the unsuccessful access requirement.

> As to altering the rule, while I’m sure the results would be much more
> useful and relevant (you can tell DISA’s thinking is out-of-date by the
> mitigation steps above), my only concern is that it would no longer be
> STIG compliant, or something that would always come up as a finding, that
> we would have to explain each time.

I occassionally chat with the DISA FSO people. The intent is the stig.rules file in the 
audit package is compliant. I think they have altered the auditing requirements to 
match what is shipped. But you just need to update to a newer version of the file.

-Steve

  reply	other threads:[~2011-10-04 13:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29 14:31 Suppress messages from /var/log/audit.log via audit.rules Worsham, Michael
2011-09-29 14:54 ` Vipin Rathor
2011-09-29 15:12   ` Worsham, Michael
2011-09-29 15:41 ` Steve Grubb
2011-09-29 15:51   ` Worsham, Michael
2011-09-30  1:51     ` Steve Grubb
2011-10-04  2:36       ` Worsham, Michael
2011-10-04 13:18         ` Steve Grubb [this message]
2011-11-01 15:45           ` Worsham, Michael
2011-11-02 17:11             ` Steve Grubb
2011-11-03 17:06               ` Worsham, Michael
2011-11-03 17:33                 ` Steve Grubb
2011-11-08 14:38                   ` Worsham, Michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201110040918.24551.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=mworsham@scires.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.