CIS Security Benchmark being applied with puppet.

579 views
Skip to first unread message

Leah

unread,
May 8, 2008, 11:28:05 AM5/8/08
to Puppet Users
I have been tasked with applying the CIS Security Benchmark
(www.cisecurity.com) to our RHEL4 servers to make sure they are
secure. If someone would like to look at the pdf of the benchmark and
is having trouble getting it from the website, let me know and I can
send the pdf. I have decided to try to use puppet to implement this
as previously, I have just run the scripts on the system during start
up but am looking at puppet to make sure the settings are kept.

I have been reading about puppet and playing with some simple
configuration stuff, but I am unsure of how to implement a few things
in the template in puppet. I have no ruby experience so at the
moment, I am unable to just customize puppet. I would like to hear if
anyone has suggestions on how to implement some of the things I need
to do.

There are a couple things I have puzzled over:

1) In the template, it wants fstab to be altered with nodev options
for all ext2 and ext3 partitions and nodev,nosuid for removable
media. I could of course manually create an fstab file, but since
each machine could potentially have a different setup for disks, this
seems like a hassle, but adding these options to the existing file
seems like a valid option. It seems like doing a simple reading of
the file and rewriting it is the best option, but I'm not clear how to
do this. I've also seen some modules on autofs, but that seems to
only be about adding lines, not changing the existing fstab.

2) A bunch of the sections are verify questions. Make sure that world
writeable directories have their sticky bit set. Make sure that no
user has a blank password. I have not found a good way to search that
a file with bad permissions has not crept up on me. In the benchmark,
it uses for loops and runs find commands, but trying to just cut and
paste this into an exec didn't work. I may have not done it right,
but it didn't seem elegant enough to force it to work. I have thought
about if you put the settings for this across the board, you don't
have to worry about something having the wrong permissions, but a
catch-all seems a little problematic.

I would love to hear if anyone has tried to implement this with
puppet. If anyone has suggestions as to ways to make things work
within the current framework. I'm open to ideas and am just looking
for thoughts. Any solution is probably a good one as I have barely
started so I'm not set in an approach.

Thanks for any help,

Leah

Trevor Vaughan

unread,
May 8, 2008, 8:24:47 PM5/8/08
to puppet...@googlegroups.com
Leah,

These are my suggestions (inline):

On Thu, May 8, 2008 at 11:28 AM, Leah <leah...@gmail.com> wrote:
>
> I have been tasked with applying the CIS Security Benchmark
> (www.cisecurity.com) to our RHEL4 servers to make sure they are
> secure. If someone would like to look at the pdf of the benchmark and
> is having trouble getting it from the website, let me know and I can
> send the pdf. I have decided to try to use puppet to implement this
> as previously, I have just run the scripts on the system during start
> up but am looking at puppet to make sure the settings are kept.
>
> I have been reading about puppet and playing with some simple
> configuration stuff, but I am unsure of how to implement a few things
> in the template in puppet. I have no ruby experience so at the
> moment, I am unable to just customize puppet. I would like to hear if
> anyone has suggestions on how to implement some of the things I need
> to do.
>
> There are a couple things I have puzzled over:
>
> 1) In the template, it wants fstab to be altered with nodev options
> for all ext2 and ext3 partitions and nodev,nosuid for removable
> media. I could of course manually create an fstab file, but since
> each machine could potentially have a different setup for disks, this
> seems like a hassle, but adding these options to the existing file
> seems like a valid option. It seems like doing a simple reading of
> the file and rewriting it is the best option, but I'm not clear how to
> do this. I've also seen some modules on autofs, but that seems to
> only be about adding lines, not changing the existing fstab.
>

Set up an fstab for every system type. Replace the fstabs when the
checksums change and make a reboot exec depend on the modification of
the fstab. Note that this is *extremely* dangerous as you may either
kill your fstab or reboot an operational system at random times.

> 2) A bunch of the sections are verify questions. Make sure that world
> writeable directories have their sticky bit set. Make sure that no
> user has a blank password. I have not found a good way to search that
> a file with bad permissions has not crept up on me. In the benchmark,
> it uses for loops and runs find commands, but trying to just cut and
> paste this into an exec didn't work. I may have not done it right,
> but it didn't seem elegant enough to force it to work. I have thought
> about if you put the settings for this across the board, you don't
> have to worry about something having the wrong permissions, but a
> catch-all seems a little problematic.
>

