Home / server / Questions / 355680
Accepted
Tom
Asked: 2012-02-01 21:09:04 +0800 CST

Configuration Compliance auditing for many CentOS 5.x boxes

  • 772
  • Current Situation

I have a client with many (200x) CentOS 5.x servers deployed in various web, mail, database and file server roles, and these boxes have been variously administrated to a lessor or greater degree.

All the boxes have EPEL repository included as part of their base-install, and all boxes have cron jobs for "yum -y update" running frequently, and are rebooted when kernels are available. (so they are not in a terrible state)

For network, local and external vulnerabilities - We use a 3rd party firm, who use WebInspect to monitor for external facing ports and vulnerable services and produce various regular reports to my boss. (hence am not looking at Nessus, OpenVAS or network based scanning tools right now, or indeed any vulnerability tools)

  • New Big Boss in Town - is an ex security compliance dude

The new rules are; that if its not being regularly tested, then its not in compliance, even if it is in compliance etc.

(to be honest, I quite like that rule)

So now I am looking for a way to generate a report of server compliance with some compliance standard for all the boxes regularly.

We have a 117 item list of configuration settings, that is a weaker form of various compliance recommendations, so I am confident that most compliance benchmarks like CIS, EAL3 or the STIG level would be sufficient.

We have chef installed on the CentOS instances, hence I can push out yum based packages, (and I can install from source tarballs, but it will make me cry, on these instances)

  • Would like to have...

I would like to have a tool that runs locally on each CentOS box and produces a reasonably comprehensive html report regarding configuration compliance (and a massive bonus would be to send email alert for severe problems, but I can script that if required)

Ideally I could generate a weekly report that indicates compliance with 1 or more of the recognised linux server benchmarks.

I am happy to pay for a subscription for the checklist, but I suspect the kind per instance 100 USD licenses I see are going to blow my budget.

Some progress...

I see that SCAP and OVAL have tools in CentOS-base or EPEL, such as

  • OpenSCAP-utils
  • ovaldi - oval reference interpreter

NIST provide SCAP content for RHEL desktop, which is kinda close;
http://usgcb.nist.gov/usgcb/rhel_content.html

But I would really like to say, here is a known standard, and here is the report...

Some further progress...

There is a tool called sectool in the fedora repos, but I can't get it to run on CentOS due to a missing python-slip module.

Looks like the last commit on that was a few years back, and the author has gone on to work on the openscap-utils project., also depends on PolicyKit and some other things that are not available on CentOS 5.x boxes.

security

1 Answers

  1. Best Answer

    I haven't used chef, but I have used cfengine quite a bit. So while I don't have specific advice for your environment, I can tell you in general how I've handled it. I expect that you can do something similar with chef, puppet, or whatever.

    To start, let me say that in my opinion, if you're using chef (or any other configuration management package) to ONLY push packages, then you're missing out on a lot of functionality that could be making your life easier. The well goes MUCH deeper.

    In the environment that I manage, I've set up cfengine to not only install/remove packages, but also to maintain specific (and frequently security-related) settings across all servers, across one or more subgroups of similar servers, or on specific hosts, as needed.

    This does a couple of things for me -

    First, if I bring up a new server, then as soon as it's added to configuration management all of the common and group-specific settings are automatically applied. This means that I don't have to worry about the base lockdown - it's done automatically for me - and I can focus on locking down the applications that are unique to that server. It's like a self-checking checklist, but better.

    Second, I can look at the logs and see the results of the configuration runs on every host, including which settings were verified as correct, and which settings were incorrect and fixed. This lets me keep on top of what's happening, but more importantly for compliance, I can parse that information and generate reports that prove the servers are not only configured as expected, but also verified as correct with every configuration run.

    This also has a side effect of letting you know if your configuration changes unexpectedly for whatever reason, whether it's a careless coworker, or an attacker that has compromised your system.

    So, while it's probably not the answer you're looking for in the short term, maybe it will give you some ideas to include in your long term plan.

    • 2