Implementation Guide For Checkpoint Firewall-1 NG FP1

A Compilation of Best Practice Items for Solaris 8 and NG
From Checkpoint, Sunsolve, Lance Spitzner (my hero),
and every other source that I could trust…
,with a few busted knuckles of my own thrown in.


This document was developed as a general framework/checklist for building a Solaris 8 / Checkpoint FW-1 NG box on Sun4u hardware. It does not represent the opinions or recommendations of anyone but myself. The good stuff, I probably found by digging through web pages, newsgroup posts and documentation. The mistakes are purely my own. I offer it, not as a definitive guide, but, rather, as an index to the steps that I went through in building the firewall. May your builds be easier and better.

Regards,
Stan Hoffman
CISSP, GCIA
Packet_geek@whitehats.ca


Installation Requirements:

Minimum Installation Requirements - Windows (Management Server)

TABLE 4-1 lists the minimum hardware and operating system required for installing a
VPN-1/FireWall-1 Management Server or VPN/FireWall Module.

IMPORTANT: Please note that Table 4-1 is the minimum recommendations from Check Point. The Management Server is also functioning as a Log Server. It is highly recommended that the disk space is larger than the recommended 40 Mbytes to be installed. It would not be a bad idea to have a faster processor to improve performance.

Minimum Installation Requirements - Sun Solaris (Firewall Module)

TABLE 4-3 lists the minimum hardware and operating system required for installing a
VPN-1/FireWall-1 Management Server or VPN/FireWall Module.

Required Patches

During the installation, the Check Point installation program checks your system for
required OS patches.

For the list of required patches, see the Release Notes. Patches can be downloaded
from the Sun® Microsystems website.

Installation Preparation:

Lance Spitzner's Recommendations:
Preparing Solaris 8 / 64-bit for CheckPoint FireWall-1 NG
References: Lance Spitzner's website: http://www.enteract.com/~lspitz
The best place to start in armoring your system is at the beginning, OS installation. 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. 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.

There are 5 required packages you have to add for FW-1 NG to install and function properly. If you did not use the JASS toolkit to automate the build, you will have to add these packages manually. To manually install packages, first mount the CDROM. You will have to do this manually, as volume manager is not installed with Core.

For the Ultra5
firewall #mount -F hsfs -o ro /dev/dsk/c0t2d0s0 /cdrom

For most other Sparc systems
firewall #mount -F hsfs -o ro /dev/dsk/c0t6d0s0 /cdrom

firewall #cd /cdrom/Solaris_2.7/Product
firewall #pkgadd -d . SUNWlibC


Checkpoint's Installation Recommendations:

These are the 5 packages required for CheckPoint FW-1 NG:

system SUNWlibC Sun Workshop Compilers Bundled libC
system SUNWlibCx Sun WorkShop Bundled 64-bit libC

# Required for installing CPfw1-50
system SUNWter Terminal Information

# Required for installing CPshrd-50
# Thanks to Lior Krochmal for pointing this out

system SUNWadmc System administration core libraries
system SUNWadmfw System & Network Administration Framework

Check Point's Recommendations:

1) Packages that should be installed:
SUNWlibC SUNWlibCx SUNWter SUNWadmc SUNWadmfw

2) Packages that should be removed:
SUNWadmr SUNWatfsr SUNWatfsu SUNWauda SUNWaudd
SUNWauddx SUNWcg6 SUNWcg6x SUNWdfb SUNWdtcor
SUNWfcip SUNWfcipx SUNWfcp SUNWfcpx SUNWfctl
SUNWfctlx SUNWftpr SUNWftpu SUNWi15cs SUNWi1cs
SUNWkey SUNWluxdx SUNWluxop SUNWluxox SUNWm64
SUNWm64x SUNWmdi SUNWmdix SUNWnamow SUNWnisr
SUNWnisu SUNWpcelx SUNWpcmci SUNWpcmcu SUNWpcmcx
SUNWpcmem SUNWpcser SUNWpl5u SUNWpsdpr SUNWrmodu
SUNWses SUNWsesx SUNWsndmr SUNWsndmu SUNWsolnm
SUNWssad SUNWssadx SUNWtleux SUNWudf SUNWudfr
SUNWudfrx SUNWusb SUNWusbx SUNWwsr2 SUNWxwdv
SUNWxwdvx SUNWxwmod SUNWxwmox

Package Information for Check Point's Recommendations:

Once the Core Installation Packages are removed and the Checkpoint Recommended Packages are added according to Checkpoint's Recommendation.
Confirming the following packages are being installed by issuing the pkginfo command:
Sun Microsystems Inc. SunOS 5.8 Generic February 2000

# pkginfo
system SUNWadmc System administration core libraries
system SUNWadmfw System & Network Administration Framework
system SUNWcar Core Architecture, (Root)
system SUNWcsd Core Solaris Devices
system SUNWcsl Core Solaris, (Shared Libs)
system SUNWcsr Core Solaris, (Root)
system SUNWcsu Core Solaris, (Usr)
system SUNWesu Extended System Utilities
system SUNWhmd SunSwift SBus Adapter Drivers
system SUNWkvm Core Architecture, (Kvm)
system SUNWlibC Sun Workshop Compilers Bundled libC
system SUNWlibCx Sun WorkShop Bundled 64-bit libC
system SUNWlibms Sun WorkShop Bundled shared libm
system SUNWloc System Localization
application SUNWm64cf M64 Graphics Configuration Software
application SUNWm64w M64 Graphics Window System Support
system SUNWnamos Northern America OS Support
system SUNWnamox Northern America 64-bit OS Support
system SUNWpd PCI Drivers
system SUNWqfed Sun Quad FastEthernet Adapter Driver
system SUNWswmt Install and Patch Utilities
system SUNWxcu4 XCU4 Utilities
#

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 spooling goes. By isolating the /var partition, you protect your root partition from overfilling. By isolating 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 separate 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. 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 30GB hard drive and 1GB of RAM could look as follows:

 
Label Size
/ 1 GB
swap 2 GB (or traditionally 2x amount of RAM)
/var 2 GB
/var/opt/CPfw1-50/log 15 GB
/var/log 5 GB
/opt 2 GB
/usr 1 GB (ReadOnly partition).
/export 2 GB

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.

