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.

Figure 4.51. Sample GUIdbedit session

graphics/04fig51.gif

WARNING!

graphics/lightning_icon.gif

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.


Table 4.2. Services that do not work with the Any service

snmp-trap

snmp-read

sip_any

sip

http_mapped

ftp_mapped

smtp_mapped

tunnel_test_mapped

ftp-port

ftp-pasv

AT-Defender

dhcp-req-localmodule

sqlnet2-1521

H323_any

H323_ras

   

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.

Table 4.3. Illegal characters

Space

+

*

?

!

(

)

{

}

?

[

]

#

<

>

,

:

;

ë

ì

`

\

/

@

$

%

^

|

&

 

NOTE!

graphics/brain_icon.gif

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


Table 4.4. INSPECT reserved words

accept

account

alert

all

and

any

apr

April

aug

august

auth

authalert

black

blue

broadcasts

call

date

day

debug

dec

December

deffunc

define

delete

direction

do

domains

drop

dst

duplicate

dynamic

expcall

expires

export

feb

February

firebrick

foreground

forest green

format

fri

Friday

from

fwline

fwrule

gateways

get

gold

gray

green

hashsize

hold

host

hosts

if

ifaddr

ifid

implies

in

inbound

interface

interfaces

intrap

insecdata

ipsecmethods

is

jan

January

jul

july

jun

june

kbuf

keep

limit

log

long

magenta

mail

mar

march

may

mday

medium

modify

mon

Monday

month

mortrap

navy

netobj

netof

nets

nexpires

not

nov

November

oct

October

or

orange

origdport

origdst

origsport

origsrc

other

outbound

outrap

packet

packetid

packetlen

pass

r_arg

r_cdir

r_cflags

r_ckey

r_connarg

r_ctype

r_entry

r_pflags

r_proxy_action

r_tab_status

r_xlate

record

red

refresh

reject

resourceobj

routers

sat

Saturday

sep

September

servers

servobj

set

short

skipmen

snmptrap

spoof

spoofalert

sr

src

static

sun

Sunday

sync

targets

thu

Thursday

to

tod

tracks

tue

Tuesday

ufp

userdefined

vanish

wasskipped

wed

Wednesday

xlatedport

slatedst

slatemethod

xlatesport

xlatesrc

xor

year

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.