| 5 comments ]

The Check Point Database Tool, also referred to as GuiDBedit, is a graphical user interface (GUI) that enables its users to edit objects and properties in the SmartCenter management database. This Database Tool allows users to change properties that cannot be edited using SmartDashboard.



Advisory: Due to the powerful database editing abilities supplied by the tool, only experienced users should work with it.

  • Availability - the Database Tool is available and supplied as part of the SmartConsole installation.
  • The Database Tool executable - GuiDBedit.exe - is located in the same folder where the SmartConsole is installed:
    Default location on Windows OS:
    C:\Program Files\CheckPoint\SmartConsole\RXX\PROGRAM\GuiDBedit.exe

    Default location on Windows Vista/7 OS:
    C:\Program Files (x86)\CheckPoint\SmartConsole\RXX\PROGRAM\GuiDBedit.exe
Note: it is suggested to backup your environment before using GuiDbEdit (refer to sk54100: How to back up your system).

For instructions on using DBedit, refer to skI3301 - Editing objects_5_0.C file via Check Point database editing utilities.

Read More ...
| 4 comments ]

Check Point Resources

CPUG:  The Check Point User Group:

CPUG  CPUG's Official Site
CPUG University  CCSA/CCSE Dual-Certification Course and Other Check Point Training Courses in San Francisco
CPUG CON  The Annual CPUG User Conference

About Check Point:

Check Point  Check Point's Official Site
Check Point  On Wikipedia
Check Point Exams Non-Disclosure Agreement
NGX Utilities Including Web Visualization Tool

Other Firewall Organizations:

Virtual Private Network Consortium  The international trade association for manufacturers in the VPN market
The Center for Internet Security  A not-for-profit organization that helps enterprises reduce the risk of business and e-commerce disruptions resulting from inadequate technical security controls and provides enterprises with resources for measuring information security status and making rational security investment decisions

HowTos:

HowTo:  Migrate From A Single Gateway to Distributed Deployment
HowTo:  Integrate Check Point Firewall-1/VPN-1 With Microsoft Active Directory
HowTo:  Check Point Rule Cleanup White Paper by FirePAC
Synchronizing Time on Security Gateways
SPLAT on VMware
Identifying HFA Versions

Utilities:

Object Filler 2.4 by Martin Hoz.  The Famous Object Filler and Object Dumper tools. (MD5: 013B1B7A5EE24DB33212951E08D539BE)

Blogs:

Tobias Lachmann's Blog
Kellman Meghu's Blog
Yuri's Blog

Useful Scripts:

SPLAT Backup Script
SPLAT Configuration Summary Script
Useful Script for grabbing all configuration information and running upgrade_export

Sites Maintained By Users:

CPrules Firewall Rulebase Viewer from Peter-Paul Worm in the Netherlands
Check Point Best Practices from Knowurtech.com
SDDelta Shows SmartDefense Changes Over Time, by Lebbeous Weekley at Hurricane Labs
Check Point Documents by wumozhe
Fireverse  Documentation and Discussions on Check Point products
Temet Information Security  Very good section on Firewall-1, by Bob Snowdale of Orlando, Florida
Snake Oil Research  Lots of useful Check Point information from Adam Barton
Check Point Notes and Videos (In English and Polish) by Wanoper
AERAsec in Germany Information about Check Point VPN-1/FireWall-1
Netl33ts: Checkpoint Some good articles about Firewall-1/VPN-1
Check Point Visio Stencil

Helpful Utilities:

VPN Guard  Automate re-logons for SNX after connect time expiresCPrules Firewall Rulebase Viewer
FWdoc  a free vendor-independent standard of storing firewall ruleset configurations
Nipper: Open Source Network Information Parser
Athena Firewall Grader (Free Trial)

Documents:

fw monitor:
    "How To" document
    Some more explanation from Check Point

Reasons Why We're Not Currently Dating Anyone:

When Data Center Cabling Becomes Art  at Royal Pingdom
RateMyNetworkDiagram vote on the "look" of a network diagram
Really Bad Wiring Jobs at Dark Roasted Blend
Cable Messes at Vibrant.com
The World's Densest Internet Meet-Me Room from Wired Magazine
Refer to https://www.cpug.org/check_point_resources.htm

Read More ...
| 0 comments ]

Smart SPLAT is a freeware software developed by Çağdaş Ulucan to troubleshoot Checkpoint firewall issues and perform management tasks.

Our software
periodically checks for an update and when a new release is published, updates itself via the SmartSPLAT web site.

SmartSPLAT lets you connect to your firewall via secure channel SSH

Critical commands like cpstop, kill, reboot and etc. deleting a license or similar commands that can cause your firewall not to function properly are colored red protected by checkboxes and shows confirmation dialogs.

In this project we have used an ssh Library based on the Poderosa project.
For file transfer operations,SmartSPLAT uses putty pscp.exe, to work with SCP /etc/scpusers/ file should be modified.
Smart SPLAT has a script named preparescp. It checks if user exists at /etc/scpusers/ if not, adds a line for it.

# more preparescp
grep admin /etc/scpusers
if [ "$?" -ne "0" ];
then
echo admin >> /etc/scpusers
else
exit 1
fi
#

Record options, allows you to record everything you type in shells, “Linux ‘# script’ command”
 
Thank you very much for your interest. SmartSPLAT users are growing world wide.

Read More ...
| 21 comments ]

What is CheckPoint Clustering ?

The premise behind CheckPoint clustering is that having two firewalls in active/standby is a bad idea. This is true for CheckPoint because they are so expensive that you can’t afford to keep buying new units so why waste half of your money with the second firewall doing nothing. Therefore, owning two units, and using them in Active/Active mode is perceived as a way of saving money. To make it worse, this very idea is so ‘kleva’ that CheckPoint engineers are commonly known to suggest the practice as a ‘competitive advantage.
There is one useful feature, the fact that you can cluster up to four units into a ‘single cluster’. However, the operational impact of this is very poor. It is not possible to to determine which firewall is handling a given flow, thus making troubleshooting very hard or impossible. Anyone who thinks that the Tracker tool can be used for troubleshooting needs a good spanking – it’s a good logging tool but not a perfect troubleshooting tool.