Patch Installation Instruction:

First, be sure the patch cluster has been unzipped if the cluster was received as a .zip file, then proceed as follows:

1) Decide on which method you wish to install the cluster:

Recommended Method Using Save Feature:

By default, the cluster installation procedure uses the patchadd
save feature to save the original objects being patched. Prior
to installing the patches the cluster installation script will
first determine if enough system disk space is available in
/var/sadm/patch to save the objects and will terminate if not.
Using the default save feature is recommended.

Method Using No Save Option:

It is possible to override the save feature by using the [-nosave]
option when executing the cluster installation script. Using the
nosave option means that you will not be able to back out individual
patches if the need arises.

2) Run the install_cluster script

cd <patch cluster directory>
./install_cluster

By default, a message warning the user to check for minimum disk
space allowance (separate from the save feature) will appear
and allow the user to abort if inadequate space exists. To
suppress this interactive message the "-q" (quiet) option can
be used when invoking install_cluster.

The progress of the script will be displayed on your terminal.
It should look something like:

# ./install_cluster

Patch cluster install script for <cluster name>

Determining if sufficient save space exists...
Sufficient save space exists, continuing...
Installing patches located in <patch cluster directory>
Installing <patch-id>
Installing <patch-id>
.
.
.
Installing <patch-id>


For more installation messages refer to the installation log file:

/var/sadm/install_data/<cluster name>_log

Use '/usr/bin/showrev -p' to verify installed patch-ids.
Refer to individual patch README files for more patch detail.
Rebooting the system is usually necessary after installation.
#

3) Check the log file if more detail is needed.

If errors are encountered during the installation of this cluster,
error messages will be displayed during installation. More details
about the causes of failure can be found in the detail log file:

more /var/sadm/install_data/<cluster name>_log

If this log file previously existed the latest cluster installation
data will be concatenated to the file, so check the end of the file.

4) THE MACHINE SHOULD BE REBOOTED FOR ALL PATCHES TO TAKE EFFECT!!

Securing the System:

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. 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. firewall.profile can be used to customize the firewall builds. This configuration files specifies how your system is built, including what packages are added (as discussed earlier) and the partitioning table. minimimize-firewall.fin Finish script which is used to remove all of the unnecessary packages from your core installation. Both the firewall.profile and the minimize-firewall.fin Finsih script are the only two customized files you will need for JASS to build and secure your Solaris 8 system for a CheckPoint FW-1 NG installation.

Additionally, Titan 4.0 has many scripts for hardening Solaris 8 & 9 on sun4 architecture. http://www.fish.com/titan

Always maintain the latest recommended patch level. To assist in determining this option, please refer to:

http://access1.sun.com/patch.recommended/rec.html

Sample Script for JASS to Strip Down Solaris O/S:

#!/bin/sh
#
# Copyright (c) 2000, 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)minimize-firewall.fin 2.3 01/08/22
#
# Firewall minimization finish script for JASS, removes
# 58 packages from a Solaris 8 Core 64-bit installation.

case ${JASS_UNAME} in

5.8)
PACKAGES='
SUNWadmr SUNWatfsr SUNWatfsu SUNWauda SUNWaudd
SUNWauddx SUNWcg6 SUNWcg6x SUNWdfb SUNWdtcor
SUNWfcip SUNWfcipx SUNWfcp SUNWfcpx SUNWfctl
SUNWfctlx SUNWftpr SUNWftpu SUNWi15cs SUNWi1cs
SUNWkey SUNWluxdx SUNWluxop SUNWluxox SUNWm64
SUNWm64x SUNWmdi SUNWmdix SUNWnamow SUNWnisr
SUNWnisu SUNWpcelx SUNWpcmci SUNWpcmcu SUNWpcmcx
SUNWpcmem SUNWpcser SUNWpl5u SUNWpsdpr SUNWrmodu
SUNWses SUNWsesx SUNWsndmr SUNWsndmu SUNWsolnm
SUNWssad SUNWssadx SUNWtleux SUNWudf SUNWudfr
SUNWudfrx SUNWusb SUNWusbx SUNWwsr2 SUNWxwdv
SUNWxwdvx SUNWxwmod SUNWxwmox
'
;;

*)
log_error "Firewall Minimization is not currently"
log_error "supported under Solaris ${JASS_UNAME}."
;;

esac

if [ ! -z ${PACKAGES} ]; then
log_notice "Minimizing Solaris ${JASS_UNAME} for Firewall installation."

for package in ${PACKAGES}; do
rm_pkg ${package}
done
fi

Hardening The Operating Systems:

By default, Solaris includes many useful services. However, most of these services are not required for a firewalled gateway and pose potential security risks. The /etc/inetd.conf file specifies services the /usr/sbin/inetd daemon will activate. None of the services in this file is essential to the running for FireWall-1.

Confirm the services are commented out, by using the following command:

#grep -v "^#" /etc/inetd.conf

In the /etc/rc2.d and /etc/rc3.d directories, there are scripts launched at boot by the init process. Several of these are not needed. To prevent a script from starting during boot, replace the uppercase "S" with a lowercase "s"

Scripts that my be disabled in the /etc/rc2.d directory

S73nfs.client - used for NFS mounting a system. A firewall should never mount another file system.
S74autofs - used for automounting, a firewall should never mount another file system.
S80lp - used for printing, your firewall should never need to print.
S88sendmail - listens for incoming email. Your system can still send mail (such as alerts) with this disabled.
S71rpc - portmapper daemon, a highly insecure service (required if you are running CDE).
S99dtlogin - CDE daemon, starts CDE by default

Scripts that my be disabled in the /etc/rc3.d directory

S15nfs.server - used to share file systems, a bad idea for firewalls.
S76snmpdx - snmp daemon

Example: Disabling scripts in the /etc/rc2.d directory

