DISA, UNIX Security, and Reality

by sunpuke

Most people would think that computers used by the U.S. Department of Defense (DoD) would be the most secure systems on the planet.

Unfortunately that is not the case, where the vast majority of computers run Microsoft Windows variants.  And to secure Windows there is excellent documentation provided by the National Security Agency.

But what about UNIX?

The documentation for securing UNIX variants comes from the Defense Information Systems Agency (DISA) and is a far cry from the NSA's Windows documentation.

This is my review of Version 4, Release 3 of the DISA UNIX Security Technical Implementation Guide (STIG).  If you ever wondered why DoD UNIX assets were easy to crack, here is why.

Some people might find this a little harsh, but let's look at how many different operating systems they are trying to give security advice on here:

In addition they cover the installation of Tivoli and MQ Series, all of this in 273 pages.

Compare this to the 21 different documents available from the NSA for securing Windows 2000 and Microsoft Enterprise products (ISA Server, Exchange, IIS, Group Policy, Active Directory) and you get the idea that if nothing else the NSA does a better job than DISA.

If you want to see for yourself, you can get the document from this site: csrc.nist.gov/pcig/cig.html

Unless you have access to .mil or .gov web sites, you cannot get the scripts and additional documentation that DISA provides.

The first thing that becomes apparent is the age of some of the operating systems they are testing.  I am all for stability, however that does not mean that:

  • I ignore updated operating systems.
  • I believe in security through obscurity.

Anyone who has spent significant time examining any operating system knows that vendors make changes on a regular basis and documentation has to be updated to reflect these changes.

Unfortunately, most of this document is in the "dark ages" when it comes to security and needs significant updates, not only in the methods to achieve better security, but in updating the operating systems the document covers.

C2 and Common Criteria

In the government you hear a lot of talk about C2 security, and this references the Trusted Computer System Evaluation Criteria (TCSEC) (DoD 5200.28-STD) of 1985.

The criteria specified in the TCSEC does not necessarily make your systems more secure, but increases what is audited based on the classification of information that is stored on the systems.  The higher the classification, the heavier the auditing requirements become for a system to pass TCSEC.

For example, C2 is the minimum level necessary to process TOP SECRET information.  Now why you would want an unclassified network to audit at that level is beyond me.

If you are looking for build methodology, protocols to secure, and other administrative guidance the TCSEC does not have it.  The TCSEC was terminated March 11, 1999 by DoD and was replaced with Common Criteria (CC), and the adoption of CC has been slow.  The difference between TCSEC and CC is that CC is based on a Target of Evaluation (TOE), and if any changes are made to the system, the evaluation becomes invalid!  This is of course if you evaluate each machine individually.

This means security (IA) personnel have to determine what a "system" is and how to evaluate it.  I will not go into this any farther, but do not expect CC to be used any time in the near future.  Basically the administrators are "on their own" when it comes to building systems because guidance is not provided by CC or the DISA STIG other than what is provided in their document.

I routinely use Solaris, AIX, and Red Hat Linux so I will discuss these operating systems and how the DISA STIG could be improved.  This is not an exhaustive list, but some of the more glaring problems I found with the DISA STIG and the methodology.

Solaris

Section 10 starts the discussion of Solaris and the document clearly states, "It is based on Solaris 2.5.1."

Solaris 2.5.1 is ancient, and most of the installed Solaris base I have seen are running version 8.  I would drop any mention of Solaris before version 7 since that is the minimum OS for 64-bit support and all current Sun hardware is 64-bit.

Section 10.1 discusses auditing and how to set it up to DISA standards.  One of the many things that is audited is login and logout (lo) events.  Solaris, like almost all operating systems writes its auditing information in a proprietary format that only Solaris tools can read.  This means that the process of checking the audit trail for possible intrusions has now become a manual process.

The document discusses how to log failed login events by modifying /etc/default/login.  The problem is that a user has to fail three times before an event is logged!

By enabling SYSLOG_FAILED_LOGINS=0 in /etc/default/login, all failed login attempts are recorded.  By doing this, the monitoring of login and logout events can be automated because the files are in plain text and can be read by various tools.

The coverage of the use of Automated Security Enhancement Tool (ASET) is terrible; ASET can be configured to monitor various directories and files for possible tampering far beyond what is specified.  Also the document does not discuss a possible problem in the configuration and use of ASET.