How does CheckPoint clustering work ?

In fact, Checkpoint doesn’t do the clustering, the Nokia IPSO software does although it seems that the manual makes no reference to this. You might want to refer to Cluster XL Admin Guide for this much improved( since 2007 when I last couldn’t get the manuals because of a paywall) but mostly unhelpful piece of documentation.
It’s worth noting that CheckPoint is actually a piece of software that runs on many platforms. In the past CheckPoint was used on Solaris, Windows and BayRS routers. Today it runs on Nokia IPSO, SPLAT (custom Linux distro) and Crossbeam. As a result, the CheckPoint software isn’t tightly coupled to the networking features of the underlying platform. Perhaps this explains why the manuals miss out on the networking aspects of firewall functions.

Normal Firewall Operation

So lets set a baseline around normal firewall operation.
Checkpoint cluster 1
In normal operation a firewall works this way:
  1. client sends packet
  2. firewall will receive an ARP from from the router,
  3. respond with MAC address that is shared between the firewalls (and transfers between the active and standby unit on failover).
  4. The firewall will receive the packet and forward it to the internal network. The reverse flow is identical.
All this is standards compliant, expected and operationally easy to maintain and troubleshoot.

Checkpoint Clustering Operation

Obviously, to provide clustering something unusual has to happen because either, or both, firewalls need to receive each and every packet that needs to be forwarded. The purpose of clustering is to enable two or more (up to four ??) firewalls to pass flows in a fully load balanced/shared way. Why would you do this ? My view is that CheckPoint / Nokia firewalls are relatively very expensive compared to Cisco/Juniper equivalents, so customers want to make the most of the “investment”. A shortcut like this looks attractive to double the throughput of the system.

From the Manual

From the manual:
ClusterXL uses unique physical IP and MAC addresses for the cluster members and virtual IP addresses to represent the cluster itself. Virtual IP addresses do not belong to an actual machine interface (except in High Availability Legacy mode, explained later). ClusterXL provides an infrastructure that ensures that data is not lost due to a failure, by ensuring that each cluster member is aware of connections passing through the other members. Passing information about connections and other Security Gateway states between the cluster members is known as State Synchronisation.

IP and MAC addresses

No, really, if you don’t understand these you should not be reading this. Return to school, do not collect $200 etc.

State Synchronisation

This is easy enough. Each flow that traverses the firewall creates a entry in a state database on the firewall, and this state database must/should/depends/your choice to be replicated to other firewalls so that if a failure event occurs, the other unit knows what traffic flows you were forwarding and can keep on going.
State Synchronisation means that for every flow on one firewall, it’s data is replicated to other firewalls. It’s most useful for long held data flows such as SQL and not so much for HTTP (YMMV).

Cluster Control Protocol

There is no standard protocol for synchronising such devices so CheckPoint created something with an imaginative name:
The Cluster Control Protocol (CCP) is the glue that links together the machines in the Check Point Gateway Cluster. CCP traffic is distinct from ordinary network traffic and can be viewed using any network sniffer. CCP runs on UDP port 8116, and has the following roles: – It allows cluster members to report their own states and learn about the states of other members by sending keep-alive packets (this only applies to ClusterXL clusters). – State Synchronisation.
Great. Basics are done.

ClusterXL modes

ClusterXL has four working modes:
  • Load Sharing Multicast Mode
  • Load Sharing Unicast Mode
  • New High Availability Mode
  • High Availability Legacy Mode
Ok, so there are four possible high availability modes. Two of which are actually “clustering” and two of which are NOT – they are ‘High Availability” active/standby. So we will ignore those.

Checkpoint/Nokia Multicast Clustering

Anything with the word ‘Multicast’ in it automatically means trouble. And, you would be right. Except that Checkpoint does naughty multicast. Well, it’s not IP Multicast it’s Ethernet Multicast. Lets walk it through:
Checkpoint cluster 2
For CheckPoint/Nokia the packet flow works something like this:
  1. client sends packet
  2. router will ARP for the next hop MAC address, all firewalls will respond with a Multicast MAC address.
  3. Router sends Ethernet frame with a Multicast MAC address which the switch must treat as a broadcast to all devices in the VLAN
  4. The Cluster protocol will notify one of the firewalls to forward the flow, and it will reach the server.

Let’s consider the reverse direction:

Checkpoint cluster 3
  1. Server sends an ARP request.
  2. Firewalls respond with Multicast MAC address and transmit Ethernet frame.
  3. Server sends Ethernet frame with a Multicast MAC address which the switch must treat as a broadcast to all devices in the VLAN
  4. The Cluster protocol will notify one of the firewalls to forward the flow, and it will reach the server.
and off to the client it goes.

Multicast Ethernet, Undirected Broadcasts and Denial of Service

CheckPoint has now switched to using Ethernet multicast without using IP Multicast. By default, Ethernet switches are configured with IGMP enabled. Therefore after IGMP Query times have expired (about three minutes), the port will start to block the frames and thus disable the Clustering functionality.
Checkpoint recommends three options to ‘fix’ this:
  1. disable IGMP on the switches
  2. configure static MAC address mappings for the multicast mac address on all ports
  3. install an IGMP agent on the firewall

Disable IGMP on the switches

