C H A P T E R  7

Securing a System

This chapter describes how to apply the information and expertise provided in earlier chapters to a realistic scenario for installing and securing a new Solaris 8 or 9 OS. This chapter illustrates how to deploy the Solaris Security Toolkit software with a Check PointFirewall-1 NG for the Solaris 8 OS.

Use the information in this chapter as a guide and case scenario for securing a new system and applications.

Sun BluePrint books and online articles are available to guide you through the process of minimizing and hardening many of Sun's systems. Refer to the following web site for the latest product-specific books and articles:

http://www.sun.com/blueprints

This chapter contains the following topics:


Planning and Preparing

To effectively and efficiently deploy minimized and secured systems as described in this case study, planning and preparation are critical. The underlying network infrastructure, policies, and procedures must be in place. In addition, support and maintenance of the systems must be defined and communicated. For more information about planning and preparing, see Chapter 2. The scenario described in this chapter documents the process and tasks that a system administrator (SA) would perform to achieve a minimized and hardened Solaris OS image for a firewall system.

In this scenario, the SA is tasked with creating an automated and scalable solution for building and deploying Check PointFirewall-1 NG systems for a service provider (xSP) that wants to provide firewall service to its customers. For this scenario, xSP's requirements and considerations are as follows:

Based on these requirements, the SA decides to automate the installation, minimization, and hardening of the OS images by using JumpStart technology and the Solaris Security Toolkit software.

Assumptions and Limitations

This chapter assumes we are using an already working Solaris Security Toolkit software and JumpStart technology installation. Chapter 3 provides instructions and guidelines for installing the software.

This chapter also assumes we are developing a custom configuration for minimizing and hardening a specific application. The Solaris Security Toolkit software does not have any drivers or JumpStart profiles specifically for the application. Therefore, we need to create custom drivers and profiles for this application. This task is done by copying existing drivers and profiles, then modifying them to fit the application.

For this case scenario, the system administrator's (SA's) skill level is the following:

System Environment

The example scenario is based on the following hardware and software environment:

Security Requirements

For this scenario, the high-level requirements and software packages have been identified, but the specific components and services of all the packages must be identified. Also, the Solaris OS capabilities needed to administer and manage the systems must be identified.

The following list provides a detailed view on how software components are used:

From this list, you can develop a security profile. For detailed information about developing security profiles and using the profile templates, see Developing and Implementing a Solaris Security Toolkit Profile.


Creating a Security Profile

A security profile defines what security modifications the Solaris Security Toolkit software makes when hardening and minimizing the security configuration of a system. None of the standard security profiles or drivers included in the Solaris Security Toolkit software meet the requirements for the minimized Check PointFirewall-1 NG systems. Therefore, you must create a custom security profile to implement the necessary system modifications.

For this scenario, the process for creating a security profile is described in several sections in this chapter. First, we create new driver files based on existing drivers. Then we modify the new drivers to comply with the security requirements outlined previously. Minimization is described in Installing the Software, and the hardening modifications in Customizing the Hardening Configuration.


Installing the Software

This section demonstrates the process of installing the software. For the sample scenario, we provide any exceptions or scenario-specific instructions. For general instructions about installing software, see Chapter 3.



Note - You can use the instructions that follow as a template for handling related situations.



This section contains the following tasks:

Downloading and Installing Security Software

Download and install the Solaris Security Toolkit and additional security software, including patches, on the JumpStart server as follows.


procedure icon  To Download and Install the Security Software

1. Download the Solaris Security Toolkit software and additional security software.

See Downloading Security Software.

2. Install the downloaded Solaris Security Toolkit software and additional security software.

See Installing and Executing the Software.



caution icon

Caution - Do notexecute the Solaris Security Toolkit software yet. First perform the additional configuration and customizing described in the following sections.



Installing Patches

OS patches might address security vulnerabilities, availability issues, performance concerns, or other aspects of a system. When installing a new OS, and on an ongoing basis after the OS is installed, check to ensure that required patches are installed.