If you have built a minimized Solaris machine that does not have NIS installed (packages SUNWnisr, SUNWhnisu, SUNWypr, and SUNWypu) running ASET will fail since it cannot find the ypcat command defined in /usr/asset/asetenv.

Any reference to ypcat has to be removed before ASET can be run successfully and you are not using NIS.

Another area of concern is the discussion of Role-Based Access Control (RBAC).  The document covers the benefits of RBAC but does not tell you how to configure it, especially if you are running a system without X (there is an article in SysAdmin Magazine that discusses the use of RBAC without the Solaris Management Console).

Finally, the removal of snoop - I do not think it is a good idea to remove a diagnostic tool.  Yes, you can capture network traffic with it, but when you need to use it, it is there and should stay.  Since it can only be used by root, there should not be a problem unless everybody is root.  There is a brief discussion of Trusted Solaris and its limited use in DISA, I like this comment:

"One of the biggest differences between normal UNIX systems and TS is that normal UNIX systems work on the principle of discretionary access control.  TS works on the principle of mandatory access control.  All users cannot execute all commands or read all files that it looks like they should be able to do."

That is how Mandatory Access Control is supposed to work.  It is like setting up an Access-Control List (ACL) - if it is not specifically authorized, it is denied!

AIX

Section 12 discusses IBM's Advanced Interactive Executive (AIX) and the first thing that strikes me is that there is no discussion of AIX 5L!

Support for AIX 4.3 ends December 31, 2003 and AIX 5L has been around since October 17, 2000 (AIX 5L 5.0).  Furthermore, AIX 5L 5.2 has the installation option of CAPP/EAL4+ security if installed on 64-bit hardware.

IBM makes it clear in their documentation (security.pdf) that if you install software or modify the system outside of the parameters used in the evaluation, the EAL4+ certification is invalid.  I suppose DISA would have a problem with AIX SL 5.2 with the EAL4+ features enabled just like they had problems with Trusted Solaris.  There is also no mention of the use of the no command to view network settings and modify them for better security (similar to the ndd command in Solaris).

Although the STIG mentions Redbooks (www.redbooks.ibm.com), they obviously spent little time there because they could have found several volumes dealing with AIX and security.

Linux

Section 13 discusses Linux and the document states, "It is based on Version 6.2 through 9.0 of Red Hat Linux."

Personally, I think the authors are a little ambitious in covering seven different versions of Red Hat Linux in 19 pages.  SUSE Linux was recently given CC EAL2+ certification and this is what DISA had to say about it:

"As of this writing, the only distribution of Linux that has been added to the NIAP Validated Products List for Common Criteria (ISOAIEC 15408) is SuSE Linux Enterprise Server Version 8 (SLES-8).  SLES-8 was evaluated against the Common Criteria for IT Security Evaluation Version 2.1 and received an Evaluation Assurance Level (EAL2+) certification.  It should be noted the SLES-8 was not evaluated against any of the U.S. Government/NSA sponsored Protection Profiles.  Reference (Section 1. Introduction) of this STIG for additional information on NIAP evaluation requirements and product endorsement."

Considering the idea of Common Criteria was to be an international standard, does that mean the EAL4+ rating for AIX 5L 5.2 is any less secure because it was not evaluated against any of the U.S. Government or NSA Protection Profiles?

Let's not mention the fact that Security-Enhanced Linux (or SEL, an NSA product) is not even mentioned here!  If you were trying to build a highly secure Linux system, using SEL allows the administrator to enable Mandatory Access Control and Role-Based Access Control features that would make the system very secure.

And the comments about Bastille Linux:

"FSO has not subjected The Bastille Hardening System to acceptance testing.  It is presently not available from a trusted source.  Though Bastille is part of the benchmark project for the Center for Internet Security, it should still be used with caution.  If the SA chooses to use the Bastille utilities, the SA should use only the latest version of the product, remove the system from the network before execution, and execute a complete system backup.  After use, as a precaution, the SA will verify that the changes selected were implemented and they were the only changes implemented and there were no security vulnerabilities introduced.  The SA will perform a self-assessment after using Bastille by running the UNIX scripts and noting deficiencies.  The Bastille Hardening System program is available from www.bastille-linux.org."