This is the primary recommendation from CheckPoint engineers and from the manual. To be fair, it’s possibly the best of three bad options although it’s most likely to cause significant problems.
When you disable IGMP on your ethernet switches, you are effectively allowing all multicast packets to be broadcast. That is, a multicast frame becomes a broadcast frame and every packet must be handled by every device in the VLAN. That is, broadcast frames are received by all devices, and the software protocol driver of the device must process the broadcast frame before discarding it thus creating performance problems (bus interrupts, buffer memory, CPU, software cycles, etc etc)
This is more commonly known as a Denial of Service Attack.
Consider this scenario: Checkpoint cluster 4
Lets assume that you have 100Mbps of inbound traffic on a fairly typical, dual router, dual firewall cluster type of setup like the following diagram. In this case, with IGMP disabled, 100Mbps of traffic will sent to the firewall and the standby router and all other devices on the public facing LAN.
Checkpoint cluster 5
In this scenario, each VPN concentrator is connected to a VLAN with Public IPv4 addresses. Since this is the only VLAN with the public address, you can’t put them anywhere else.
The VPN concentrators will needs to handle 100Mbps of broadcast traffic, in addition to the VPN traffic. Most likely, this will cause intermittent outages and service problems on those devices as the CPU struggles to read and discard that volume of traffic. In the worst case, the VPN concentrator may attempt to report broadcast flood and even shut down.

Server hosting

Lets consider the return path for traffic (because all flows have a return path). In this case, lets have a VLAN directly connected to the CheckPoint / Nokia firewall and some servers connected to that VLAN. Typically, this would be an email server, a web server, maybe a proxy or some other gateway. Most likely it would be several servers on that VLAN.
Checkpoint cluster 6
The server will get a Multicast MAC address for the IP address of any frames destined for firewall (most likely the default gateway) and will dispatch those according to the normal process. However, EVERY OTHER server will receive every packet as a Broadcast.
This will cause serious CPU impacts, and possible stability problems. You can fix this by having a L3 device on the inside of the firewalls, and limiting the impact of the broadcasts to the L2 VLAN that is directly connected to the firewalls, of course. But this limits your design choices, and isn’t helpful in an existing environment.

Configure static MAC address mappings for the multicast mac address on all ports

It’s worth noting that some cheaper Ethernet switches are unable to handle large volumes of multicast or broadcast packets in silicon. They may use the onboard CPU for frame replication which can drive on a few megabits before becoming overloaded. (Less common today, but still applicable on some products).
Lets take a look at configuring static MAC address in your switches. That is, you create manual MAC address entries for each port that has the Checkpoint device connected. This seems like a good solution since it stops the broadcasting outlined previously and tightly controls the packet flow.
However, the firewall team and network team must be fully aware of this for it to be operationally effective. Consider what happens a year later, when someone upgrades the switches, or replaces a faulty module, some other minor task ? It requires close supervision to keep the static database maintained over time.
This will work for some companies, but for larger companies it’s only a matter time until an outage is caused and therefore, not a good design choice. For smaller companies where just a couple of people manage the firewalls AND the network, the static MAC address can work.

Install an IGMP agent on the firewall

This document on ClusterXL IGMP Membership dated February 14, 2006 (!) explains how to add IGMP support to Checkpoint. However, I’m told by Checkpoint that this is not supported / not recommended (it’s hard to to get a straight answer). It’s requires a number of CLI entries to work, plus specific configuration on the Module configuration.
In short, this option is operationally a disaster. You may struggle to get upgrades completed properly, module configuration on Linux/Windows need changing in the Config/Registry for the IGMP configuration to survive a reboot.

Using Unicast Mode instead

So the second option is to use Unicast instead of Multicast. In this case, the ClusterXL software selects a PIVOT firewall to act as the Master unit, and it will either process the packets itself, or redirect them to another member of the cluster.
Checkpoint cluster 7
The diagram shows this mode of operation using Unicast redirect. Although Unicast redirect doesn’t have the same problems as the Multicast solution discussed above, it does have a problem. The pivot firewall must reserve resources to be able to redirect all flows and ensure that it has enough CPU capacity to send sync data to all other firewalls in the cluster. The pivot firewall therefore handles much less traffic than other members of the cluster.

Troubleshooting

One big challenge of clustering firewalls, is that capturing packets, and troubleshooting becomes relatively more difficult. I’ve had some odd problems using Wireshark and surmise that the volume of broadcast packets was overrunning the workstation network adapter I was using to capture packets. Sadly, I wasn’t able to try with another machine to verify this theory.

Firewall Deployment with Layer Data Centre Interconnect

Apparently, there are a number of people who think that this clustering idea is perfect for data centres that are L2 interconnected. By now, most of you will have realised the problem that clustering will cause when an ethernet segment is extended between two data centres, but lets make a diagram of it anyway. Two data centres, geographically separated, but with a L2 connection between them. Doesn’t much matter how (OTV, VPLS, dark fibre, WDM – all the same for this purpose).
Checkpoint cluster 8
On the interconnect, a multicast CheckPoint ClusterXL, with an active/active firewall configuration, is going to trombone traffic between sites according to some random algorithm.
In addition, the firewall synchronisation traffic must also be given high priority and if the sync data doesn’t occur quickly enough the firewalls seem to fail quite badly (again, apocryphal evidence here, not able to test in a live network).
Finally, Multicast/ Broadcast must flow across the L2 Link on the inside and outside interfaces for every VLANs.
Thus, for 100Megabits of traffic across the firewall, 200Megabits of broadcast traffic is generated, plus the Sync traffic (determined according to firewall rule but usually a lot of traffic).
This isn’t a good idea(tm) since you need that bandwidth for server-server communication as well. Should be obvious, I think.

The EtherealMind View

Experience suggests that the Nokia/CheckPoint clustering works but at relatively low volumes, say up to 10 Mbps at a rough non-educated guess because the customer has a number of existing clusters that do work reliably. However, as load increases on the firewall, it appears that the multicast/broadcast technique causes serious service problems to devices on the same VLAN as the firewalls themselves. Since static mac options require the firewall team and network team to operate closely, this isn’t practical for very large support teams because of the level of specialisation that occurs in those teams. I have deep reservations about larger volumes of clustered traffic and have seen a number of inexplicable problems when clustering is enabled.
I could wish to have done some more testing but project timescales are a bit tight, and there is no way to have a lab of CheckPoint firewalls because of licensing and/or cost.
On the basis of this research, and recent experiences with service difficulties, I can’t recommend CheckPoint Nokia clustering because it appears to be a technology with more drawbacks than capabilities.

