Problem solve Get help with specific problems with your technologies, process and projects.

Using kickstart and understanding packages for RHEL 5.4 hardening

While wholesale installation of Red Hat is the easiest method, it is not the safest for an enterprise Linux server use. Using kickstart and understanding packages in RHEL 5.4 can save a Linux admin a lot of time later dealing with patches and will protect the system from multiple vulnerabilities.

With the release of Red Hat 5.4, system administrators have to prepare themselves for the latest operating system (OS). Besides the compatibility testing that administrators need to perform to ensure existing applications will function on the new OS version, many must also harden the new OS.

This hardening effort is to reduce the risks associated with running an OS exposed to the network and the Internet. Generally, a hardening operation comes down to a three pronged approach:

  • Installing the minimal packages needed for the operating system to provide functionality.
  • Turning off service to the network for services needed on the system but not on the network.
  • Removing unused accounts to minimize access that may not be obvious.

This tip will cover the minimal install and turning off service approaches to Linux server hardening.

Custom installation removes unnecessary packages
Red Hat is quite convenient to install, and is available as a DVD ISO image, so a system can be up and running in a matter of minutes by simply selecting one of the common purposes of the system. While this approach is simple and straight forward, it is impractical from an enterprise standpoint when a minimal install is needed. A common or simple install approach will install many more packages than are needed, which will lead to unneeded patching and maintenance and unnecessary risk.

More on hardening Linux
Hardening Linux with Bastille Unix

Hardening SUSE Linux in eight steps

TCS automates Linux server hardening

A more precise method of OS install that will insure a minimal approach and consistency, even with multiple system administrators, is to use a kickstart system with the bare minimum install. Although we will not cover setting up the kickstart server, we will cover how to configure the kickstart.ks file to ensure a minimal build.

Red Hat uses a grouping of packages in RHEL 5.4. This grouping of packages determines which packages are required when the user selects a particular group that will be installed by default. For example, whenever the user selects the Web server functionality during a DVD install, the httpd package (Apache) is required. Understanding this grouping is important to determine which packages should and should not be included in your install.

The definition of this grouping is defined in xml format and is called comps-rhel5-server-core.xml. This is normally stored in the Server/repodata/ on the install. The comps-rhel5-server-core.xml file is human readable; however, due to the amount of language localization in the file it can be cumbersome to read. To get a good feeling of the grouping the following grep command can be run to get a listing of the groups from the file:

grep "<name>" comps-rhel5-server-core.xml

Here is a snippet of the previous grep command:

<name>Administration Tools </name>
<name>Afrikaans Support </name>
<name>Arabic Support </name>
<name>Assamese Support </name>
<name>Authoring and Publishing </name>
<name>Base </name>
<name>X Window System </name>
<name>Bengali Support </name>
<name>Brazilian Portuguese Support </name>
<name>Breton Support </name>

RHEL 5.4 includes 104 groups on the install DVD. Many of these are not installed (such as localization, or extras). To minimize install, let's look closer at the Web Server installation.

After opening the file in vi or another text editor find the Web Server configuration parameters by searching on Web Server. Scroll down to the area showing:

<packagereq type='mandatory'>httpd</packagereq>
 <packagereq type='default'>crypto-utils</packagereq>
 <packagereq type='default'>distcache</packagereq>
 <packagereq type='default'>httpd-manual</packagereq>
 <packagereq type='default'>mod_perl</packagereq>
 <packagereq type='default'>mod_python</packagereq>
 <packagereq type='default'>mod_ssl</packagereq>
 <packagereq type='default'>php</packagereq>
 <packagereq type='default'>php-ldap</packagereq>
 <packagereq type='default'>squid</packagereq>
 <packagereq type='default'>tux</packagereq>
 <packagereq type='default'>webalizer</packagereq>
 <packagereq type='optional'>mod_auth_kerb</packagereq>
 <packagereq type='optional'>mod_auth_mysql</packagereq>
 <packagereq type='optional'>mod_auth_pgsql</packagereq>
 <packagereq type='optional'>mod_authz_ldap</packagereq>

So, if the group Web Server is chosen, then httpd must be installed by the installer as the "mandatory" parameter points out.

Unfortunately, 10 other packages are also installed by default, as defined by the "default" parameter. While php and ssl are likely needed on most Web servers; it is highly unlikely that the squid, tux, and webalizer are needed on every server. Also if the languages perl and python are not needed, they should not be included. As can be seen by this example, one package is actually needed, and in most environments, a total of 3-4 are needed, yet 10 packages have been installed.

Hardening the kickstart.ks
Building on the Web server example further, let's assume we would like to remove unneeded packages. Within the kickstart.ks file we would add - entries to remove the rest of the default packages, as follows:


After building your standard kickstart.ks file for a minimal install, there are still services running that are not needed. In a server environment, the following services are typically not needed: bluetooth and iptables6. These services can be turned off using chkconfig. For example:

chkconfig bluetooth off

To get a complete list of services that will start at bootup and to determine their run level use:

chkconfig --list | grep ":on"

Another useful method to determine which services are running and listening to ports is the netstat command. For example:

netstat -lp

This will report ports listening and the application listening to the port. Any unrecognized services should be investigated.

By using this method, system administrators will find that a lot fewer issues are present on production systems, and have to do fewer patches. It is a bit easier to see the effects on 5.4, but on 5.3 I found about 30-50% less patching on systems after using these techniques.

ABOUT THE AUTHOR: Ronald McCarty is a freelance writer and consultant specializing in systems, network, and information security. He received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany and his master's degree in Management with a specialization in information technology at Capella University. Ron's company, Your Net Guard offers IT consulting and integration services in the Dallas/Forth Worth area. He can be reached at

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.