#cd /etc/rc2.d
#mv S37nfs.client s37nfs.client
#mv S74autofs s74autofs
#mv S801p s801p
#mv S88sendmail s88sendmail
#mv S71rprc s71rprc
#mv S99dtlogin s99dtlogin
#mv S15nfs.server s15nfs.server

Hardening The Operating Systems (Continued):

Running any GUI (CDE or OpenWindows) is not a good idea. You can disable CDE, the default GUI in Solaris 2.6, with the S99dtlogin startup script (replace the capital S with a small s). To get an idea of how many ports and services CDE requires, type the following command when it is running.

ps -aef | wc - l

Once you are done with the installation and have turned off S99dtlogin and S71rpc (required to run CDE), type the command again and compare how the numbers of services have decreased. The fewer services running, the smaller target the box is. For those of you who installed the Core installation, this is not an issue, as the GUI is not installed.

Disabling Syslog Server:

It is not a good idea for a Firewall to be a syslog server. Logs should be redirected to another syslog server. In Solaris 8, edit script /etc/rc2.d/S74syslog to start syslogd with the "-t" option. This will cause local listening service to be disabled for the syslog daemon and prevent listening on port 514, allowing local logging only.

Testing the Boot Files:

Test all boot files changes by rebooting, using dmesg or examining /var/adm/messages, and checking for extraneous processes in ps -elf output.

Disabling IP Forwarding in the Kernel:

IP forwarding is enabled during the init process, in /etc/rc2.d/S69inet. If the system detects more then 2 interfaces (including the loopback) ip forwarding will be enabled by default. Your system is now a gateway.

It is recommended that IP Forwarding be disabled in the kernel. In this way, IP Forwarding will be never be enabled unless VPN-1/FireWall-1 is working, no matter which of the above options you have chosen.

This section specifies how to enable and disable IP Forwarding on the following platforms: Solaris 2.x

Solaris 2.x (source routed packets)

To turn off IP Forwarding and source routed packets, edit /etc/rc2.d/S69inet and change:
to:

ndd -set /dev/ip ip_forwarding 1
ndd -set /dev/ip ip_forwarding 0
ndd -set /dev/ip ip_forward_src_routed 0

Solaris 2.5 or Later

You can have a system with 2 or more interfaces and not forward packets if you want. This is done one of two ways. First, by touching the file /etc/notrouter. During the init process, /etc/rc2.d/S69inet will look for this file. If it finds it, it turns off ip forwarding by executing the following command.

ndd -set /dev/ip ip_forwarding 0

Additional Security Protection:

1. First we will create the wheel group. The wheel group is a group of select individuals that can execute powerful commands, such as /usr/bin/su. By limiting the people that can access these commands, you enhance the system security. To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group. Then identify critical system binaries, such as /usr/bin/su. Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries). For /usr/bin/su, the commands would be:

/usr/bin/chgrp wheel /usr/bin/su
/usr/bin/chmod 4750 /usr/bin/su

* Note: (Don't forget, for su there is actually another binary in /sbin. For 2.6, this is called /sbin/su.static This is the same thing as /usr/bin/su, however the libaries are statically linked, hence the larger file size. Don't forget to change this file also ).

2. Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv. The r commands use these files to access systems. To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/usr/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/usr/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

3. Also, we want to set the TCP initial sequence number generation parameters. By truly randomizing the initial sequence number of all TCP connections, we protect the system against session hijacking and ip spoofing. This is done by setting TCP_STRONG_ISS=2 in the file /etc/default/inetinit. By default, the system installs with a setting of 1, which is not as secure. This is an example of setting the TCP initial sequence number generation parameters in the file /etc/default/inetinit

# @(#)inetinit.dfl 1.2 97/05/08
#
# TCP_STRONG_ISS sets the TCP initial sequence number generation parameters.
# Set TCP_STRONG_ISS to be:
# 0 = Old-fashioned sequential initial sequence number generation.
# 1 = Improved sequential generation, with random variance in increment.
# 2 = RFC 1948 sequence number generation, unique-per-connection-ID.
#
TCP_STRONG_ISS=2

To protect against possible buffer overflow (or stack smashing) attacks, add the following to lines to /etc/system.

set noexec_user_stack=1
set noexec_user_stack_log=1

4. Next, we make some modifications to the IP module. Add these commands to one of your start up scripts. For detailed information on ndd and tuning ip modules for security, check out Network Settings for Security.

### Set kernel parameters for /dev/ip
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_respond_to_timestamp 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_ignore_redirect 1

5. Last thing I like to do is eliminate as many suid root binaries as possible. suid root binaries pose a high risk, as vulnerable versions can be used to gain root. Since this is a dedicated system with few accounts, most of the suid binaries can be disabled or removed. To find all suid root binaries, run the following command on your system.

find / -type f -perm -4000 -exec ls -lL {} \; | tee -a /var/tmp/suid.txt

Once you have identified all of the suid root binaries, you can remove most of them by changing the permissions to '555', or deleting the binaries entirely. For example, I eliminated the suid bit on the following binaries from a Core installation of Solaris 2.7.

