Getting Started with the New Red Hat 5 STIG

Thursday, August 18, 2011

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

I am pleased the U.S. Defense Information Systems Agency (DISA) released a draft of “Red Hat 5 STIG” earlier this year.

As expected, there are some specific configuration guidelines for Red Hat Enterprise Linux 5 which were missing from the generic UNIX Security Technical Implementation Guide (STIG).

The generic UNIX STIG supported numerous UNIX and Linux distributions but never addressed Red Hat Enterprise Linux 5. For many years, this lack of support was a source of frustration for system administrators. In February 2011, I discussed the new guidelines in the article “DISA UNIX STIG for Red Hat Enterprise Linux 5 and 6.”

I am reviewing the “Red Hat 5 STIG” to develop a plan to add support for it to our Security Blanket product. I've completed my initial review and I want to share some of my findings along with some tips.

First of all, the “Red Hat 5 STIG” is not to be used in conjunction with the generic UNIX STIG. Download the ZIP file, extract it, and transform the XML document to a more usable format. I used the XSLT processor which comes with Red Hat as follows:

/usr/bin/xsltproc STIG_unclass.xsl U_RedHat_5_V1R0_STIG_Manual-xccdf.xml > stig.html

The previous command will transform the document from XML format to HTML, so you can open it with your web browser. I like to have a delimited text list of the guideline, so I created the following simple XSLT:

Jamie Adams 8-19-11

Save the above as a file and use it instead of the “STIG_unclass.xsl” file.

This STIG, like the generic UNIX one, requires you to have a Disaster Recovery Plan or some form of Business Continuity Plan (BCP). The plan must contain detailed procedures for performing backups and recovery.

Wherever possible, try to have on-line, off-line, and off-site backups. On-line could include storage mirroring technologies and off-line could be some sort of media which isn't connected to equipment.

If at all possible, perform encrypted backups and then store them in a media safe on-site and off-site. The off-site backups could be as simple as taking the off-line media outside of your data center and preferably not in the same building.

Account management and personnel security practices must be clearly documented. This includes documenting how access is granted to personnel. Procedures on removing accounts or revoking rights must also be documented.

This also means taking a serious look at shared application and administrative accounts. Stop logging directly into these accounts (especially root!) — personnel should be logging into their own personal account then switching to the application/administrative account.

The biggest tip I can offer is to REMOVE ALL SOFTWARE WHICH IS NOT NEEDED. This is where you gain great insight to your system's architecture because you will learn what components rely on what. For example, if you are not using any features or utilities of Samba — remove it.

The new “Red Hat 5 STIG” has 596 potential discrepancy indicators (PDI) – sometimes called “STIG items.” Of these, 62 of them are related to extended access control lists (ACL), 8 to IPv6, and 14 to FIPS 140-2.

In the generic UNIX STIG, many STIG items restrict standard user-group-other permissions. These Discretionary Access Controls (DAC) are a fundamental security mechanism and POSIX.1e Access Control Lists (ACL) provide administrators the ability to grant access to additional users and groups without having to grant access to other (a.k.a, the world).

Nonetheless, there are 62 new STIG items which recommend stripping ACLs from files and directories. By default, file systems such as ext2 and newer support POSIX.1e ACL. If none of your applications require POSIX ACLs, I recommend mounting file systems with the 'noacl' option to disable support for them. This is an easy way to address all 62 items.

As for IPv6, my opinion is that if you are not using IPv6 simply disable support for it. First edit the /etc/sysconfig/network and set “NETWORKING_IPV6” to “no”. Next, add the following two lines to /etc/modprobe.conf:

alias net-pf-10 off
alias ipv6 off

Lastly, stop the IPv6 firewall service and configure it to not start when the system is rebooted:

# /sbin/service ip6tables stop
# /sbin/chkconfig ip6tables off

Fourteen of the new items require the “...[use of] a FIPS 140-2 validated cryptographic module (operating in FIPS mode).” These items, however, don't give the detailed check procedures as many of the other items do.

Instead, DISA states, “The NIST CVMP web site provides a list of validated modules and the required security policies for the compliant use of such modules. Verify that the module is on this list and configured in accordance with the validated security policy.

To make Red Hat Enterprise Linux 5 compliant with the Federal Information Processing Standard (FIPS) Publication 140-2 you need to make several changes to ensure that accredited cryptographic modules are used. For detailed instructions, download DOC-3923 from the Red Hat Knowledgebase.

Ensure the following accredited packages are available:

kernel 2.6.18-164.2.1.el5
libgcrypt 1.4.4-5.el5
openssl 0.9.8e-12.el5
openswan 2.6.21-5.el5_4.3
nss 3.12.6-2.el5_4
selinux-policy 2.4.6-255.el5_4.2
fipscheck-lib 1.2.0-1.el5

Next, disable prelinking by editing /etc/sysconfig/prelink and setting “PRELINKING” to “no”. Previous prelinks should be undone with:

# /usr/sbin/prelink -u -a

You'll need to recreate the initial RAM disk for x86_64 based platforms as follows:

# /sbin/mkinitrd --with-fips -f /boot/initrd-$(uname -r).img $(uname -r)

and for IA64 based platforms as follows:

# /sbin/mkinitrd --with-fips -f /boot/efi/efi/redhat/initrd-$(uname -r).img $(uname -r)

Finally, add “fips=1” as a kernel boot parameter. It's best to do this by editing your grub.conf file.

Once the operating system is operating in “FIPS” mode, you can proceed to address items such as GEN005490 – which requires the Secure Shell Daemon be configured to use the accredited modules. I will cover these specific items in some later posts.

Overall, I am impressed with the “Red Hat 5 STIG” and will be sharing tidbits over the next few months. The Security Blanket development team is working hard to automate the assessment and configuration of your systems to these new guidelines.

Cross-posted from Security Blanket Technical Blog.

Help Support Infosec Island by Tweeting and Stumbling our Articles - Thanks!

 

Possibly Related Articles:
25011
Operating Systems
Information Security
Unix NIST Disaster Recovery Linux STIG DISA FIPS 140-2
Post Rating I Like this!
Default-avatar
ted smitherman Nice post! Do you have anything on reversing this process?
1378325424
Default-avatar
J Anthony Mazzarella There's a reason WHY the Generic STIG was never updated for RHEL 5. The DISA contract workforce that worked the Generic STIG was explicitly denied the opportunity to do this. The same comment is true for the SRR scripts. Upper level management WANTED them to go away. FSO contractors that supported (email/REMEDY tickets) were, however, not allowed to "offically" mention this to anyone.
1407771595
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.