Before You Begin

This section will prepare you to install the Next Generation product. We will discuss each step of the installation process so that you understand its importance, and we will guide you in your endeavor to secure your network. The list of minimum system requirements (as defined by Check Point) is outlined in Table 12.1. You can find these online at www.checkpoint.com/products/supported_platforms/index.html.

Table 12.1: Minimum System Requirements

System Requirement	Primary Management & Enforcement Module	GUI Clients (Policy Editor, Log Viewer, etc)
Operating Systems	Microsoft Win2k Server and Advanced Server SP0 and SP1 Windows NT 4.0 SP6a Sun Solaris 7 (32-bit mode only)[*] Sun Solaris 8 (32- or 64-bit mode)[**] RedHat Linux 6.2, 7.0 and 7.2	Microsoft Win2k Sun Solaris SPARC Windows 98/ME Windows NT 4.0 SP4, SP5 and SP6a
Disk Space	40 MB	40 MB
CPU	300+ MHz	No minimum specified
Memory	128 MB	32 MB
Network Interfaces	ATM, Ethernet, Fast Ethernet, Gigabit Ethernet, FDDI, Token Ring	Any supported by the operating system
Media	CD-ROM	CD-ROM
[*]You must have patch 106327 on Solaris 2.7. [**]You must have patches 108434 and 108435 on Solaris 2.8.

Solaris patches can be obtained from http://sunsolve.sun.com.

Note

To check whether your Solaris machine is in 32- or 64-bit mode, use the following commands:

• isainfo –b

• isainfo –vk

To change from 64- to 32-bit mode in Solaris 2.7 or 2.8, perform the following actions:

1. Enter EEPROM mode using the STOP-A keyboard combination.

2. Type setenv boot-file kernel/unix and press Enter.

3. Reboot.

4. If the machine has difficulty booting, use the set-defaults command to return to 64-bit mode.

To change from 32- to 64-bit mode, do the following:

1. Enter EEPROM mode using the STOP-A keyboard combination.

2. Type setenv boot-file /platform/sun4u/kernel/sparcv9/unix and press Enter.

3. Reboot.

Performance of your firewall software will rely in large part on the hardware you choose. It is highly recommended that you increase your hardware requirements above the minimum listed in Table 12.1 in real-world environments. Keep in mind that your management station will be handling logs from each module it controls, so you should ensure that you have adequate disk space, memory, and CPU to handle these connections.

Figure 12.1: Check Point's User Center

Before you start your installation, make sure that you complete the items listed as follows:

• Get your licenses.

• Secure the Host.

• Configure routing and test network interface cards.

• Enable IP forwarding.

• Configure Domain Name Service (DNS).

• Prepare for the Check Point Installation and Configuration Screens.

Obtaining Licenses

Check Point licenses have changed (again) with the Next Generation release. You can obtain a license through your Check Point Value Added Reseller (VAR) or you can use the Check Point User Center to license your products at https://usercenter.checkpoint.com/UserCenter/index.jsp (see Figure 12.1). There are two options when it comes to licensing your firewall modules. You can either have them tied to their individual IP addresses (external interface recommended) as with previous versions, or you can tie them all to the management station's IP address. These licenses are called local and central, respectively. All licenses are maintained on the management console, and administrators can add or remove licenses using the SecureUpdate management tool.

The Management Module itself must have a local license based on its own IP address. The nice thing about using central licenses for the Enforcement Modules is that you can change their IP addresses without having to replace the license, and you can easily move a license from one module to another.

It is always best to obtain your licenses before you install the firewall software. The program will ask you for your license details during the install procedure. If you cannot obtain your permanent license prior to the install, then you should ask for an evaluation license. Check Point's evaluation licenses have full functionality for all VPN-1/FireWall-1 features. They are usually valid for one month, and the product is not adversely affected in any way while running with an evaluation license.

Securing the Host

With any firewall installation, it is important to consider the security of the host computer on which you are installing the firewall software. There are some guidelines available on the Internet for securing the various operating systems. The following is a list of some good guides:

• WinNT http://support.checkpoint.com/kb/docs/public/os/winnt/pdf/Securing_NT.pdf

