HostedDB - Dedicated UNIX Servers

TICM - The Firewall Hardening Guide v0.1

The Firewall Hardening Guide v0.1 - Checkpoint Firewall-1 Specific Requirements



Implicit Rules (Rule Zero rules)

DNS Rule Zero Rules

Open the Properties Setup window. Deselect both “Accept Domain Name Queries” checkboxs (UDP & TCP).
Insert specific rules to manage the DNS traffic. Rule Zero Rules are rules that get executed before any user defined rule. They Do Not appear in the normal rule table, but appear in a configuration screen.
The DNS Rules are risky because the default configuration allows traffic on the DNS port to traverse the firewall without being controlled from any port. This rule has been used to enable such tools as BackOrifice to bypass the firewall.
Insert specific rules to manage the DNS traffic. Rule Zero Rules are rules that get executed before any user defined rule. They Do Not appear in the normal rule table, but appear in a configuration screen.
The DNS Rules are risky because the default configuration allows traffic on the DNS port to traverse the firewall without being controlled from any port. This rule has been used to enable such tools as BackOrifice to bypass the firewall.

FW-1 Control Connections

FW-1 accepts connections on any of the Firewall-1 management ports. These include:
TCP port 256 - 259 and 261
UDP port 161 (SNMP)
TCP port 18181 – 18184
IP Type=94 (IP within IP encapsulation)
This setting should be disabled in control properties, and enabled through the rule base. This is done to be able to log, and also gain better control of traffic on this port.

Apply gateway rules to interface direction

The communication direction in which rules that are installed on gateways will be enforced. A setting of ‘Inbound’ applies the policy rules to traffic as it enters the firewall. ‘Outbound’ applies the policy rules after the firewall receives the traffic while ‘Eitherbound’ applies the rules in both directions. Eitherbound can cause traffic to be processed twice by the rule base.
Our recommendation is to use ‘Inbound’.
This will check the data as they enter the firewall. Eitherbound will represent a doubling in processing load, and is not recommended.

TCP session timeout

This parameter is by default set to 3600 seconds (1 hour),  the time period which a TCP session will be considered to have timed out. This is useful for protocols such as FTP which can be inactive for a long period (the FTP control session does not use keep-alives while the data session is transferring information).
Default 3600 seconds is recommended
By lowering this value users will experience more problems with broken connections in their sessions. On the other hand a higher value increases the risk of session hijacking and programs like trojan hors-es to operate undetected.

Accept UDP Replies

A UDP service sets up a two-way communication between the source and the destination; that is, when the communication is established between the source and the destination, a reply channel is also cre-ated between the destination and the source. When a UDP service communication is accepted on the destination and Enable UDP Replies is active, the reply channel is allowed. Only packets from the des-tination host and port are accepted as part of this communication.
This setting should be enabled.

Reply Timeout

The amount of time a UDP reply channel may remain open without any packets being returned. Since the communication is connectionless, there is no way to inform the reply channel when the communi-cation has finished. Note that FireWall-1 creates a connection context for UDP. Once the specified time has elapsed, the session is assumed to have ended and the reply channel is closed.
The default value is normally to be secure.

Accept Outgoing Packets

Allow all traffic originating from the firewall. This may be required if the rules have been applied Either-bound, NAT is being performed, or you are using security servers (i.e. FW-1 proxies).
This setting should be enabled. Otherwise no traffic will ever leave the firewall in any direction, making the firewall act as a ‘black hole’.

Enable Decryption on Accept

Decrypt incoming packets even if the rule accepting the connection does not specify it.
This setting should be enabled.

Use Fastpath/Fastmode

(This option is no longer available in V4.xx, but may be defined for TCP services that does not require encryption or authentication. The option is renamed Fastmode)The Fastpath feature speeds the process of forwarding traffic but does so at the cost of security.
Use Fastpath should be disabled. If Fastpath is enabled, encryption and authentication cannot be used. The firewall will also be less picky in inspecting passing traffic. Using fastmode for TCP services in general is not recommended, unless one or more of the following conditions apply:

Synchronisation between firewalls are being used

Packet loss can be documented (Fastmode will speed up the processing of TCP packets). In normal installations packet loss should not occur until throughput exceeds 30 – 60 Mbit. (ref. CheckPoint documentation on performance for Firewall-1 under various operating systems.)

Accept RIP

Accept Routing Information Protocol traffic used for dynamic routing. RIP maintains information about reachable systems and routes to those systems. This setting assumes that RIP is running on the fire-wall. You should always use static route entries on a firewall unless you are running redundant firewalls or Internet links.
This setting should be disabled, unless RIP Must used through the Firewall-1 (not recommended).

Accept ICMP

Allow all ICMP based traffic.
Each of these rules are processed based on the pull down setting to the right. The options are:
First: Accept this traffic before processing the rule base.
Before Last: Accept this traffic, unless the rule base specifically blocks it from taking place.
Last: Process this traffic after the last rule in the rule base. If it is not specifically blocked, let it pass. If the last rule is "Drop all traffic from any source to any destination," this property is not evaluat-ed.
There are 17 types of ICMP, where types like ‘host unreachable’ and ‘source quench’ represent secu-rity risks for DoS (Denial-of-Service) attacks. Normally there should be no need for ICMP through the firewall. RFC 1700 holds more information on ICMP.
This setting should be disabled. ICMP passing through the firewall will not be needed under nor-mal circumstances, and will only serve as a security risk.