Provide standard lockdown scripts/package
Large numbers of corporate servers these days undergo a lock-down during or immediately after installation. This is because the standard install leaves too many things installed and/or configured. Examples are: root login via SSH, remove telnet, disable cups. I'm not being rigid about this list by the way.
Groups like NIST, NSA, CIS publish security documents that provide methods for locking down base install systems to provide a good base security level for servers.
Rather than having to come up with scripts independantly, it would be hugely beneficial to customers for Red Hat to provide a set of scripts (or other method) for applying such a base setup lockdown. This would provide users with an install to a known good security level which could be easily demonstrated to auditors, for example.
This is not a "lazyboy" option that I would suggest relying entirely on, but a good first step that an organisations security team could understand immediately.
The security lockdown would have to be agreed upon of course, but could perhaps be flexible (i.e. configured with an answer file?)
Audit scripts would also be invaluable so that deviations from the lockdown could be quickly highlighted to admins & auditors.
Responses
We conform to the CIS standards, but need to do it ourselves. Of course, these standards are released after RHEL, because it is a remediation to the issues they find in RHEL. So it may not be possible to release RHEL pre-standardized to CIS (or other).
However, I imagine that much of the info from older CIS benchmarks are still relevant today. I've not tested this so I'm not positive but it would be nice if Red Hat ensured that released builds were locked down based somewhat on older released standards. i.e. the changes necessary to ensure a RHEL 5 box was conforming were taken care of by Red Hat in RHEL 6, etc.
Also it would be nice if, after a CIS (or other) benchmark is released, Red Hat incorporate the scripts into standard kickstarts on new builds. Would also be nice if there were a way to pull these scripts from Red Hat for already installed boxes. This way, after a benchmark, the admin only needs to complete these tasks until the next build is released, whereas Red Hat has also released a bundle of the remediation steps.
Having RHEL V6 comply with CIS 1.5 for RHEL V5 and CIS V2.0 for RHEL V5 would make it usable and secure; when CIS get a V6 benchmark, RHELV6.<current+1> should implement the changes - and this may encourage CIS to act quickly, so 6.1/6.2 would have a standard to follow.
We have implemented the CIS V5 benchmarks on V6 and generally there have been no problems.
Being able to deploy these on the existing systems would also be a great help, as it would give us a "correct" implementation of the standard and save us the time / effort of writing our own scripts, although having done it for RHEL V4/5 moving to V6 is not a massive job.
Now being lazy, if RH will write the compliance scripts, they could write the verification scripts to show that the system conforms to the standard, but does not change the configuration - so we can report on compliance.
Guru
2135 points
I'm all in favour of your "being lazy" option too :-) But it's a big win for Red Hat too I think. Being able to sell an OS that can be deployed in a standard security lock-down mode that will comply with auditors requirements AND run verification scripts that prove compliance.
That can't be anything BUT a win for Red Hat in acquiring new business.
For those of us who have already chosen Red Hat it's a win as it makes life easier.
Guru
3262 points
We use CIS as a baseline, where appropriate, in our environment as well. We would also see value in compliance and verification scripts.
This is being addressed in an Open Source community project.
https://fedorahosted.org/aqueduct/
-Vincent C. Passaro
Absolutely 100% Agree!
DoD Customers would greatly appreciate the efforts to simplify the hardening of RHEL.
What would really be awesome, is if this can be done via Kickstart...
Guru
2135 points
I already harden my own installs by hand to the CIS benchmarks. It's a mixture of kickstart and Puppet. The Puppet stuff is there because Puppet does all our config management, so it made sense to do it there, rather than do it in kickstart and duplicate the work in Puppet.
Whilst re-reading this thread, I had a few more ideas.
My original comment was aimed at providing some helper RPM's or scripts that would be applied post-install and harden a system. Perhaps some more sense could be made of this if the @Base package list could be replaced with @Base-Secure for example (removing, for example, telnet, rdate, rdist, talk, tcpdump, traceroute). This would stop the unrequired packages even being installed. Things like bind-mounting of /var/tmp to /tmp could also be done in Anaconda if the user created a separate /tmp partition?
Red Hat
Guru
3598 points
Using puppet one can also ensure that the lockdown state
remains in place.
One should also be able to do lockdowns in kickstart and
use OpenScap to verify if the state stays locked down.
Guru
2135 points
I generally don't like packages to be installed only to be removed by some other mechanism later on. Waste of efforts really. I'm all for enforcing the removal via Puppet in case a package gets installed manually. Under this situation, I'd explicitly remove the packages from the kickstart with a minus tag in the package list. This tends to make the package list difficult to manage however.
If Red Hat can provide a "secure" version of @Base and/or @Core, then these insecure packages such as telnet, rdate, rdist, talk could be excluded from a build without being explicitly removed in the kickstart package list. End result - more manageable kickstart file, no wasted effort during package installation just to be removed later.
So +1 for the Puppet management for sure, but I'd still like to see an @Base-secure and @Core-secure to reduce installation overhead and simplify kickstart files.
Duncan
We have used some of the RH scripting JLabocki (I think) provided for securing our RHEL 5 boxes. STIG compliance is a mandate for my team and anything we can do to show RHEL takes a proactive stance is a selling point.
So I have just recently had to respond to CIS benchmarks against our systems, and while there is plenty that falls under local configuration one of the things that bugged me was the expectance of these benchmarks that you go in and remove permissions from files and directories all across the system in the name of obscuring the view from users. I particularly don't care for this because it can have unattended consequences on the behavior of the system.
What I'd like to see is for these types of permissions issues to be directly addressed. If there is no reason for 'other' to have access to a file/directory, and these security benchmarks notice it and complain, I'd rather see it fixed in the upstream and/or RPM than have to run a script after the fact to fix it.
While I realize that there will still be some outliers that come down to local configuration, it would be nice to get the valid ones removed as a standard rather than have all of us waste the man hours on the obvious entries.
This is absolutely one of the biggest challenges for becoming compliant. For our systems, we need to be DISA STIG compliant, and there are a significant number of files and directories that need to have permissions altered (removed) after a default install.
I suppose this can be done via a Kickstart shell script to change the permissions after installation, however, that method appears to open a lot of potential issues.
Does anyone know if this can be done with aqueduct or Puppet? Unfortunately, I have not yet had the time to research those tools.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.