puppet module for checking CVE's

[Garrett Honeycutt]

Hello,

Published puppet-module-cve[1] to act as a framework for adding facts
for specific CVE's that tell you if you are vulnerable to them.

Inspiration came after ShellShock where I saw people had written modules
with corresponding facts exclusively for that exploit. Our community
needs a simple module that is easily extended to test for multiple CVE's
instead of managing a bunch of separate modules that each check for one
exploit.

Each CVE has its own flat fact, such as 'cve_2014_6271'.

$ facter -p cve_2014_6271
not_vulnerable

There is a structured fact, 'cve', that returns a list of all tested
CVE's, all vulnerable CVE's, and all CVE's to which you are not vulnerable.

$ facter -p --yaml cve
---
cve:
vulnerable:
- cve_666
tested:
- cve_777
- cve_2014_6271
- cve_666
not_vulnerable:
- cve_777
- cve_2014_6271

By default the module is quiet, though you can enable the ability to use
notify{} to alert you to which CVE's you are vulnerable.

Looking forward to your help in adding facts to check for more exploits.

[1] - https://github.com/ghoneycutt/puppet-module-cve

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[Felix Frank]

Hi Garrett,

cool idea. I think it could use a dial to explicitly whitelist the facts
that I want to be populated. Deploying an ever growing range of
(sometimes expensive) checks to all agents, all of which will forever
return false after patching, is not a merry perspective.

What do you think?

Cheers,
Felix

[Jeremy T. Bouse]

Granted I haven't completed taking a good look at the code yet, but to
address Felix's concerns. What about a method of caching successful (ie:
non-vulnerable) CVE fact results for an administratively configured
time? This could limit the number of facts that have to run through
their logic to verify on each run but also allow the administrator to
configure this cache to expire at some point in time to re-validate
everything to ensure a regression hasn't occurred.

I do agree with Garrett that a common framework to identify these
vulnerabilities and be able to respond quickly is both needed and a very
valuable framework to have in place. Fits nicely with being able to use
your run reports for auditing and with PuppetDB very easy to query and
determine risk assessment of your environment quickly.

[Garrett Honeycutt]

Hi Felix,

I was thinking of that though my approach was to use a blacklist to
disable specific facts. That way we go with least surprise so that the
default would be to check for everything if you include the class.
Hopefully folks would only blacklist expensive facts that they are
confident in and not all cve facts after they patch, as the exploit
could reappear in their environment.

To that end, I could create a define that you pass the checks to
blacklist which could be defined in Hiera. On the first puppet run, all
facts would be synced and executed, then puppet would blacklist whatever
you defined, and then on subsequent runs the facts would be skipped.

Something like this in Hiera

cve::blacklisted:
- cve_666
- cve_777


We could check if a file exists in a directory and if so, skip the fact.

Suggest using /usr/local/etc/cve/<fact_name>

What do you think?

[Garrett Honeycutt]

Hi Jeremy,

Thanks for taking a look at this project. As far as I can tell, Facter
does not currently support any caching mechanism between Facter runs.
This could be worked around by adding that logic to these facts in
different ways, such as creating files and checking for their mtime,
though this sounds like a lot of over engineering to me and would make
the checks overly complex.

I believe that the blacklist solves your use case, since you can disable
facts through that mechanism and if you want to check them again, you
either modify Hiera and do a Puppet run or just delete the files to the
corresponding CVE's from the blacklist directory.

[Felix Frank]

On 10/11/2014 02:22 AM, Garrett Honeycutt wrote:

We could check if a file exists in a directory and if so, skip the fact.

Suggest using /usr/local/etc/cve/<fact_name>

What do you think?

Sure, some thing in the file system.

I suggest to not hard code locations. This should be a parameter.

Cheers,
Felix

[Trevor Vaughan]

Would it be possible to side-load this into PuppetDB?

For instance, instead of running the full list of checks with every run of puppet, have a cron job (or something) that runs the list and feeds the data directly into PuppetDB for the node.

That would take the pressure off of each Puppet run but still make the data available.

A nifty MCollective plugin for triggering full runs or targeting specific CVE regexes would be handy for catching things like Shellshock.

For skipping facts, why not use a JSON/YAML file?

Trevor

--
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/543AEFAB.1070906%40Alumni.TU-Berlin.de.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Garrett Honeycutt]

> --
> 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

> <mailto:puppet-users...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/543AEFAB.1070906%40Alumni.TU-Berlin.de

> <https://groups.google.com/d/msgid/puppet-users/543AEFAB.1070906%40Alumni.TU-Berlin.de?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

Hi Felix,

I agree this should be configurable, though I'm not sure the best way to
go about that. Facts do not take parameters, so I'm not sure what you
mean by that.

[Garrett Honeycutt]

On 10/13/14 8:59 AM, Trevor Vaughan wrote:
> Would it be possible to side-load this into PuppetDB?
>
> For instance, instead of running the full list of checks with every run
> of puppet, have a cron job (or something) that runs the list and feeds
> the data directly into PuppetDB for the node.
>
> That would take the pressure off of each Puppet run but still make the
> data available.
>
> A nifty MCollective plugin for triggering full runs or targeting
> specific CVE regexes would be handy for catching things like Shellshock.
>
> For skipping facts, why not use a JSON/YAML file?
>
> Trevor
>

Hi Trevor,

Goal is to use facts so vulnerabilities could be determined without
Puppet while also working with Puppet and its ecosystem - PuppetDB and
MCollective.

Good idea on skipping facts using structured data. While that is easy on
the fact side to implement in ruby, it seems easier to implement from
puppet using either file{} or file_line{} as I want to maintain the
ability to specify an array of facts to skip through Hiera.

BTW: Could really use help adding code to check for more CVE's :)

[Felix Frank]

On 10/13/2014 06:36 PM, Garrett Honeycutt wrote:
> Hi Felix,
>
> I agree this should be configurable, though I'm not sure the best way to
> go about that. Facts do not take parameters, so I'm not sure what you
> mean by that.
>
> Best regards,
> -g

Good point. You *could* manage an external fact through a file resource
I suppose. Not pretty but effective :)

Cheers,
Felix

[Trevor Vaughan]

Unfortunately, I very much share Felix's fear in getting swamped by facts. I mean, there are *thousands* of CVEs.

Good goal though, I'll have to think about this.

Trevor

--
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/543C00CE.1000301%40garretthoneycutt.com.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 10/13/2014 09:23 PM, Trevor Vaughan wrote:
> Unfortunately, I very much share Felix's fear in getting swamped by
> facts. I mean, there are *thousands* of CVEs.

Yeah, but then...

> > Would it be possible to side-load this into PuppetDB?

...this made me think of blackjack. And hookers ;-)

But it could be a cool device indeed.

Cheers,
Felix

[Thomas Bendler]

Question is the goal of the factor output. From my point of view, only CVEs not implemented in the system are relevant (i.e. for reporting). CVEs already implemented are not really from interest to me. So if the standard behavior is, only show facts with CVEs not implemented yet and show all CVEs only if configured, than there shouldn't be to much facts.

More important is the question how to get the CVEs into the system without to much manual interaction. I think it could be an idea to check if this could be generated from openscap.

Regards Thomas

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

For more options, visit https://groups.google.com/d/optout.

--
Linux ... enjoy the ride!