In part 1 of this series we were introduced to OpenSCAP and the process of running scans via the SCAP workbench. In part 2, we explored concepts and components that define security/vulnerability scans. In this 3rd post we are going to dive into the command line operation.
Let’s get started with oscap.
Installing oscap
In RHEL 7 oscap can be installed with the following command
In part one of the OpenSCAP series we were introduced to the basic usage of the OpenSCAP toolset. In that post we learned how to run a basic scan via the scap-workbench in a desktop environment.
This post will focus on the Content, Profiles, and Targets.
Content
All content will be installed in the directory shown below. The content in this directory will vary based on the installed OS (the content on my Fedora differs from RHEL for example).
/usr/share/xml/scap/ssg/content
The screenshot below contains a list of content installed by default on RHEL 7.
Additional content can be obtained and added to the content directory shown above. For example, NIST content can be downloaded directly from the NIST website. Link below.
OpenSCAP is a standardized compliance solution for Linux. It is comprised of policies (NIST, STIG, etc) and tooling (oscap, scap-workbench) that allow you to scan and evaluate Linux hosts in order to validate their compliance with industry defined standards.
In addition to providing industry standard compliance rules, OpenSCAP also allows administrators to create custom compliance standards using the scap-workbench.
Administrators can then generate remediation files in bash, ansible or puppet.
Let’s get familiar with OpenSCAP below.
Getting Started
Below is an overview of the “Getting Started” workflow. In this workflow we are gonna run through a very simple use-case, scanning your local Fedora workstation.
Install
Choose Policy
Modify/Adjust
Scan
Remediate
In the sections below we will walk through each of these steps in detail.
In this post, I am going to walk you through the process of installing and configuring two- factor SSH authentication via Google Authenticator. My base system is running a fresh install of RHEL 7.2
Installation Steps
The first step on my system was to install autoreconf, automake, and libtool. These packages are required by the bootstrap.sh script that we will need to in a couple more steps.
# yum -y install autoconf automake libtool
Now, we are going to install Git.
#yum -y install git
One more dependency to knock out. Install pam-devel as shown below.
# yum -y install pam-devel
Next, we clone the google-authenticator Git repo. In this example, I am cloning to /root
This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however, then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.
So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.
The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,
Below is my stock /etc/pam.d/system-auth file
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.
[root@ip-172-31-21-28 pam.d]# cat system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so
Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.
Auditd gives you the ability to write your own custom audit rules. This functionality allows an administrator to keep a close eye on system calls, file access, and user behavior. This added functionality is especially useful in environments that are requred to adhear to compliance standards that are above and beyond normal standards. Think PCI.
Once of the simplest rules to add is a watch rule which can be set on files and directories. In the example below we are watching the /etc/passwd file for permission changes (writes and attibute changes specifically). We are creating a custom key to use for organizational purposes.
[root@ip-172-31-21-28 ~]# auditctl -w /etc/passwd -p wa -k edit_watch
Here is a cool one – lets audit all binary executions under /usr/bin.
[root@ip-172-31-21-28 ~]# auditctl -w /usr/bin -p x
Using the -l option you can list your current audit rules, and using the -s option you can see the current status of the auditd subsystem
Auditd is the userland piece of the RHEL audit tool suite. When its up and running, audit messages sent by the kenel will be send to log files that you have configured. By default, only a small and limited number of messages will be picked up by Auditd; these are mostly messages related to authentication and authorization.
Its possible to send audit messages to a syslog. By setting active=yes in /etc/audisp/plugins.d/syslog.conf you can send all your audit messages to syslog. If your system is setup to log to a remote syslog server, then your audit messages will go along for the ride as well. Note that you can also send audit messages to a remote logging server via native audit protocol over TCP. I am not going to go into this option, but I want to make sure that we are aware that it exists.
Looking for Audit Events in All the Wrong Places:
Auditd includes a handy-dandy tool for searching audit logs. Ausearch. You can check out all your current audit log messages using the command below.
[root@ip-172-31-21-28 ~]# ausearch -l
Viewing audit logs in their raw format can be accomplished with the command below
[root@ip-172-31-21-28 ~]# ausearch –raw
The -a option allows you to search by audit event ids
[root@ip-172-31-21-28 ~]# ausearch -a 282
Auditd also includes ausearch, which allows you to get a quick summary of audit events, rather than trying to view massive audit logs. Usage and output shown below.
root@ip-172-31-21-28 ~]# aureport
Summary Report ====================== Range of time in logs: 07/17/2014 10:21:36.438 – 07/17/2014 19:52:49.556 Selected time for report: 07/17/2014 10:21:36 – 07/17/2014 19:52:49.556 Number of changes in configuration: 4 Number of changes to accounts, groups, or roles: 24 Number of logins: 20 Number of failed logins: 4 Number of authentications: 75 Number of failed authentications: 3 Number of users: 3 Number of terminals: 18 Number of host names: 19 Number of executables: 14 Number of files: 0 Number of AVC's: 10 Number of MAC events: 20 Number of failed syscalls: 10 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 244 Number of keys: 0 Number of process IDs: 203 Number of events: 1132
You can also use aureport and ausearch together. Simliar to the powerfull partnership between Batman and Robin, these two tools complement each other in ways that you can only imagine. Check out my sexy bits below.
Summary Report ====================== Range of time in logs: 07/17/2014 10:21:36.438 – 07/17/2014 20:01:01.911 Selected time for report: 07/17/2014 10:21:36 – 07/17/2014 20:01:01.911 Number of changes in configuration: 4 Number of changes to accounts, groups, or roles: 24 Number of logins: 20 Number of failed logins: 4 Number of authentications: 75 Number of failed authentications: 3 Number of users: 3 Number of terminals: 18 Number of host names: 19 Number of executables: 14 Number of files: 0 Number of AVC's: 10 Number of MAC events: 20 Number of failed syscalls: 10 Number of anomaly events: 0 Number of responses to anomaly events: 0 Number of crypto events: 244 Number of keys: 0 Number of process IDs: 205 Number of events: 1144
Want to know another cool tool that is part of auditd? I know, its a lot to take in at one time, but I am sure that you can handle it. Using autrace you can trace and investigate system calls made by a process.
Want to see everything that nslookup is doing? Then run the command below.
