Part 1

Check Point Firewall-1 on Linux, Part One
by David "Del" Elson <mailto:del@babel.com.au>
last updated Feb. 7, 2001

This is the first in a series of three articles that will examine Check Point Firewall-1 for Linux. This installment will consist of a brief introductory overview of Firewall-1, and a discussion of installation, post-installation tasks, as well as single and multi-system installations. Subsequent articles in this series will focus on concepts such as network objects, firewall rules, address translation rules, and NAT, features and limitations of Firewall-1, file and directory layout, rulesets, migrating existing Firewall-1 installation to Linux, and back-up and standby configurations.

Introductory Overview
The Product
Check Point Firewall-1 has been the market-leading firewall system since its introduction in 1994. The main advantage of Firewall-1 is its comprehensive and easy to understand GUI, which has made it a firewall system of choice for many corporate IT managers. Firewall-1 is not a cheap product; however, it is well marketed and product support is available from some of the leading IT vendors and outsourcers. In a recent Internet Security Software survey, IDC estimated that Check Point has a 41 percent market share in the firewall software category, which is a significant consideration for many customers.

Installing Firewall-1
Installation of Firewall-1 on Linux is not an excessively complicated process and should not be beyond the capabilities of any experienced Linux system administrator. The system is targeted to run on Red Hat Linux version 6.1 and 6.2. I have heard reports of Firewall-1 being installed successfully on other Linux platforms (e.g.: Debian users have managed to turn the RPM files into DEB files for installation); however, I have had a notable lack of success running Firewall-1 on Red Hat version 7.0! When running with Red Hat version 6.2, ensure that all of the latest updates are installed (from Red Hat's FTP site or your nearest mirror).

Planning
Pre-planning your Firewall-1 installation is quite important. Before you proceed with your installation you should have an idea of what your network looks like, preferably with network diagrams if possible.

Firewall-1 is a-PC based firewall system, and only supports Ethernet interfaces. As a result, if your external Internet connection goes via a different sort of interface (e.g.: a PPP serial link, Frame Relay, or ATM,) you will need a router between your firewall and the Internet. Planning the addresses that you will use on this link is also important. You will probably want to run Firewall-1 on a machine dedicated to the purpose. Generally speaking, a firewall will need at least two Ethernet cards, and if you have a DMZ or other networks attached to your firewall then you will need more than that. (One of the more recent installations of Firewall-1 that I completed was on a machine with 9 Ethernet interfaces!) The PC to be used for Firewall-1 should have at least 64MB of memory, with 128MB recommended. It should have sufficient disk space for the operating system and Firewall-1 software installation, as well as some amount for log files and spare space. A machine with a 4GB or larger hard disk should suffice.

Depending on your required throughput (and the speed of your Internet connection), the CPU requirements for Firewall-1 may vary. I have successfully run and installed the system on a 133MHz Pentium, although it ran somewhat faster on a 600MHz Pentium III! For a firewall with a 2MB circuit to the Internet and approximately 200 users being protected, I found that a 400MHz Pentium II processor was adequate.

Operating system considerations
Firewall-1 for Linux is designed to run on Red Hat Linux 6.1, with a 2.2.x kernel. Although this distribution is not the latest from Red Hat, Firewall-1 installs and performs quite adequately on Red Hat 6.2. Ensure that you have the latest updates from Red Hat installed, either from the Red Hat FTP site <ftp://updates.redhat.com> or your nearest mirror. All recent and current releases of Red Hat Linux have vulnerabilities that should be fixed by applying these updates before installing any third party software or connecting your server to the Internet.

I have attempted an installation of Firewall-1 on Red Hat 7.0, but this was unsuccessful. I suspect that some differences in the as-built kernel or libraries supplied with 7.0 are not compatible with the Firewall-1 software. Note, however, that I did get Firewall-1 successfully installed and running on a Red Hat 6.2 system with the 2.2.16-3 kernel supplied in the latest 6.2 updates, and this is quite similar to the 2.2.16 kernel supplied with Red Hat 7.0, so your mileage may vary! Note that the main component of Firewall-1 is a loadable kernel module. Although such modules are usually specific to a kernel version, the one that Check Point has shipped appears to load in most of the 2.2.x series kernels that I have tried. It will not load into a 2.4.x kernel!

[It should be noted that after this article was initially published, I received an e-mail from a reader that stated:
"I have gotten firewall-1 4.1 sp2 running on red hat 7.0. The only mod required was to link a couple of libraries thus:

cd /usr/lib
ln -s libstdc++-libc6.2-2.so.3 libstdc++-libc6.1-1.so.2"
This is the one thing I had missed in attempting to get Firewall-1 running on Red Hat 7.0 - David Elson]
Users of other distributions are on their own, however Phoneboy's Firewall-1 site states: "Officially, Firewall-1 supports RedHat 6.0 thru 6.2. Some people have had success with SuSE 6.2, Mandrake 7.0, and Debian with a 2.2.12 kernel (the rpm was converted to a deb)."

Firewall-1 Management Software
The Check Point management software provided with Firewall-1 does not run on Linux. Currently, it runs on Windows NT, Windows 2000, and some UNIX systems (e.g.: Solaris) only. Therefore, to use Firewall-1 you will need an additional workstation to be your management station - unfortunately this must be running on one of the above operating systems. The Firewall-1 management software for Solaris is in fact reasonably poor, and so I would instead recommend that a Windows NT or Windows 2000 workstation be used for the purpose. The Firewall-1 management software must be installed separately from the Firewall-1 gateway software, although both are contained on the same CD-ROM.

File System Layout
First, a quick note: I install nearly all of my Linux systems using a Red Hat kickstart build. This enables me to very quickly install a Red Hat system from an NFS directory containing the latest 6.2 or 7.0 build with all updates, and not have to touch the system during installation -- all of the installation questions are answered for me in the kickstart file. For more information on Red Hat kickstart builds, see the following section in the documentation on the Red Hat web site <http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/ch-kickstart2.html>.

Generally speaking, a Linux system used for Firewall-1 will need the following partitions:

All of the above partitions can be created manually if you are installing the system from CD (or any other manual installation method). My kickstart (ks.cfg) file for installing Firewall-1 systems has the partitions defined as follows:

part / --size 200
part swap --size 128
part /usr --size 1000
part /var --size 200
part /opt --size 1 --grow
Note the use of the "--grow" parameter in the definition of the /opt partition, allowing the partition to use all of the remaining available disk space.

Before Installing Firewall-1
After Linux is successfully installed, you might want to take a few minutes to secure your system. In particular, here are a few things that I always do on a Red Hat Linux system before exposing it to the Internet:

Firewall-1 Installation
Check Point has provided an installation script that is compatible with all UNIX systems that Firewall-1 can be installed on. To install Firewall-1 using this script, first ensure you have the correct CD-ROM, this should be marked "Check Point 2000 Enterprise Suite v4.1.2". This includes service pack 2 of Firewall-1 v4.1, which is required for running Firewall-1 on Linux. Earlier releases of the Check Point 2000 CD-ROM did not include this service pack, so if you have an earlier release, contact your Check Point vendor for an upgrade CD.

Mount the CD-ROM into your CD-ROM drive using:
mount /mnt/cdrom
... and install the software using the following commands:
cd /mnt/cdrom ./InstallU
The installation script will take you through several steps, including:

Post Installation Tasks
After Firewall-1 is installed, you should perform the following tasks:

Single system and multi system installations
Firewall-1 has the ability to control multiple firewalls from a single management module. Before I discuss this, I will explain a few concepts:

It is normal practice to run the Firewall-1 Management Module (fwm), and the Enforcement Module on the same machine, being your Internet gateway. This is not required, however, especially where you have multiple Internet gateways, or perhaps multiple gateways between networks of various levels of trust.

Two installation types were presented during the installation sequence, these were:

The Firewall-1 stand alone installation installs the Management Module and the Enforcement Module on the same machine. The Distributed Installation allows you to specify some combination of Management Module and Enforcement Module (i.e. either one or both) to be installed.

For example, Company X has a wide area network covering the USA. They have a Frame Relay WAN connecting most of their sites, with offices around the country. They have two sites that have their own separate Internet connections, one in San Francisco and one in New York. It would be possible for them to set up a distributed installation, with the management module and enforcement module both installed in New York, but only the Enforcement Module installed in San Francisco. They could control both firewalls from a central management console, and connect only to the New York firewall to update the rule set covering both firewalls.

Ensure that you have the correct installation type selected before installing Firewall-1. The stand-alone installation will give you error messages if you attempt to apply a rule set that covers more than one enforcement module! This might require some pre-planning of your network layout and Internet connections.

Installing the User Interface (on Windows)
The Firewall-1 GUI should be installed on a Windows system before or immediately after you have installed the firewall modules on Linux. To do this, you should insert the CD-ROM into your Windows workstation, and follow the set up instructions in the installation program that is automatically started.

If the installation program does not automatically start then you may run it manually from the CD-ROM (use the SETUP.EXE program in the \windows\CPMgmtClnt-41 directory on the CD).

In the Next Episode
This article has offered a brief overview of the Check Point Firewall-1 for Linux, including pre-installation procedures, installation and post-installation procedures. The next article in this three-part series will cover Firewall-1 concepts such as network objects, firewall rules, address translation rules, and NAT, as well as features and limitations of Firewall-1. The final article will then discuss aspects of Firewall-1 such as file and directory layout, rulesets, migrating existing Firewall-1 installation to Linux, and back-up and standby configurations.


Part 2

Check Point Firewall-1 on Linux, Part Two
by David "Del" Elson <mailto: del@babel.com.au>
last updated March 5, 2001

Check Point Firewall-1 has been the market-leading firewall system since its introduction in 1994. The main advantage of Firewall-1 is its comprehensive and easy to understand GUI, which has made it a firewall system of choice for many corporate IT managers. This is the second in a series of three articles that will examine Check Point Firewall-1 for Linux. The first article consisted of a brief introductory overview of Firewall-1, and a discussion of installation, post-installation tasks, as well as single and multi-system installations. This installment will cover Firewall-1 concepts such as network objects, firewall rules, address translation rules, and NAT, as well as features and limitations of Firewall-1. The final article will then discuss aspects of Firewall-1 such as file and directory layout, rulesets, migrating existing Firewall-1 installation to Linux, and back-up and standby configurations.

Firewall-1 Concepts
Network Objects
A network object is the basic "unit of information" for Firewall-1. The "Network Objects" table is where all of the information about anything with an IP address (or group of IP addresses) is stored.

To manage your network objects, start the Firewall-1 Policy Editor, and choose "Network Objects" from the manage menu. You will need to enter details of the various objects you have on your network, including:

For example, you might want to define the following simple set of network objects:

Services
Firewall-1 comes with a pre-defined set of services, including most of the well-known services in use on the Internet. It is possible, however, that you may want to include more services that are not predefined. To do this, choose "Services" from the Manage menu in the Firewall-1 Policy Editor.

Groups
You can group network objects or services together into an easy-to-manage group. For example, you may have a number of web servers in a DMZ to which you want to allow public access. To avoid having to define a large number of rules, one for each server, or to define a rule containing a large list of servers, you could group all of your web servers together into a single group called "Web-Servers". Use this group in a rule, rather than each individual server.

Firewall Rules
Firewall-1 comes pre-installed with an empty rule set.
Once you have a basic set of network objects and groups defined, you will want use the Policy Editor to begin programming your firewall with a set of rules that define your security policy. Rules can be added to the end of the rule set, inserted at the top or anywhere in the middle. The Firewall-1 policy editor allows you to cut and paste rules, move rules up and down in the rule set, or delete rules at will.

Experimenting with an existing rule set, reading the Check Point "Getting Started Guide" and the Firewall-1 manual (contained in PDF format on the installation CD, in the Docs directory) is the best way to learn how to use the GUI management tool.

Address Translation Rules
Firewall-1 supports a wide range of Network Address Translation (NAT) rules. The Policy Editor's main tab, "Security Policy", lists accept/deny rules only. The second tab, "Address Translation", is where the address translation rules are shown.

In most cases, you will create address translation rules when defining the network objects. To do this, in the network object properties window, choose the "NAT" tab. There are two basic types of NAT: These are Static and Hide NAT.

1. Static NAT
Static NAT is where a single IP address outside your network gets mapped to a single IP address inside your network, in other words a 1:1 mapping. For Static NAT to work, your firewall must have more than one externally visible IP address (more on that under "ARP" shortly), and your ISP must provide routing for all of your externally visible IP addresses.

Static NAT is most useful in cases where you have a server inside your network (or on a DMZ) to which you want to provide access from the Internet. In order for this to happen, you must have an externally visible IP address for that server to use, and hence you must use Static NAT.

To use Static NAT for a network object, you must first ensure that no other network object is using the external IP address that you want to use. Open the network object to which you want to apply NAT (e.g.: an internal server of some kind). In the NAT tab, select the checkbox labelled "Add Automatic Address Translation Rules", choose "Static" as the translation method, and enter the externally visible IP address of the network object in the "Valid IP Address" field. You should now have created a network object that has an internal IP address as well as an externally visible IP address.

2. Hide NAT
Hide NAT (or dynamic NAT) is similar to IP Masquerading or other similar functions. This is where a number of network objects, or your entire network, gets hidden behind a single externally visible IP address.

To use Hide NAT, you only need to use a single IP address connected to the Internet (although you can have more.) You can use Hide NAT to hide your network behind the external IP address of your firewall, this is exactly the same as IP Masquerading. To use Hide NAT for a network object, open the network object that you want to apply NAT to (this could be a workstation, group, or network). In the NAT tab, select the checkbox labelled "Add Automatic Address Translation Rules", choose "Hide" as the translation method, and enter the externally visible IP address that you wish to use in the "Valid IP address" field.

Editing NAT rules
When you create static or hide NAT rules in a network object, this creates address translation rules within the "Address Translation" tab of the Policy Editor. These rules cannot be edited, but new rules can be added above and below the automatically generated rules.

For example, after setting up NAT for a pair of hidden networks, you may wish to disable NAT for traffic going between those networks. You can do this by inserting an address translation rule at the top of the list, showing that traffic from and to these networks are to be left untranslated. To do this, you might want to first create a group object containing all of your networks (the Address Translation rules can only take a single object in each field of a rule), and leave the "translated packet" source and destination fields reading "= (Original)".

NAT rules can also be used for more complex packet mangling. For example, you might want a host to appear as one IP address when access is requested from the Internet, but a different IP address when it is accessed from a DMZ. (The discussion of why and how to do this is complex and beyond the scope of this article.)

ARP and routes
Firewall-1 relies on a fairly complex system of ARP and route table entries to assist with static NAT.
In order for static NAT to operate correctly, you must define an ARP rule to make the externally visible IP address of the NAT-ed server appear at the MAC address of your firewall. To do this, you need to know the MAC address of your firewall's external interface (this can be obtained by running "ifconfig" and looking at the "HWaddr" value).

Publishing the ARP entry is done using the /sbin/arp program, as follows:
/sbin/arp -s <ip address> xx:yy:zz:aa:bb:cc
... where xx:yy:zz:aa:bb:cc is the address that you want to publish, and <MAC address> is the MAC address of the external interface of the firewall (NOT that of the host!).

Surprisingly enough (and confusing even for TCP/IP experts), you also need to create a route, from the external IP address to the internal IP address. For example, if you have a web server which has an internal IP address of 192.168.1.1, and you have set up Static NAT for this server to appear on the internet as 211.11.22.33, then you need to add a route table entry with the following command:

/sbin/route add -host 211.11.22.33 gw 192.168.1.1
Needless to say, adding all of these arp and route entries can be somewhat boring each time your firewall is restarted, so you had probably best put these in one of your init scripts (e.g.: /etc/rc.d/rc.local).

FEATURES AND LIMITATIONS
Features
Firewall-1's main feature, in comparison to other firewall systems, is the relatively easy to use and intuitive GUI.
Firewall-1 supports many types of address translation, that (for example) are not supported by the ipchains module in the Linux 2.2 kernel. For a complex firewall that protects many different types of network devices, this is a must-have feature. This type of address translation is now a feature of the Linux 2.4 kernel with the ipfilter package, and so support for complex address translation is no longer a feature that differentiates Firewall-1 from the Linux kernel.

Comparison between Firewall-1, ipchains, and netfilter
Ipchains is the firewalling system built into the Linux 2.2 kernel. The ipchains home page is here: http://netfilter.kernelnotes.org/ipchains/

Netfilter, the firewalling system built into the Linux 2.4 kernel, is designed as a replacement for ipchains. The home page for netfilter is here: http://netfilter.kernelnotes.org/

Note that netfilter is, correctly speaking, a conglomerate of components. At the bottom layer in the kernel there is "netfilter" which is the system built into the 2.4 kernel for mangling packets. On top of this is a layer for network address translation (NAT), a layer for packet filtering (IPtables), and a user-space tool called "iptables" for managing the entire process.

Rule chains and trees
Both ipchains and iptables set up a number of "rule chains" in a type of tree structure. At the top of the tree are some pre-installed chains, called input, output, and forward (or for iptables, INPUT, OUTPUT and FORWARD). Each of these chains can branch to another chain for evaluating rules, performing NAT, or other functions (such as logging) based on certain conditions.

A common procedure with ipchains or iptables is to set up a rule chain based on the input and output interface of the packet. The pre-installed chains then branch to these chains based on some rules defined at the top of the chain.

Firewall-1 supports a single chain of rules. Each packet passes the rule chain from the top to the bottom, until it meets a rule that either accepts or rejects the packet.

Performance Issues
The branching-chain of rules is more efficient than the single chain of rules, because each packet has to pass through fewer rules, on average, before meeting an accept/reject match. Because of this, Firewall-1 is, on a complex rule set, measurably slower on average than using netfilter on the same hardware.

On the other hand, establishing the branching chain is more complex, and more error-prone. Many GUI-based rule-set generators for ipchains do not use the branching-chain mechanisms but instead put all rules into the input, output and/or forward chains as appropriate. This negates most of the performance advantage that would be obtained from not using Firewall-1.

Both Firewall-1 and ipchains / netfilter are implemented as kernel modules. I expect that any measurement of the performance difference between Firewall-1 and iptables using a similar (non-branched) rule set would be very slight. Note that Firewall-1 for Windows NT is not implemented as a kernel module (I expect that this is because Check Point does not have access to Microsoft's source code) and is therefore measurably slower than Firewall-1 for Linux on the same hardware.

Management, Usability, and Support
Generally speaking, I have found Firewall-1 support to be quite good, although somewhat slow. There are many individuals and organisations world-wide that are well trained in Firewall-1 management, and so obtaining staff or an outsourcer to look after a Firewall-1 system should not be a major headache. In comparison, the ipfilter code in Linux is relatively new, and rather complex. I would expect that the learning curve for this would be fairly significant, and finding staff trained in its use would be noticeably more difficult.

To a certain extent, however, a firewall is a firewall, and an experienced security consultant with a good understanding of firewalling concepts should have no difficulty learning either the Firewall-1 or iptables systems. Firewall-1 does appear to have the edge in terms of usability at the moment, however. The Firewall-1 GUI is excellent, and I hope that there will be a port to KDE and/or GNOME in the not too distant future!

Price
Firewall-1 does not compete with either iptables or ipchains on price. Both ipchains and iptables are free products. Firewall-1 is not-free, and not even particularly cheap.

Proxy services
Ipchains and netfilter are packet-filtering and packet-mangling modules only. Firewall-1 is not a proxy server system, and does not provide some features found in other packages available on Linux (e.g.: the Squid proxy cache server). It does, however, provide some limited content filtering through proxy "resources" which are defined as Firewall-1 objects.

Because Firewall-1's content filtering features are rather limited, and, in any case, slow down the operation of the firewall ruleset, I am inclined not to use it. Content filtering in HTTP requests is probably best done using a separate proxy server (e.g.: Squid), while SMTP filtering is probably best done using a combination of mail relay system (e.g.: sendmail) and attachment filtering / virus scanning package. There are many of these available on the market, some of which are reasonably priced or free.

Generally speaking, a packet filtering system is much faster than a proxy firewall. Firewall-1 is built for speed, and is therefore mostly implemented as a packet filtering system only. Although it would be possible to run Squid on the same Linux server as being used for Firewall-1, I would be inclined not to do so, for performance reasons.

The Next Article...
This installment of our look at Check Point Firewall-1 for Linux has covered Firewall-1 concepts such as network objects, firewall rules, address translation rules, and NAT, as well as features and limitations of Firewall-1. The third and final article will discuss aspects of Firewall-1 such as file and directory layout, rulesets, migrating existing Firewall-1 installation to Linux, and back-up and standby configurations.



Relevant Links

Check Point Firewall-1 for Linux, Part One <http://www.securityfocus.com/focus/linux/articles/checkpoint1.html>
David "Del" Elson, SecurityFocus.com

Check Point Firewall-1 <http://www.checkpoint.com/products/firewall-1/>
Check Point

Packet Manging for Linux 2.3+ <http://netfilter.kernelnotes.org/>
The Netfilter Project


Part 3

Check Point Firewall-1 for Linux, Part Three
by David "Del" Elson <mailto:del@babel.com.au>
last updated March 28, 2001

This is the third and final article in a series devoted to the exploration of Check Point Firewall-1 for Linux. In the first article we discussed single and multi-system installation and post-installation tasks. The second article explored Firewall-1 concepts such as network objects, firewall rules, address translation rules, and NAT, as well as features and limitations of Firewall-1. In this installment, we will go over aspects of Firewall-1 such as file and directory layout, rulesets, migrating existing Firewall-1 installations to Linux, and backup and standby configurations.

Inside Firewall-1
File and Directory Layout
Firewall-1 on Linux is installed into a directory on /opt. This directory is symbolically linked as /etc/fw, and all directories, commands, and files are accessed relative to /etc/fw. Inside /etc/fw/ there are the following important subdirectories:

... plus several others.
The Conf Directory
The conf directory contains the most user-serviceable parts, and is where a Firewall-1 hacker might spend most of his or her time. Inside the conf directory there are a number of files, including:

File Formats
Most of the files in the conf directory are ASCII text, and rather than using the GUI Policy Manager program, it is possible to interface directly with Firewall-1 from the command line. The basic Firewall-1 rulesets are stored in *.W files, which are in a easily readable text format. These files correspond to the rule sets defined in the Policy Manager, with each policy being stored in a separate file, and each line in a policy stored in a set of lines in the *.W file.

The format of the *.W files is not complex, and if you are an experienced firewall administrator then some experimentation will explain the language used in the files. It is possible to copy the *.W files, edit a copy, and revert to the old copy if your edits go astray or cause problems.

Network Objects
The network objects are stored in the objects.C file. This file is, again, ASCII text and can be edited with a text editor such as vi. The network objects for all rule sets are stored in the same objects.C file, so be careful when editing it.

Rulesets (.W and .pf files)
Generating a firewall ruleset from one of the *.W files can be done from the command line. The command to do this is:
fw gen myrules.W > myrules.pf
This generates an inspection (*.pf) file from the *.W language used by the Policy Manager. Note that it is possible to edit the *.pf files directly, as they are ASCII text as well. The *.pf files are in a language called INSPECT, which is described in chapter 3 of the Firewall-1 Reference Guide. The Reference Guide is available in PDF format in the Docs directory on the CD-ROM.

Ruleset Generation
Once you have generated an INSPECT file from a *.W file, it is possible to load this into the running firewall using a command such as:

fw load myrules.pf
Note that loading an INSPECT file reads both the inspect script and the objects.C file, so if you have hand-edited both files and not kept them in sync, you could encounter problems at this stage.

Migrating an Existing Firewall-1 Installation To Linux
If you have an existing Firewall-1 installation on, for example, Windows NT, it is possible to upgrade to the latest version of Firewall-1 by using the standard Firewall-1 installation program. This upgrades previous versions of the rulesets to new versions, adds any required network objects to the objects.C file and installs the new software. If you have an existing installation on Windows NT and wish to migrate this to a Linux installation, there are several steps that you will need to follow.

Pre-Planning and Preparation
Firstly, upgrading a machine from Windows NT to Linux is going to involve some (possibly considerable) period of down time. Assuming that you have a running firewall, and that it is in a production environment, you may wish to consider building a second machine to migrate your NT firewall onto, rather than re-installing the production firewall. One other advantage of this is that it gives you a chance to fall back should things go wrong. It also means that once you are finished you may possibly have a spare machine for redundancy or disaster recovery purposes.

Your new firewall system should be of sufficient capability and performance to cater for your organisation's growth over a period of, perhaps, 2 - 3 years.

ASCII Files
Firstly, one warning: ASCII files on Windows NT and ASCII files on Linux are not exactly the same format. On Windows NT, each line of an ASCII file is terminated by a CR/LF sequence, which is 2 bytes. An ASCII file on Linux is terminated by a single LF byte. Firewall-1 on Linux uses ASCII files in the Linux format, while Firewall-1 on NT uses ASCII files in the NT format. They will not be able use each other's files directly. There are many utilities around that are capable of converting a NT (or DOS) format text file to a Linux (or UNIX) format file. The one I prefer to use is the old faithful vi (actually vim, with the -b flag):

vi -b some-dos-file
On loading a DOS text file, you will see that each line has a hanging "^M" sequence at the end. The command to remove these is:

:%s/<ctrl-V><ctrl-M>//g
where <ctrl-V><ctrl-M> means "hold down the Ctrl key, hit V, then hit M". You will see a "^M" sequence appear in vi when you do this.

Any files (objects.C, *.W, or rulebases.fws) copied from an NT system to a Linux system must be put through this process.

Migrating the Network Objects
Copying the network objects from an NT system to a Linux system is relatively straightforwards. You just copy the objects.C file on NT to a floppy disk and copy it back into the conf directory on Linux.

Remember to convert the file to UNIX format, as mentioned above!
Migrating the Rulesets
As mentioned earlier, the Firewall-1 rulesets are stored in a group of text files, which are *.W on Windows NT. You need to copy all of these files from your NT firewall to your Linux firewall and put them in the conf directory.

There is one other file you will need to copy: rulebases.fws. This file contains a conglomeration of all of the rule sets, in a format used by the Policy Editor. Without the rulebases.fws file, you will be able to manually compile and load *.W files but you will not be able to see them in the GUI.

Migrating from a v4.0 Installation
If you have an existing Firewall-1 installation on NT that is Firewall-1 version 4.0, and you want to migrate that to a Linux installation, then you will have two tasks. The first is migrating from NT to Linux, the second is to upgrade to Firewall-1 version 4.1 (as version 4.0 does not run on Linux).

The migration process is very similar, with a few catches. Firstly, there are some additional objects in the version 4.1 objects.C file that you must capture as you migrate to Linux. These will be in the default objects.C file when you install Firewall-1 on Linux, so it is important not to lose this file when you copy your objects.C file from Windows NT.

Instead of copying the file directly across from NT, copy it to a new file called objects.C.old. You then will have two files, objects.C.old which has come from NT, and objects.C which was provided with Firewall-1 on Linux.

After converting the objects.C.old file to UNIX format, you can merge these two files into one by using the following command:

fw confmerge objects.C.old objects.C > objects.C.new
You now have an objects.C.new file that contains all of the necessary network objects. Rename this to objects.C using:
mv objects.C.new objects.C
Additionally, you will want to copy both the rulebases.fws and the *.W files from your version 4.0 system to your new version 4.1 system. These can be copied across directly. I suggest loading each rule set into the Policy Manager and saving it after you have done this, this will update them into their new version 4.1 formats if required.

Migrating From a v3 or Earlier Installation
I would recommend against upgrading from Firewall-1 version 3.0 to 4.1 and migrating across platforms at the same time. Provided that you have all of the necessary software and media, I would instead recommend the following procedure:

Note that Check Point states that it is not possible to upgrade from a version prior to 3.0 to a version 4.1 firewall. You need to upgrade from your prior version to version 3.0, and then from 3.0 to 4.1. If you are migrating to Linux at the same time then you will probably have a 3 step process. Plan for plenty of downtime while you are doing this!

Migrating Multi-System Installations
Note that migrating a system from NT to Linux is not significantly more complicated if you have a multi system installation than a single system installation. The first step is to migrate the master firewall (aka the management server, or machine running the fwm module). While doing so, you should refrain from applying any ruleset changes to any of the slave Enforcement Modules. The Enforcement Modules can then be migrated one at a time. While you are migrating an Enforcement Module, there is no need to migrate any of the rulesets (rulebases.fws, objects.C, or *.W files), as these can be propagated to the Enforcement Module once it has been installed. Essentially, you should set up an "empty" Enforcement Module, and use the Management Module to propagate a rule set to it, just as you did when you first installed the module.

Backup and Standby Configuration
Some Firewall-1 administrators on NT have set up standby configurations of Firewall-1, using such software as StoneBeat. This is not really possible with the Linux version of Firewall-1, although there are some pieces of software that are emerging to perform failover and High Availability on Linux. I haven't tested any of these with Firewall-1, however.

An alternative to having a hot standby is to have a spare machine, configured (hardware and software) similarly to your primary firewall. This can be left running, off-line, or even switched off and locked in a safe. Periodically, it would pay to back up the conf directory of your primary Firewall-1 system and restore it onto your spare machine, or even just restore the objects.C and rulebases.fws files, from which most of the rest of the configuration can be regenerated.

Summary
Without getting into the good or bad points of commercial software (I tend to use a mix of commercial and free software myself, whatever suits my needs best tends to get the green light), it can be said that Firewall-1 is a fast, reliable, and popular piece of software that does the job of creating a firewall with an easy to manage GUI on Linux. Existing Firewall-1 customers with an interest in Linux will be pleased to note that Firewall-1 performs more than adequately on Linux. The performance of Firewall-1 on Linux appears to noticeably exceed that of Firewall-1 on NT, even from anecdotal evidence gained from the small handful of installations that I have performed. Firewall-1 customers with an NT based firewall who are concerned about performance may well be advised to migrate away from Windows NT and on to Linux.



Relevant Links

Check Point Firewall-1 for Linux, Part One <http://www.securityfocus.com/focus/linux/articles/checkpoint1.html>
David "Del" Elson, SecurityFocus.com

Check Point Firewall-1 for Linux, Part Two <http://www.securityfocus.com/focus/linux/articles/checkpoint2.html>
David "Del" Elson, SecurityFocus.com

Check Point Firewall-1 <http://www.checkpoint.com/products/firewall-1/>
Check Point