The Solaris Security Toolkit software provides a mechanism to install the Recommended and Security Patch Cluster available from SunSolve Online. This OS-specific cluster of patches includes the most commonly needed patches.


procedure icon  To Install Patches

1. At a minimum, download the Recommended and Security Patch Cluster into the Patches directory and uncompress it.

If the install-recommended-patches.fin script is included in the hardening driver, then that patch cluster is installed automatically.

There is an added issue for Check PointFirewall-1 NG. This application requires specific patches not included in the Recommended and Security Patch Cluster. The Check PointFirewall-1 NG requires the following patches:

2. To automate the installation of patches 108434 and 108435, download the latest versions from SunSolve OnLine, and place them in the Patches directory.

3. Create a new finish script (for example, fw1-patch-install.fin) that calls the add_patch helper function, with the name of each patch.

This finish script calls the correct helper functions with the two Check PointFirewall-1 NG required patch IDs. For example:


# !/bin/sh
# add_patch 108434-10
# add_patch 108435-10

Specifying and Installing the OS Cluster

After defining a disk layout for the OS installation, the next task is to specify which Solaris OS cluster to install. Choose one of the five installation clusters available with Solaris OS: SUNWCreq, SUNWCuser, SUNWCprog, SUNWCall, and SUNWCXall.


procedure icon  To Specify and Install the OS Cluster

1. Specify the OS cluster to install.

Because the goal of this case scenario is to build a minimized and dedicated firewall device, use the smallest of the available Solaris OS clusters, SUNWCreq, which is also known as Core.

Because this cluster includes a relatively small number of packages, other packages are probably required. These other required packages must be included in the profile with the Solaris OS cluster definition.

The baseline profile definition adds the following to the previously defined profile.


cluster SUNWCreq


The SUNWCreq installation cluster includes packages that are not required for a firewall Sun server to function properly. Remove these extra packages after you have a working baseline. Refer to Sun BluePrints OnLine article "Minimizing the Solaris Operating Environment for Security: Updated for the Solaris 9 Operating Environment."

2. Run through an installation with your defined security profile to determine if there are any package dependency issues.

Some package dependencies are encountered during installation, and we determine that the following Solaris OS packages are required for Check PointFirewall-1 NG:

The complete listing of packages in the profile is as follows.


cluster SUNWCreq

package SUNWter add

package SUNWlibC add

package SUNWlibCx add

package SUNWadmc add

package SUNWadmfw add




Note - Although this list is complete for this case study, additional packages can be added or removed based on the actual environment into which this configuration is deployed.



Until the system is verified from both a function and security perspective, as described in Testing for Quality Assurance, the final list of packages might require modification. If so, modify the profile, reinstall the system, and repeat the testing.

3. Create a minimize-firewall.fin script, based on the package dependencies in the previous two steps.


Configuring the JumpStart Server and Client

This section demonstrates how to configure the JumpStart server and client to use a custom security profile for minimization. For detailed information about using the the Solaris Security Toolkit software in JumpStart environments, see Chapter 5.

This section contains the following tasks:

Preparing the Infrastructure

Perform the following tasks to prepare the infrastructure. The following tasks demonstrate the process of creating a baseline configuration for the client using existing drivers, profiles, and finish scripts. After this baseline is in place, verify that it works properly, then customize it for the chosen application.


procedure icon  To Prepare the Infrastructure

1. Configure your JumpStart server and environment.

See Chapter 5 for detailed instructions.

2. Add the client to the JumpStart server by using the add-client command.


CODE EXAMPLE 7-1 Adding a Client to the JumpStart Server
# pwd
/jumpstart
# bin/add-client -c jordan -o Solaris_8_2002-02 -m sun4u -s nomex-jumpstart
cleaning up preexisting install client "jordan"
removing jordan from bootparams
updating /etc/bootparams

3. Create a rules file entry for the client, specifying the correct JumpStart profile and finish script. For example:


hostname jordan - Profiles/xsp-minimal-firewall.profile \
  Drivers/xsp-firewall-secure.driver

4. Create a profile file named xsp-minimal-firewall.profile and a driver file named xsp-firewall-secure.driver by copying the files provided with the Solaris Security Toolkit software.

You must create these files before you can successfully complete the next step. Initially, these files can be copies of files distributed with the Solaris Security Toolkit software.



Note - Never modify the original files distributed with the Solaris Security Toolkit software.



The following example shows how to create the files.


CODE EXAMPLE 7-2 Creating a Profile
# pwd
/jumpstart/Drivers
# cp install-Sun_ONE-WS.driver xsp-firewall-secure.driver
# cp hardening.driver xsp-firewall-hardening.driver
[...]
# pwd 
/jumpstart/Profiles
# cp minimal-Sun_ONE-WS-Solaris8-64bit.profile \
     xsp-minimal-firewall.profile

This example is based on a dedicated web server configuration, because it is a good baseline from which to develop a dedicated firewall.

5. After creating the profile and driver files, modify the files as follows:

a. Replace the xsp-firewall-secure.driver reference to hardening.driver with xsp-firewall-hardening.driver.

b. Replace the two finish scripts defined in JASS_SCRIPTS with references to minimize-firewall.fin and your finish script (for example, fw1-patch-install.fin).

The modified script should appear similar to the following.


CODE EXAMPLE 7-3 Sample Output of Modified Script
DIR="`/bin/dirname $0`"
export DIR
. ${DIR}/driver.init
. ${DIR}/config.driver
JASS_SCRIPTS="
                minimize-firewall.fin
                fw1-patch-install.fin"
. ${DIR}/driver.run
. ${DIR}/xsp-firewall-hardening.driver

6. Check the rules file entry for correctness using the following command.


CODE EXAMPLE 7-4 Checking the rules File for Correctness
# pwd
/jumpstart
# ./check
Validating rules...
Validating profile Profiles/end-user.profile...
Validating profile Profiles/xsp-minimal-firewall.profile...
Validating profile Profiles/test.profile...
Validating profile Profiles/entire-distribution.profile...
Validating profile Profiles/oem.profile...
The custom JumpStart configuration is ok.

At this point, it should be possible to begin the JumpStart installation on the client, jordan in this example. Use the JumpStart configuration and Solaris Security Toolkit drivers, finish scripts, and profiles that you created.

7. If you encounter problems when checking the rules file, see Validating and Checking the Rules File.

8. From the client's ok prompt, enter the following command to install the client using the JumpStart infrastructure.


ok> boot net - install

If the client does not build, review the configuration and modify it until it works properly. Note that all aspects of the JumpStart configuration are not addressed in this section. Refer to the Sun BluePrint book JumpStart Technology: Effective Use in the Solaris Operating Environment for more details.

After achieving a correct run of the rules file and verifying that patches were installed correctly, you can start the base-level installation of the client system and its minimization and hardening.

Validating and Checking the Rules File

When validating the rules file for correctness, you might encounter a variety of problems. Some of the most common are addressed in this section.

The first run on the rules file results in the following output.


CODE EXAMPLE 7-5 Sample Output for rules File
# pwd
/jumpstart
# ./check
Validating rules...
Validating profile Profiles/xsp-minimal-firewall.profile...
Error in file "rules", line 20
hostname jordan - Profiles/xsp-minimal-firewall.profile Drivers/xsp-firewall-secure.driver
ERROR: Profile missing: 
   Profiles/xsp-minimal-firewall.profile

In this example, the profile specified in the rules entry for jordan does not exist. The profile, xsp-minimal-firewall.profile, was not present in the Profiles directory. Typically, this error is generated due to a spelling mistake in the file name, forgetting to specify the correct directory for the profiles, or simply not having created the profile yet. Fix the problem and rerun the check.