# NOTE: You want to delete '/usr/bin/yppasswd', as it is hard linked
# to '/usr/bin/passwd'.
#
-r-sr-xr-x 1 root bin 15260 Oct 6 1998 /usr/lib/fs/ufs/quota
-r-sr-sr-x 1 root tty 174392 Aug 14 03:32 /usr/lib/fs/ufs/ufsdump
-r-sr-xr-x 1 root bin 869168 Aug 14 03:32 /usr/lib/fs/ufs/ufsrestore
---s--x--x 1 root bin 4316 Oct 6 1998 /usr/lib/pt_chmod
-r-sr-xr-x 1 root bin 8576 Oct 6 1998 /usr/lib/utmp_update
-r-sr-xr-x 1 root sys 27628 Oct 6 1998 /usr/bin/sparcv7/ps
-r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/uptime
-r-sr-xr-x 2 root bin 11528 Oct 6 1998 /usr/bin/sparcv7/w
-rwsr-xr-x 1 root sys 35916 Oct 6 1998 /usr/bin/at
-rwsr-xr-x 1 root sys 13996 Oct 6 1998 /usr/bin/atq
-rwsr-xr-x 1 root sys 12704 Oct 6 1998 /usr/bin/atrm
-r-sr-xr-x 1 root bin 14352 Oct 6 1998 /usr/bin/eject
-r-sr-xr-x 1 root bin 28776 Oct 6 1998 /usr/bin/fdformat
-r-sr-xr-x 1 root bin 29292 Oct 6 1998 /usr/bin/login
-rwsr-xr-x 1 root sys 7736 Oct 6 1998 /usr/bin/newgrp
-r-sr-xr-x 1 root bin 21368 Oct 6 1998 /usr/bin/rcp
-r-sr-xr-x 1 root bin 56280 Oct 6 1998 /usr/bin/rdist
-r-sr-xr-x 1 root bin 16772 Oct 6 1998 /usr/bin/rlogin
-r-sr-xr-x 1 root bin 9332 Oct 6 1998 /usr/bin/rsh
-rws--x--x 1 uucp bin 56240 Aug 14 03:34 /usr/bin/tip
-r-sr-sr-x 2 root sys 99824 Sep 9 1999 /usr/bin/yppasswd
-r-sr-xr-x 1 root bin 12948 Oct 6 1998 /usr/sbin/sparcv7/whodo
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/allocate
-rwsr-xr-x 1 root bin 10000 Aug 14 03:34 /usr/sbin/mkdevalloc
-rwsr-xr-x 1 root bin 10336 Aug 14 03:34 /usr/sbin/mkdevmaps
-r-sr-xr-x 1 root bin 20404 Oct 6 1998 /usr/sbin/ping
-rwsr-xr-x 1 root sys 23000 Aug 14 03:32 /usr/sbin/sacadm
-r-sr-xr-x 1 root bin 22056 Oct 6 1998 /usr/sbin/traceroute
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/deallocate
-rwsr-xr-x 3 root bin 17536 Aug 14 03:34 /usr/sbin/list_devices

Solaris Environment Settings for Security:

Strict Destination Multihoming

Strict destination multihoming prevents packet spoofing on nonforwarding multihomed systems. A Solaris system with IP forwarding disabled and strict destination multihoming enabled will ignore packets sent to an interface from which it did not arrive. This prevents attackers from creating packets destined for networks only connected to a multihomed server that does not forward packets. The system is aware of which interface on which a packet arrives. If a packet appears to be from a
network attached to another interface, the packet is dropped.

This feature can be enabled on the Solaris Operating Environment. It is disabled by default. Use the following ndd command to enable it:

# ndd -set /dev/ip ip_strict_dst_multihoming 1

Forwarding Directed Broadcasts

A directed broadcast is a unicast datagram from a system on a remote network addressed all systems on another network. Once the datagram reaches the router connected to the intended network, the datagram is forwarded to all systems as a
data-link layer broadcast.

Directed broadcasts can be problematic due to the amount of network traffic generated by broadcasts and the ability to send a packet to all systems on a network. An attacker may take advantage of forwarded directed broadcasts to attack and
probe systems. CERT Advisory CA-98.01 describes a denial of service attack called the "smurf" attack after its exploit program. It involves forged ICMP echo request packets sent to broadcast addresses. The source address in the forged packet is set to a target. The result is that the target and intermediate routing machine which forwards the directed broadcasts suffered from network congestion. One recommended action is to disable directed broadcast forwarding at all routers.
Attackers may also send directed broadcasts to probe the network and determine which systems have exploitable vulnerabilities.

A Solaris system with IP forwarding enabled forwards directed broadcasts by default. You can disable it using the following ndd command:

# ndd -set /dev/ip ip_forward_directed_broadcasts 0

Forwarding Source Routed Packets

A source routed packet contains a specific path that datagram should follow to its final destination. Normally, routing decisions are handled by routers. They maintain information on available routes and dynamically update them as new route
information is received. Source routed packets bypass routing decisions made by routers to define their own path to the final destination.

There is not much need for source routing in most networks. Properly configured routers make better decisions about routing. Source routed packets may be an indication of nefarious activity on the network. An attacker may attempt to use
source routed packets to bypass specific routers or internal firewalls or try to avoid a known network intrusion detection system by routing packets around it. Source routed packets are rare. Silently dropping them should affect few if any applications.

A Solaris system with IP forwarding enabled forwards source routed packets by default. It can be disabled with this ndd command:

# ndd -set /dev/ip ip_forward_src_routed 0

Solaris Environment Settings for Security (Continued):

Echo Request Broadcast

An echo request is a common network diagnostic created with the ping command. Echo requests can be sent to broadcast addresses. All systems configured to respond to broadcasted echo requests will send an echo reply. That can be a large number of packets. Even more devastating is the ability to increase the payload size of the
packet. The receiving system will return all of the data contained in the payload. Extremely large payloads will be fragmented across several packets, thus further increasing network traffic. Disable responding to echo request broadcasts with this
ndd command:

# ndd -set /dev/ip ip_respond_to_echo_broadcast 0

ICMP - Redirect Errors

Redirect Errors are used by a router to inform a host sending data to use a different router. Both routers involved in the redirection must be connected to the same subnet. The sending host will then install a new host routing entry in the routing
table for the destination host. Unlike ARP entries, these will not time out and be deleted. Most systems check the redirect message for errors and potential problems prior to modifying the routing table.

Receiving Redirect Errors

An attacker may forge redirect errors to hosts to install bogus routes. This may create a denial of service attack since the different router may not be a router at all. There are some rules governing valid redirect errors, all of which can be spoofed
easily. There are several attack tools do this. Use this ndd command to ignore ICMP redirect errors:

# ndd -set /dev/ip ip_ignore_redirect 1

Sending Redirect Errors

Only routers need to redirect errors, never hosts or even multihomed systems. Disable the sending of redirect errors with this ndd command:

# ndd -set /dev/ip ip_send_redirects 0

IP Spoofing Attacks Prevention

Solaris 2.6

There are several settings available on Solaris systems: the predictable method (0), an improved method with random increment value (1), and the RFC 1948 method (2). The default method for all revisions of Solaris is 1.

