Any pointers to RHEL7 CIS hardening usig puppet

Ash26

unread,

Feb 9, 2015, 9:57:57 AM2/9/15

to puppet...@googlegroups.com

arildjensen-cis seems not to have worked for RHEL7

Joseph Holland

unread,

Mar 30, 2015, 2:07:16 PM3/30/15

to puppet...@googlegroups.com

Hi Ash26,

Did you manage to get this working in the end or have you figured out another way to implement the CIS benchmarks in some automated fashion?

Thanks,

Joe.

Dan White

unread,

Mar 30, 2015, 2:41:36 PM3/30/15

to puppet...@googlegroups.com

<Just my opinion>
I believe that making a module out of the CIS Hardening Guidelines is the wrong approach.
I implemented RHEL 5 and RHEL 6 hardening throughout my catalog.
Specific example: Guidelines for ssh_config and sshd_config are in the ssh moduile.
</Just my opinion>

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5cbbbc24-70cb-4db9-b6bb-5c527f70f92c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Peter Pickford

unread,

Mar 30, 2015, 4:10:42 PM3/30/15

to puppet...@googlegroups.com

Hi Dan,

Could you expand on why "making a module out of the CIS Hardening Guidelines is the wrong approach".

It seems like a good option when the likes of PCI DSS suggest implementing industry standards.

Are you referring to the conflicts you end up with when using more specific, and usually more appropriate to the task at hand, modules (ssh module deals with ssh and cis also tries to manage ssh).

Last time I tried this I recall having to modify and disable some of the CISmodule.

I did end up with systems that proved easy to demonstrate complied with the CIS guidelines.

Is there a good way to combine cross cutting concerns such as implement a policy of standardizing on CIS Hardening Guidelines and wishing to use/resuse more specific/standard/appropriate modules for each component?

Thanks

Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/63abe2dd-d338-4448-afc3-29ea481f3e97%40me.com.

Dan White

unread,

Mar 30, 2015, 5:13:49 PM3/30/15

to puppet...@googlegroups.com

I will reply to this in detail later today when I have time to gather my references.
I did not want you to think I was ignoring you.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKx2DRYPx%2BVwX%3DPBah2mgS367jQFbFjsHPA9KO5KiZ34p1knyQ%40mail.gmail.com.

Christopher Wood

unread,

Mar 30, 2015, 8:14:14 PM3/30/15

to puppet...@googlegroups.com

On Mon, Mar 30, 2015 at 09:10:03AM -0700, Peter Pickford wrote:
> Hi Dan,
> Could you expand on why "making a module out of the CIS Hardening
> Guidelines is the wrong approach".

Not sure what Dan will say and I haven't done it myself. However I have watched another team here produce a hardening module which reaches into all sorts of places and applies all sorts of resources. After watching their experience I would not willingly do that myself.

> It seems like a good option when the likes of PCI
> DSS suggest implementing industry standards.
> Are you referring to the conflicts you end up with when using more
> specific, and usually more appropriate to the task at hand, modules (ssh
> module deals with ssh and cis also tries to manage ssh).

Don't forget the dependency loops. There can be many fun dependency loops when managing related resources using different modules. This goes double when you have the obvious collector/chaining relationships like apt/yum before packages, packages before mounts, mounts before "special" execs, and so on. A shim'ed-in dependency can be difficult to untangle.

It's also not terribly obvious where the problem is when your resource keeps apply because there's another resource in another module changing it (file_line vs file revert fight sort of thing).

> Last time I tried this I recall having to modify and disable some of the
> CISmodule.
> I did end up with systems that proved easy to demonstrate complied with
> the CIS guidelines.
> Is there a good way to combine cross cutting concerns such as implement a
> policy of standardizing on CIS Hardening Guidelines and wishing to
> use/resuse more specific/standard/appropriate modules for each component?

I suspect that the most generic puppet modules were not built with CIS/PCI/etc. paranoiac hardening in mind. (Grep the manifests for 'mode' to illustrate this, blink at all the o+r.) If you want hardening in the standard modules maybe the authors will accept patches with $enablehardening type of class parameters toggling things?