The second run uncovers two other problems. The first problem is the driver being called in the xsp-firewall-secure.driver. Instead of calling xsp-firewall-hardening.driver, the xsp-firewall-secure.driver is still calling the hardening.driver.

The second problem is that the JASS_SCRIPTS variable is incorrectly set to minimize-Sun_ONE-WS.fin instead of minimize-firewall.fin.

The following is the incorrect script.


CODE EXAMPLE 7-6 Sample of Incorrect Script

#!/bin/sh

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

JASS_SCRIPTS="minimize-Sun_ONE-WS.fin"

. ${DIR}/driver.run

. ${DIR}/hardening.driver


The following is an example of a correct script.


CODE EXAMPLE 7-7 Sample of Correct Script

#!/bin/sh

DIR="`/bin/dirname $0`"

export DIR

. ${DIR}/driver.init

. ${DIR}/config.driver

JASS_SCRIPTS="

minimize-firewall.fin"

. ${DIR}/driver.run

. ${DIR}/xsp-firewall-hardening.driver



Customizing the Hardening Configuration

The hardening configuration of the proposed firewall is ready to be customized and fine-tuned. The initial scripts are based on the hardening.driver. This means that the system is turned into a "warm-brick"; that is, all of its services are disabled.

Because Solaris 8 OS does not include a Secure Shell client, you need to make modifications to allow for remote, network-based administration of the firewalls. For the firewall in this case scenario, the requirements specify that FTP services must remain enabled, and a Secure Shell client must be installed for remote administration. Restrict both of these services to the private management network only, thereby not enabling listening on any other network interfaces. For information about restricting these services, refer to the Sun BluePrints OnLine article titled "Solaris Operating Environment Security: Updated for Solaris 9 Operating Environment."

In addition to leaving these two services enabled, leave RPC services enabled so that we can use the Solstice DiskSuite GUI to configure Solstice DiskSuite for disk mirroring. If the Solstice DiskSuite GUI is not going to be used, then the RPC services are not needed. In this example, the GUI is required and therefore RPC services are left enabled. Note that installation and configuration of Solstice DiskSuite is beyond the scope of this book.

The final modification required for this client is that a customized syslog.conf is crafted that uses xSP's centralized SYSLOG server. This customized syslog.conf file must be installed on each of the firewall systems.

These modifications require changes to a variety of Solaris Security Toolkit configuration options. Each of the required modifications is detailed in the following sections.

Enabling FTP Service

For the firewall in this case scenario, leave the FTP services enabled.


procedure icon  To Enable FTP Service

1. To leave FTP enabled, modify the default behavior of the update-inetd-conf.fin file by setting the JASS_SVCS_DISABLE and JASS_SVCS_ENABLE variables.

To disable all standard Solaris OS services except for FTP, the best method for our case scenario is to define JASS_SVCS_ENABLE to be ftp while ensuring that JASS_SVCS_DISABLE is left with its default value obtained from the finish.init script. Refer to the Solaris Security Toolkit 4.2 Reference Manual.

2. To implement the change through the environment variables, add an entry similar to the following to xsp-firewall-secure.driver before the call to xsp-firewall-hardening.driver.


JASS_SVCS_ENABLE="ftp"


3. Ensure that FTP is available only on xSP's management network by implementing it through the firewall software.

One of the other requirements was that FTP should be available only on xSP's management network. On Solaris 8 OS, you can implement this requirement either through incorporating TCP wrappers onto the system or through the firewall software itself. In this case scenario, implement it through the firewall software.

Installing Secure Shell Software



Note - These instructions apply only to systems running the Solaris 8 OS. If your system is running the Solaris 9 or 10 OS, you can use the Secure Shell software distributed with the Solaris OS and skip the OpenSSH installation steps in this section.



Solaris 8 OS does not include a Secure Shell client, so if your system is running Solaris 8 OS, you need to install a Secure Shell client for remote administration.