Read More ...
| 3 comments ]

The intent of this paper is to help you understand how  FW-1's stateful inspection  connections table works.   This table is how FW-1 maintains who is doing what and what connections are allowed based on the rule base.  The paper is based on continued research I have done with the latest version of FW-1, version 4.1.  To help you better understand your own FW-1 stateful inspection table and validate my data, I have posted all the source code I used at the bottom of this page. 

Stateful Inspection
This paper started off with a basic question.  If you have a firewall with a rule base that allows anything through it (any - any - accept), will the firewall allow a new TCP connection that is initiated with an ACK?  A part of me said yes.  If the firewall allows everything, then any packet should go through.  However, a part of me also said no.  Based on how stateful inspection works, the packet should be dropped.
My initial understanding of stateful inspection (at least on Check Point FireWall-1) worked as follows.  Whenever a firewall receives a SYN packet initiating a TCP connection, that SYN packet is reviewed against the Firewall rulebase.  Just like a router, this SYN packets is compared to the rules in sequential order (starting with rule 0).  If the packet goes through every rule without  being accepted, the packet is denied.  The connection is then dropped or rejected (RST is sent back to the remote host).  However, if the packet is accepted, the session is then entered into the firewall's stateful connection table, which is located in kernel memory.  Every packet that follows (that does not have a SYN) is then compared to the stateful inspection table.  If the session is in the table, and the packet is part of that session, then the packet is accepted.  If the packet is not part of the session, then it is dropped.  This improves system performance, as every single packet is not compared against the rule base, only SYN packets initiating a connection are compared to the rule base.  All other TCP packets are compared to the state table in kernel memory (very fast).
Now, back to our original question.  If you initiate a session with an ACK packet, will the firewall accept the packet, even with a rulebase that accepts everything?  As we said earlier, your would think yes.  But now that we have a better understanding of the connections table, maybe the answer is no.  When the firewall receives the ACK packet, it is going to compare it to the state table in kernel memory, not the rule base.  However, the firewall will not have this session in its state table, there was never a SYN packet.  So, does the firewall accept the packet, or drop it since there is no entry for it in the state table?
The Result - How FW-1 Builds a Connection.
The results were surprising.  Not only was the ACK packet accepted, but it was entered into the state table.  My understanding of the firewall state table was incorrect.  What I discovered is this, when the firewall receives a packet that is NOT part of the state connection table, that packet is checked against the rule base, regardless if it is a SYN, ACK or 'whatever' packet.  If the rule base accepts the session, then it is entered into the state table.  All subsequent packets of that session are compared to the state connection table and then accepted.  Since there is an entry in the state table for the session, the packets are accepted without being compared to the rulebase.  Below is some of the output from the tool, fwtable.pl (ver 1.0), which converts the data found in 'fw tab -t connections'.  This table is where FW-1 stores all of the concurrent connections in memory. The entries you see below are part of my firewall state connections table created by initiating connections with  ACK packets.
mozart #fwtable
                            ---- FW-1 CONNECTIONS TABLE ---
 
Src_IP          Src_Prt Dst_IP          Dst_Prt IP_prot Kbuf    Type    Flags       Timeout
192.168.7.131   10003   207.229.143.8   25      6       0       16385   02ffff00    2845/3600
192.168.7.131   10002   207.229.143.8   24      6       0       16385   02ffff00    2845/3600
192.168.7.131   10001   207.229.143.8   23      6       0       16385   02ffff00    2845/3600 

Here you see three packets accepted and entered into the firewall state table.  However, these three packets were initiated with ACK packets.   The same thing is true for Null, SYN/ACK, and various other packets, such as FIN/ACK.   If a packet is not part of the state table, it is then compared to the rulebase.  If the rulebase accepts the packet, the session is then added to the state table.  If the packet is not accepted by the rulebase, the packet is dropped/rejected, killing the session.  This is how the firewall "maintains" connections when you do a 'fwstop;fwstart'.  When you bounce the firewall, the connections table is cleared, nothing is maintained.  However, any concurrent connectins will most likely be sending ACKs.  The firewalls sees these packets, verifies them against the rulebase, and rebuilds the connections table.  All of this is transparent to the end user.  This is why you lose Authenticated and Encrypted sessions, the firewall does not have the 'initial state' for these connections. Also, notice the timeout in the right hand column, 3600 seconds.   After entering a session into its state table, the firewall leaves that entry.  That means you have 60 minutes to create and send another packet to reset the timeout clock.   The timeout properties can be set in the control properties menu.
NOTE:  valid FIN or RST packets cannot build a session, as they are used to tear a connnection down.  Also, the only packet that was NEVER added to the state table were 'Xmas' packets created with Fyodor's nmap (-sX option), however these packets were accepted and logged.
Another thing I learned, stateful inspection for FW-1 looks only at Source/Destination IP and Port numbers for determining a session.  It does NOT care about sequence numbers, as I was making up all sorts of whacked out sequence numbers, which the firewall accepted.  Nor does FW-1 maintain state about packet type when building a connection.  When you send a SYN packet initializing a session, the Firewall compares it to the rulebase.  If accepted, it adds it to the state table, as we discussed before.  At this point, the timeout is first set to 60 seconds.  The firewall then expects a return packet to build the connection.  When it sees this return packet, the timeout is then set to 3600 seconds (60 minutes). However, the firewall  is not particular about what type of packet comes back.  I initiated a connection with SYN, then sent back an ACK only, which the firewall happily accepted as part of that connection (as long as the IPs and Ports matched up).  So, the firewall does not have the intelligence to expect SYN/ACK response, nor matching of sequence numbers.   This is most likely done for performance reasons, as maintaining state of Seq numbers would require greater resources. 