Solaris 2.6 and 7 releases have and 7 releases should be modified to use method 2.

To do this, edit the /etc/default/inetinit file and change the following line:

TCP_STRONG_ISS=1
to
TCP_STRONG_ISS=2

Driver Installation for Quad (qfe) Interface:

1. Check the /etc/driver_aliases file for the line required by the adapter.

# grep 'pci_pci "pci1011,25"' /etc/driver_aliases

If this line already exists in the driver_aliases file, you can proceed with the adapter installation, which is described in the next section. Otherwise, you will need to add this line to the file before installing the adapter.

2. Using a text editor, add the following line to the end of the /etc/driver_aliases file.

pci_pci "pci1011,25"

Once you have added this line to the file, you can safely install the adapter.

Verifying the Installation

After you have installed the Sun Quad FastEthernet PCI adapter, but before you boot your system, perform the following tasks to verify the installation. Refer to the Solaris 2.x Handbook for SMCC Peripherals manual or your Solaris documentation for the detailed instructions.

1. Power on the system, and when the banner appears, press the Stop-A keys to interrupt the boot process and to get to the ok prompt.
2. Use the show-devs command to list the system devices.

You should see lines in the list of devices, similar to the example below, specific to the Sun Quad FastEthernet PCI adapter:

ok show-devs
...
/pci@1f,2000/pci@2/SUNW,qfe@0,1
/pci@1f,2000/pci@2/SUNW,qfe@1,1
/pci@1f,2000/pci@2/SUNW,qfe@2,1
/pci@1f,2000/pci@2/SUNW,qfe@3,1
...


The SUNW,qfe@x,1 entries identify the adapter's four Ethernet devices.

Local-Mac-Address Property:

Each of the network interfaces of the Sun Quad FastEthernet PCI adapter have a MAC (Media Access Control) address, which represents the 48-bit ethernet address for that channel. The OpenBoot firmware reports this MAC address via the local-mac-address property in the device nodes corresponding to the network interfaces.

A system is not obligated to use this assigned MAC address if it has a system-wide MAC address. In such cases, the system-wide MAC address applies to all network interfaces on the system.

The device driver, or any other adapter utility, can use the network device's MAC address (local-mac-address) while configuring it. In the Solaris 2.6 operating system (and later Solaris revisions), you will be able to use a channel's MAC address when booting over the network.

The mac-address property of the network device specifies the network address (system-wide or local-mac-address) used for booting the system. To start using the MAC addresses assigned to the network interfaces of the Sun Quad FastEthernet PCI adapter, set the NVRAM configuration variable local-mac-address? to true

ok setenv local-mac-address? true

Configuring the Hostname File(s):

After installing the Sun Quad FastEthernet driver software, you must create a hostname.qfe<num> file for the adapter's Ethernet interfaces. You must also create both an IP address and a host name for its Ethernet interfaces in the /etc/hosts file.

1. At the command line, use the grep command to search the /etc/path_to_inst file for qfe devices.

# grep qfe /etc/path_to_inst
"/pci@1f,2000/pci@2/SUNW,qfe@0,1" 4 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@1,1" 5 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@2,1" 6 "qfe"
"/pci@1f,2000/pci@2/SUNW,qfe@3,1" 7 "qfe"


In the example above, the four SUNW,qfe@x,1 instances are from a Sun Quad FastEthernet PCI adapter installed in slot 2. For clarity, the instance numbers are bold.

2. Create an /etc/hostname.qfe<num> file, where <num> corresponds to the instance number of each interface you plan to use.

If you wanted to use all of the adapter's interfaces in Step 1's example, you would need to create four files:

Filename Instance Number Adapter Ethernet Channel (See Figure 1-2)

Filename
Instance Number
Adapter Ethernet Channel (See figure 2)
/etc/hostname.qfe0
0
0
/etc/hostname.qfe0
1
1
/etc/hostname.qfe0
2
2
/etc/hostname.qfe0
3
3

Using the instance examples in Step 1, the following example shows the four /etc/hostname.qfe<num> files required for a system called fw01 that has a Sun Quad FastEthernet PCI adapter (fw01-qfe0, fw01-qfe1, fw01-qfe2, and fw01-qfe3).

# cat /etc/hostname.hme0
fw01
# cat /etc/hostname.qfe0
fw01-qfe0
# cat /etc/hostname.qfe1
fw01-qfe1
# cat /etc/hostname.qfe2
fw01-qfe2
# cat /etc/hostname.qfe3
fw01-qfe3

3. Create an appropriate entry in the /etc/hosts file for each active qfe channel.

Using the example in Step 1, you will have:

# cat /etc/hosts
#
# Internet host table
#
# Note - 10.2.2.5 Subnet Mask 255.255.255.248
#
127.0.0.1 localhost
10.2.3.2 fw01 loghost
209.27.3.252 fw01-qfe0
172.20.1.252 fw01-qfe1
192.168.1.252 fw01-qfe2
192.168.10.252 fw01-qfe3
10.2.3.1 fwmngt

4. Reboot your system.

Hostname.* File:

The file /etc/hostname.* is critical, this is what causes the device to be plumbed. During the boot process, the /etc/rcS.d/network.sh file reads all the /etc/hostname.* files and plumbs the devices. Once plumbed, the devices are configured by reading the /etc/hosts and the /etc/netmasks file. By reading these two files, the device is configured for the proper IP and netmask, and brought to an up state. Lets take the device hme0 as an example. During the boot process, /etc/rcS.d/network.sh looks for any /etc/hostname.* files. It finds /etc/hostname.hme0, which contains the following entry.

Fw01

/etc/rcS.d/rootusr.sh looks in /etc/hosts and resolves the name fw01 with an IP address of 10.2.2.5. The device hme0 is now assigned this IP address. The script then looks at /etc/netmasks to find the netmask for that IP address. With this information, the startup script brings up interface hme0 with an IP address of 10.2.2.5 and a netmask of 255.255.255.248. It may seem redundant having the script review the netmask of a class C address. However, do not forget that, starting with 2.6, Solaris supports both classless routing and VLSM (Variable Length Subnet Masks).

