auditd configuration for PCI DSS 10.2.x Compliance
Steve Grubb
sgrubb at redhat.com
Mon Jan 15 15:45:13 UTC 2018
On Monday, January 15, 2018 9:52:07 AM EST Joshua Ammons wrote:
> Hello All,
>
> Just thought I'd give this one more shot to see if anyone had any comments
> on my prior message (see below)? Any input you have would be greatly
> appreciated. I won't bother the group any more on this topic.
Not sure if you noticed, but the audit system ships with a PCI set of rules.
# rpm -ql audit | grep pci
/usr/share/doc/audit/rules/30-pci-dss-v31.rules
> I was wondering if anyone had any experience putting together an auditd
> configuration to meet PCI DSS 10.2.x requirements? Below are the
> requirements and my thoughts for each one...if anyone has anything that
> they have done I'd love to hear it!
>
> 10.2.2 All actions taken by any individual with root or administrative
> privileges
>
> * Enable the pam_tty_audit.so shared library in
> /etc/pam.d/[su/sudo/sudo-i/su-l] files.
>
> o USER_TTY event type will contain all commands from privileged user.
>
> * Add following lines to /etc/audit/rules.d/audit.rules file:
>
> o # Audit all actions by any individual with root or administrative
> privileges
>
> o -a exit,always -F arch=b64 -F euid=0 -S execve -k root-commands
>
> o -a exit,always -F arch=b32 -F euid=0 -S execve -k root-commands
The above is best done by TTY auditing.
> ? EXECVE event type will contain all commands from user with elevated
> privileges.
>
> ? Question: with the pam_tty_audit.so enabled, and those commands being
> logged to USER_TTY events...is this rule needed also?
No. And you would want to add -F auid >= 1000 -F auid != -1 if you were
keeping it.
> 10.2.3 Access to all audit trails
> * I'm not sure the best route to cover this one. If I add a rule
> to watch /var/log/* for 'wa' actions, those logs are constantly being
> written to so that would be too noisy I believe. Does anyone know how I
> would form a rule that would fire when a file within /var/log is accessed
> directly by a user? Also, if the user makes any manual changes, such as
> deleting a file or modifying its contents?
Its not too noisy. Check the rules for this in the pci file. It picks up
everything.
> 10.2.4 Invalid logical access attempts
>
> * Based on my understanding, this wouldn't really be covered by
> auditd, but by the standard authpriv facility. Anybody configure anything
> in auditd to cover this requirement?
pam probably covers this.
> 10.2.5 Use of and changes to identification and authentication
> mechanisms-including but not limited to creation of new accounts and
> elevation of privileges-and all changes, additions, or deletions to
> accounts with root or administrative privileges
Put a watch on passwd & group and shadow-utils does the rest.
> * CRED_ACQ (sudo) and USER_AUTH (su) events should contain when a
> user sudo's or su's to privileged account. My understanding is that these
> would not require any extra rules to be written. However, I'm not quite
> sure how to handle the requirements to log creation of new accounts, and
> all changes, or deletions to accounts with root/admin privileges...any
> ideas?
Shadow utils covers this.
> 10.2.6. Initialization, stopping, or pausing of the audit logs
>
> * Auditd:
>
> o DAEMON_END events would indicate auditd was stopped.
>
> o DAEMON_START and SERVICE_START events would indicate when auditd
> initialized.
>
> o Anything else anybody would add here?
>
> * Rsyslog:
>
> o SERVICE_START event (unit=rsyslog) when rsyslog is initialized
>
> o SERVICE_STOP event (unit=rsyslog) when rsyslog is stopped
>
> o Anything else anybody would add here?
> 10.2.7 Creation and deletion of system- level objects
>
> * -w [DIRECTORY] -p wa rules for the directories below:
>
> o /bin
>
> o /sbin
>
> o /usr/bin
>
> o /usr/sbin
>
> o /var/lib
>
> o /usr/lib
>
> o /usr/libexec
>
> o /lib64
>
> o /usr/lib64
>
> ? Would the above cover this requirement? Any other suggestions here?
This will probably make you very unhappy when you do yum update. But you can
add those rules.
-Steve
More information about the Linux-audit
mailing list