Denial of Servic Potential (Bugtraq ID 549):  When building a connection, if you start a connection with an ACK (or most other non-SYN packets, such as Null, FIN/ACK, SYN/ACK, etc) the timeout is automatically set to 3600 seconds (default) see example above.  This has Denial of Service implications.   By initiating many connections with ACK packets to systems that do not exist, you quickly fill up the connections table.  Since there is no remote system, no RST or FIN is sent to teardown the connection, leaving a "dead" connection in the connections table for an hour (remember, timeout for ACK or most other non-SYN packet is 3600 seconds).  You can quickly fill up the connections table initiating connections with ACK packets.  Fortunately, this DoS attack is far more difficult to execute from the outside then from behind the firewall.  Unfortunately, it is easy to DoS yourself if you are doing any scanning from behind your Firewall (as I learned :). Check Point posted a response to this issue.  You can take the following steps to address this issue:
  • Check Point has posted a solution using Inspect.  However, this can effect the functionality of the state table when reloading a policy.
  • Decrease your TCP timeout to 15 minutes (900 seconds).  This decreases the 'window of opportinuty' a black-hat can use to fill your connections table.
  • Increase your connections table.  This makes it more difficult to fill the connections table.
  • Implement a strict rulebase that limits what can go outbound and inbound.
  • Jason Rhoads has developed a PERL script, fwconwatch.pl, that will monitor your connections table for you and alert you based on criteria you define.
  • Implement Fastpath (for ver 3.0) or FastMode (for ver 4.0).  This eliminates TCP connections from you connections table.  However, this could introduce additional security issues. See below for more information on Fastpath/FastMode.
  • NOTE:  SynDefender does NOT protect against this threat, as it was designed to protect against SYN flooding, a different kind of attack.  This DoS issue is based on non-SYN packets.
One feature I like with FW-1 is how the firewall treats SYN packets.  If you attempt to initialize a new session that emulates an existing one, the firewall still compares it to the rulebase.  For example, lets say you attempt the following.
A --- FW --> B                    #  System A connects to system B
Now, system B can send whatever packets it wants to system A, as long as the IPs and ports match up (ie, the packets are part of the session).  However, if system B attempts to initialize a new connection (with the standard SYN), even if he uses the exact same ports of the existing session, the firewall still considers the SYN part of a new session and compares it to the rulebase.  In my opinion, this is a good thing.  In the example above, lets say the firewall allows ALL traffic from system A outbound, but no traffic from system B inbound.  The only way system B can talk to system A is if it is part of a connection.
When system A connects to system B, the connection is added to the firewalls inspection table (see example above of inspection table).  Now system B can respond by sending packets to system A.  However, the firewall has NOT blown a hole wide open.  System B cannot send any SYN packets to System A initiating another connection, even if the IPs and port numbers are the same.  When the firewall sees that SYN packet, it applies the packet to the rulebase.  In the above scenario, that packet would be dropped, even thought there is an established connection.
Fastpath:  Something else I learned is if fastpath is enabled, then the session is not added to a connections table, ie no connections table is built.  The reason for this is Fastpath only looks at the SYN packet, so there is no need for a session to be added to the connections table.  If the packet has any other flag enabled, then the packet is not filtered and is allowed through by default.  Normally, fastpath is used to improve performance (or in rare routing situations).  The idea is, if a packet does not have the SYN flag, then it must already be part of an establish connection, as only a SYN packet can start a connection.  Since only SYN packets are inspected, peformance is greatly improved.  However, enabling fastpath is normally a bad move, as this opens you up to a wide variety of attacks.  Fastpath is in FW-1 ver 3.0 only and is a global property applied to all TCP packets.  In ver 4.0, it is called Fastmode, and can be selectively applied to different TCP services.
Closing a Connection
Based on some initial testing, it seems FW-1 closes connections by timeing the connection out.  When the inspection module sees a session exchange a FIN or RST packet, it changes the timeout from 3600 seconds to 50.  If no other packets are exchanged in that 50 second period, the connection is then removed from the state table.  If any packets are sent during the timeout period, the clock is reset to 50 seconds.  By continually sending packets after a session tear down, you can keep resetting the clock to 50 seconds.  This prevents Denial of Service attacks if someone sends spoofed RST or FIN packets.   This timeout behavior can also be considered similar to the TIME_WAIT state a TCP connection enters after acknowledging (ACK) the second FIN packet in closeing a session.
UDP
UDP connections are simplier to maintain, as they are stateless.  When a UDP packet is allowed through the firewall (based on the rulebase) a entry is added to the connections table.  Any UDP packet can return within the timeout period (default 40 seconds) as long as both the SRC/DST IP addresses and SRC/DST ports match.  For example, below is a DNS query.
 
Src_IP          Src_Prt Dst_IP          Dst_Prt IP_prot Kbuf    Type    Flags           Timeout
192.168.1.10    1111    136.1.1.20      53      17      0       16386   ff01ff00        34/40
192.168.1.10    1111    136.1.1.20      0       17      0       16386   ff01ff00        34/40 

