#OpenSCAP introduction

[virtualizationhowto]

Openscap: Open Source Vulnerability and Compliance Scanner

Openscap: Open Source Vulnerability and Compliance Scanner @vexpert #vmwarecommunities #100daysofhomelab #homelab #OpenSCAPintroduction #OpenSCAPscannerinstallation #SecurityContentAutomationProtocol #Linuxsecurity

Open-source security tools are not only cost-effective, they are also very powerful. OpenSCAP is a robust line of defense in achieving and maintaining system security compliance. It delivers many features, including for the community and enterprise businesses. Table of contentsWhat is OpenSCAP?Diving Deeper into the SCAP Security GuideCustomizing OpenSCAP with Your Own Content FilesOpenSCAP…

[ushf]

F27 rpmdb bug, auditd and augenrules

Saw a similar rpmdb lock bug to this: https://bugzilla.redhat.com/show_bug.cgi?id=918184 Have enabled the audit log to watch out for it in the future.

ush@gargantua ~]$ sudo dnf update [sudo] password for ush: warning: rpmdb: BDB2053 Freeing read locks for locker 0xc24: 12836/139735431249280

The auditd logging system is completely independent of syslog and derivatives http://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ Q: is it now more integrated with journald? PanuMatilainen suggested https://bugzilla.redhat.com/show_bug.cgi?id=918184#c1

# echo "-w /var/lib/rpm/Packages -p war -k rpmdb" >> /etc/audit/audit.rules # systemctl restart auditd.service After that, the next time that something has misbehaved and you get those "freeing read locks ...: /" messages, you can look rpmdb accessing processes by their pid with # ausearch -k rpmdb --pid To identify the troublemaker for sure, the pid of the "freeing read locks" message needs to be matched to those of audit logs. Taking the original message as an example: BDB2053 Freeing read locks for locker 0x1bf4: 4981/140246004406208 Here, the pid of the naughty process who left locks behind is 4981. So to search for the process that caused it, you need to do: # ausearch -k rpmdb --pid 4981

Instead have appended the new audit rule to /etc/audit/rules.d/audit.rules The systemctl restart of the auditd is no longer possible. Use augenrules instead. Do I really need to disable the -a never,task and what is its actual impact on performance?:

[ush@gargantua ~]$ sudo auditctl -l -a never,task [ush@gargantua ~]$ sudo augenrules --load No rules [ush@gargantua ~]$ sudo auditctl -l -a never,task -w /var/lib/rpm/Packages -p rwa -k rpmdb

This seems to be the best reference (is pointed to in the systemd unit) https://github.com/linux-audit/audit-documentation/wiki/SPEC-Writing-Good-Events https://security.stackexchange.com/questions/4629/simple-example-auditd-configuration Seems like the rules should be broken into 3 types in /etc/audit/rules.d/audit.rules (for clarity): CONTROL, FILE/DIRECTORY, SYSCALL (see man audit.rules). Syscall rules should follow the template:

-a action,list -S syscall -F field=value -k keyname

-a {always,never},{task,exit,user,exclude} -S {name or number} -S {othername or number} -F {auid,uid,euid,suid,fsuid,obj_uid,gid,egid,sgid,fsgid,obj_gid} -k $keyname-defined-by-you

Then

aureport --start this-week --key --summary

This related post is interesting in context of how augenrules works by merging all the contents of rules.d https://github.com/OpenSCAP/scap-security-guide/issues/551 This is a good first part of two-part tutorial https://www.tecmint.com/linux-system-auditing-with-auditd-tool-on-centos-rhel/