Security Before Firewall Activation

Achieving Security Before Firewall Activation

There are several scenarios in which a computer does not yet have a security policy installed and is vulnerable. Two features provide security during these situations: Boot Security, which secures communication during the boot period, and Initial Policy, which provides security before a security policy is installed for the first time. As a result, there is no point in time when the computer is left unprotected.

Boot Security

During the boot process, there is a short period of time (measured in seconds) between the point when the computer is capable of receiving communication (and can be attacked) and the point when the security policy is loaded and is enforced. During this time, the firewall Boot Security feature protects both the internal networks behind the Security Gateway, and the computer itself. Boot Security is provided by two elements working together:

• Control of IP Forwarding on boot
• Default Filter

The Default Filter also provides protection in a scenario where firewall processes are stopped for maintenance.

Control of IP Forwarding on Boot

For networks protected by a Security Gateway, protection is available at boot by disabling IP forwarding in the OS kernel. This ensures that there will never be a time when IP Forwarding is active and no security policy is enforced. This ensures that networks behind the gateway are safe.

Disabling IP Forwarding protects networks behind the Security Gateway computer, but it does not protect the Security Gateway computer itself. For this purpose, the Security Gateway implements a Default Filter during the period of vulnerability.

The Default Filter

When a Security Gateway boots with the Default Filter, the following sequence is performed:

1. Computer boots up.
2. Boot security takes effect (Default Filter loads and IP Forwarding is disabled).
3. Interfaces are configured.
4. Security Gateway services start.

The computer is protected as soon as the Default Filter loads.

There are several Default Filters:

• General Filter accepts no inbound communication (this is the default option).
• Drop Filter accepts no inbound or outbound communication. This filter drops all communications into and out of the gateway during a period of vulnerability. Note, however, that if the boot process requires that the gateway communicate with other hosts, then the Drop Filter should not be used.
• Default Filter for IPSO allowing SSH incoming communication to support remote Administration.
• Default Filter for IPSO allowing HTTPS incoming communication to support remote Administration.
• Default Filter for IPSO allowing SSH and HTTPS incoming communication to support remote Administration.

The appropriate Default Filter should be selected based on platform and communication needs. The General Filter is selected by default.

The Default Filter also provides Anti-Spoofing protection for the Security Gateway. It ensures that packets whose source is the Security Gateway computer itself have not come from one of its interfaces.

Changing the Default Filter to a Drop Filter

For a typical setup there are two Default Filters: defaultfilter.boot and defaultfilter.drop. They are located in $FWDIR/lib.

To change the Default Filter:

1. Copy over and rename the relevant desired Default Filter Inspect file (defaultfilter.boot or defaultfilter.drop) to $FWDIR/conf/defaultfilter.pf
2. Compile the Default Filter by running the command:

   fw defaultgen

   The output will be in $FWDIR/state/default.bin

3. Run fwboot bootconf get_def to print the Default Filter file path.
4. Copy default.bin to the Default Filter file path.
5. If the security policy has not yet been installed, run cpconfig to regenerate the Initial Policy.

Defining a Custom Default Filter

For administrators with Inspect knowledge, you can define your own Default Filter.

To define a Default Filter:

1. Create an Inspect script named defaultfilter.pf in $FWDIR/conf:

1. Continue from step 2 of Changing the Default Filter to a Drop Filter.

You must ensure that your security policy does not interfere with the boot process.

Using the Default Filter for Maintenance

It is sometimes necessary to stop firewall processes for maintenance, and it is impractical to disconnect the Security Gateway computer from the network (for example, the computer may be at a remote location).

The cpstop -fwflag ‑default and cpstop -fwflag ‑proc commands allow Security Gateway processes to be temporarily stopped for remote maintenance without exposing the computer to attack.

During maintenance, the Default Filter allows open connections to the gateway to remain open, without dropping them.

The Initial Policy

Until the Security Gateway administrator installs the security policy on the gateway for the first time, security is enforced by an Initial Policy. The Initial Policy operates by adding "implied rules" to the Default Filter. These rules forbid most communication yet allows the communication needed for the installation of the security policy. The Initial Policy also protects a gateway during Check Point product upgrades, when a SIC certificate is reset on the gateway, or in the case of a Check Point product license expiration.

The sequence of actions during boot of the Security Gateway computer until a security policy is loaded for the first time:

1. The computer boots up.
2. The Default Filter loads and IP Forwarding is disabled.
3. The Interfaces are configured.
4. Security Gateway services start.
5. The Initial Policy is fetched from the local gateway.
6. SmartConsole clients connect or Trust is established, and the security policy is installed.

The Initial Policy is enforced until a user-defined policy is installed, and is never loaded again. In subsequent boots, the regular policy is loaded immediately after the Default Filter.