There are two agencies that are responsible for the evaluation of open-source software and its use within the Department of Defense: National Security Agency and Defense Information Systems Agency.

So why does DISA not recommend or even implement Security-Enhanced Linux?  I find it interesting that on one hand they question a CC evaluation because the evaluators did not use U.S. or NSA Protection Profiles, while on the other hand not recommending or mentioning an NSA product.

The document does mention the Center for Internet Security and recommends the use of Linux Benchmark, a tool that in my opinion does not go far enough to secure a Linux machine.  Specifically the ability for a non-privileged user to reboot the machine by pressing Ctrl-Alt-Del and the ability to use USB devices such as memory sticks, amongst other things.

The section concerning Kickstart (13.2.3) I found interesting if for nothing else than to show what I feel is backward thinking on the part of the authors of this document.  If DISA were to actually examine Kickstart (as well as JumpStart for Solaris and NIM for AIX), they would find an effective way to deploy machines where configurations would match and could customize the install based on machine function.

Sun and IBM are looking to these technologies not only for installation, but also for disaster recovery as well as a management tool (Sun's N1 initiative).  It is only a matter of time before Red Hat adds similar functionality.

All of these use NFS, TFTP, and RARP to allow the clients to download the boot image.  Like everything else, if enough time was spent researching methods to deploy such servers securely, life for system administrators would be made much easier.

Many of the problems associated with Linux are the result of default installations, not just poor system administration.  A Red Hat Linux box I examined had 853 RPMs installed and was supposed to be a DNS server!  This is obviously the result of a neophyte system administrator install of Linux.

Section 13.11.1 discusses Linux password aging and what I find interesting here is this statement:

These changes will be applied to /etc/login.defs:

PASS_MAX_DAYS	90  # Maximum days a password is valid
PASS_MIN_DAYS	15  # Minimum days between password changes
PASS_WARN_AGE	10  # Days warning before a forced password change
UID_MIN       1000  # Minimum value for automatic UID selection
GID_MIN        100  # Minimum value for automatic GID selection
PASS_MIN_LEN     8  # Minimum acceptable password length

This last line does NOT work in all versions.

It is superseded by the PAM module "pam_cracklib". 

See the pam_cracklib parameter "minlen" for information, or the module 
on PAM in this document.

The underlined portion of this indicates a problem with PAM, but the authors chose not to specify which version of Linux displays the problems they encountered.  The comment in Section 13.4.1 indicates serious problems with password checking:

"Linux has very poor native password checking.  See the Linux Account Management section for an expansion of this subject."

Again, this should be addressed by what version of PAM this behavior was observed in and how to fix it.

They mention the use of passwd+ or npasswd.  Both come in source form only and npasswd has not been updated since 1992!

In some cases the use of a compiler might not be allowed by some commands.  DISA should recommend something that can be installed as a RPM, or provide a RPM for download.

Reality (or life outside of DISA)

The document does not go into any explanation about various build methods and what they can or cannot do for the system administrator.

Most of the issues encountered with a UNIX machine security wise can be dealt with during or immediately after the installation of the operating system.  Virtually all of the machines I have encountered were full operating system installs despite excellent documentation from other sites and books to the contrary.

The DISA STIG does not go into sufficient detail on how to actually build a secure machine, nor would I consider a machine built using the STIG as secure.

A recent piece on Slashdot discussed information technology personnel in the military and unfortunately most do not get proper training to perform their jobs.

Documentation like the DISA STIG becomes crucial in how military systems are secured.  The emphasis cannot be just on auditing.  It has to change its focus from a single system mentality to that of a data center, where there are numerous systems and that installation might be automated, or hands-off.

The authors of the STIG should foster working smarter and not harder.

Specific recommendations to DISA for improving the STIG:

1.)  Conduct operating system research on current and future operating systems.

2.)  If DISA cannot keep up with the latest developments, then recommend security related sites that can such as SecurityFocus.

3.)  Recommend products that can improve security without the politics (like not recommending Security-Enhanced Linux) because the NSA is in "competition" with DISA for the same job.

4.)  DISA should write OS specific documentation as opposed to creating one document that tries to cover everything.  Tivoli and MQ Series should have their own unique documentation.

5.)  If DISA is going to report a problem with an operating system, they should also provide a relevant fix that can work in all situations or provide the fix themselves.
Return to $2600 Index