[chef] Re: Re: Re: Auditing file checksums

[Daniel Gutierrez < >]

Hi Lamont,

  Thank you for your thoughtful request! Our goal is to unify all automated infrastructure management with Chef, so we are not really interested in another product like Tripwire as someone suggested, if we wanted that we would stick with Puppet.

We need this for PCI FIM (File Integrity Monitoring) compliance on our eCommerce systems.

The first level of FIM requires checksum monitoring of key system files for changes (trojans, injections, hacks, etc..), and alerting when changes occur. Managing file contents is another level of FIM, however this is highly inefficient for monitoring files (binaries) of the same name that might have different contents across the infrastructure, when all we need to do is checksum comparisons, i.e. we would have to maintain massive amounts of files and node specific recipes/cookbooks on the Chef server.

Another approach might be to develop an OHAI plugin to get the checksum comparison base into the Chef DB at a minimum?

Puppet does this with a simple "audit=>all" statement as in my first mail. When you assert audit=>all in a file resource statement it loads those values into the Puppet DB and compares the values on each client run, alerting if there is a change. It can also replace the file, and/or correct mode, owner, group. This is highly valuable for eCommerce systems as it is a legal requirement. 

Please let me know if I can provide any more information.

Regards,

Daniel

On Thursday, September 25, 2014 2:40 PM, Lamont Granquist < > wrote:

I would advise not trying to this with remote_file like that, even if it accidentally works.  That's a hack that only addresses file permissions and a use case that we wouldn't want to sign up to support.

We could add a "whyrun true" or "audit true" to resources that would cause them to run in "whyrun-always mode" and not do anything even during normal Chef runs and then just output what they would have done, and then resource reporting could report them normally and just flag them as being from an audit resource that didn't do anything but just was reporting.  We're aware that Puppet has this functionality but don't really have any visibility into how much that gets used in the Puppet community and if it was considered a hack or something that was useful.

The problem with this approach is that its hard to express things like "should not be listening on the telnet port" as a Chef resource so we couldn't cover those kinds of use cases this way.  The serverspec language has the ability to express things like this, so there's another idea which is allow users to write serverspec code which would execute as part of recipe execution which would be used to generate these kinds of reports.  And then there's two implementation details of this where in one you embed the serverspec code as resources in the Chef recipes and the other where its other files which are added to the cookbook.  This would be a use of serverspec in addition to specs used to ci test cookbooks because it would be testing real chef client converges and a lot of the cookbook spec testing code does configuration to exercise edge cases that would be inappropriate to do on a prod server.

Daniel, as a user migrating away from Puppet security audits, what would you rather see (and why)?  And anyone else who has thoughts...

On 9/25/14, 12:09 PM, DV wrote:

(forgot to CC chef list)

On Thu, Sep 25, 2014 at 12:08 PM, DV < " target="_blank"> > wrote:

Daniel,

Indeed the file resource doesn't have a checksum, but I think that makes sense because when you use a file resource in Chef, you must also specify file contents right there in Chef. Only with remote_file resource the file contents come outside of Chef, so checksum applies here.

Here's what you can specify as remote_file's source:

>The location (URI) of the source file. This value may also specify HTTP (http://), FTP (ftp://), or local (file://) source file locations.

I haven't tested this out, but perhaps you can make the source and destination the same and add checksum like following:

remote_file "/etc/at.deny" do

  source "file://etc/at.deny"

  checksum "12345abdcef.."

end

On Thu, Sep 25, 2014 at 11:45 AM, Daniel Gutierrez < " target="_blank"> > wrote:

Hello Chefs,

We are trying to migrate all of our Puppet security audit functionality to Chef,

however, we don't see an easy way to monitor file checksums

for security audits. For example in Puppet this is easy with a line like:

file {"/etc/at.deny": mode=>"600", owner=>"root", group=>"root", checksum=>"
md5", audit=>all; }

Puppet will log the checksum of a file, and compare it on each subsequent run.

The Chef file resource has no checksum, or audit option similar to the Puppet file resource.

I found some references to the "remote_file" resource but this seems geared toward

downloading files remotely, not auditing files in place.

Has anyone done something like this with Chef before?

Any pointers would be greatly appreciated.

Regards,

Daniel

--
Best regards, Dmitriy V.

--
Best regards, Dmitriy V.