Specifying Netmasks:

To define the netmasks of your network, you use the file /etc/netmasks. This file is read during the bootup process, defining the makeup of your networks. Here is an example of a /etc/netmasks file.

#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
# network-number netmask
#
# The term network-number refers to a number obtained from the Internet Network
# Information Center. Currently this number is restricted to being a class
# A, B, or C network number. In the future we should be able to support
# arbitrary network numbers per the Classless Internet Domain Routing
# guidelines.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
#
#
10.2.3.2 255.255.255.0
209.27.3.252 255.255.255.0
172.20.1.252 255.255.255.0
192.168.1.252 255.255.255.0
192.168.10.252 255.255.255.0

Network Interface(s) Configuration:

When using a quad (qfe) network interface card, set the MAC addresses of different interfaces to different values using ifconfig. By default, all four interfaces of the quad card are assigned the same MAC address. This change yields significant improvement in network traffic throughput

Force all LAN network interfaces to maximum speed and full duplex, when applicable. Disable the auto-negotiation feature.

The procedure for checking and setting link parameters of qfe interfaces is the same as for hme with the additional consideration of the interface "instance". For a single four port qfe card, the instances are 0-3: qfe0,qfe1,qfe2,qfe3.

An additional qfe card would have interfaces qfe[4-7]

Checking the current running speed(s)

  Choose the interface instance:
   
  # ndd -set /dev/qfe instance 0
   
  This selects the first instance, qfe0. Note that the default instance is 0.
   
  Check the status, speed & mode
   
  # ndd -get /dev/qfe link_status
1 = up
0 = down
   
  # ndd -get /dev/qfe link_speed
1 = 100Mb
0 = 10Mb
   
  # ndd -get /dev/qfe link_mode
1 = Full Duplex (FDX)
0 = Half Duplex (HDX)

To check another instance, repeat the "ndd -set /dev/qfe instance N, where N is the instance id, and re-run the "ndd -get..." commands above.

Configuring via /etc/system

This will set all qfe interfaces to 100 full-duplex. Select only one value set to 1, as appropriate for your system.

  Forcing 100Mb Full Duplex (FDX)
Note: all line MUST be used.
   
  ndd -set /dev/qfe instance 0
ndd -set /dev/qfe adv_100fdx_cap 1
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0

Configuring individual interfaces via ndd commands

This script is usually installed as /etc/rc3.d/S99qfe.

#!/bin/sh
# /etc/rc3.d/S99qfe to set port modes
# set the speed as defined
# for all the ports on QFE cards 0 and 1 (0-7)
# and for hme ports 0 and 1

n100H=""
n100F="0 1 2 3"
n10F=""
n10H=""
HMEF="0 1"

for nic in $n100F
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 1
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $n100H
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 1
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

(continued)


for nic in $n10F
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 1
ndd -set /dev/qfe adv_10hdx_cap 0
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $n10H
do
ndd -set /dev/qfe instance ${nic}
ndd -set /dev/qfe adv_100fdx_cap 0
ndd -set /dev/qfe adv_100hdx_cap 0
ndd -set /dev/qfe adv_10fdx_cap 0
ndd -set /dev/qfe adv_10hdx_cap 1
ndd -set /dev/qfe adv_autoneg_cap 0
done

for nic in $HMEF
do
ndd -set /dev/hme instance ${nic}
ndd -set /dev/hme adv_100fdx_cap 1
ndd -set /dev/hme adv_100hdx_cap 0
ndd -set /dev/hme adv_10fdx_cap 0
ndd -set /dev/hme adv_10hdx_cap 0
ndd -set /dev/hme adv_autoneg_cap 0
done

Bringing up the Network Interface(s):

The first step in bringing up an interface is "plumbing" the interface. By plumbing, we are implementing the TCP/IP stack. We will use the above interface, hme0, as an example. Lets say we had just physically added this network interface card and rebooted, now what? First, we plumb the device with the plumb command.

ifconfig hme0 plumb

This sets up the streams needed for TCP/IP to use the device. However, the stack has not been configured as you can see below.

hme0: flags=842<BROADCAST,RUNNING,MULTICAST> 
    mtu 1500 
inet 0.0.0.0 netmask 0
ether 8:0:20:9c:6b:2d

The next step is to configure the TCP/IP stack. We configure the stack by adding the IP address, netmask, and then telling the device it is up. All this can be down in one command, as seen below.

Fw01 #ifconfig hme0 10.2.2.5 netmask 255.255.255.248 up

This single command configures the entire device. Notice the up command, which initializes the interface. The interface can be in one of two states, up or down. When an interface is down, the system does not attempt to transmit messages through that interface. A down interface will still show with the ifconfig command, however it will not have the word "up" on the first line.

Adding Static Route:

The route statement for the static NAT configuration needs to be put in the Solaris start up files. Typically routing commands are put in /etc/rc2.d/S69inet.

Edit this file and add the appropriate route command:

route add <static_external_ip> <static_internal_ip>

This would be a host route for configurations where the static_internal_ip is on the same network as the VPN-1/FireWall-1 Module machine. It is also possible, if the host is on a different network, to use the route command to specify a network route, like this:

route add <static_external_ip> mask <netmask> <gateway IP>

Where gateway_ip is the IP address of the next hop router in the path to the network in which the static NAT host is located.

Troubleshooting Network Interface(s):

ifconfig -a will show you which interfaces are currently installed and active. Remember, just because you added the physical network interface card does NOT mean it is active. If you do an ifconfig before you have configured the device, the interface will not show up. Once configured however, the typical output of the ifconfig -a command would look like this:

lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232 
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.132 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:9c:6b:2d

Here we see two interfaces, lo0 and hme0. lo0 is the standard loopback interface found on all systems. hme0 is a 10/100 Mbps interface. All hme interfaces are 10/100 Mbps, all le interfaces are 10 Mbps, all qe interface are quad 10 Mbps, and qfe interfaces are quad 10/100 Mbps. There are three lines of information about the interface. The first line is about the TCP/IP stack. For the interface hme0, we see the system is up, running both broadcast and multicast, with a mtu (maximum transfer unit) of 1500 bytes, standard for an Ethernet LAN. Notrailers is a flag no longer used, but kept for backwards compatibility reasons.

