Welcome back! If you’re just now joining me, then you’ll want to take a look at the first two days in this little Inspec journey.
- Day 1: Hello World
- Day 2: Command Resource
In Day 2 I told you that the two resources that you’ll use most with Inspec are command and file. The command resource basically reads the output of the command that you give it, and you pass or fail based on that output. And the file resource basically passes or fails based on what the control says the different aspects of that file should or shouldn’t be.
So far I’ve found the simplest file resource to be the content matcher. Today we’re going to do just that. You’re going to write a control that looks for specific text within a file. Easy but mighty.
So do you remember our workflow and windows we need open?
Ingredients
Open these up, and make sure your CentOS vm is up and running.
- Nathen Harvey’s workshop
- InSpec Reference page
- Rubular
- Download the PDF of the CIS CentOS Linux Benchmark
- your text editor
- your command line
Workflow
Even though we are dealing with a file resource this time, the workflow will still be the same. I found that when I follow this workflow exactly, it goes way faster and I make fewer mistakes.
- Go to Harvey’s workshop and look up our control
- Find and read the control in the CIS PDF
- Run the audit command on our command line
- If audit fails, run remediation
- Go to the Inspec Reference page to decide on a resource and matcher to use
- Construct a regex in Rubular
- Finish the control in your text editor
- Test
1. Go to Harvey’s workshop and look up our control
So head over to Nathen Harvey’s workshop, and let’s do the second one since we did the first one last time.
2. Find and read the control in the CIS PDF
Open the CIS CentOS Linux 6 Benchmarks v1.1.0 that you downloaded, then look for our command inside there: 1.2.2. Remember how we need those bits of info to fill in our control?
control "cis-1-2-2" do
impact 1.0
title "1.2.2 Verify that gpgcheck is Globally Activated (Scored)"
desc "The gpgcheck option, found in the main section of the /etc/yum.conf file determines if an RPM package's signature is always checked prior to its installation."
You’re a pro already. Moving right along…
3. Run the audit command on our command line
So the CIS benchmark will tell us the command to run to see if we’re compliant. Let’s run that now:
grep gpgcheck /etc/yum.conf gpgcheck=1
That tells us that gpgcheck
should equal 1
, right? So what if it doesn’t?
4. If audit fails, run remediation
We’ll need to edit the file if the audit failed, so let’s do that by ssh from the command line. Once you’re
in sudo nano /etc/yum.conf
Then add the text, write out Ctrl+O
, and exit Ctrl+X
. Then run the command again to
make sure you fixed the problem.
5. Go to the Inspec Reference page to decide on a resource and matcher to use
I told you already that command
and file
are the most common resources, and I told you already that we’re going to
be doing a file resource today. But how do we know that? Well, simple. The CIS audit wants us to look in a
file
.
Let’s head over to the Inspec Reference page and look at the options in the right sidebar menu.
We want to make sure that content exists within a file right? So we’re going to see if we get a match
for the
content
when we look inside that file
.
6. Construct a regex in Rubular
The audit already gave us a regex, so we don’t need to create one. On to #7.
Update: I’ve since changed my tune on this a bit. Please see this post on Regular Expressions so that you can take care to use the best possible regex when necessary.
7. Finish the control in your text editor
Okay, so you already had the first four lines, and now let’s fill in the rest with the file resource:
control "cis-1-2-2" do
impact 1.0
title "1.2.2 Verify that gpgcheck is Globally Activated (Scored)"
desc "The gpgcheck option, found in the main section of the /etc/yum.conf file determines if an RPM package's signature is always checked prior to its installation."
describe file('/etc/yum.conf') do
its('content') { should match /gpgcheck=1/ }
end
end
8. Test
On your command line navigate to your workshop folder. Now run:
inspec exec test/1_spec.rb -t ssh://username@ipaddress --password 'password'
Again, for the command line newbs like me, test
is the folder you’ve put your file in. username
, ipaddress
,
and password
are for your CentOS vm. (I hope you got that, because I’ll assume you know it next time!)
Hopefully your test passed. If not…back to the drawing board for you.
Now, if you plan to do more, then you’ll hit a snag when you get to 1.5.3, so let me help you out now to save you some frustration. When you’re running your test, use this instead:
inspec exec test/1_spec.rb -t ssh://username@ipaddress --password 'PASSWORD' --sudo-password=PASSWORD --sudo
I ran into controls that I had to have sudo
access to run. So after that I decided just to
run --sudo-password=PASSWORD --sudo
every time.
Concluding Thoughts
I’ve written a lot more of these controls since last time, and each time it gets easier and easier. The first few took me a little while to navigate, and then I got stumped by the sudo issue, but after I got in a groove, each one took me just a minute or two.
As always, if you’d like to look at my GitHub repository, feel free! I’m adding a few controls little by little.
I’d love your feedback, so hit me up on Twitter!
Go to Day 4: Custom Matchers