CIS RHEL6 Security Configuration Benchmark - Salt State

[Sergio Aguilar Guerrero]

Hello All,

I am currently working on a Salt State implementation of the CIS(Center for Internet Security) Red Hat Enterprise Linux 6 Benchmark.

https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_6_Benchmark_v1.1.0.pdf

This is my first salt state and I'm still a beginner with salt. So far I have  been able to implement about 90% of it. 

I am sure this state can be better and that's precisely the point of sharing it with the salt community. 

Here's the link to the git repo https://github.com/chekolyn/cis-saltstack 

If you have any suggestion or ideas to make it better please let me know or better yet send a pull request.

From some testing that I've done, systems where I applied this state are currently passing about 95% of the CIS Unix compliance checks on Tenable Nessus.

I recently saw the release for Salt ver 0.17.0 and I will work to transform this state in to a formula in the near future (after the new salt packages are available to be installed).

Regards,

Sergio Aguilar

 

[Ethan Erchinger]

I think the state looks pretty great, thorough for sure and nicely documented.  I think you'd find it easier to write and to use if you use pillar data for some of the long lists of things, like cis_removed_pkgs or the mount points. If you just setup a list, such as:

cis_pkgs_to_remove:

- httpd

- xinetd

- ...

Then:

 {% for pkg in pillar.get('cis_pkgs_to_remove',[] %}

...

You can then easily comment them out, instead of inserting "keep" statements. Scoping them under the cis_pkgs_to_remove variable keeps from cluttering up the top-level of pillar data as well.

A nice thing that pillar gives you is the ".get()" statement, as used above. For instance, on lines 198-199 you could do something like:

{% if pillar.get('grub_change_password','') and 

pillar.get('grub_md5_password','').startswith("$1") %}

Moreover, you could use config.get(), which will search through pillar, minion config, grains to determine whether a variable is set.

Nice work.

E

[Sergio Aguilar Guerrero]

Hello Ethan,

Thanks a lot for you suggestions.  The use of cis_removed_pkgs list makes a lot of sense to me. I guess I was trying to accommodate for exceptions, but ended up creating something a bit more confusing than it should be.

I will definitely try pillar.get or config.get() it sure looks much better and cleaner than what I currently have. 

I really appreciate your review and I thank your for your time.

Regards,

Sergio

  

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/O3ZjkgkSNmY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jacob Albretsen]

On Friday, October 04, 2013 11:32:01 AM Sergio Aguilar Guerrero wrote:
> Hello All,
>
> I am currently working on a Salt State implementation of the CIS(Center for
> Internet Security) Red Hat Enterprise Linux 6 Benchmark.
> https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_
> 6_Benchmark_v1.1.0.pdf

The states I've written where I am at are based and CIS as well. My final
approach has been to break them up into logical parts (core/selinux,
core/sysctl, etc).

After trying to specify every single thing that should be off and not
installed, I decided it was overkill. My solution was to do a bare bones
kickstart install of CentOS, and from there only add what is needed. All of
my servers have everything in core/ (examples above) and from there, I add
server/apache or whatever application as needed for a specific server.

I will also caution to not blindly trust CIS guidelines. THe RHEL 5.0 version
1.0 had suggestions for bash commands to run for parts in section 9 that
either (a) Outright did not check what it claimed or (b) Worked in say HP-UX,
but had no hope of working in Linux. The Python script I wrote to check those
items has modifications to actually do what CIS suggested. Another example is
I researched what /tmp and /var/tmp are expected to do in Linux (Section
1.1.6), and I opted to not do what CIS suggested and link them. It almost
felt like someone who specialized in UNIX wrote parts of the RHEL guidelines.
I have not had time to look over the latest for RHEL 6 to see if they actually
got someone who knew Red Hat to write the entire thing.

Just my two cents.

[Sergio Aguilar Guerrero]

Hello Jacob,

I really appreciate your input.   I think the benchmark for RHEL6 is much better, it certainly seem like they had a good group of people working together to make it.  

One of the primary goals for this state is for strict compliance situations where you have constant audits to the systems ( at work I  need as many passed checks as I can get). Therefore I have to follow the CIS benchmark to the fullest extent. 

I have thought about dividing the state not into logical parts per say, but into CIS level 1 and CIS level 2 profiles. Currently the state is implementing almost everything.

 

I actually used the same approach as you had, I have kickstart file with the minimum requirements  (this is the way that I make sure that the partition layout is as CIS specifies). I think it would be a good idea to add it to the repo.

In the past I even implemented the full CIS specification with a kickstart file, but you can get out of compliance really easily after you initially create the system, this is one of the primary reasons I created this state. 

Best regards,

Sergio

[Jacob Albretsen]

Indeed each situation is different. I don't get audited on CIS, I get audited
on PCI which requires "a security policy". Although PCI has it's own list of
requirements, and CIS plus extra things I do covers my needs.

I just stopped seeing the need to check for some oddball EPEL ftp server not
being installed and not running on every run of salt. I control all my
servers, so if I didn't install it, it's not there. If it does get installed
without my knowledge, I should be notified about it via my file integrity
monitoring software.

But, I understand stricter guidelines at some places. Been there done that.
I'm just surprised you convinced the powers that be to use Salt. My powers
that be back when I had to use strict CIS policies took 3 - 4 months to
approve of me installing screen, and those of us chanting puppet at the time
were never listened to.

--
Jacob Albretsen
ja...@xmission.com
http://blog.knine.net/

[scoobydooxp]

1.2 is the latest version of the benchmark BTW. 1.3 is due out soon.

https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_6_Benchmark_v1.2.0.pdf

[Sergio Aguilar Guerrero]

Thanks for the info.  I just looked at the change history list and there about 25 changes.  I will incorporate this in the near future.

Sergio

On Tue, Oct 8, 2013 at 12:53 PM, scoobydooxp <ajpr...@gmail.com> wrote:

1.2 is the latest version of the benchmark BTW. 1.3 is due out soon.

https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_6_Benchmark_v1.2.0.pdf

[mike r]

Great work Sergio, this is very helpful

[Peeter U]

Hi
I'm also looking at linux baseline/hardening with Saltstack and so far this is the only source I have found.
Does anybody know of any other projects like this?
Or maybe anybody has experience with any puppet or chef playbooks that are more extensive?

[Colton Myers]

You should check out hubblestack! Christer Edwards and I have been working on a compliance product which includes auditing. We already have most of the CIS checks in.

Hubblestack: https://hubblestack.io

hubblestack/nova: https://github.com/HubbleStack/Nova

--

Colton Myers

@basepi

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peeter U]

Do I understand correctly that HubbleStack is just for reporting and not implementing the needed changes?

[Christer Edwards]

The remediation isn't built into HubbleStack yet, but it is planned.

The idea is that a scan can detect a violation and trigger a state to remediate. Perhaps you could contribute your states to the project and bring us that much closer to supporting that feature? :) We'd love to see more community feedback and contribution. (You can check out our Slack channel from https://hubblestack.io if you'd like to discuss).