• Solaris http://support.checkpoint.com/kb/docs/public/os/solaris/pdf/strip-sunserver.pdf

• Solaris www.spitzner.net/armoring2.html

• Linux www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Security-HOWTO.html

Lance Spitzner also has several great papers at www.spitzner.net, which you might want to check out.

When installing the firewall, you should start out by installing the base operating system (OS) without any bells or whistles, and then apply any necessary OS patches. You should not install any additional Internet servers on your firewall host, either. For example, you should not have Internet Information Server (IIS) or a File Transfer Protocol (FTP) server running on your firewall since these services could be vulnerable to attack.

Disabling Services

Probably the most important step in any of these guides is the process of disabling services on the firewall host. Almost any OS installation enables various services out-of-the-box that are not needed for the operation of a firewall. Your firewall should have as few services running as possible. If you are installing on a Windows machine, you should disable NETBEUI or any other non-IP protocols. The kernel processes of the NG product do not inspect traffic on non-IP protocols, so your NETBEUI and IPX traffic would not be protected, therefore it should not be installed on the firewall.

Note

By default, the Nokia hardware platform comes with a hardened FreeBSD operating system out of the box. Nothing has to be done to secure a Nokia platform prior to installing the NG product when starting with a default install.

If you are installing the firewall on a Unix system, the most common method of disabling services is through the /etc/inetd.conf file. This file tells the system which services/protocols are enabled, and therefore which ports the system will be listening to. The following code is the beginning of a typical inetd.conf file as installed in Solaris 2.7. As you can see, there are several services running that do not have to be enabled. Most things in the inetd.conf file can be disabled. If you want to leave FTP or Telnet open temporarily, then that is your option.

# more inetd.conf # #ident  "@(#)inetd.conf 1.33    98/06/02 SMI"   /* SVr4.0 1.5   */ # # # Configuration file for inetd(1M).  See inetd.conf(4). # # To reconfigure the running inetd process, edit this file, then # send the inetd process a SIGHUP. # # Syntax for socket-based Internet services: #  <service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args> # # Syntax for TLI-based Internet services: # #  <service_name> tli <proto> <flags> <user> <server_pathname> <args> # # Ftp and telnet are standard Internet services. # ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd # # Tnamed serves the obsolete IEN-116 name server protocol. # # name    dgram   udp     wait    root    /usr/sbin/in.tnamed     in.tnamed # # Shell, login, exec, comsat and talk are BSD protocols. # shell   stream  tcp     nowait  root    /usr/sbin/in.rshd       in.rshd login   stream  tcp     nowait  root    /usr/sbin/in.rlogind    in.rlogind exec    stream  tcp     nowait  root    /usr/sbin/in.rexecd     in.rexecd comsat  dgram   udp     wait    root    /usr/sbin/in.comsat     in.comsat talk    dgram   udp     wait    root    /usr/sbin/in.talkd      in.talkd 

To disable services in this file, simply edit it, and insert a pound sign or hash mark in front of the line that you wish to disable. When completed, send a HUP signal to the inetd process running on the system as shown in the following output:

# ps -ef | grep inet     root   229     1  0   Nov 06 ?        0:00 /usr/sbin/inetd -s # kill -HUP 229

You can verify that the processes are no longer listening on the system by running the netstat –an command. Because there are fewer services running on the firewall, the system is more secure. You can think of each of those listening ports as holes into your operating system. Although the firewall software will protect the operating system from direct attack if you have the security policy defined properly, it is better to stay on the safe side and reduce the number of possible ingresses.

Routing and Network Interfaces

We recommend that before you install the Check Point product, first configure and test the networks that the firewall will be communicating on. When you install VPN-1/FireWall-1, the product binds to the interface adapters, and even begins configuring the firewall at this early stage. Regardless of the platform you are installing on, it is recommended that you configure the first interface on your firewall as the external interface, and that this IP address resolves to the name of the host computer in the hosts files. On Windows systems, this means that the external IP address of the enforcement firewall should go on the network interface that is displayed first in the interface pull-down list under the IP Address tab on the Microsoft TCP/IP Properties window. If this is not defined properly, then several problems may occur with Secure Internal Communications (SIC) and Virtual Private Network (VPN) configurations.