You can configure the Solaris Security Toolkit software to install the OpenSSH tool. Use the install-openssh.fin script, which is listed in the config.driver file used by xsp-firewall-secure.driver.


procedure icon  To Install Secure Shell

1. Copy the default config.driver to xsp-firewall-config.driver.

2. In the copy of the file, uncomment the entry for install-openssh.fin.

3. Modify the entry in xsp-firewall-secure.driver that calls config.driver to call xsp-firewall-config.driver instead.

4. Obtain the latest version of OpenSSH.

As with patches and OS releases, use the most recent version of OpenSSH. Refer to the OpenSSH web pages for the latest release information:

http://www.openssh.org

5. Compile the latest OpenSSH package, name it, and install it in the Packages directory.

For more information about this package, refer to the Sun BluePrints OnLine article titled "Configuring OpenSSH for the Solaris Operating Environment."

6. Update the install-openssh.fin script to reflect the correct OpenSSH package name.

Modifications to the install-openssh.fin script might be required. This script defines the package name of the OpenSSH package to be formatted similar to the following:


OBSDssh-3.5p1-sparc-sun4u-5.8.pkg


where the package name follows the version number (3.5p1), the architecture (sparc), the version of the architecture (sun4u), the OS for which the package was compiled (5.8), and a pkg suffix.

7. Ensure that SSH is only available on xSP's management network by implementing it through the firewall software.

One of the other requirements stated was that Secure Shell should be available only on xSP's management network. With Solaris 8 OS, you can implement this requirement either by incorporating TCP wrappers onto the system or through the firewall software itself. In this case scenario, we implement it through the firewall software. Note that this requirement could also be implemented by modifying the Secure Shell server's configuration.

Enabling RPC Service

Leave RPC services enabled so that you can use the Solstice DiskSuite for disk mirroring, which requires RPC.

This modification is relatively straightforward because a specific finish script, disable-rpc.fin, is available to disable RPC services during a Solaris Security Toolkit run.



Note - Remotely accessing RPC services on a system should be explicitly denied by the system's firewall configuration.




procedure icon  To Enable RPC

single-step bulletComment out the entry for disable-rpc.fin in the xsp-firewall-hardening.driver.

Disable scripts from drivers by commenting them out instead of removing them. Be careful when commenting out entries in the JASS_SCRIPTS definition, because only certain combinations of comment values are accepted.

The following is the comment, contained in the driver.funcs script, on what the Solaris Security Toolkit software accepts as comment indicators in the JASS_SCRIPTS definition.


#Very rudimentary comment handler. This code will only recognize
#comments where a single `#' is placed before the file name
#(separated by white space or not). It then will only skip the
#very next argument.

Customizing the syslog.conf File

The final modification required for this client is that a customized syslog.conf is crafted that uses xSP's centralized SYSLOG server. This customized syslog.conf file must be installed on each of the firewall systems.


procedure icon  To Customize the syslog.conf File

1. Copy the xSP standard syslog.conf file, rename it syslog.conf.jordan, then place it in the Files/etc directory.

The Solaris Security Toolkit software supports several different modes of copying files. The best option for this configuration is to append the system's host name as a suffix to the file so that the syslog.conf file is only copied to jordan, because it has unique firewall-specific modifications. In this case, the client is called jordan, so the actual file name used in Files/etc is syslog.conf.jordan. It is important to note that the JASS_FILES definition must not have this suffix appended. For more information about suffixes, refer to the Solaris Security Toolkit 4.2 Reference Manual.

2. If the xSP standard syslog.conf file is not available, create a custom syslog.conf file as follows:

a. Copy the syslog.conf file included with the Solaris Security Toolkit software, then rename it syslog.conf.jordan, and place it in the Files/etc directory.

b. Modify the syslog.conf.jordan to conform to the xSP standard for SYSLOG.

3. Verify that the /etc/syslog.conf file is listed in the JASS_FILES definition of the xsp-firewall-hardening.driver.

By default, the modified JASS_FILE definition in xsp-firewall-hardening.driver appears as follows.


