Re: Suppress messages from /var/log/audit.log via audit.rules

[Steve Grubb <sgrubb@redhat.com>]

On Thursday, November 03, 2011 01:06:52 PM Worsham, Michael wrote:
> After contacting DISA today, here is what they responded with:
> 
> "The SRR script currently does not support RHEL 5, only 3 and 4. Also, the
> STIG for RHEL 5 is currently in draft form and a manual review would need
> to be performed on the assets:
> http://iase.disa.mil/stigs/os/unix/red_hat.html"
 
Yes, its in draft which means there are no STIGs for RHEL5 or 6. However, I have met 
with them and there is an agreement that the stig file is correct until new 
requirements are levied.
 
 
> So I took a look at the RHEL 5 draft and found this entry:
> 
> Group ID (Vulid):  V-814
> Group Title:  Audit failed file and program access attempts
> Rule ID:  SV-27291r1_rule
> Severity: CAT II
> Rule Version (STIG-ID):  GEN002720
> Rule Title: The audit system must be configured to audit failed attempts to
> access files and programs.
> 
> Vulnerability Discussion:  If the system is not configured to audit certain
> activities and write them to an audit log, it is more difficult to detect
> and track system compromises and damages incurred during a system
> compromise.
> 
> Responsibility:  System Administrator
> IAControls:  ECAR-1, ECAR-2, ECAR-3
> 
> Check Content:
> Check that auditd is configured to audit failed file access attempts.
> 
> # cat /etc/audit.rules /etc/audit/audit.rules | grep -e "-a always,exit" |
> grep -i "open" If no results are returned, or the results do not contain
> "-S open" and "-F success=0", this is a finding.
> 
> Fix Text: Edit the audit.rules file and add the following line to enable
> auditing of failed attempts to access files and programs: 
> -a always,exit -F arch=<ARCH> -S open -F success=0
> Restart the auditd service.

Which is slightly better, but still wrong.


> The 'Fix Text' sounds like it will still spam the audit.log or am I missing
> something?

It would, which is a good reason its still a draft. This also doesn't cover the openat 
syscall which glibc uses. The NSA publishes a SNAC guide for RHEL5. You can find the 
latest at this location:

http://www.nsa.gov/ia/_files/os/redhat/NSA_RHEL_5_GUIDE_v4.2.pdf

If you look in section 2.6.2.4.8, you will see the correct audit rule listed as CCE 
14917-9. This is what the RHEL5 STIG should map to in its XCCDF.

-Steve


> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Wednesday, November 02, 2011 1:12 PM
> To: Worsham, Michael
> Cc: linux-audit@redhat.com
> Subject: Re: Suppress messages from /var/log/audit.log via audit.rules
> 
> On Tuesday, November 01, 2011 11:45:51 AM Worsham, Michael wrote:
> > SRR still shows this as a failure, using stig.rules contents for
> > audit.rules:
> > 
> > GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit
> > failed attempts to access files and programs. AUDITING is NOT correctly
> > CONFIGURED on va33-time.
> > Ensure that -a exit,always -S open -F success=0 is in
> > /etc/audit/audit.rules
> 
> This ^^^ is wrong. For example, it does not limit the syscall by the arch.
> So what this means is that it will look up the open syscall for the arch
> that auditctl is. So, lets see what that does:
> 
> # ausyscall open
> open               2
> 
> OK, now what does the 32 bit API think of it?
> # ausyscall 2 i386
> fork
> 
> So, that rule will watch for all 32 bit forks and 64 bit opens. Is that
> what your security folks want?
> 
> Additionally, the intent of the STIG is to catch failed opens due to
> permission problems. You are going to trap normal system activity when
> glibc goes looking around for library resolution information. This will
> waste space in your logs and make it hard to find actual problems.
> 
> > PDI Number: GEN002720
> > Finding Category: CAT II
> > Reference: UNIX STIG: 3.16
> > Description: The audit system is not configured to audit failed attempts
> > to access files and programs. Status: Open
> > 
> > 
> > Is there any documentation that says that the stig.rules file is
> > compliant for GEN002720?
> 
> There are no docs that I know of. I could write one, but would that be
> authoritative?
> 
> :)
> :
> > The project security folks will only be looking at the SRR
> > output, which says it's not.
> 
> And the SRR is completely wrong. So, they need to have some understanding
> that you either want a system configured right but failing the SRR's or
> matching the SRR's but configured wrong. I'd hate to be in your position,
> but that's where you are.
> 
> > We are using the rules as found here:
> > https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules
> 
> These rules are correct. You can contact DISA to verify.