Frequently Asked Questions

This section contains some questions that are frequently asked in terms of general policy configuration. Specific features have their own subsections. The FAQs are numbered so the text can refer to them more easily.

4.1 Which Files Make Up My Security Policy?

The user-defined part of the security policy lives in $FWDIR/conf. Specifically, these files include the ones listed below.

• objects_5_0.C: All network objects, services, and rulebase properties are stored in this file.

• fwauth.NDB*: This is the user database file, which also stores the encryption keys used for the VPN features of FireWall-1.

• rulebases_5_0.fws: This file contains all security policies for FireWall-1 and VPN-1.

• slprulebases_5_0.fws: This file contains all security policies for Secure Client, that is, Desktop Security policies.

• *.W: This file contains individual policy files that get converted to .pf files, which are installed on your firewall module.

• *.pf: This file contains "compiled" policy files. These files are not really compiled in the conventional sense, but they are turned into INSPECT code. You can edit this file directly if you would like; any changes you make to this file will be overwritten any time you reload this policy from the GUI.

Other files also make up your security policy in $FWDIR/lib/*.def. You can edit these files, but normally you do not edit these files unless instructed to do so by your support provider (or as directed in this book).

4.2 How Do I Edit objects_5_0.C and rulebases.fws Manually?

To modify objects_5_0.C and rulebases.fws manually (which several sections of this book tell you to do to enable or disable features), kill the fwm process on your management console by using the command fw kill fwm, which terminates any GUIs that may be connected. Once you edit these files, make sure you delete objects_5_0.C.bak and objects_5_0.C.sav. If these files have a more recent timestamp, fwm will use these files instead of your edited objects_5_0.C. Check Point recommends executing cpstop on the management console, making the changes, and then typing cpstart to restart the software.

All modifications to these files, unless otherwise specified, will always occur on the management console only, not the firewall modules. Once you have made changes to these files, you need to reinstall the security policy for the changes to take effect on the firewall modules.

An alternate approach to manually editing objects_5_0.C, and the suggested approach for most of the changes needed in this book, is to use dbedit or the GUIdbedit tool. A sample session with dbedit follows.

C:\Download>dbedit
Enter Server name (ENTER for 'localhost'): 10.0.0.16
Enter User Name: dwelch
Enter User Password: abc123
Please enter a command, -h for help or -q to quit:
dbedit> modify properties firewall_properties nat_dst_client_side_manual true
dbedit> update properties firewall_properties
firewall_properties updated successfully.
dbedit> quit

To make the same change with GUIdbedit, log into the GUIdbedit utility, which presents a login screen similar to that of the Policy Editor. Once you've logged in, you can navigate to the appropriate setting and make the change. Figure 4.51 shows the same change being made that was made with dbedit above.

WARNING!

dbedit does not work correctly when run from an IPSO platform prior to NG FP3. You should either run dbedit from a different platform or use the GUIdbedit tool.

4.3 Does Any Service Really Mean Any Service?

Prior to FireWall-1 NG, it was not possible to easily "see" which services would not apply when the Any service is specified. In NG, it is now possible to define a service in the GUI so that Any does not include that particular service. This means the service in question must be explicitly listed in any accept rule. In NG FP2, the predefined services defined without the Match for Any flag set include those shown in Table 4.2.

To obtain a current list of services for your installation, create a file called Servername with the following three lines in it:

localhost
-t services -pf
-q

Then run the following command on a UNIX management station:

# more ServerName | queryDB_util | awk '/Object Name/ {host=$3}
/include_in_any/ {print host,":"$2}' > include.txt

The file include.txt will now include services that are included in the Any service based on their property settings.

4.4 When Should I Reinstall My Security Policy?

You should reinstall your security policy anytime you make a change to a network object, the rulebase properties, the rulebase, or any of the files that make up the security policy.

4.5 Which Characters or Words Cannot Be Used When Naming Objects?

The most current list of characters or words that cannot be used when naming objects can be found in Check Point Support's Knowledge Base article number 36.0.89127.2471605. Tables 4.3 and 4.4 list these words and characters.

NOTE!

In Table 4.4, any capitalization of these words is also illegal.

4.6 Are the Global Properties per Firewall or Global?

Rulebase properties apply to all gateways managed by the management console. Many properties that used to be global have moved to the individual firewall.

4.7 How Do I Enable DNS Verification When I Use the Rulebase Property to Allow DNS Queries?

In dbedit, explained in FAQ 4.2, execute the following commands:

dbedit> modify properties firewall_properties fw_dns_verification true
dbedit> update properties firewall_properties

Similar changes can be made via the GUIdbedit tool.

4.8 Are the GUI Clients Backward Compatible?

You can manage FireWall-1 4.1 firewalls from an NG management console, but you cannot use an NG GUI to connect to a 4.1 management console. SMART Clients are not backward compatible, that is, you can use only the version of the GUI that came with the version of your software.

4.9 How Do I Enable Specific Rules on Specific Interfaces?

SmartDashboard/Policy Editor was not set up to allow you to bind specific rules to specific interfaces of a firewall. Rules are processed in order. Rules that do not apply are skipped. Processing a rule takes a near-zero amount of time, so unless you have a few hundred rules, there's little reason to do it this way.

If it is an absolute requirement that certain rules are active only on certain interfaces, it can be done, but the technique is not elegant. Take the generated .pf file from a policy install in the GUI (it should be called rulebase-name.pf, located in $FWDIR/conf on the management console) and modify it so that the rules in question are installed only on the interface in question. Chapter 14 explains how you might go about that. You can then install it with the fw load command.

Note that every time you change your security policy in the GUI, you will need to go into the generated .pf file, manually reapply the changes, and fw load the modified .pf file. It's not elegant, but that's what you have to do to make it do what you want.