> Thanks
> Peter

> On 30 March 2015 at 07:41, Dan White <[1]d_e_...@icloud.com> wrote:
>
> <Just my opinion>
> I believe that making a module out of the CIS Hardening Guidelines is
> the wrong approach.
> I implemented RHEL 5 and RHEL 6 hardening throughout my catalog.
> Specific example: Guidelines for ssh_config and sshd_config are in the
> ssh moduile.
> </Just my opinion>
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes)
>

> On Mar 30, 2015, at 10:07 AM, Joseph Holland <[2]j0ey...@gmail.com>

> wrote:
>
> Hi Ash26,
> Did you manage to get this working in the end or have you figured out
> another way to implement the CIS benchmarks in some automated fashion?
> Thanks,
> Joe.
>
> On Monday, February 9, 2015 at 9:57:57 AM UTC, Ash26 wrote:
>
> arildjensen-cis seems not to have worked for RHEL7
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [3]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [4]https://groups.google.com/d/msgid/puppet-users/5cbbbc24-70cb-4db9-b6bb-5c527f70f92c%40googlegroups.com.
> For more options, visit [5]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [6]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [7]https://groups.google.com/d/msgid/puppet-users/63abe2dd-d338-4448-afc3-29ea481f3e97%40me.com.
> For more options, visit [8]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [9]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

Dan White

unread,

Mar 31, 2015, 2:35:19 AM3/31/15

to Puppet Users Mailing List

Chris, you make some good points, so I will respond here rather than earlier in the thread.

The CIS Benchmarks are guidelines rather than rules. Quoting the overview:
"This document, …, provides prescriptive guidance for establishing a secure configuration posture for Red Hat Enterprise Linux (RHEL) version 7.0 running on x86 and x64 platforms.”

As I originally stated, I believe that a “CIS Hardening Module” is the wrong approach. The approach I used was to understand the CIS document and apply it, as appropriate, throughout the Puppet catalog.

I believe this is not like implementing an individual service because it touches the entire operating system.

In my workplace, we do not follow all the guidelines as some of them would prevent us from doing our work -- specific example: Section 3.11 Remove HTTP Server. How do you run a web server without HTTP ? If you read more carefully, it says to delete the HTTP packages unless there is a need to run the system as a web server.

In my opinion, you cannot blindly convert this document into a Puppet module.