There are different Initial Policies for standalone and distributed setups. In a standalone configuration, where the Security Management Server and the Security Gateway are on the same computer, the Initial Policy allows CPMI communication only. This permits SmartConsole clients to connect to the Security Management Server.

In a distributed configuration, where the Primary Security Management Server is on one computer and the Security Gateway is on a different computer, the Initial Policy allows the following:

• Primary Security Management Server computer — allows CPMI communication for SmartConsole clients.
• Security Gateway — allows cpd and fwd communication for SIC communication (to establish trust) and for Policy installation.

In a distributed configuration, the Initial Policy on the Security Gateway does not allow CPMI connections. The SmartConsole will not be able to connect to the Security Management Server if the SmartConsole must access the Security Management Server through a gateway running the Initial Policy.

There is also an Initial Policy for a Secondary Security Management Server (Management High Availability). This Initial Policy allows CPMI communication for SmartConsole clients and allows cpd and fwd communication for SIC communication (to establish trust) and for Policy installation.

Managing Default Filter and Initial Policy

Verifying Default Filter or Initial Policy Loading

You can verify that the Default Filter and/or Initial Policy are loaded.

To verify loading of the Default Filter or Initial Policy:

1. Boot the system.
2. Before installing another security policy, type the following command:

$FWDIR/bin/fw stat

The command's output should show that defaultfilter is installed for the Default Filter status. It should show that InitialPolicy is installed for the Initial Policy.

Unloading Default Filter or Initial Policy

To unload a Default Filter or an Initial Policy from the kernel, use the same command that is used for unloading a regular policy. Do this only if you are certain that you do not need the security provided by the Default Filter or an Initial Policy.

To unload the Default Filter locally:

• Run the fw unloadlocal command.

To unload an Initial Policy from a remote Security Management machine:

• Run the following command on the Security Management Server:

  fwm unload <hostname>

  where hostname is the SIC_name of the gateway.

Troubleshooting: Cannot Complete Reboot

In certain configurations the Default Filter may prevent the Security Gateway computer from completing the reboot following installation.

First, examine the Default Filter and verify that the Default Filter allows traffic that the computer needs in order to boot.

If the boot process cannot complete successfully, remove the Default Filter as follows:

1. Reboot in single user mode (for UNIX) or Safe Mode With No Networking (for Windows 2000).
2. Ensure that the Default Filter does not load in future boots. Use the command
   fwbootconf bootconf Set_def
3. Reboot.

Command Line Reference

control_bootsec

Enables or disables Boot Security. The command affects both the Default Filter and the Initial Policy.

Usage

$FWDIR/bin/control_bootsec [-r] [-g]

options control_bootsec

fwboot bootconf

Use the fwboot bootconf command to configure boot security options. This command is located in $FWDIR/boot.

Usage

$FWDIR/bin/fwboot bootconf <command> [value]

options fwboot bootconf

comp_init_policy

Use the comp_init_policy command to generate and load, or to remove, the Initial Policy.

This command generates the Initial Policy. It ensures that it will be loaded when the computer is booted, or any other time that a Policy is fetched, for example, at cpstart, or with the fw fetch localhost command. After running this command, cpconfig adds an Initial Policy if there is no previous Policy installed.

Usage

$FWDIR/bin/comp_init_policy [-u | -g]

options comp_init_policy

The comp_init_policy -g command will only work if there is no previous policy. If there is a policy, make sure that after removing the policy, you delete the folder $FWDIR\state\local\FW1\. The $FWDIR/state/local/FW1 folder contains the policy that will be fetched when fw fetch localhost is run.

The fw fetch localhost command is the command that installs the local policy. cpstart. comp_init_policy creates the initial policy, but has a safeguard so that the initial policy will not overwrite a regular user policy (since initial policy is only used for fresh installations or upgrade). For this reason, you must delete the $FWDIR\state\local\FW1\ directory if there is a previous policy, otherwise comp_init_policy will detect that the existing user policy and will not overwrite it.

If you do not delete the previous policy, yet perform the following commands …
… the original policy will still be loaded.

comp_init_policy -g + fw fetch localhost
comp_init_policy -g + cpstart
comp_init_policy -g + reboot

cpstop -fwflag default and cpstop -fwflag proc

To stop all firewall processes but leave the Default Filter running, use cpstop -fwflag -default. To stop all Security Gateway processes but leave the security policy running, use cpstop -fwflag -proc.

To stop and start all Check Point processes, use cpstop and cpstart. These commands should be used with caution.

On Win32 platforms, use the Services applet in the Control Panel to stop and start Check Point Services.

Usage

cpstop -fwflag [‑default | ‑proc]

Options for fwflag