Prior to installation, configure your firewall interfaces with the correct IP addresses and subnet masks. Ideally, you can plug your system into a test network so that you are not putting your unprotected system on the live network before installing the firewall software. It is always best to install a firewall in an isolated environment so that it cannot be compromised before it has been protected. You should test routing and IP forwarding first. Once Check Point VPN-1/FW-1 NG is installed, it will control IP forwarding, but you must first enable IP forwarding in the OS and test that your network adapters and routing are functioning properly. Just imagine if you didn't perform this test before installing the software, and then found that you had a faulty Network Interface Card (NIC). It would have saved you a lot of blood, sweat, and tears if you had determined this first.

Note

When you are configuring your interfaces on a Windows system, be sure that you only configure one interface with a gateway. This is a common mistake since each interface gives you the option of filling in a gateway. You should never have more than one default gateway configured on your firewall.

Next, make sure you understand the wide area network (WAN) connections that will be coming into your firewall, and configure routing accordingly. You may decide to set up a dynamic routing protocol on your firewall to maintain its routing table, or you may decide that static routes are the way to go. If you add a route on a Windows system, then you should provide the –p switch so that the route will still be there after a reboot. This switch permanently adds the route into the system registry. For example, the following command will route the 10.1.1.0/24 network to the next hop router of 10.2.2.1 on a WinNT system:

route add -p 10.1.1.0 mask 255.255.255.0 10.2.2.1

In Solaris, you need to set up your route statements in a file that will be run at startup (for example the /etc/rc2.d directory). The file name must begin with a capital S for the system to run it (e.g. S99local), and you should set the file modes to allow execution. The previous route command can be written in Solaris as follows:

route add 10.1.1.0 -netmask 255.255.255.0 10.2.2.1

If your firewall will be on the boarder of your network, connecting your LANs and WANs to the Internet, you will need to ensure that default routes are configured throughout on all your workstations and routers so that they are routed to the next hop closest to the Internet. It may prove helpful if you create a network diagram that shows how your network looks prior to having a firewall, and another to show the network after the firewall is in place. This will help you to visualize which connections will be changing so that you can prepare accordingly.

Enabling IP Forwarding

To test your routing and interfaces, you must enable IP forwarding in your OS. To do this on WinNT 4.0, access the TCP/IP properties window and select Enable IP Forwarding from the Routing tab (shown in Figure 12.2). To enable IP forwarding in Win2k, you must edit the registry as outlined in Microsoft's KB article Q230082 as follows:

Figure 12.2: Enable IP Forwarding in WinNT 4.0

1. Open the registry by running regedt32.exe.

2. Find the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\_Tcpip\Parameters

3. Add the following value to this key:

   • Value Name: IPEnableRouter

   • Value type: REG_DWORD

   • Value Data: 1

In Solaris, IP forwarding is usually enabled by default. You can switch it off and on with the following command: ndd -set /dev/ip ip_forwarding 1. The settings for this command are as follows:

• 0 disables IP forwarding

• 1 enables IP forwarding

Configuring DNS

Since it is suggested that you install your firewall while it is not plugged into any untrusted networks, it will be best to start with DNS disabled on the firewall. If you have DNS enabled and the system cannot reach its name servers, then the system may become sluggish and system performance will be affected. It is important that when you do configure DNS, you configure it properly. The firewall should be able to resolve its own external IP address to the name of the host computer. This could be set up in advance by creating an A record in your domain for the firewall, and you should enter it into the firewall's hosts file. In Unix, this file is located in /etc/hosts, and in Windows it is located in c:\winnt\system32\drivers\etc\hosts. The Nokia platform also must have the host name associated with its external IP address, and this is done through the Host Address Assignment link found under the System Configuration heading in the Voyager GUI. You can use this interface to configure host entries instead of editing a host's file.

You should also include IP addresses in the host's file that your firewall may communicate with frequently, like a management server and/or Enforcement Module. Policy installation performance can be increased on a management server by having all network objects (which are defined later) resolvable.