The arildjensen-cis module (I think) turns many of the scored “rules” into cryptically named facter-type-facts (? “f0000” thru “f0022" ?). I created facts for my hardening implementation, but they are clearly named (like “duplicate_user_name”).

The module’s classes are also cryptically named and (IMHO unnecessarily) multi-level with no references to the individual CIS guideline it applies to.

In the code I wrote, each CIS paragraph is referenced. I did this for the security group’s ease of verification. I can do a recursive grep for “CIS” on my Puppet Master and produce a list to show that every paragraph is being addressed. Rather than using the CIS document exactly, we use it as a beginning and produce a local document that walks down each “rule” in the CIS, recording which ones we choose NOT to follow and the necessary mitigation.

Most of the guideline “rules” can be implemented with a single Puppet resource, but not every rule is for every environment.

I kinda like Chris’s suggestion for the $enablehardening parameter, but I do not know how much cooperation you will get on that idea.

To sum up my point of view: (preface this whole block with “I believe…/I think…/IMHO…”)

Puppet-izing the CIS Hardening Guidelines should be done throughout the entire catalog as necessary for one’s environment and system requirements. A security audit should be an easy thing if all the code bits are clearly referenced by paragraph.

DISCLAIMER: This is my opinion as an experienced Puppet-using systems engineer/administrator. I do not claim to be 100% correct. I do make mistakes and my opinions sometimes go way out in left-center field.

I welcome discussion and feedback on this topic. Maybe we can collectively figure it out.

Bill Waterson (Calvin & Hobbes)

Peter Pickford

unread,

Mar 31, 2015, 6:46:27 AM3/31/15

to puppet...@googlegroups.com

Hi Dan, Chris,

Many thanks for taking the time to respond, some very useful ideas to ponder.

Apologies if this is a bit waffley and repeats itself.

Dan's approach is more elegant in the sense that it implements just what is required, but makes me uncomfortable because it distributes hardening implementation throughout all of the code base.

Using a hardening module is somewhat elegant in the sense that the hardening is 'mostly' in one place, but it makes me uncomfortable that many other modules are affected, not all the hardening can remain in the hardening module if other modules manage conflicting resources, and conflicts can be problematic to diagnose and resolve, it doesn't seem too follow the puppet way of doing things.

My experience is that using a hardening module was a pragmatic way to take advantage of existing code that implements an industry standard hardening guideline, especially without an extensive pre-existing code base and it was easier to communicate that hardening was being enforced.

Agreed -- the CIS Hardening guidelines should not be applied verbatim (as the individual sections don't always apply to the business's use of the system). Each item should be considered and applied to each system as appropriate. There may also be site standards to take into account that can add or subtract hardening requirements.

If you go down the path of using a module specific to hardening....

The implementation of hardening guidelines via an independent module affects many other generic modules and may well cause conflicts.

Resolving these conflicts involves changing either the hardening module or the generic module (assuming you can identify the conflict or lack of convergence). If you have to change the generic module anyway perhaps that should be where the hardening code should be implemented rather than attempting to have a separate module to implement the hardening.

However some of the CIS guidelines don't have a corresponding generic module (at least in the code base I was working on) so the hardening module provides a starting point.

I remember the f000 and c000 things now -- quite a PITA to find and trace the relationships when there are problems, I didn't enjoy that one bit.

I liked the idea of having a cis::el6all include classes for each guideline paragraph, it provides a reference for which paragraphs of the hardening guide are being implemented. The use of sequential numbers for the classes that actually implement the hardening (called from cis:: classes named after the corresponding document section) makes tracing problematic, I think there are couple of cases where they are reused -- still meaningful names would probably help. I don't see why the facts and there corresponding script fragments cant have meaningful names.

If I recall correctly I commented out some of the classes in the cis::el6all class and added a description of where this functionality was implemented in a generic module (ssh, ntp etc). If I end up having to do this again and go down this path I will comment the changed ssh module etc with the CIS section too (should of thought of that before).

I like the idea of having most of the hardening implementation in one place rather than scattered over the whole code base.

The way puppet works doesn't lend itself to taking a cross cutting concern like hardening and putting it in an independent module -- at least not without significant issues -- so its fair to argue it misappropriate use of puppet.

It seems to me that hardening is a distinct aspect and in some circumstances I would like to see all the hardening things and none of the rest of the details, however I'm unaware of any support for a module implementing specific functionality (say ssh) having part of is implementation overideable by a class in a foreign module (say cis hardening).

If you go down the path of implementing hardening directly in the code base without a module then apart from a text search there seems no way of gathering all of the hardening specifics together.

My experience of using arildjensen-cis was that there was quite a bit of breakage that had to be resolved, but that breakage identified things that were managed but non-compliant. Some of the arildjensen-cis classes were not relevant and were disabled before attempting the first run.

I found that arildjensen-cis was a good starting point and covered quite a number sections of the guide, diagnosing problems was not always straight forward and the end solution had most but not all the hardening in one place.

I also subscribe to Dan's disclaimer above, this is just my experience and opinions however code was written systems configured and audits passed.

The $enablehardening idea sounds interesting but don't expect there would be much uptake unless puppetlabs found some way to mandate it or something similar.

I feel like hardening should override other modules resources by some magic, or there should be some way to compose a resource from unrelated modules, but its not the way puppet works and I suspect it would be extremely unworkable. I feel something is missing but I don't have a concrete suggestion of what form a solution should take.

Dan, did you present the security team with the comments in puppet code containing the string CIS or extract the CIS relevant code for their inspection?

Were there new modules that implemented some of the hardening sections and if so did you use module names that describe what they implement along with comments referencing the security guidelines?

On one hand pre-existing code to perform hardening can get you going quicker but on the other hand perhaps Dan's approach is better in the long run and gathering the all hardening information from across the code base is sufficient.

Do you have the code base or some fragments on git-hub, I guess not as security related code is usually quite sensitive but if you don't ask:)

Thanks

Peter

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1FE02271-FC6B-4A2A-B936-329AC7D779ED%40icloud.com.

Brad Knowles

unread,

Mar 31, 2015, 7:06:59 AM3/31/15

to puppet...@googlegroups.com, Brad Knowles

On Mar 30, 2015, at 9:34 PM, Dan White <d_e_...@icloud.com> wrote:

> To sum up my point of view: (preface this whole block with “I believe…/I think…/IMHO…”)
> Puppet-izing the CIS Hardening Guidelines should be done throughout the entire catalog as necessary for one’s environment and system requirements. A security audit should be an easy thing if all the code bits are clearly referenced by paragraph.

I’ve actually done hardening on three separate projects with tools like Chef (one) and Puppet (two, including my current one). I’ve also been a professional Unix system administrator since 1989 (got my start in the basement of the Pentagon), and I’ve been involved in a multitude of security projects over the decades (some classified ones, and plenty of unclassified ones). I’ve worked in a variety of sectors, but mostly Internet/tech-related.

I’m not as experienced with Puppet as I am with Chef, but I would agree with Dan's assessment.

Fundamentally, security is not something you can bolt-on as an after-thought. It has to be baked into all of your processes and procedures as well as all your tools. Any other approach is likely to lead to “ensure => madness”.

On the current project I’m working on, we are using the Roles/Profiles/Component module methodology, and we’re trying to minimize the number of component modules that we have to build, so we choose to make maximum use of publicly available modules from places like puppetforge. We also have provided to us lengthy security standards based on the ones from CIS, among other sources. Unfortunately, we have already run into problems with various Component modules pushing out configuration files (and other things) that didn’t meet our security requirements and we didn’t want to get into a constant battle of which module would win.

So, we have decided that we will fork any public Component modules that we use and make necessary modifications to them. However, we are going to do this in a way that the necessary changes are parameterized and minimized, and then hopefully we will get approval to contribute this code back to the community. Among other things, we really don’t want to have to continue to maintain our forks.

At that point, we can keep most of our work in the Profile modules that call the Component modules, and we get both the functionality that we require as well as the security that we require.

I see no viable alternative to this approach.

--
Brad Knowles <br...@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

signature.asc

Dan White

unread,

Mar 31, 2015, 1:05:46 PM3/31/15

to puppet...@googlegroups.com

Nice discussion we have going here. Comments/responses inline

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)