Here you see the system 192.168.1.10 doing a dns query to the server 136.1.1.20.  For 40 seconds (Timeout) that system can return as many UDP packets as it wants, as long as both the SRC/DST IPs match, and the SRC/DST ports match.  Notice how there is two entries, both are identical execept for the Dst_Prt, which is 53 and 0.  I do not know why FW-1 creates a second entry for a Dst_Prt of 0.  However, this is common for most, if not all UDP traffic that FW-1 filters.
ICMP
ICMP is a large dissapointment with FW-1.  By default, FW-1 does not statefully inspect ICMP traffic.  It is never entered into the connections table.   As a result, users are forced to blindly allow certain ICMP traffic (such as inbound ECHO_REPLIES) or hack the Inspect code (see http://www.phoneboy.com/fw1).  I believe this is one of the greatest failings of FW-1.
Fragmentation
Recently I have been playing with fragmentation, specifically how does FW-1 handle fragmented packets. Though fragmentation does not apply directly to the state table, I feel it is important enough to add to this paper. I will not be going into detail on how fragmentation works, I am assuming the reader has basic knowledge of IP Fragmentation. I will first cover general findings on how FW-1 handles fragmentation, then I will review the specifics of TCP, UDP, and ICMP.
First, FW-1 does fragmentation in, fragmenation out. What I mean by this is if FW-1 receives a fragmented packet that is accepted by the rulebase, that is what it will send out once it has completed its inspection. Thus the term "frags in, frags out". However, I also believe that FW-1 does some type of reassembly for the fragmented packets before inspecting them. This conlclusion is based on the following tests. When I initiated an allowed connection with a complete, fragmented TCP packet, the packet was accepted by the firewall, added to the state table, and then sent on its merry way (fragmented). By complete, I mean that all the fragments that make up the packet were sent. I now had a session built in the state table for 3600 seconds. I then tried to send more fragmented TCP packets that were part of the same session. These fragmented packets were accepted, the timeout setting in the state table was reset, and the accepted packets continued on. However, when I sent an incomplete TCP fragment of the same session (in other words, I sent a single fragment that did not complete a packet) the fragment was not accepted. Not only was it not accepted, but it was not logged. This leads me to believe that when FW-1 first receives a fragmented packet, it does not inspect the packet untill all the fragments have arrived and the packet is fully assembled. Once assembled, the firewall then decides what to do (accept, deny, etc), logs the packet, and adjusts the state table accordingly. Another example of this behavior is with jolt2 a DoS tool used to attack Window systems. The tool send 100's of incomplete fragmented ICMP (or UDP) packets against a selected target. When ran against FW-1, the packets neither get through the firewall (even though I was accepting ICMP) nor was logged by the firewall. I believe this is due to the fact that these fragmented ICMP packets are incomplete, they do not make up a complete ICMP packet. Since no ICMP packet can be fully assembled, nothing is inspected, nor logged.
When you think about it, some type of reassembley of fragmented packets is most likely required for a stateful firewall. Many stateful firewalls (including FW-1) inspect packets based on Src/Dst IP addresses and Src/Dst ports (TCP Header). However, only the first fragment of a fragmented packet contains all of this information, all other fragments have only the IP address information. If some form of fragment assembly did not happen, the firewall would have no way of knowing what session all the follow on fragments belong to, only the first fragment of the packet. By reassembling all the packets, the firewall inspection engine can them determine which session all the fragments belong to.
However, not inspecting the packets untill after reassembly also has a problem, the firewall is now vulnerable to fragmentation attacks that use incomplete or 'illegal' packets, such as those that are generated by jolt2. Since these incomplete or 'illegal' frag packets will never be properly reassembled, they will neither be inspected or logged. So, the firewall will continue to accept these packets and attempt to assemble them, however reassembly is impossible. Meanwhile, the firewall is vulnerable to the fragmentation attacks, system resources are consumbed trying to process all the fragments. So, the firewall can be attacked using incomplete or illegal fragments, and the attack can neither be stopped by the firewall rulebase nor logged by the firewall rulebase. This vulnerability has been assigned by bugtraq the tracking number 1312. For more information on both the vulnerability and possible solutions, read CheckPoint's advisory. For you Unix users, you can also use the command line option "fw ctl pstat" to view how many fragments the firewall has processed. See phoneboy.com for more info.
Now, on to protocol specifics. First, TCP. First, FW-1 will drop the first fragment of a fragmented TCP packet that has less then 24 bytes of data. If the first fragment of the fragmented packet has less then 24 bytes of data, the firewall drops the fragment by default and logs the packet with the message "TCP packet too short". (NOTE: remeber, when discussing data bytes with fragmentation, this does not include the 20 byte IP header.) For example, the popular network scanner nmap has a '-f' option which will fragment scanning packets into a 16 data byte packet, followed with a 8 data byte packet. These fragmented scans are dropped by default by FW-1 (regardless of your rulebase), with the message "TCP packet too short".
ICMP and UDP are different. First, both allow any standard fragment size (8 bytes, 16 bytes, 32 bytes, etc) unlike TCP, which had a requirement of at lease 24 bytes. (NOTE: like TCP, the data size does not include the 20 byte IP header). However, odd fragmentation byte sizes were not allowed (by odd I mean not increments of 8 bytes). For example, I attemped a fragmented data size of 12 bytes, but this was neither accepted nor logged.
As always, these findings are based on my own personal research, they are in no way official. In fact, I challenge the security community to conduct their own tests to validate these findings. If you find any flaws in my logic, testing methods, or technical implementation, please let me know!
Network Address Translation
I am currently working on understanding how the state table works for Network Address Translation. If you have any input, I would greatly appreciate it, as I am trying to develop both my understanding and this section of the paper on NAT. I have improved the fwtable script so that it now supports Network Address Translation tables (in large part due to the work of Brett Eldridge, beldridg@best.com). If you would like to try out the latest version of this script, download fwtable_1.1. Let me know what you think of the script. Suggestions greatly appreciated.
Conclusion
My initial impression, based on preliminary testing,  is Check Point FW-1's stateful inspection is intelligent, but only semi.  If the FW-1 receives a packet that is NOT part of the state table, that packet is checked against the rulebase. If accepted, it is added to the state table, where all subsequent packets are checked against (known exceptions are Xmas, FIN, and RST packets).  This is a good thing, as the firewall has a robust state table that will maintain connections.  What concerns me is when you initiate a connection with an ACK packet (or various other packets) the timeout is automatically set to 3600 seconds, regardless if a system responds or not.  This has  Denial of Service potential.   What I do like is all SYN packets are checked against the rulebase, regardless if its part of an existing session (this prevents 'tunneling' or 'piggybacking').  However, the inspection table does NOT keep state about sequence numbers, nor SYN - SYN/ACK - ACK sequence.    As for closing connections, its methods seem rather straight forward, similar to TCP's TIME_WAIT period. The state table looks for either a RST or FIN packet, then times the session out. Fragmentation seems to be reassebled during the inspection process. No fragmented is either inspected nor logged untill it has been fully reassembled. Hopefully, after further testing and input from the firewall community, this whitepaper can be a production document that answers many common questions concerning what stateful inspection is, and how really stateful the tables are.
Further Testing
What I have presented was tested on Check Point FireWall-1, ver 4.1 on Solaris x86 2.7.  The tools I used to read the state table and create my own packets can be found below.  I would like to do further testing to understand how the firewall interprets the 'Type' and 'Flags' columns in the state connections table.  Also, how the Firewall 'drops' a connection.  I am looking for anyone to validate (or invalidate) what I have presented here.  Also, any additional information would be greatly appreciated.
Downloads:
fwtable.pl will help you better understand the stateful inspection tables for your firewalls (only works on Check Point FW-1).  The script can be ran locally on any Firewall Module, remotely from any Management Station, or standalone on any system that has PERL.
hping2  Allows you to build your own TCP/ICMP/UDP packets, with built in traceroute and 'pinging' capabilities.
Nemesis is similar to hping, but with some different functionality. Written in C, it uses libpcap and libnet. It allows you to build any type of packet, including TCP, UDP, ICMP, DNS, OSPF, etc. Extremelly simple to use, everthing is done at the command line. Nemesis and hping2 are my tools of choice for packet building. 

Read More ...
| 0 comments ]