CODE EXAMPLE 7-8 Sample Output of Modified xsp-firewall-hardening.driver

JASS_FILES="

/etc/dt/config/Xaccess

/etc/init.d/inetsvc

/etc/init.d/nddconfig

/etc/init.d/set-tmp-permissions

/etc/issue

/etc/motd

/etc/notrouter

/etc/rc2.d/S00set-tmp-permissions

/etc/rc2.d/S07set-tmp-permissions

/etc/rc2.d/S70nddconfig

/etc/syslog.conf

"


At this point, all of the required modifications have been made. The installation of the OS, minimization, and hardening are customized for a specific application and fully automated. The only processes not fully automated are the configuration and installation of the firewall software and Solstice DiskSuite. Although it is possible to perform these configurations by using JumpStart technology, it is beyond the scope of this book. Refer to the Sun BluePrints book JumpStart Technology: Effective Use in the Solaris Operating Environment.


Installing the Client

After making all of the modifications to the drivers, install the client as described in this section.


procedure icon  To Install the Client

1. After all of the required modifications are made to the drivers, install the client using the JumpStart infrastructure.

Use the following command from the client's ok prompt.


ok> boot net - install

2. If any errors are encountered, fix them and reinstall the client's OS.


Testing for Quality Assurance

The final task in the process involves verifying that the applications and services offered by the system are functioning correctly. Also, this task verifies that the security profile successfully implemented the required modifications.

It is important that this task be done thoroughly and soon after the reboot of the now hardened and minimized platform, to ensure that any anomalies or problems are detected and corrected rapidly. This process is divided into two tasks: Verifying profile installation and verifying application and service functionality.


procedure icon  To Verify Profile Installation

To verify that the Solaris Security Toolkit software installed the security profile correctly and without error, review and evaluate the following.

1. Review the installation log file.

This file is installed in JASS_REPOSITORY/jass-install-log.txt.



Note - This log file can be used as a reference to understand exactly what the Solaris Security Toolkit software did to the system. For each run on a system, there is a new log file stored in the directory based on the start time of the run. These files, and any other files in the JASS_REPOSITORY directory, must never be modified directly.



2. Use the audit option to assess the security configuration of the system.

For detailed information about the audit option, see Chapter 6. For this scenario, we use the following command from the directory into which the Solaris Security Toolkit software was installed on the client.


CODE EXAMPLE 7-9 Assessing a Security Configuration
# ./jass-execute -a xsp-firewall-secure.driver
[NOTE] Executing driver, xsp-firewall-secure.driver
================================================================
xsp-firewall-secure.driver: Driver started.
================================================================
 
================================================================
Solaris Security Toolkit Version:   4.2.0
[...]

If the Solaris Security Toolkit verification run encounters any inconsistencies, they are noted. A summary at the end of the run reports on the total number of inconsistencies found. The entire output of the run is in the JASS_REPOSITORY directory.


procedure icon  To Verify Application and Service Functionality

The verification process for applications and services involves the execution of a well-defined test and acceptance plan. This plan is used to exercise the various components of a system or application to determine that they are in an available and in working order. If such a plan is not available, test the system in a reasonable way based on how it is used. The goal is to ensure that the hardening process in no way affected the ability of applications or services to perform their functions.

1. If you discover that an application or service malfunctions after the system is hardened, use the techniques described in Chapter 2 to determine the problem.

For example, use the truss command. This command can often be used to determine at what point an application is having difficulty. Once this is known, the problem can be targeted and traced back to the change made by the Solaris Security Toolkit software.



Note - Based on the collective experience of many who have deployed the Solaris Security Toolkit software, the majority of problems can be avoided using the approach in this book.



2. In a similar fashion, test the Check PointFirewall-1 NG software, trace any issues back to Solaris Security Toolkit software modifications, and correct the issues.

3. If the final list of packages requires modification, modify the profile, reinstall the system, and repeat the testing.