warron.french wrote: > Anyway, my organization has a goal to audit several things; of which I > know how to manage most, for examples: > ... > Hi Warron. Have you looked at the various *.rules files that are shipped with the audit package? In RHEL/CentOS, you'll see: ~]# ls -1 /usr/share/doc/audit-2.4.1/*rules > /usr/share/doc/audit-2.4.1/capp.rules > /usr/share/doc/audit-2.4.1/lspp.rules > /usr/share/doc/audit-2.4.1/nispom.rules > /usr/share/doc/audit-2.4.1/stig.rules > These files already have example rules to do probably everything you're trying to do. In newer versions, e.g., in Fedora, it gets even fancier: ~]# ls /usr/share/doc/audit/rules/ > 10-base-config.rules 32-power-abuse.rules > 10-no-audit.rules 40-local.rules > 11-loginuid.rules 41-containers.rules > 12-cont-fail.rules 42-injection.rules > 12-ignore-error.rules 43-module-load.rules > 20-dont-audit.rules 70-einval.rules > 21-no32bit.rules 71-networking.rules > 22-ignore-chrony.rules 99-finalize.rules > 30-nispom.rules Makefile > 30-pci-dss-v31.rules Makefile.am > 30-stig.rules Makefile.in > 31-privileged.rules README-rules > These are also all well-documented examples. I think if you look through those, you'll find everything you're looking for. warron.french wrote: > For these I would have used a watch (*-w*) rule and set the -p flags to *r, > w* or *a* as shown above. From what I understand though, correct me if I > am wrong Steve, we should be getting away from the watch rules and move > towards Syscalls and using *-F path=/path/to/file*, or > *-F path=/path/to/several_files/* -- is this correct, both for RHEL6 > and RHEL7? > No. The simple -w syntax isn't going anywhere. My understanding: there's no performance hit for adding additional simple -w rules; whereas, you DO take a performance hit for each additional syscall-auditing rule line. Use watches if you can get away with the restrictive simplicity they offer; use syscall-rules when you need to. warron.french wrote: > Also, I need to audit (Success/Failure) for the following sort of things: > > *Authentications* > Logons > Logoffs > You can see examples of how to handle that in the rules the audit package ships with, e.g., from nispom: ## Audit 1, 1(b) Successful and unsuccessful logons and logoffs. > ## This is covered by patches to login, gdm, and openssh > ## Might also want to watch these files if needing extra information > #-w /var/log/tallylog -p wa -k logins > #-w /var/run/faillock/ -p wa -k logins > #-w /var/log/lastlog -p wa -k logins > #-w /var/log/btmp -p wa -k logins > #-w /var/run/utmp -p wa -k logins > Or from stig: ## (GEN002720-GEN002840: CAT II) (Previously – G100-G106) The SA will > ## configure the auditing system to audit the following events for all > ## users and root: > ## > ## - Logon (unsuccessful and successful) and logout (successful) > ## > ## Handled by pam, sshd, login, and gdm > ## Might also want to watch these files if needing extra information > #-w /var/log/tallylog -p wa -k logins > #-w /var/run/faillock/ -p wa -k logins > #-w /var/log/lastlog -p wa -k logins > > ##- Process and session initiation (unsuccessful and successful) > ## > ## The session initiation is audited by pam without any rules needed. > ## Might also want to watch this file if needing extra information > #-w /var/run/utmp -p wa -k session > #-w /var/log/btmp -p wa -k session > #-w /var/log/wtmp -p wa -k session > warron.french wrote: > > *Writes/downloads to external devices/media* > *Uploads from external devices/media *( > *such as DvD, thumbdrive, etc)* > You can audit mount syscalls, but that's not exactly fun on a modern system. In any case, in stig rules: ##- Export to media (successful) > ## You have to mount media before using it. You must disable all > automounting > ## so that its done manually in order to get the correct user requesting > the > ## export > -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=4294967295 -F > key=export > -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=4294967295 -F > key=export > That said, the above example is assuming root login is disabled (requiring people login as their own user and su/sudo to root) ... but it's something. There was some discussion back in April cross-posted between the linux-audit, linux-usb, and linux-kernel mailing lists (subj: "[RFC] Create an audit record of USB specific details"). I think the usual approach is to just disable stuff from BIOS. I could imagine (as a band-aid) adding udev rules that generate audit events as well but I've never done it. warron.french wrote: > *User & Group* *events* > User: Creation, deletion, Modification, suspending/locking > Group/Role: Creation, deletion, modification > > *Use of Privileged/Special Rights events* (*such as sudo, su, etc..)* > Yep you'll find that in stig, nispom, etc. warron.french wrote: > > *Printing to a print-device* > *Printing to a file* > I would just completely remove CUPS ... or log use of lp/lpr commands. Hope this helps get you on the right track.