This document is intended to describe a problem with Checkpoint’s Firewall-1 product which can allow an attacker to pass traffic through the firewall which the administrator may not have intended to allow in. It also describes conditions where traffic is allowed to pass through the firewall without an entry being created in the firewall log. This document will also describe precautions that can be taken in order to eliminate these issues.

Problem Description
Although it appears that all Firewall-1 traffic control is setup within the main screen of the Policy Editor, there is actually a special "Properties" page where traffic control is enforced as well. This can be accessed by selecting Policy-->Properties from the Policy Editor main menu. This produces the screen shown in Figure 1. All of the settings in Figure 1 are collectively known as "Rule 0".

Figure 1

 

A brief description of each item is as followed (much of this text is from Firewall-1’s on-line help file):

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.

TCP Session Timeout
The time period after which a TCP session will be considered to have timed out. The 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 moving information).

Accept FW-1 Control Connections
Accept connections on any of the Firewall-1 management ports. These include:

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 created 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 destination host and port are accepted as part of this communication.

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 communication 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.

Accept Outgoing Packets
Allow all traffic originating from the firewall. This may be required if the rules have been applied Eitherbound, NAT is being performed, or you are using security servers (i.e. FW-1 proxies).

Enable Decryption on Accept
Decrypt incoming packets even if the rule accepting the connection does not specify it. This rule has always bothered me although I have yet to hear of an exploit. Essentially it causes the firewall to attempt decryption from remote hosts even if the administrator has not previously setup a VPN.

Use Fastpath
The Fastpath feature speeds the process of forwarding traffic but does so at the cost of security. If Fastpath is enabled, encryption and authentication cannot be used. The firewall will also be less picky in inspecting passing traffic.

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 firewall. You should always use static route entries on a firewall unless you are running redundant firewalls or Internet links.

Accept Domain Name Queries (UDP)
Accept Domain Name Queries used to resolve Internet host names. This opens UDP port 53.

Accept Domain Name Download - (TCP)
Allow DNS zone transfers between DNS systems. This opens TCP port 53.

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 evaluated.

To demonstrate this problem, I setup a test network. The systems used where:

FW_TEST - A Compaq system with 2 NICs acting as a firewall. The configuration of this system was as followed:

The Firewall-1 properties screen was left at its default settings (per Figure 1). Within the Policy Editor, I created a single rule: ANY-ANY-ANY-DROP
This rule states "Any traffic originating from any location and going to any location, using any service, should be dropped". This implies that the firewall should be dropping all traffic and not allowing anything to pass.

I then loaded a copy of Netcat onto the target NT system. This could just as easily have been BO or any other remote control program. The exploit software does not matter, what does matter is that Netcat was set to listen on TCP port 53.

I then went to the attack system (Hellsfarr) and attempted to create a connection through the firewall. The results are shown in Figure 2. In log entry number 3, I installed the above described rules. Around log entry 7 or so I was able to create a session from the external system Hellsfarr to the internal system Target. This session allowed me to view files and even launch applications on the NT server. Had I used BO or some other variant, I would have also been able to monitor desktop activity as well.

Figure 2

 

As you can see, no log entry for my inbound attack session was created. An internal system is currently under attack and the firewall is showing no indication that something is going on. Also, while the rule base makes it look like the firewall should be blocking all traffic, I am able to create an inbound session on port 53 due to the default settings on the Properties screen.

At log entry 16, I modified the Property setting by deselecting the "Accept Domain Name Download" option. Entry 16 is when I re-installed the firewall rules in order to make this change active. As you can see in entry number 17, my session to the target system is now properly logged and dropped.

To test the effect of the ICMP property setting, I then launched a SMURF attack against the target system. This was around the time of log entry 18. As you can see, this traffic was not logged either. I confirmed that the SMURF attack was able to penetrate the firewall by using a sniffer device on the internal network. I also verified penetration by checking the Ethernet stats on the internal NT system.

I then attempted to create an inbound session from Hellsfarr to the target system using one of the Firewall-1 control ports. As you can see in log entry 19, this traffic was properly logged and dropped. I then attempted to establish a session from the external system to the firewall itself using the Firewall-1 control ports and was successful every time. What was disturbing however was that these attempts where not logged as shown by the remaining log entries in Figure 2.

I should qualify "successful". By successful I mean I was able to complete a TCP 3 packet handshake on the port in question without creating a log entry. While this did not provide me with system access, it is sufficient for launching a SYN denial of service attack or possibly some form of buffer overflow if one exists. I did not test these attacks to see what the effects would be as my main concern was that this activity could be performed without generating log entries. I personally consider it a major security flaw that someone could spend days or weeks attempting a control session to the firewall and not a single log entry would ever be generated.

Implications
Because of the default properties settings, Firewall-1 will accept and fail to log the following traffic:
UDP/53 traffic to any destination
TCP/53 traffic to any destination
ICMP traffic to any destination
TCP/256 - 259 and 261 traffic sent to the firewall
UDP/160 (SNMP) traffic sent to the firewall
TCP/18,181 - 18,184 traffic sent to the firewall
IP Type=94 (IP within IP encapsulation) traffic sent to the firewall

How to Fix the Problem
To start, you should disable most of the default property settings as shown in Figure 3. The only Property settings left active are "Accept UDP Replies" and "Enable Decryption on Accept". It is possible to deselect the "Enable Decryption on Accept" option as well, so long as you setup your VPN rules correctly (or a VPN does not exist). These property changes will prevent the firewall from passing traffic not shown in the policy editor. It will also force all traffic to be logged except for UDP replies (you will still see the session establishment packet).  I should also note that if you are using FW-1 to manage access lists on routers, you must make similar configuration changes to the Access Lists tab of the Property Setup window (last tab on the right in Figure 3).

Figure 3

Now that these properties are disabled, you must make sure you add any required traffic policies to the policy editor. For example, lets say you have an internal DNS server named "Thoth" which handles your internal DNS. All internal systems point to this DNS server for name resolution, so Thoth also needs to be able to perform external queries. You would need to add a rule to your security policy similar to the following:
Source = Thoth
Dest. = Any
Service = DNS
Action = Allow

This would allow Thoth to perform DNS queries while logging this activity. If Thoth is listed with the InterNIC as one of your DNS servers, you would need to add a second rule similar to the following:
Source = Any
Dest. = Thoth
Service = DNS
Action = Allow
 
Note that if you wanted to prevent external systems from performing zone transfers, you could limit the service in the second rule to only UDP based DNS queries. Using the above set of rules, an attacker who has successfully loaded BO or some other trojan on an internal system, while configuring the software to listen on port 53, would no longer be able to access the compromised system.

You will also need to add additional rules if you want to be able to remotely manage the firewall (no rule changes are required to run the management software from the firewall console itself). For example, lets say I wish to be able to use the Log Viewer remotely. I would add a rule similar to rule number 2 in Figure 4. With this rule I have specifically limited access to the firewall’s Firewall-1 management port to the system named Hellsfarr. I would also need to add Hellsfarr’s IP address as a management station using the Firewall-1 Configuration utility. Once these two changes are made and the policy is installed, I will be able to remotely access the Log Viewer.

Figure 4

Summary
So while it is possible to log all passing traffic with Firewall-1, you can not do so with the default settings. The default settings have the additional problem of being configured to allow unrecorded access to the internal network. The combination of these two problems can allow an attacker to penetrate a firewall and go completely undetected without having to compromise the firewall itself.