By Lance Spitzner
Preparing Solaris 8 64-bit for CheckPoint FireWall-1 NG
Lance Spitzner
http://www.spitzner.net
Last Modified: 20 July, 2002
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 Solaris Security Toolkit (JASS).
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 - 400MB
/var/opt/CPfw1-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 .
|