Here is a short list of the hardware used in Check Point appliances. The numbers show SPU and the maximum throughput for firewall, VPN and IPS traffic according to Check Point.

Check Point 2012 Appliance series

Modell SPU FW VPN IPS CPU RAM
21400 2003 50 7 21 2x Intel Xeon E5645 2.40GHz (Six-Core) 6
12600 1861 30 7 17 2x Intel Xeon E5645 2.40GHz (Six-Core) 6
12400 1046 25 3.5 12 Intel Xeon E5645 2.40GHz (Six-Core) 4
12200 738 15 2.5 8 Intel Core i5 750 2.67GHz (QuadCore) 4
4800 623 11 2 6 Intel Core2 Quad CPU Q9400 2.66GHz 4
4600 374 9 1.5 4 Pentium Dual-Core E6500 2.93GHz 4
4400 223 5 1.2 3.5 Intel Celeron Dual-Core E3400 2.6 GHz 4
4200 114 3 0.4 2 Intel Atom D525 1.80GHz Dual-Core 4
2200 114 3 0.4 2 Intel Atom D525 1.80GHz Dual-Core 2

Check Point Smart-1 Appliance series

Modell CPU RAM HDD
Smart-1 5 Intel Celeron M 1.50GHz 2 500 GB
Smart-1 25b Intel Core2 Duo Processor E7400 2.80 GHz 4 2 TB
Smart-1 50 Intel Xeon E5410 2.33GHz (DualCore) 4 2 TB
The details can be determined from the command line.

For the CPU details use cat /proc/cpuinfo, for the RAM details use cat /proc/meminfo.

If you have more details on appliances, feel free to send them to tobias@lachmann.org

All other values are taken from official Check Point materials.

If you take the appliance hardware together with the throughput stated by Check Point, it might give you an idea how your OpenServer hardware will perform in comparison.

Thanks to all the contributors for their info!

Tobias Lachmann
Refer to http://blog.lachmann.org

Read More ...
| 3 comments ]

http://www.fw-1.de/aerasec/index.html

Here you find some further information about Check Point R70 and above, NGX and VPN-1/FireWall-1 Next Generation
Please note: To obtain a HFA for any version, you will need a valid Software Subscription (CES) for all of your products registered in your UserCenter Account!
R75:
In July 2012, Check Point has released R75.40VS. This version has integrated VSX which is now also licensed by using Software Blades. Besides this, a modified GUI comes with this version.
The latest regular version is R75.40. This release delivers many new features as well as the new Operating System called GAIA. It includes all bufixes that were published with R75.30. This version is stable. The release before (R75.20) started offering many improvements regarding URL filtering combined with new features regarding DLP as well as SSL inspection for IPS, APCL, URLF, and DLP. The earlier published R75.10 delivers some improvements like e.g. better performance for the GUI, support of Edge Firmware 8.2 and SecuRemote R75.10.
R71:
In July 2011, version R71.45 has been published, delivering more functionality and compatibility, as also R71.40 does. Both versions offer direct upgrade to R75.40. When using the SSL VPN Software Blade (i.e. Mobile Access Blade), please use at least version R71.10, since there is a security problem when using SSL VPN in R71 without patch.
R70:
The latest version of R70 is R70.50. If you plan an upgrade to R75.40, a direct upgrade is possible (but not to earlier versions). Using R70.30 might still be useful if an upgrade to other version as R75.40 is planned. Some important improvements as well as more features (to be licensed) have been introduced with Version R70.20. It's available for all users of R70. At least this version should be used in productive environments. As usual, please regard that the GUI needs to be of the same version as the Security Management, e.g. SmartConsole 70.30 for the corresponding versions of R70.
NGX R65:
When using this (outdated and no more supported) version, you should use HFA_70 for NGX R65. Since December 2007 the corresponding GUI für Microsoft Windows is SmartConsole NGX R65 HFA_01. Please be aware that neither this nor elder versions are supported any more.

The latest version is R75, introducing the Application Control Software Blade, Identity Awareness, the Integrated DLP Software Blade and Mobile Access blade. In parallel, Endpoint Security E80 has been released at the very end of 2010.
Before, R71 has been published in May 2010. New Software Blades for DLP and SmartEvent have been published with it. It's based on the latest major release, published in March 2009: R70. This version introduced Software Blades, making the licensing very modular. Because R7x is a new major release, a new license is needed to get access to all new features. Please contact your reseller to obtain it.
Please be aware that Check Point has changed the licensing for RAS - today, you need an Endpoint Security Container with Service Blades for the use of e.g. VPN, Full Disk Encryption or Endpoint Security Secure Access.
Licenses for NGX and earlier will only work with R70. Since R71 the new licensing scheme using Software Blades is strictly enforced. If you haven't updated yet, please do it. In most cases you can do it for free in your Check Point UserCenter account.
Other versions (NGX R65, NGX R62, NGX R61, and NGX R60) were officially supported until March 2011 and May 2009, respectively. If you cannot upgrade, please contact your reseller to obtain (restricted) support. A quarterly fee per system is due. If you still have NG AI (e.g. R54/R55) in production, please upgrade as soon as possible!





Version
Ports
R70 Ports used by Check Point R70 and above
R60-R65 Ports used by Check Point NGX
R50-R55 Ports used by Check Point VPN-1/FireWall-1 Next Generation (not supported any more)
4.0/4.1 Ports used by Check Point VPN-1/FireWall-1 4.x (not supported any more)


Further information
Links to FAQ's, mailing lists and further information about Check Point FireWall-1/VPN-1

Licensing, Products and basic Installation
R71/R75 "Basic" License Features of R7x (software only)
R70 "Basic" License Features of R70 (software only)
R60-R65 "Basic" License Features of NGX (not supported any more)
R54/R55 "Basic" License Features of NG AI and earlier versions (not supported any more)
R54/R55 "Extended" License Features of NG AI (not supported any more)
NGX - R7x Direct comparison of license features of NGX and R71/R75
NGX - R70 Direct comparison of license features of NGX and R70
R70 About licensing RAS clients for R70
R70/R71 About licensing Endpoint Security for R70 using Software Blades

R65/R70

About Check Point Appliances for NGX R65 and R70

>R53

Terms used since Next Generation Feature Pack 3
R70 Terms used since Check Point R70

R70

About the use of computers with Dual Core or Quad Core Processors (outdated)
R70 About the use of computers with Dual Core or Quad Core Processors since 2010

<R70

Compatibility between Nokia IPSO and Check Point VPN-1/FireWall-1
R70 Nokia Hardware compatible with Check Point R70

R54/R55

Installation fails on patched Sun Solaris 8 or 9

Useful tools
all Tool for generating INSPECT code using a GUI: Ginspect
NG/NGX Tool for State Tables in human readable form
fw1-tool.pl by AERAsec
(supports SSH and some more features, covers Unix/Linux, SecurePlatform as well as Windows)
NG/NGX Tool for Traffic Analysis
"tcpdump"-like wrapper for "fw monitor": fw1-dump.sh (fw1-dump.sh.zip) by AERAsec
Use the syntax of the well known command "tcpdump" to use "fw monitor".
all Tool for Managing Check Point SecurePlatform
Easier remote Management with SmartSPLAT
NG/NGX Tools for Management of Check Point objects
Ofiller and Odumper are used for editing Check Point object databases.

Authentication
4.1 Using OpenLDAP to authenticate users with Check Point VPN-1/FireWall-1 4.1
NG Authentication using OpenLDAP with Check Point NG is described on the OPSEC server
4.x/NG To configure the LDAP server, you will need the correct schema file (4.1, NG AI R55)
R53 How to integrate Novell eDirectory 8.7 with Check Point NG FP3 is described by Oren Green
R53 The use of CRYPTOCard Authentication with Check Point NG FP3 is described by CRYPTOCard
Secure Computing describes how to authenticate users by SafeWord PremierAccess 3.0
all Configuring Client Authentication using HTTPS
R52 Authentication with SecurID/ACE-Server doesn't work

VPN
all Links to hints for VPN between Check Point and other products
VPN with Linux FreeS/WAN using pre-shared-secret or X.509 certificates
VPN with Racoon (under Linux),VPN from Gateway to Gateway
VPN with BinTec IPsec enabled router using pre-shared-secret or X.509 certificates
R70 Endpoint Connect cannot download Topology
VPN-1 configuration for use of an external CA
all Problem with an overlapping encryption domain
R51 Problem with Extranet under Linux
<R55 Problem with Extranet when using the "Simplified Mode"
<R55 How to configure an Extranet

Installation of rulebase, Objects, Services and Resources
all Rulebase will not install - atomic loading failed
R53 Rulebase will not install - no memory
all Check Point FireWall-1 acting as a Mail-Relay?!
all What to do against sender-specific routing for E-Mail
R52.. Problem when changing or creating a TCP Service
R53 ICMP doesn't work sometimes
R53 NG blocks HTTPS/SSL when using a Proxy
HTTP/HTTPS connections are being blocked by NG
R54 Timeout for Oracle Services SQL*Net2 not working

SYN Defender
Short graphical description of SYNDefender Relay, Gateway and passive Gateway (PDF)
Which kind of SYNDefender is supported by Check Point version X?

NAT
Problem with manual NAT on Microsoft Windows 2000 Server

Logging
R53 Sending syslog messages to SmartView Tracker is possible now
R53 Time of SmartView Tracker is one hour late
<R60 Rule numbers in SmartView Tracker aren't in the rulebase
all Negative Rule numbers in SmartView Tracker

Upgrade
R51 Upgrading Check Point VPN-1/FireWall-1 from 4.0 to Next Generation FP1 (outdated)
R51 Upgrading Check Point VPN-1/FireWall-1 from 4.1 to Next Generation FP1 (outdated)
Problem with Internal CA after upgrading from version 4.1 to Next Generation
NG AI Problem exporting a configuration using upgrade_export
R7x Problem importing a configuration in a new version
R75.40 Problem upgrading with fwkern.conf configured

Auditing
4.x Lance Spitzner has published a good paper called "Auditing Your Firewall Setup", based on 4.x
all Auditing NG AI, NGX, and R70 is offered by AERAsec




Read More ...