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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit