Armoring Solaris: II

Preparing Solaris 8 64-bit for CheckPoint FireWall-1 NG

Lance Spitzner
http://www.spitzner.net

Last Revised: November 5, 2001

Firewalls are one of the fastest growing technical tools in the field of information security. However, a firewall is only as secure as the operating system it resides upon. This article is a continuation of the original Armoring Solaris article, focusing on building a minimized Solaris 8 64-bit for CheckPoint FW-1 NG firewall. This article does not include an updated script for the automated securing of the new installation, as there was in Armoring Solaris. Instead, we will be using . This is a new tool developed and released by Sun for the secure deployment of the Solaris platform. In otherwords, I'm not going to develop a tool to automate the secure build since that tool is already out there.

Installation

The best place to start in armoring your system is at the beginning, OS installation. Since this is your firewall, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity. Place your system in an isolated network. At no time do you want to connect your unprotected system to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a newly installed system probed, scanned and exploited within 15 minutes of connecting to the Internet. To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files.

Once you have placed your future firewall box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. The idea is to load the minimum installation, while maintaining maximum efficiency. The less software that resides on the box, the fewer potential security exploits or holes. I recommend Core installation. I prefer Core because this is the absolute miminum installation, creating a more secure operating system. However, packages can even be removed from a Core installation, creating a more secure platform for our firewall. Note: the package listing below is based on a Core installation using Solaris 8 distribution 04/01, which automatically includes 64-bit support with the Core installation. Regardless of which release of Solaris 8 you use, you want to have the same number of packages at the end. The installation was done on a Ultra5 sun4u with a single quad-ethernet card.

• Listing of 83 packages for Core installation with 64-bit OS support.
• Listing of 58 packages that are NOT required and can be removed.
• Listing of 5 packages required for FW-1 NG support.
• Listing of 30 total packages your installation should look like.
• Listing of optional packages you may want to add to your firewall.

If you require a GUI, need additional functionality, or are new to Solaris, then you may want to consider the End User installation. Be aware, using End User installation does add almost 100 additional packages, exposing the system to far greater risk, so use Core installation whenever possible. Anything above the End User package, such as Developer, is adding useless but potentially exploitable software. For more information on building a minimal installation, refer to Solaris Minimization for Security.

Partitioning and patching

During the installation process, you will be asked to partition your system. Partitioning helps security in two ways. First, you can protect critical patitions, such as '/' partition, from filling up by creating seperate patitions for logging and mail. Second, partitioning allows you to restrict which partitions have which capabilities, such as making the '/usr' partition, for all the system binaries, read only.

Therefore, I recommend a separate partition for both "/var" and "/usr". "/var" is where all the system and firewall logging and email spoolling goes. By isolating the /var partition, you protect your root partition from overfilling. By isoloating the /usr partition, we can create this read-only, helping to protect system binaries from modification or potential remote exploit. You may want to consider an seperate partition for "/opt' also, as this is where the FW-1 NG binaries will be located.

Firewall-1 NG logs and configuration files are located in "/var/opt/CPfw1-50". Most Solaris systems have two or more drives, such as the Ultra 10 or 2 IDE drives for an x86. If you are not mirroring the second drive, dedicate the drive for all the firewall logs and configs. Once again, this protects all the other partitions from filling up. With such a setup, a 20GB hard drive and 128MB of RAM could look as follows:

/	everything else
swap	256MB (or traditionally 2x amount of RAM)
/var	400 MB
/var/opt/CKPfw-50	15GB or 2nd drive
/usr	500MB (if you want seperate ReadOnly partition))

Once the system has rebooted after the installation, be sure to install the Recommended and Security patch cluster from Sun. Also, FW-1 NG requires two additional patches that are not part of the cluster, specifically 108434-02 and 108435-02. You will have to download and install these patches in addition to the patch cluster. Be sure to use your go between box to get the patches, the firewall box should always remain on an isolated network. Patches are CRITICAL to maintaining a secure firewall and should be updated at least once a week. http://www.securityfocus.com maintains an excellent vulnerability database.

Securing the system

In the original paper Armoring Solaris, I went into detail on how your Solaris system should be properly secured. In this paper I will not attempt to do that. Security engineers from Sun Microsystems have released an excellent series of papers (called the Blueprint series) which document in far better detail how to properly secure your Solaris system. I refer you to these excellent documents to learn more about securing Solaris. The Solaris Security blueprint series can be found online at http://www.sun.com/security/blueprints.

In the original paper Armoring Solaris, I supplied a script that automated the armoring process of your Solaris system. Once again, I have chosen not to include such a script with this documents. Security engineers from Sun Microsystems Alex Noordergraaf and Glenn Brunette have developed a tool that automates the secure build process. The tool, called Solaris Security Toolkit (JASS), can be used to secure a system while you build it using Jumpstart, or can secure a system that is already installed. I highly recommend this tool, especially if you will be building multiple systems. JASS requires several configuration files to customize your system builds. I have included such a configuration file, called firewall.profile that can be used to customize the firewall builds. This configuration files specifices how your system is built, including what packages are added (as discussed earlier) and the partitioning table. I have also included a minimimize-firewall.fin Finish script which is used to remove all of the unecessary packages from your core installation. Both the firewall.profile and the minimize-firewall.fin Finsih script are the only two customzied files you will need for JASS to build and secure your Solaris 8 system for a CheckPoint FW-1 NG installation.

Conclusion

The purpose of this paper was to detail how to build a minimized, secured Solaris 8 64-bit platform for a CheckPoint FW-1 NG installation. We focused specifically on the minimal amount of packages and system partitioning required for a successful installation. This article did NOT include a step-by-step armoring process, as Sun Microsystems has released the Blueprint Series. Also, this article did NOT include a toolkit to automate the secure build process, as the tool JASS already has this functionality. However, this article does include two customized JASS configuration files to assist you in building your secured system. It is hoped that this article has helped you build the most secure system possible.

Author's bio

Lance Spitzner is currently an active member of the Honeynet Project. He enjoys learning by blowing up systems in his home lab. Before this, he was an Tanker in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@honeynet.org.

---

Thanks to Lance Spitzner for permission to re-publish the article.
Original text: http://www.spitzner.net/armoring2.html