In the previous blog post we initiated an OpenSCAP assessment with the DISA STIG profile. What we are going to do is use the GUI of scap-workbench to create an Ansible playbook that we can use to remediate the findings on the CentOS 7 system. The requirements to perform this is a Linux system with a GUI. In this blog post I will be using Fedora (my primary OS) to generate the Ansible playbook used to remediate findings.
Note that this should not be done on a production system since the fixes can be invasive, proceed at your own risk.
Generating The Playbook
First, we must install the needed package(s). Open up a terminal and run:
sudo yum install scap-workbench ansible -y
Now lets start the scap-workbench:
This should bring up a window like so:
Change the drop down to the appropriate operating system and click “load content”. For mine I’m using CentOS 7.
Now you will see a fancy tool called SCAP Workbench. We will need to set the profile, so click the drop down and select the profile that applies. For this post I will be using the “DISA STIG for Red Hat Enterprise Linux 7(243)”
As you might have guessed you can run the scan through the SCAP Workbench to produce the same results we did via the command line in the previous blog post. You also have the ability to run the scan against a remote host. Ignore that aspect of the tool for now and click the drop down “Generate remediation role”.
Select “ansible” which will open up a file explorer, save the file to where you know you will be able to find it again.
What just happened?
SCAP Workbench generated a remediation role for Ansible against the DISA STIG profile. If we view the file, we can see exactly what it is doing and will apply when we run the playbook.
Running The Playbook
For the sake of this example I am going to modify the playbook to ignore any errors that are found. If you do not do this the playbook will fail out instead of skipping over any missing files.
Using Vim at the beginning of the file I modified the it to include “ignore_errors: yes” under my “- hosts: all” like so:
Save and quit the file (if using Vim that is :wq)
Now let us create a hosts file that we will use as an inventory. In the same location as your remediation.yml lets create a file called “inventory”.
You can get really advanced with your inventory files, but for this example we are keeping it simple. Add the IP address of the CentOS server you would like to harden.
So now this is what my inventory file looks like, really simple just one line with “192.168.1.39” :
Side note, you are also able to leverage dynamic inventories. For example if you are using AWS and have ec2 instances tagged as something you are able to use the dynamic inventory with the tags instead of specifying IP addresses, more on that here
Now back at the terminal we can execute the playbook. What this command is doing below is telling ansible to use the switch -i which passes a file called “inventory”, –user is run the ssh connection as the user “spencer” , -k which is ask for the ssh password, and -K which is ask for the sudo password, –become which means become root by default (you can become other users but the default is root), and -v for verbose.
ansible-playbook -i inventory --user=spencer -k -K --become remediation.yml -v
You will now see the playbook executing and changing the system. By us making the change to the playbook ignore_errors: yes, it will skip over any problematic errors (which consequently means those mitigation’s won’t be applied).
This playbook will take some time so let it run. Upon completion you should see something like this:
If you login to the system you will be able to validate that everything that has been marked as “changed” has been modified on the system. You will notice that all the hardening paramaters now exist on the system we ran the playbook against.