Common Configuration Questions

In the course of using or configuring FireWall-1, a number of common configuration questions come up from time to time. The following subsections document the most common ones.

6.1 How Do I Modify FireWall-1 Kernel Variables ?

Over the years , Check Point has introduced some rather obscure features by exposing "kernel variables" that can be tweaked to change certain behavior. While this is not the most elegant solution, it involves the least amount of work because it requires no GUI changes. Modifying kernel variables is relatively straightforward once you know how. You perform the appropriate commands for your platform and reboot.

Let us assume that the kernel variable we want to modify is fw_allow_udp_port0 . For the record, this particular variable allows packets to be sent from or to UDP port 0, which FireWall-1 normally drops . In order to allow these kinds of packets, we need to change the value of this parameter to 1 . The value can be specified in decimal or hexadecimal (precede with an 0x for hexadecimal).

In general, you can substitute fw_allow_udp_port0 and 0x1 for the variable you want to modify and the value you wish to assign it, respectively.

On Solaris machines, add the following line to the bottom of the /etc/system file, and reboot:

 set fw:fw_allow_udp_port0=0x1 

On an IPSO system (VPN-1 Appliance or Nokia IPxxx), you need to get the modzap utility from Resolution 1261 in Nokia's Knowledge Base. You can then use the following command line to modify the fw_allow_udp_port0 parameter and reboot the system:

 nokia[admin]#  modzap _fw_allow_udp_port0   $FWDIR/boot/modules/fwmod.o 0x1  

NOTE!

On IPSO, all kernel variables begin with an underscore ( _ ).

On a Linux platform, you simply add the following line to $FWDIR/boot/modules/fwkern.conf and restart FireWall-1 (no reboot required):

 fw_allow_udp_port0=1 

For Windows, there is no way to modify kernel variables without getting a special utility called fwpatch from Check Point support. In some cases, it is possible to tweak registry settings.

6.2 Can I Direct FireWall-1 Log Messages to syslog?

To log specific events to syslog, I use user-defined logging for this. My user -defined program (defined in the Global Properties section, Log and Alert frame) is /usr/ucb/logger -p daemon.notice . The path to the logger utility varies depending on the operating system.

Another alternative is to log everything to syslog. You can do this with the following command:

 #  fw log -f 2>>/var/adm/fw-log.log  /bin/logger p \   local5.info > /dev/null 2>&1 &  

This command runs in the background and logs everything to syslog. Note that it might be best to put this into a boot script after FireWall-1 loads so that everything is dumped to syslog.

On Windows platforms, instead of logger , use the Kiwi SyslogGen program, available from http://www.kiwisyslog.com.

6.3 How Can I Disconnect Connections at a Specific Time?

Active connections stay in the connections tables until they either terminate or expire. The rulebase controls only when connections start, not how long they are allowed to stay connected.

One way to block connections at a specific time is to use the fw sam command, which is described in Chapter 5. At a specified time, run a command via cron that blocks all inappropriate traffic and disconnects any active session for a specific period of time. Once the timeout for that command expires (you can set it as low or as high as you want), everything should go through your rulebase normally. The old connections should theoretically be forgotten.

6.4 How Many Interfaces Are Supported?

FireWall-1 NG up to NG FP2 supports 256 interfaces. Versions NG FP3 and above support 1,024 interfaces. However, each IP associated with the platform might get associated with the interface slot, depending on how old a version you are running.

On the Nokia platform, things are a little more complicated, depending on which version of IPSO and FireWall-1 you happen to be using. The following list shows what your interface limit is based on the versions used:

• FireWall-1 NG FP2 or earlier without VLAN hotfix : 64 interfaces

• FireWall-1 NG FP2 with VLAN hotfix: 256 interfaces

• FireWall-1 NG FP3 on IPSO 3.6: 256 interfaces

• IPSO 3.7 or above (with supported FireWall-1 version): 1,024 interfaces

What constitutes an interface varies by platform. GRE tunnels, VLANs, frame relay DLCIs, point-to-point links, permanent virtual circuits, and other similar constructs may be considered interfaces by FireWall-1.

6.5 How Do I Create a Large Number of Objects via the Command Line?

Bulk creation of objects is accomplished through the use of the command-line program dbedit , which provides a protected interface to the Check Point object database, along with object validation.

The dbedit commands used to create a simple network object are listed below. (x.y.z.w is the IP address, a.b.c.d is the netmask , and sample-network is the name of the object.)

 dbedit>  create network sample-network  dbedit>  modify network_objects sample-network ipaddr x.y.z.w  dbedit>  modify network_objects sample-network netmask a.b.c.d  dbedit>  update network_objects sample-network  

The create command is used to bring the object into existence, the modify command is used to change elements of that object, and the update command is used to push that change to the object database.

To create a simple host object (e.f.g.h is the host object IP), use these commands:

 dbedit>  create host_plain sample-host  dbedit>  modify network_objects sample-host ipaddr e.f.g.h  dbedit>  update network_objects sample-host  

To group the objects together, use these commands:

 dbedit>  create network_object_group sample-group  dbedit>  addelement network_objects sample-group ''   network_objects:sample-network  dbedit>  addelement network_objects sample-group ''   network_objects:sample-host  dbedit>  update network_objects sample-group  

In the preceding example, the addelement command is responsible for adding the objects into the group. Since a group can potentially contain non-network objects, we have to be explicit when we add them to a group, which is why we refer to sample-network and sample-host as network_objects:sample-network and network_objects:sample-host , respectively, within the code.

You can also create a network object with automatic NAT by using the following commands:

 dbedit>  create host_plain london  dbedit>  modify network_objects london ipaddr 192.168.1.1  dbedit>  modify network_objects london color red  dbedit>  modify network_objects london comments "This is london calling"  dbedit>  modify network_objects london add_adtr_rule true  dbedit>  modify network_objects london NAT NAT  dbedit>  modify network_objects london NAT:valid_ipaddr 195.195.195.3  dbedit>  modify network_objects london NAT:netobj_adtr_method adtr_static  dbedit>  update network_objects london  

In the preceding example, if you wanted to do hide mode NAT, replace adtr_static with adtr_hide .

By putting the appropriate dbedit commands in a file and invoking dbedit correctly, you could script the creation of network objects. To automate the process, execute something similar to the following on your management station ( dbeditcmdfile.txt contains the dbedit commands).

 #  dbedit -s localhost -u admin -p adminpw -f dbeditcmdfile.txt