Another DNS record that you should create is a pointer (PTR) record for your firewall's external IP address or any other address(es) that you will be using for Network Address Translation (NAT). Some Web sites and FTP servers require that you have a reverse resolvable IP address before they will grant you or your users access to download their files. If you have obtained a block of IP addresses from your Internet Service Provider (ISP), then chances are that they control the PTR records for your addresses. Sometimes they will provide you with a Web site where you can administer these yourself. Other times, you will need to find the right person who can make the changes for you. If you have your own abstract syntax notation (ASN), then you can set up your own in-addr.arpa domain and create your own PTR records.

Preparing for VPN-1/FireWall-1 NG

During the install process, you will be asked which components you want to install and then you will be required to fill in the configuration screens at the end of the installation procedure. The Check Point Next Generation CD gives you the following options for installation:

• Server/Gateway Components Choose this option if you wish to install one or more of the following components from the Next Generation Suite:

  • VPN-1 & FW-1 This includes FW-1 Management Module and enforcement point software along with the VPN-1 encryption component.

  • FloodGate-1 Provides an integrated Quality of Service (QoS) solution for VPN-1/FW-1.

  • Meta IP Integrated IP Management with DNS and Dynamic Host Configuration Protocol (DHCP) servers.

  • Management Clients The GUI for Check Point including the Policy Editor, Log Viewer, and System Status GUI.

  • UserAuthority A user authentication tool that integrates with FW-1, FloodGate-1, and other e-business applications.

  • VPN-1 SecureClient Policy Server Allows an Enforcement Module to install Granular Desktop Policies on mobile users' SecureClient personal firewalls.

  • Reporting Module An integrated reporting tool that can generate reports, graphs, and pie charts to display information obtained from the VPN-1/FW-1 logs.

  • Real-Time Monitor Allows an organization to monitor their VPN connections, Internet connections, etc.

• Mobile/Desktop Components (Windows Only) If you just want to install client software on your mobile users or desktops in the office as described in the following options, then choose this option.

  • VPN-1 SecuRemote Client Encryption software loaded on your mobile clients.

  • VPN-1 SecureClient Client Encryption software with Desktop Security (personal firewall) features.

  • Session Authentication Agent This agent is installed on desktop computers where your users will need to authenticate with Session Authentication.

If you are installing from files, be sure that you download and install the Check Point SVN Foundation first. This package is the base of the entire Check Point Next Generation software suite as its name suggests. It's this program that allows the easy integration of all other NG components. The only VPN-1/FW-1 applications that don't rely on the SVN Foundation are the management clients.

The next important question that the installation process will ask you (if you are installing a management server on your firewall) is whether you want to enable backward compatibility. If you choose not to enable backward compatibility, then you will only be able to manage other NG modules. If you do choose to enable backward compatibility, then you will be able to manage NG, 4.1, and 4.0 modules from this management station.

The default folder installation in Windows is c:\winnt\fw1\5.0 and Check Point installs files on Solaris in /opt and /var/opt. Make sure that you have partitioned your disk properly to accept the default installation folder, or be prepared to give a custom location for the installation (Windows only). If you don't accept the defaults, you should verify that the install program configures the firewall's environment variables properly.

Note

You will see the use of the FW-1 Environment Variables or the $FWDIR environment variable throughout this book. It is the nature of an environment variable to contain some value (similar to a variable used to represent a number in algebra). The $FWDIR variable contains the value of your firewall's installation directory, and it is configured upon install. If you install on Windows, this variable is set to c:\winnt\fw1\5.0. In Solaris the $FWDIR environment variable is set to /opt/CPfw1-50.

There is also a $CPDIR variable, which contains the installation directory of the CPShared (SVN) components. In Windows, the $CPDIR variable is set to c:\Program Files\CheckPoint\CPShared\5.0, and in Solaris it is set to /opt/CPshared/5.0.

So, whenever you see these terms used, $FWDIR or $CPDIR, substitute the appropriate directory for your firewall installation in their place. On a Unix system, you can type echo $FWDIR to see the value of the variable, or type set to see a list of all environment variables and their associated values. To be technically accurate, we should probably use %FWDIR% when talking about the Windows environment, but we are going to stick to the Unix method of describing variables in this book.

The VPN-1/FW-1 component options are as follows:

• Enterprise Primary Management To install a management server only, which will be acting in a primary capacity.

• Enterprise Secondary Management To install a management server only, which will be acting in a backup capacity.

• Enforcement Module & Primary Management To install both a Primary Management Module and VPN-1/FW-1 Enforcement Module (this is the default option).

• Enforcement Module To install an Enforcement Module only, the management server will be installed on a separate host.

The Management Client options are as follows:

• Policy Editor Used to connect to your management server to configure your rule base, NAT, FloodGate-1 QoS policy, and SecureClient Desktop Security Policies.

• Log Viewer Used to view your VPN-1/FW-1 security logs, accounting logs, and audit logs on the management server.

• System Status Used to view the status of the remote enforcement points connected to the management server.

• SecureClient Packaging Tool Used to create custom packages for SecuRemote/SecureClient mobile users.

• Traffic Monitoring Used to monitor an interface, QoS rule, or virtual link in real time. The display is in the form of a line or bar graph.

• SecureUpdate Used for managing licenses and doing remote software updates of the remote enforcement points connected to you're the management server.

• Reporting Tool Used to generate reports with graphs and pie charts from the data in the VPN-1/FW-1 logs.

After the Check Point installation wizard copies files, it will run through a number of configuration screens. These will be identical if you are installing a Management Module with or without an Enforcement Module with the exception of the SNMP option in Solaris, which is only configured if you are installing an Enforcement Module. The screens that you can prepare for in advance are the following:

• Licenses You should read the section on Licenses if you need help getting licenses. You will be required to fill in the following fields:

  • Host/IP Address The IP address associated with this license or "eval."

  • Expiration Date The date that the license expires, which may be "never."

  • SKU/Features These are the features that this license will enable (e.g. Management or 3DES).

  • String/Signature Key The license string provided by Check Point to validate the license. This key will be unique for each license and IP address.

• Administrators You will need to configure at least one administrator during install. Subsequent sections in the chapter provide additional details for more on adding Administrators.

  • Administrator Name Choose a login name. This field is case- sensitive.

  • Password Choose a good alphanumeric password. It must be at least four characters long.

  • Confirm Password Repeat the same password entered previously.

• GUI Clients These are the IP addresses of the management clients that your administrators will use when connecting to this Management Module. You may need to configure static IP addresses for your administrators. You may add as many GUI clients as you'd like or you may enter none; it's up to you. Subsequent details for additional details regarding the GUI client options can be found elsewhere in the chapter.

• SNMP extension (Unix only) If you wish to utilize external network management tools such as HP OpenView, then you can install the Check Point FW-1 SNMP daemon. With the daemon installed and activated, you will be able to query the firewall status. You could use a network management tool to monitor the firewall's health and generate alerts based on certain criteria.

• Group Permissions (Unix only) If you choose to set group permissions on your VPN-1/FW-1 installation on Solaris, enter the group name at this prompt (from /etc/group). If you do not want to set group permissions, only root will be able to execute all FW-1 commands. You might want to set group permissions so that you can enable a number of firewall operators to execute FW-1 commands without having to grant them superuser privileges on the system.

  Warning

  Around mid-February 2002 a CERT Advisory was posted, warning about various vulnerabilities that have been found and exploited in many SNMP implementations. These vulnerabilities could lead to Denial of Service attacks or unauthorized access. Please ensure that you have applied any applicable security patches to your systems prior to accepting SNMP through your firewall. For more information, and links to patches visit the CERT Web site: www.cert.org/advisories/CA-2002-03.html. Nokia IPSO 3.4.2 and above already have the SNMP fix integrated.

Administrators

It is best to use individual administrator usernames instead of a generic username like fwadmin. The problem with using a generic login ID is that you cannot properly audit the activities of the firewall administrators. It may be important for you to know who installed the last security policy when you are troubleshooting a problem. This becomes more and more important when there are several people administering a firewall system. The fields that you need to fill in follow:

• Administrator Name Choose a login name for your administrator. This field is case-sensitive.

• Password Choose a good alphanumeric password. It must be at least four characters long.

Note

If you are installing just an Enforcement Module, then you will not have any administrators or GUI clients to configure.