Create cron scripts for /etc/cron.<whatever> and make sure they're
kept up to date with Puppet. Make sure you run the entire system ones
as little as possible since they'll bring your system to its knees due
to the I/O requirements. Nice them down to the lowest level.

> I would love to hear if anyone has tried to implement this with
> puppet. If anyone has suggestions as to ways to make things work
> within the current framework. I'm open to ideas and am just looking
> for thoughts. Any solution is probably a good one as I have barely
> started so I'm not set in an approach.
>
> Thanks for any help,
>
> Leah
> >
>

Good luck,

Trevor

Evan Hisey

unread,
May 8, 2008, 11:54:26 PM5/8/08
to puppet...@googlegroups.com
On Thu, May 8, 2008 at 10:28 AM, Leah <leah...@gmail.com> wrote:
>
> I have been tasked with applying the CIS Security Benchmark
> (www.cisecurity.com) to our RHEL4 servers to make sure they are
> secure. If someone would like to look at the pdf of the benchmark and
> is having trouble getting it from the website, let me know and I can
> send the pdf. I have decided to try to use puppet to implement this
> as previously, I have just run the scripts on the system during start
> up but am looking at puppet to make sure the settings are kept.
I have glanced over the Benchmark texts. A large chunk of the
Benchmarks are really out side of the scope of puppet and more in line
with something like AIDE. Use a kickstar and post install script to
set the a new system just eh way you want it. Use puppet to keep AIDE
up to date and late AIDE do the heavylifting on keeping track of
permissions changes. That would be my approach. That way each tool
does what it is best at.

Evan

Al @ Lab42

unread,
May 9, 2008, 4:06:45 AM5/9/08
to Puppet Users
My cents:

On 8 Mag, 17:28, Leah <leahf...@gmail.com> wrote:
> There are a couple things I have puzzled over:
>
> 1) In the template, it wants fstab to be altered with nodev options
> for all ext2 and ext3 partitions and nodev,nosuid for removable
> media. I could of course manually create an fstab file, but since
> each machine could potentially have a different setup for disks, this
> seems like a hassle, but adding these options to the existing file
> seems like a valid option. It seems like doing a simple reading of
> the file and rewriting it is the best option, but I'm not clear how to
> do this. I've also seen some modules on autofs, but that seems to
> only be about adding lines, not changing the existing fstab.

You can manage fstab entries with the Mount native type:
http://reductivelabs.com/trac/puppet/wiki/TypeReference#mount
There you can define the mount options you want.
No need to provide the fstab file via puppet for the various hosts
(dangerous and scales badly).

> 2) A bunch of the sections are verify questions. Make sure that world
> writeable directories have their sticky bit set. Make sure that no
> user has a blank password. I have not found a good way to search that
> a file with bad permissions has not crept up on me. In the benchmark,
> it uses for loops and runs find commands, but trying to just cut and
> paste this into an exec didn't work. I may have not done it right,
> but it didn't seem elegant enough to force it to work. I have thought
> about if you put the settings for this across the board, you don't
> have to worry about something having the wrong permissions, but a
> catch-all seems a little problematic.