On Mar 31, 2015, at 02:46 AM, Peter Pickford <pe...@netremedies.ca> wrote:

Hi Dan, Chris,

Many thanks for taking the time to respond, some very useful ideas to ponder.

Apologies if this is a bit waffley and repeats itself.

Dan's approach is more elegant in the sense that it implements just what is required, but makes me uncomfortable because it distributes hardening implementation throughout all of the code base.

Using a hardening module is somewhat elegant in the sense that the hardening is 'mostly' in one place, but it makes me uncomfortable that many other modules are affected, not all the hardening can remain in the hardening module if other modules manage conflicting resources, and conflicts can be problematic to diagnose and resolve, it doesn't seem too follow the puppet way of doing things.

My experience is that using a hardening module was a pragmatic way to take advantage of existing code that implements an industry standard hardening guideline, especially without an extensive pre-existing code base and it was easier to communicate that hardening was being enforced.

Agreed -- the CIS Hardening guidelines should not be applied verbatim (as the individual sections don't always apply to the business's use of the system). Each item should be considered and applied to each system as appropriate. There may also be site standards to take into account that can add or subtract hardening requirements.

If you go down the path of using a module specific to hardening....
The implementation of hardening guidelines via an independent module affects many other generic modules and may well cause conflicts.
Resolving these conflicts involves changing either the hardening module or the generic module (assuming you can identify the conflict or lack of convergence). If you have to change the generic module anyway perhaps that should be where the hardening code should be implemented rather than attempting to have a separate module to implement the hardening.