The second line is about the IP addressing. Here we see the IP address, netmask in hexadecimal format, and the broadcast address. The third line is the MAC address. Unlike most interfaces, Sun Microsystems? interfaces derive the MAC addressing from the NVRAM, not the interface itself. Thus, all the interfaces on a single SPARC system will have the same MAC address. This does not cause a problem in routing, since most NICs are always on a different network. Note, you must be root to see the MAC address with the ifconfig command, any other user will only see the first two lines of information.
Once you have mastered the tricks to modifying your interfaces, troubleshooting should be easier. Several things I always look for when troubleshooting an interface. First, when working with an unfamiliar machine, often you do not know how many physical interfaces are on the machine. A quick way to tell is use dmesg, this will give you information on the physical hardware. Look for le0, qfe0, hme0, or qe0. These are the names assigned to the physical devices.

If an interface is not responding to the network, check to be sure it is the correct IP address and netmask. The ifconfig command is a quick and temporary way to change IP and netmask information for troubleshooting purposes. Mtu (maximum transfer unit) is another possibility. Some systems may have problems communicating due to fragmented packets. Changing the mtu size may solve that problem. You'll notice that you did not have to set the mtu size in the examples above, these are set to defaults automatically, such as 1500 for Ethernet interfaces.

If that fails, try bringing the face down, then reinitializing it with the up command. If nothing else works, unplumb the device, then plumb it again. Basically, this reinstalls the TCP/IP stack.

Performance Tuning:

Performance tuning a VPN-1/FW-1 Server is an important step during, and after an installation. Capacity planning is important before the installation.

Here are some good guidelines to follow:

Tunning the TCP parameters:

1) Tuning the TCP high-water parameters for maximum throughput. The default values are set to 8192.

  ndd -set /dev/tcp tcp_xmit_hiwat 65535
ndd -set /dev/tcp tcp_recv_hiwat 65535

2) Tuning the TCP Slow Start and TCP queue sizes affects performances.

 

  In /etc/system:
   
  set tcp:tcp_conn_hash_size = 16384
ndd -set /dev/tcp tcp_slow_start_initial 2 (Default = 1)
ndd -set /dev/tcp tcp_conn_req_max_q 1024 (Default = 128)
ndd -set /dev/tcp tcp_conn_req_max_q0 4096 (Default = 1024)
ndd -set /dev/tcp tcp_close_wait_interval 60000 (Default = 240000)

Example:

  vi /etc/system
   
  set tcp:tcp_conn_hash_size = 16384
ndd -set /dev/tcp tcp_slow_start_initial 2
ndd -set /dev/tcp tcp_conn_req_max_q 1024
ndd -set /dev/tcp tcp_conn_req_max_q0 4096
ndd -set /dev/tcp tcp_close_wait_interval 60000

Increasing the open file descriptors:

Increasing the number of open file descriptors is especially relevant for busy security servers. This can be added into the /etc/system file:

set rlim_fd_max = 16384 (Default = 1024)
(Minimum recommended)

This parameter is a hard limit on file description that a single process might have open. This modification should be at least twice the tcp_conn_req_max_q0 parameters.

The rlim_fd_cur is the soft limit on the file descriptors. The soft limit (rlim_fd_cur) is initially allocated to a user process. More file descriptors can be provided to this process, as needed, up to the hard limit (rlim_fd_max).

To view the current hard and soft limits on the file descriptors, use the following commands:

  ulimit -Sn
ulimit -Hn
  Soft limit (rlim_fd_cur)
Hard limit (rlim_fd_max)

To verify the tcp_conn_req_max_q0 parameter, type in the following command:

  ndd /dev/tcp tcp_conn_req_max_q0

Tweaking the memory allocation parameters:

By default, VPN-1/FW-1 allocates 3MB of memory for the kernel. Every simple connection (not authenticated or encrypted) requires about 70 bytes of memory, Encrypted (IKE) traffic requires 3 Kb per encrypted tunnel. Based of these values, it is possible to estimate the amount of memory VPN-1/FW-1 will require to support the given number of concurrent connections.

A general guideline it is a good idea to allocate 16 MB of memory for a busy firewall:

On Solaris, edit the /etc/system file and add the following set parameter:

Set fw:fwhmem = 0x1000000

Installing Check Point SVN Foundation:

Check Point SVN Foundation

For a new installation, install the NG FP1 package.
For upgrading an existing 4.0/4.1 installation, install the NG FP1 package.
For upgrading an existing NG installation, install the NG FP1 patch.

Solaris

Patch
1) Download cpshared_NG_FP1_0352_1_solaris_patch.tgz to a temporary directory and extract
the files.

2) Run the patchadd command, giving the CPSVNSP500001-01 directory as an argument:

Package

3) Download cpshared_NG_FP1_0352_1_solaris_package.tgz to a temporary directory and extract
the files.

4) Run the pkgadd command, giving the CPshrd-50 directory as an argument:

patchadd CPSVNSP500001-01
pkgadd -d . CPshrd-50

Installing Check Point Firewall-1 NG:

Solaris

Patch
1) Download fw1_NG_FP1_51129_2_solaris_patch.tgz to a temporary directory and extract the
files.

2) Run the patchadd command, giving the CPFWSP500001-01 directory as an argument:

Package

Installing FW-1 NG

1) Download fw1_NG_FP1_51129_2_solaris_package.tgz to a temporary directory and extract the
files.

2) Run the pkgadd command, giving the CPfw1-50 directory as an argument:

patchadd CPFWSP500001-01
pkgadd -d . CPfw1-50

Please make sure you reboot the Firewall Module after the packages have been added.

Installation of <CPfw1-50> was successful.

# reboot
syncing file systems... done
rebooting...
Resetting ...

