Some in our infrastructure group want to upgrade to start taking advantage of the new features in RHEL 6. In the past, I have relied on the NSA Guide (www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf) to secure RHEL 5 and CentOS 5 installations. I find this guide invaluable.

Does anyone out there have experience with securing RHEL / CentOS 6 in a similar way? If so, what resources (written or consultative) did you leverage?

I have heard from some colleagues that version 6 is significantly different from version 5 in various ways, so I don't want to leave gaping holes in our security because I didn't adequately account for those differences.

Is Red Hat's own guide for RHEL 6 (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/index.html) really sufficient?

Would anyone go so far as to say that, unless you have a compelling functional reason, you should hold off on upgrading from 5 to 6 until some group like the NSA can produce a guide that is specific to the version you are trying to protect?

I appreciate any feedback that you may have, even if it is directing me to a more appropriate forum.



  • You might want to also try the Security StackExchange site: security.stackexchange.com
    – HTTP500
    Mar 9, 2012 at 17:07
  • I don't think RHEL6 have been approved for anything gov/mil operations yet, so no STIGs or SNACs have been released.
    – Marcin
    Mar 9, 2012 at 19:14
  • Going through similar issues for a client, where not all vendors have added RHEL6 to their supported OS. I haven't run it myself but May I suggest running a Nessus scan?
    – Raj J
    Apr 15, 2012 at 18:42

2 Answers 2



there are generally a few sources of good guides out there for security hardening.

  • The DISA STIGs
  • The NSA SRGs
  • NIST
  • CIS Benchmarks
  • Vendor guidance
  • SANS
  • Books specific to hardening

At my work, we use a combination of the DISA STIGs, along with puppet for Linux. I'd be more likely to say that is inadequate and push for some of the recommendations below.

Keep in mind that the hardening guides above do have overlap, and some missing areas. A best practice is to track all configuration options via guide in a database or spreadsheet, so you can have the most coverage.

An alternative way of doing the same thing is to create hardening or auditing scripts based on above, and then run audits of yourself to figure out where the gaps between the different standards are.

I don't believe RHEL's guides are sufficient - I prefer the outputs of the NSA, DISA and NIST. But, Red Hat's guides are a great starting point.

As the NSA and DISA start working on hardening standards far in advance, in draft, that may be a good source for you. If you have a friend in DoD, you can get access to pre-release material too. Due to the current state of the DISA STIG for Red Hat, I'd say the NSA is likely to produce something faster. I can check in with them and see where they are. I'd recommend starting to move forward to 6 in a testing environment right now. Get your hardening scripts tested in 6.

Engaging outside assistance to develop security hardening guidance

Consider an engagement with a Security Engineer focused specifically on Linux security hardening to produce guidance for you. Red Hat can make available their employees for engagements as well in order to accelerate security engineering efforts.

Everything you've said thus far indicates a due diligence approach and reasonable security. Based on that, I think considering above, you are clear to move forward to RHEL6. However, I am going to add some additional tasks you could consider since I assume you are working in a regulated environment that is very security conscious.

Augmenting your approach with a Risk Assessment

If you wanted to take your approach to the next level, and justify it in a way would pass review by even the most retentive auditor, consider performing a full blown developmental risk assessment using NIST 800-30 along with the particular controls sets used in your industry. This, supported by security testing & analysis. Having a risk assessment formalized will enable a good documentation of the risks presented by going forward with RHEL6, and some potential compensating controls you could add to buttress any potential weaknesses.

Adding a penetration test

Taking it even beyond the risk assessment, you could engage a penetration tester with a strong Linux background to attempt white box or black box penetrations of your RHEL6 host after some secure configurations. A secured base operating system might not present much attack surface so loading it with applications would present a much more realistic platform for attack that would better enable you to understand potential attack vectors. Circling around at the end, using the pen test report you could augment your previous work, close any gaps, add additional controls and head towards operations with much more of a warm and fuzzy.


The RHEL 6 STIGS are expected to be finished around May 13, 2013. You can follow the information on Red Hat's Gov-Sec mailing List.


Not the answer you're looking for? Browse other questions tagged or ask your own question.