However some of the CIS guidelines don't have a corresponding generic module (at least in the code base I was working on) so the hardening module provides a starting point.

I remember the f000 and c000 things now -- quite a PITA to find and trace the relationships when there are problems, I didn't enjoy that one bit.

I liked the idea of having a cis::el6all include classes for each guideline paragraph, it provides a reference for which paragraphs of the hardening guide are being implemented. The use of sequential numbers for the classes that actually implement the hardening (called from cis:: classes named after the corresponding document section) makes tracing problematic, I think there are couple of cases where they are reused -- still meaningful names would probably help. I don't see why the facts and there corresponding script fragments cant have meaningful names.

If I recall correctly I commented out some of the classes in the cis::el6all class and added a description of where this functionality was implemented in a generic module (ssh, ntp etc). If I end up having to do this again and go down this path I will comment the changed ssh module etc with the CIS section too (should of thought of that before).

I like the idea of having most of the hardening implementation in one place rather than scattered over the whole code base.

The way puppet works doesn't lend itself to taking a cross cutting concern like hardening and putting it in an independent module -- at least not without significant issues -- so its fair to argue it misappropriate use of puppet.

It seems to me that hardening is a distinct aspect and in some circumstances I would like to see all the hardening things and none of the rest of the details, however I'm unaware of any support for a module implementing specific functionality (say ssh) having part of is implementation overideable by a class in a foreign module (say cis hardening).

If you go down the path of implementing hardening directly in the code base without a module then apart from a text search there seems no way of gathering all of the hardening specifics together.

My "grep -rn CIS" method works very nicely for me, but YMMV

My experience of using arildjensen-cis was that there was quite a bit of breakage that had to be resolved, but that breakage identified things that were managed but non-compliant. Some of the arildjensen-cis classes were not relevant and were disabled before attempting the first run.
I found that arildjensen-cis was a good starting point and covered quite a number sections of the guide, diagnosing problems was not always straight forward and the end solution had most but not all the hardening in one place.

I also subscribe to Dan's disclaimer above, this is just my experience and opinions however code was written systems configured and audits passed.

The $enablehardening idea sounds interesting but don't expect there would be much uptake unless puppetlabs found some way to mandate it or something similar.

I feel like hardening should override other modules resources by some magic, or there should be some way to compose a resource from unrelated modules, but its not the way puppet works and I suspect it would be extremely unworkable. I feel something is missing but I don't have a concrete suggestion of what form a solution should take.

Dan, did you present the security team with the comments in puppet code containing the string CIS or extract the CIS relevant code for their inspection?

A combination. The security folks are not as technical as the could be, so showing them code is a questionable use of time. Where possible without breaking something, I demonstrated how Puppet would either fix or notify something that went against a hardening guideline we chose to follow.

Were there new modules that implemented some of the hardening sections and if so did you use module names that describe what they implement along with comments referencing the security guidelines?

On one hand pre-existing code to perform hardening can get you going quicker but on the other hand perhaps Dan's approach is better in the long run and gathering the all hardening information from across the code base is sufficient.

Do you have the code base or some fragments on git-hub, I guess not as security related code is usually quite sensitive but if you don't ask:)

Great idea. While I may encounter hot water by publishing my classes outright, I believe I am safe posting snippets demonstrating how to implement individual rules or groups of rules. I will try to get a git-repo started by the weekend, but it is Easter weekend and I have some family obligations I cannot (and do not wish to) side-step.

Any requests for a section to start on ?

Thanks

Peter

You are most welcome

Dan

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKx2DRaub4LzY8aUu2CvfLXWSTwgE4fTPovjVmpMEriECzk_qQ%40mail.gmail.com.

Dan White

unread,

Mar 31, 2015, 1:38:43 PM3/31/15

to puppet...@googlegroups.com

Good points, Brad.
I am just getting into the rol-profile-component methodology, but the way you put it makes perfect sense to me.

signature.asc

Reply all

Reply to author

Forward