For specific files and dirs you can set and verify that they have
correct permissions with the file
native type (of course you should declare in puppet manifests all the
files/dirs for which you want to have defined permissions, so it
doesn't apply for any arbitrary file or directory).
If other checks require more or less compley scripts, you can place
them in files that you provide and then execute from puppet.

jtimberman

unread,
May 13, 2008, 1:43:12 AM5/13/08
to Puppet Users
Leah,

Our security standards are based off the CIS Security Benchmark for
RHEL 5. I have been working when I have time to release the module to
the Puppet community. My goal is to get a configuration that scores as
high as possible (some things Puppet just isn't appropriate for, so
those won't pass) with the benchmark tool itself.

While my boss approved this project, it has taken lower priority on my
projects list to some other things we're implementing.

I will make a more formal announcement when the module is available.

On May 8, 9:28 am, Leah <leahf...@gmail.com> wrote:
> There are a couple things I have puzzled over:
>
> 1) In the template, it wants fstab to be altered with nodev options
> for all ext2 and ext3 partitions and nodev,nosuid for removable
> media.

This is one of the things that Puppet really doesn't handle very well.
It can do some simple mount points, sure, but given the sheer
complexity of differing storage systems - there's two ways to handle
multipathing with RDAC based storage, for example - I don't think
storage management is appropriate for Puppet. We're not actually using
those particular options because the hassle of implementing the change
to every filesystem is not worth the [somewhat minor] gain in
security.

I'll reread the benchmark, but I don't recall these items being
particularly useful. In other words, if you're implementing [almost]
everything else, this won't have a large impact on your overall
security posture.

> 2) A bunch of the sections are verify questions. Make sure that world
> writeable directories have their sticky bit set. Make sure that no
> user has a blank password. I have not found a good way to search that
> a file with bad permissions has not crept up on me. In the benchmark,
> it uses for loops and runs find commands, but trying to just cut and
> paste this into an exec didn't work. I may have not done it right,
> but it didn't seem elegant enough to force it to work. I have thought
> about if you put the settings for this across the board, you don't
> have to worry about something having the wrong permissions, but a
> catch-all seems a little problematic.

These are more or less manual checks you'll do as a part of regular
maintenance and monitoring. I would implement these parts in puppet by
pushing out a script bundle (via wget tarball or yum, or whatever) and
setting up a cron job to run the script(s), sending an email with
results.

Overall the benchmarks are suggestions, and not a defacto policy, of
course. Definitely a good starting point to assess your current
security posture. Your organizations other policies and standards must
be considered, as well as any industry and legal standards that may
apply (SOX, PCI, State of Kentucky or whereever).

-joshua

Eric Eisenhart

unread,
May 15, 2008, 1:53:43 PM5/15/08
to puppet...@googlegroups.com
Already some good comments and suggestions on this thread.

We have internal security standards some of which I believe were based
on the CIS Security Benchmark, and I have a puppet module that
references (in comments) some of that document, though some is just
includes of stuff handled in other modules (correct time: see ntp
module). Makes for nice documentation; just gave a copy to a security
auditor yesterday as our "hardening procedure" yesterday, in fact.

On May 8, 2008, at 8:28 AM, Leah wrote:
> 2) A bunch of the sections are verify questions. Make sure that world
> writeable directories have their sticky bit set. Make sure that no
> user has a blank password. I have not found a good way to search that
> a file with bad permissions has not crept up on me. In the benchmark,
> it uses for loops and runs find commands, but trying to just cut and
> paste this into an exec didn't work. I may have not done it right,
> but it didn't seem elegant enough to force it to work. I have thought
> about if you put the settings for this across the board, you don't
> have to worry about something having the wrong permissions, but a
> catch-all seems a little problematic.


Our long-term plan is basically to write a tool that runs at some
interval (nightly?) and updates our central system inventory DB with
results of the automatic "audit" for most of those kinds of things.

Personally, I'd avoid any filesystem-wide finds in puppet Exec rules;
you want to try to keep things reasonably swift. Set up a cron job
that runs nightly instead.

However, I was brave (stupid?) enough to implement one of those things
you mention in a puppet rule:

# "Make sure all accounts have a non-empty, non-default password."
# Note: doesn't check for non-default passwords
replace {
"no empty passwords in /etc/shadow":
file => "/etc/shadow",
pattern => "^([^:]+)::",
replacement => $operatingsystem ? { # proper syntax depends a
little on OS
"redhat" => "\$1:!!:",
"solaris" => "\$1:NP:",
default => "\$1:*:",
}
}

The "replace" define is from here: http://reductivelabs.com/trac/puppet/wiki/Recipes/SimpleText

--
Eric Eisenhart <eric.ei...@sonoma.edu>
Lead Unix/Linux System Administrator
1.707.664.3099
Sonoma State University, Information Technology
Jabber/XMPP: eise...@jabber.sonoma.edu
AIM: ericeisenhart

Reply all
Reply to author
Forward
0 new messages