There is a section labeled Permissions that enables you to define the access level you will require on an individual basis for each administrator. If you select Read/Write All or Read Only All, then your administrator will have access to all the available GUI client features with the ability to either make changes and updates or view the configuration and logs (perhaps for troubleshooting purposes) accordingly. You may also choose to customize their access so that they may be able to update some things and not others. To do this, select Customized and configure each of these options:

• SecureUpdate This GUI tool enables you to manage licenses and update remote modules.

• Objects Database This tool is used to create new objects to be used in the security policy rule bases.

• Check Point Users Database This tool is used to manage users for firewall authentication purposes.

• LDAP Users Database This tool is used to manage Lightweight Directory Access Protocol (LDAP) users.

• Security Policy This tool is used to create and manage rule bases using the Policy Editor GUI.

• Monitoring This option enables access to the Log Viewer, System Status, and Traffic Monitoring GUI clients.

GUI Clients

When you enter GUI clients, you type their hostnames or IP addresses into the Remote hostname: field and add them to the list of clients allowed to connect to your Management Module. You are allowed to use wildcards as follows:

• Any If you type in the word Any, anyone will be allowed to connect without restriction (not recommended).

• Asterisks You may use asterisks in the hostname. For example, 10.10.20.* means any host in the 10.10.20.0/24 network, and *.domainname.com means any hostname within the domainname.com domain.

• Ranges You may use a dash (-) to represent a range of IP addresses. For example, 1.1.1.3-1.1.1.7 means the 5 hosts including 1.1.1.3 and 1.1.1.7 and every one in between.

• DNS or WINS resolvable hostnames

It is recommended that you stay away from using hostnames or domain names, however, since this requires DNS to be configured and working on the firewall. Using IP addresses are the best method since it doesn't rely on name resolving, and will continue to work even if you cannot reach your name servers from the firewall.

Upgrading from a Previous Version

Although this chapter describes how to perform a fresh install of NG, you may be interested in upgrading from your existing versions of FW-1. You can install or upgrade to NG from version 4.0 or 4.1, and it can manage v4.x firewalls if you choose the Backward Compatibility option during the install. Although NG utilizes Secure Internal Communication (SIC) for other NG modules, it can also use the fw putkey command to communicate with previous versions of the product. FW-1 NG is not compatible with versions earlier than 4.0.

It's very important that you upgrade your management console prior to upgrading any of your firewall Enforcement Modules to NG. A 4.1 management station cannot control an NG module. When you do upgrade your enforcement points, you will need to edit their workstation objects in the Policy Editor, and change their version to NG before you will be able to push or fetch a policy.

Read the release notes before you begin. This is very important since there is a list of limitations in the NG release notes that you will need to consider ahead of time. Some of these include, but are not limited to, your resources, VPNs, and external interface settings. NG does not support more than one resource in a rule. If you have rules configured with multiple resources, NG will copy this rule into the new format with only one resource, and will not create new rules for the others. NG does not support Manual IPSec or SKIP VPNs any longer. If you have these types of VPNs in your rule base before the upgrade, they will be converted to IKE VPNs without notification during the upgrade to NG. If you have a limited license on your VPN-1/FW-1 v4.x firewall, your $FWDIR\conf\external.if settings will not be preserved during the upgrade. You will need to define your firewall's external interface in the workstation properties window under the Topology tab after the upgrade. You may also need to run the confmerge command to manually merge your objects.C file with the new objects in NG. These things and more are laid out for you in the product release notes.

It is also highly recommended that you have a back-out plan in place if your upgrade to NG does not go as smoothly as planned. Check Point recommends upgrading on a new piece of hardware; that way you will minimize downtime. If you do it this way, remember that you may need to redo SIC or putkeys, and your Internet router or any routers directly connected to the firewall may have to have their ARP cache cleared after putting the new hardware in place.

Last, but certainly not least, make sure that you have a backup of the entire system prior to an upgrade. It is especially important to save the $FWDIR/conf directory and any files that may have been edited from $FWDIR/state (like local.arp in Windows), $FWDIR/database, and $FWDIR/lib (for files like base.def and table.def that may have been modified).