The system is coming up. Please wait.
checking ufs filesystems
/dev/rdsk/c0t0d0s3: is clean.
/dev/rdsk/c0t0d0s4: is clean.
/dev/rdsk/c0t0d0s6: is clean.
/dev/rdsk/c0t0d0s7: is clean.
Starting IPv4 routing daemon.
Setting default IPv4 interface for multicast: add net 224.0/4: gateway fw01
cprid started...
Product fw-1 is not configured.
The system is ready.


Configuring Check Point Firewall-1 NG:

# cpconfig

Welcome to Check Point Configuration Program
=================================================
Please read the following license agreement.
Hit 'ENTER' to continue...

Do you accept all the terms of this license agreement (y/n) ? y

Which Module would you like to install ?
-------------------------------------------
(1) VPN-1 & FireWall-1 Enterprise Primary Management and Enforcement Module
(2) VPN-1 & FireWall-1 Enforcement Module
(3) VPN-1 & FireWall-1 Enterprise Primary Management
(4) VPN-1 & FireWall-1 Enterprise Secondary Management
(5) VPN-1 & FireWall-1 Enterprise Log Server

Enter your selection (1-5/a) [1]: 2

**************** VPN-1 & FireWall-1 kernel module installation ****************
installing VPN-1 & FireWall-1 kernel module...
FW-1: driver installed
VPN-1: driver installed
Done.
**************** Interface Configuration ****************
Scanning for unknown interfaces...
Would you like to install the High Availability product ? (y/n) [y] ?
IP forwarding disabled
Hardening OS Security: IP forwarding will be disabled during boot.
Generating default filter
Default Filter installed
Hardening OS Security: Default filter will be applied during boot.
This program will guide you through several steps where you
will define your VPN-1 & FireWall-1 configuration.
At any later time, you can reconfigure these parameters by
running cpconfig

Configuring Licenses...
=======================
Host Expiration Features

Do you want to add licenses (y/n) [n] ? y_ _n

Configuring Groups...
=====================
VPN-1 & FireWall-1 access and execution permissions
-------------------------------------------
Usually, a VPN-1 & FireWall-1 module is given group permission
for access and execution.
You may now name such a group or instruct the installation
procedure to give no group permissions to the VPN-1 & FireWall-1 module.
In the latter case, only the Super-User will
be able to access and execute the VPN-1 & FireWall-1 module.

Please specify group name [<RET> for no group permissions]:

No group permissions will be granted. Is this ok (y/n) [y] ? y

Setting Group Permissions... Done.

Adding Local Licenses to Check Point Firewall-1 NG:

Adding Licenses using the Local Licensing Model

# cpconfig
This program will let you re-configure
your VPN-1 & FireWall-1 configuration.

Configuration Options:
----------------------
(1) Licenses
(2) SNMP Extension
(3) Groups
(4) PKCS#11 Token
(5) Secure Internal Communication
(6) Disable Check Point High Availability/State Synchronization
(7) Automatic start of Check Point Products
(8) Exit

Enter your choice (1-8) :1

Configuring Licenses...
=======================
Host Expiration Features


Do you want to [A]dd or [D]elete a license. ('q' to quit): a

Do you want to add licenses [M]anually or [F]etch from file: f

Please enter the file name: CPLicenseFile.lic


Adding Local Licenses to Check Point Firewall-1 NG:

Adding Licenses using the Local Licensing Model

# cpconfig
This program will let you re-configure
your VPN-1 & FireWall-1 configuration.

Configuration Options:
----------------------
(1) Licenses
(2) SNMP Extension
(3) Groups
(4) PKCS#11 Token
(5) Secure Internal Communication
(6) Disable Check Point High Availability/State Synchronization
(7) Automatic start of Check Point Products
(8) Exit

Enter your choice (1-8) :1

Configuring Licenses...
=======================
Host Expiration Features


Do you want to [A]dd or [D]elete a license. ('q' to quit): a

Do you want to add licenses [M]anually or [F]etch from file: f

Please enter the file name: CPLicenseFile.lic


Adding Hostname Entry for Management Console and FW-1

On the management console, add the hostname for the firewall in the hosts file:

Hosts File Path Location on Windows 2000:

EDIT (Drive Letter:)\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
10.2.3.2 fw01

On the Firewall Module, make sure that the hosts file contacts the Management Console

# cat /etc/hosts
#
# Internet host table
#
# Note - 10.2.2.5 Subnet Mask 255.255.255.248
#
127.0.0.1 localhost
10.2.3.2 fw01 loghost
209.27.3.252 fw01-qfe0
172.20.1.252 fw01-qfe1
192.168.1.252 fw01-qfe2
192.168.10.253 fw01-qfe3
10.2.3.1 fwmngt


Checking Cluster XL Licensing Errors

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-1999 Microsoft Corp.

C:\>cd \winnt\fw1\ng\bin


C:\WINNT\FW1\NG\bin>cplic print
Warning: Can't find ::CPMP-CXL-HA-1-NG in cp.macro. License version might be no
t compatible
Host Expiration Features
10.2.3.1 Never CPMP-CXL-HA-1-NG CK-7F5E720E6499
10.2.3.1 Never CPVP-VEE-U-3DES-MGMT-NG FW1:5.0:DBVR_UNLIMIT CK-E9E5
C332A925


C:\WINNT\FW1\NG\bin>cplic check ha
Warning: Can't find ::CPMP-CXL-HA-1-NG in cp.macro. License version might be no
t compatible
cplic check 'ha': no license

C:\WINNT\FW1\NG\bin>cprlic print ha
Warning: Can't find ::CPMP-CXL-HA-1-NG in cp.macro. License version might be no
t compatible
Operation failed. Module: ha not found.
Please make sure that you enter the network object name as it appears in the Pol
icy Editor.

C:\WINNT\FW1\NG\bin>cplic print
Warning: Can't find ::CPMP-CXL-HA-1-NG in cp.macro. License version might be no
t compatible
Host Expiration Features
10.2.3.1 Never CPMP-CXL-HA-1-NG CK-7F5E720E6499
10.2.3.1 Never CPVP-VEE-U-3DES-MGMT-NG FW1:5.0:DBVR_UNLIMIT CK-E9E5
C332A925


C:\WINNT\FW1\NG\bin>