|
In today's IT environment, the ability to provide consistency between system installations is critical. Installing various servers with the same system enables IT personnel to create a strong system image and to recover quickly from a system failure or intrusion. Since 2.1, Solaris has offered the power to quickly install systems in the form of JumpStart. This is the first of two articles that will look at JumpStart. This article will examine the basics of JumpStart: what it is and what benefits it may provide to system administrators. It will also discuss how these benefits can be used to create bastion hosts to be deployed throughout the enterprise. The second article in this series will discuss the complete installation of the bastion mail server using the JumpStart Architecture and Security Scripts (JASS) toolkit.
What is JumpStart?
JumpStart is Sun's method of providing a turnkey, hands-off solution to installing Solaris [1]. Installing Solaris is typically a time-consuming, tedious task. It can be done in one of three ways: Interactive, JumpStart, and WebStart. The interactive installation is the method most commonly used by system administrators - it also happens to require the most time. Sun's WebStart, a browser-based "virtual assistant" for installing Solaris, provides for ease of installation by allowing the selection and installation of all the software a system requires including: a Solaris distribution, Solstice utilities and other applications. WebStart uses the JumpStart utility to read the system profile thus installing the system with minimal intervention.
JumpStart is a tool that enables Solaris system administrators to install and configure systems remotely. JumpStart works by automating the Solaris installation process. While setting up a JumpStart server requires some initial work up front, the long term benefits of being able to install Solaris quickly makes the time investment worthwhile. JumpStart installs the Solaris OS according to instructions in a file on the JumpStart server called a Profile. Profile files can be customized to define specific Solaris installations. Profiles also allow the use of Bourne shell scripts to provide additional pre- and post-installation tasks such as installing patches or unbundled software.
JumpStart is method by which a system, upon power-up, can contact a bootp server and download a small boot kernel that subsequently brings the machine to a functional state. While this process is very similar to the way Sun diskless clients function, the JumpStart client then reads a file on the JumpStart server called a rules.ok file. A rules file can be viewed as a table that contains one or more rules that define how clients are installed. These rules are based on the client system attributes. The rules file entry format is:
keyword value begin profile finish
where the keyword is a predefined word that defines a system attribute such as kernel architecture, hostname, etc. The value field contains the system-specific attribute for the corresponding keyword. The begin and finish scripts are optional Bourne shell scripts that are executed prior to and after system installation respectively. The profile file is a text file that defines how to install the Solaris operating system on the client. Like the rules file, the profile file has a set of specific keywords that require a value.
The JumpStart server and the bootp server do not necessarily have to reside on the same host. The following steps outline the procedure to install a client using JumpStart (see Figure 1):
1. The install client is turned on and booted with the following command at the boot prom:
ok boot net - install
This causes the client to send out a RARP broadcast to determine its IP address. The RARP packet contains the client's Ethernet hardware address. The boot server responds by providing the client an IP address and other information necessary to function on the network.
2. Once the client has determined its network information, it continues the boot process, loading the install kernel and the install OS. It also determines the network information for the designated profile server containing a rules.ok file.
3. The sysidtool determines default information for the client in the name service.
4. The installation software contacts the profile server and searches for an appropriate rule in the rules.ok file for the client.
5. The rule for the client contains the name of the profile file to be used for the installation.
6. The installation software installs Solaris on the client according to the instructions in the profile file.
Figure 1 - How a JumpStart Installation Works [1]
One weakness of the JumpStart process is that the client to be installed is vulnerable to exploitation during the installation process. This is due to the fact that JumpStart installs a mini-OS in the client's memory while it installs the final OS on the client's disk. This results in a fully functioning system that can be attacked and have a Trojan program installed. It is for this very reason that all JumpStart installations should be conducted on an isolated network either in a lab or in an office rather than in the location in which the machine will site while in production. [2]
By using JumpStart it is possible to install groups of identical systems easily. This provides system administrators with a valuable tool for configuration and change management. However, while JumpStart eases the problem of system installation, it does nothing for improving the security of the installed system, which is where the JumpStart Architecture and Security Scripts (JASS) come in.
JumpStart Architecture and Security Scripts
The JumpStart Architecture and Security Scripts toolkit is a recent development from Sun Microsystems that focuses on configuring Solaris installations with an emphasis on security. While the toolkit is designed to be used during the Solaris install process it can also be used on systems that are in productions, require security modifications but cannot be taken out of service in order to make those modifications. [3]
The toolkit architecture consists of several directories that are installed under the /jumpstart directory on the install server. These directories are:
- Drivers
- Files
- Finish
- OS
- Packages
- Patches
- Profiles
- Sysidcfg
The Drivers directory contains configuration files that specify the scripts to be run during client installation. The main scripts in the Drivers directory are the driver.init and user.init scripts. The driver.init script is called by a driver file after the directory path is set. The driver.init script then calls the user.init script to ascertain site-specific configuration information. The driver file being used for the installation then defines two environment variables: FILES and SCRIPTS. These two variables define the files that will be copied from the Files directory to the client as well as which finish scripts will be executed during client installation. The final section of a driver file is the execution of the driver.run script. The driver.run script processes the contents of the FILES and SCRIPTS environment variables. The scripts called by the files in the Drivers directory are found in the Finish directory. [5]
The Files directory contains system files to be copied to the JumpStart client. The Finish directory contains scripts that perform system modifications, such as installing patches and third party packages, during installation. The OS directory contains the Solaris operating system images. The Packages directory contains Solaris software packages to be installed using the finish scripts in the Finish directory. The Patches directory contains OS patches that can be downloaded from http://sunsolve.sun.com. The patches need to be unzipped and then extracted into the Patches directory in order for the JumpStart Architecture and Security Scripts (JASS) toolkit to use them properly. [4]
The Profiles directory contains the JumpStart profiles for the various client install images. As mentioned previously, Profile files contain configuration information such as the disk partitioning scheme, the package cluster to be installed, and the type of install to perform. The Sysidcfg directory is used to store OS-specific versions of sysidcfg files. The sysidcfg files are used to automate Solaris installations by providing information such as the system locale, time zone, root password, and name service among others. [4]
The JumpStart Architecture and Security Scripts (JASS) toolkit provides a Solaris system administrator with an easy to use and easy to implement method of hardening Solaris systems. This toolkit provides the ability to install identical hardened Solaris operating system images to multiple systems.
Another benefit of the toolkit, which stems from the ability to install secure JumpStart systems from scratch, is a lower incident recovery time. If a server or a group of servers is discovered to have been compromised, the JASS toolkit allows a system administrator to quickly add the patch for the exploit to the toolkit and replicate the affected system on new hardware or reinstall the operating system on the compromised host.
The Bastion Host
The remainder of this article focuses on defining a mail server to be installed using the JASS toolkit. This host will be installed with a minimal Solaris installation as defined by Alex Noordergraaf in "Solaris Operating Environment Minimization for Security: A Simple Reproducible and Secure Installation Methodology ? Updated for Solaris 8 Operating Environment" [6]. The purpose of using a minimal installation is to reduce the number of possible avenues of exploitation on the server. Furthermore, the JASS toolkit will be used to patch the system to the most current level suggested by Sun. The specifics of the mail server are:
Hardware - Sun SPARCstation IPX
Software - Solaris 7 (SPARC)
Patches - Solaris 7 Recommended Patch Cluster
Additional Software includes:
- Secure Shell;
- S/Key;
- Sendmail 8.11.2;
- sudo-1.6.5;
- noshell;
- fix-modes;
- ifstatus;
- logcheck; and,
- secureip
One of the profiles provided with the toolkit is the 32-bit-minimal profile. This profile defines a minimal Solaris install by using the Core Solaris package cluster and then adding in additional packages to support such services as NTP and Secure Shell. This profile provides an ideal starting point for installing a secure system, as it uses the Solaris Core package cluster, the smallest Solaris installation cluster possible as defined by Sun. However, even that cluster contains more than is needed as defined in Noodergraaf?s article [6]. Finish scripts will be used to both remove any unnecessary packages as well as add in the additional software listed above. Once that procedure is complete, the mail server will be ready for deployment. Furthermore, there will be a complete record (in terms of the profile file and any begin and finish scripts) that can be used to quickly replicate an identical host should the mail server ever fail or be compromised.
The choice of the additional software comes from the need to:
- provide secure access to the system (Secure Shell),
- use one-time passwords to reduce the reliance on insecure passwords (S/Key),
- remove group and world write permissions from files, devices and directories (fix-modes),
- refuse and log any attempts to log into the server using old or locked accounts (noshell),
- ensure that network interfaces are not in promisuous modes (ifstatus),
- use the latest version of Sendmail (sendmail 8.11.2),
- continuously monitor system logs (logcheck), Building Identical Bastion Hosts using Solaris
Conclusion
This concludes the basic overview of JumpStart and the JumpStart Architecture and Security Scripts. The next article in this series will follow the complete installation of the bastion mail server using the JASS toolkit.
References:
[1] Automating Solaris Installations, Paul Anthony Kasper and Alan L. McClellan, Prentice Hall/SunSoft Press, 1995
[2] "Building Bastion Hosts with Solaris: Step by Step", Hal Pomeranz, SANS Network Security '98, October 1998
[3] "JumpStart Architecture and Security Scripts for the Solaris Operating Environment - Part 1: Updated for Toolkit version 0.2", Alex Noordergraaf and Glenn Brunette, Sun Blueprints, November 2000
[4] "JumpStart Architecture and Security Scripts for the Solaris Operating Environment - Part 2: Updated for Toolkit version 0.2", Alex Noordergraaf and Glenn Brunette, Sun Blueprints, November 2000
[5] "JumpStart Architecture and Security Scripts for the Solaris Operating Environment - Part 3: Updated for Toolkit version 0.2", Alex Noordergraaf and Glenn Brunette, Sun Blueprints, November 2000
[6] "Solaris Operating Environment Minimization for Security: A Simple Reproducible and Secure Installation Methodology - Updated for Solaris 8 Operating Environment", Alex Noordergraaf,November 2000 Building Identical Bastion Hosts using Solaris
To read JumpStart for Solaris Systems, Part Two, click here.
Ido Dubrawsky has been working in UNIX and network administration field for almost 8 years. He is currently employed by Cisco Systems in the Cisco Secure Consulting Service as a Network Security Engineer.
|