Check Point
for Beginners
Security Basics
The idea of filtering traffic between different networks is as old as routing itself. Most routers are capable of enforcing so-called “access lists” to define basic inter-network communication restrictions.
The first paper describing network packet filtering was published by Digital Equipment Corporation (DEC) in 1988. In 1992 DEC presented the very first commercial firewall: DEC SEAL. Early firewalls such as SEAL checked network addresses and sometimes the port numbers of a packet to determine whether that packet could be forwarded or should be discarded. This type of inspection is called Static Packet Filtering (SPF).
Figure 1: Static Filtering Enforcement - OSI Model
As shown on the diagram above, SPF acts on Layers 3 and 4 of OSI Networking Model. Its security decision is based on IP addresses and in some cases ports of IP packets.
Although packet filtering’s logic is very simple, is has a fundamental flaw. The firewall has to check each and every packet individually, disregarding state of a connection. Most problematically, the same security decision is made over and over again to forward new packets within the same connection.
Everything changed in December 1993, when an Israeli startup called Check Point filed US patent application 5,606,668 describing a new principle of network security: Stateful Inspection.
Generally speaking, stateful firewalls deal not with single packets, but with connections and sessions. This representation allows making a concise security filtering decision when inspecting the very first packet in the connection, and applying this action to any further packets of connections allowed by the security policy. On top of that, a stateful firewall enforces RFC-defined network protocol behavior through the allowed sessions and blocks any attempt of improper use of network resources. A stateful firewall is not only inspecting headers of IP and TCP packets, but also allowing enforcement of many other parameters in the data payload of the packets, securing communications on higher layers of the OSI model up through Layer 7.
Figure 2: Stateful Inspection - OSI model
Check Point presented FireWall-1 version 1.0, the very first commercial stateful firewall, in 1994. Version 2.0 followed in 1995.
FireWall-1 1.0 was supported with SunOS and Solaris. Version 2.0 added HP-UX support. Version 3.0 added support for Windows NT and IBM AIX, and was also rebranded and sold by Sun Microsystems under the name “Solstice FireWall-1”.
The market success of Check Point and its firewall product was tremendous, and not only because of revolutionary Stateful Inspection principles. It also had to do with the product itself. Check Point introduced the “Three Tier Architecture” principle, distinguishing the three parts of its security system: SmartConsole GUI, Security Management Server, and Security Gateways (firewalls). While the Three Tier Architecture often seemed cumbersome (especially to those with only a single gateway), it soon proved to be a game-changer for those who needed to manage multiple gateways. The Graphical User Interface provided a simple and very intuitive way of managing policies and security rules. It wins the hearts and minds of many a network security professional even now.
This is how the main administrative (fwui) tool looked on the Sun Motif windowing system:
Figure 3: fwui on Solaris
On Windows the color scheme was different, but the main look of the rulebase was still recognizable. It is actually quite similar to the latest Check Point products:
Figure 4: Rulebase view - FW 2.0 on Windows
Evolution of Check Point firewall products proceeded smoothly for several more years. In 2000, version 4.1 was introduced, supporting Windows NT, Solaris, Red Hat Linux, IBM AUX, HP-UX, and IPSO.
With a growing number of supported platforms and increasing complexity of the product, Check Point faced some development challenges. The firewall software was originally maintained as a single piece of code. It had to be re-compiled for every bug fix and every new feature added, and for each specific flavor of the supported platforms. The software for version 4.1 had more than 1.5 million lines of code. Product development and improvement started to become somewhat cumbersome. The situation had to change.
In 2001 Check Point released a completely redeveloped product called NG[1], the fifth generation of its firewall software. It had a modular structure, with various features and functionalities organized as separate pieces of software, and with a common infrastructure called Secure Virtual Network (SVN) Foundation. The modular structure allowed Check Point to accelerate implementation of new features.
One of the most interesting improvements added to the NG version was related to performance. At the beginning of the century Check Point started working on developing acceleration solutions that would allow offloading some of the security processing to a separate CPU. Although the initial development was oriented towards an external CPU on a card, such as VPNx cards to offload VPN encryption and decryption calculations, Check Point developers added acceleration APIs to the software that would allow using an external acceleration solution such as ADP card, or just an additional CPU available on a multi-core system. This solution is known as SecureXL. This technology is still among core architectural principles of Check Point security system.
While firewalls were becoming more and more effective, the security landscape was also changing rapidly. At the beginning of 21st century, IDS/IPS systems became a real necessity. Check Point first introduced SmartDefense in NG Service Pack 3 (R53). While really just a compilation of pre-existing advanced defense features (like SynDefender, CPMAD, and anti-spoofing), it laid the foundation for what was to come. In year 2003 Check Point released version NG AI R54. The “AI” in the product name stood for Application Intelligence, which was the name Check Point used for IPS-like functionality. Later on, with the NG AI R55 version of the firewalls, Check Point started grouping the AI function into SmartDefense and Web Intelligence categories, to distinguish general protocol related protections and security features protecting Web communications.
Unfortunately, Application Intelligence was not competitive enough given the new IPS vendors that were defining the market such as ISS and Tipping Point. NG AI was difficult to configure and was missing some security features. At this time, Check Point started looking to acquire a true IPS solution.
In 2005 Check Point attempted to acquire Sourcefire, a security company developing Snort-based IDS products. In early 2006, the deal was ultimately scuttled after it became clear that USA authorities would not approve it. In December 2006 Check Point acquired NFR Security, another American company with its own IPS solution. Immediately after this acquisition Check Point started working on integrating NFR Sentivist IPS technology into its security products. The Sentivist IPS was renamed to Check Point IPS-1.
In 2009 Check Point released new IPS blade as part of the R70 firewall version. It was based on deep packet inspection technology that is now shared with other advanced security features of Check Point firewalls.
As network technology and overall speeds were progressing, the performance requirements for firewalls were also growing. Although Stateful Inspection principles were much more efficient than static filtering, they presented a completely different challenge. Enabling IPS and other more advanced security features on a firewall required much more firepower than Check Point Stateful Inspection was originally designed for. Why is that, you may ask?
Classic Stateful Inspection is based in the operating system kernel of the firewall system. Multiple additional modules (called kernel chains) are inserted into OS kernel prior to the IP stack for inspection purposes. In the classic firewall architecture, just a single CPU core was used by the FW kernel to perform traffic inspection and to maintain a state table containing all accepted connections and their allowed parameters.
In a dual CPU system, it made sense to let one of the CPUs make FW security decisions and use the second CPU for acceleration via SecureXL. This was the case for all Check Point firewall versions up to NGX R65. With firewall performance requirements growing drastically, Check Point needed to make a major change to the firewall’s architecture. In 2009, the company released version R70 with CoreXL – new technology allowing simultaneous use of multiple CPU cores for Stateful Inspection filtering.
Check Point also significantly changed the licensing model for R70 and above, protecting their value by controlling performance and sizing with a licensing model based on the number of CPU cores used by the firewall system.
Throughout the first 15 years of its history, Check Point firewalls evolved smoothly. New features were added in response to market demands. The architecture of the product evolved, and so did the licensing. Competitors were fighting Check Point for market share here and there, yet all firewall products in the market were still using the same principles (Stateful Inspection & Three Tier Architecture) as in the early 90s, with some minor technological improvements.
It was too quiet and predictable. It was bound to be disrupted.
In July 2007 Palo Alto Networks (PAN) came to market with its concept of Next Generation Firewalls or NGFW. According to PAN, stateful inspection firewalls were obsolete. Evolving security requirements demanded that new principles be applied to network-based security enforcement. These new principles would filter traffic based on applications and user information, not just based on network and protocol parameters.
NGFW became a buzzword, and the market began expecting similar features from all established firewall vendors. In 2009, Check Point acquired the application classification and signature database of FaceTime Communications, Inc. (who soon after sold the naming rights and trademark to Apple). FaceTime had been selling solutions (initially focused on IM and compliance) since 2001. The Facetime engine and App Wiki (which was more mature than PAN’s App Id) became the foundation of Check Point’s Application Control blade. At the same time, Check Point introduced Identity Awareness, enabling Access Role object, rounding out Check Point’s ability to surpass, or at least compete with other content filtering solutions. Unlike PAN, the company did not completely dismiss Stateful Inspection principles but complemented them with NGFW features.
In the 20 years since the very first commercial Stateful Inspection product was introduced, Check Point offerings had evolved enormously. Modern firewalls now include lots of sophisticated security features on top of the classic rulebase filtering: IPS, Data Loss Prevention, Threat Prevention and the already mentioned NGFW protections.
Managing such a complex security solution is no longer nearly as simple today as it was in 1994. Most of the newer advanced NGFW features have their own security policies independent of the regular FW rulebase, at least as of version R80. Each aspect of the firewall’s security enforcement functionality dictates its own security principles and has to be managed separately.
For example, in the R77 release, Application Control & URL Filtering has its own rulebase. If a connection is allowed by the classic Stateful Inspection FW rulebase, it also has to be further inspected and secured through the Application Control rulebase. This is known as layered security, where each feature provides an independent security enforcement layer while enforcing traffic flow through a firewall.
The following diagram presents a simplified view of multi-layered security enforcement, where traffic is being inspected and secured by different security software blade policies, bottom to the top.
Figure 5: Simplified representation of Multi-Layered Security
There are multiple arguments and competing reasons for using a layered security policies approach. It may be useful when different administrators and teams are responsible for different portions of security enforcement functionalities. For example, if Alice is managing the access policy rulebase, Bob is in charge of IPS policies, and Application Control policies are defined by Charles, the layered security policies & procedures of the organization fit into this situation very well.
However, if one person or a single team is in charge of the whole security system and its policies, using multiple rulebases and different tools to set up layered security policies may not be advantageous.
Another argument against layered policies concerns performance. Any connection accepted through the access security rulebase must then be matched through potentially many other enabled security layer policies: Threat Prevention, IPS, Application Control, DLP/Content Awareness, etc. Each independent layer’s inspection is independent and unavoidable, which adds some burden to security system resources.
An alternative is to implement a single unified policy where particular advanced features would be part of the security rules or even applied as sub-rules under selected access rules, as will be described later on in these papers. Such security policy requires new architecture of both Security Gateway and Security Management Server. Hence Unified Policy is fully available starting from the R80.10 version.
The full company name of Check Point is Check Point Software Technologies Limited. The key word here is “Software”. For many years, Check Point concentrated its efforts to build software products, allowing customers to bring/build their own servers, while leveraging multiple hardware partners and vendors to produce purpose-built security appliances.
During 20 years of company history there were quite a few partnerships of this nature with such participants as HP, Dell, Siemens, Nortel, IBM, Nokia, SofaWare, Crossbeam, and many others.
Newcomers to Check Point may find this surprising, as Check Point now offers many different appliance models in its portfolio, covering all varieties from SOHO to High End Security Gateway lines.
Yet, even as late as 2005, Check Point did not have a single enterprise appliance in its own price list. All available offerings were from HW partners such as Nokia; HP and IBM. The Company executive team explained its reluctance to enter the hardware business with the following statement: “We know how to make very good software. We engage other companies as partners because they know how to make a very good hardware. Let our customers decide which hardware they want to use by themselves”.
Although this argument makes a lot of sense, other competitors did not hesitate to offer off-the-shelf security appliances to compete with Check Point. The “Software only” policy also had some disadvantages that were not solely competitive: it was actually causing development, maintenance, and support issues along the way.
We mentioned some of the early supported Check Point platforms at the beginning of this chapter. Some of those platforms and OSs, such as HP AIX and Nokia IPSO, were owned directly by the HW partners themselves.
Multi-platform development does have its challenges. The company has to port and compile the same source code for different Operating Systems and different software libraries. These products then have to be debugged and tested to assure their quality and stability. Each new supported platform adds its own required development and test cycle along with continuous training of support engineers, increasing both support and development costs.
Dealing with multi-platform security systems out in the field is also cumbersome. Some of the supported platforms also had additional licensing costs included on top of Check Point’s pricing. One also must contend with OS support, which was provided by the OS vendors themselves. This could sometimes result in “finger-pointing” in a troubleshooting scenario, where the OS support engineers blamed the firewall software for a problem, and the firewall support engineers blamed the OS.
Through a great deal of effort, Check Point managed to eliminate the firewall OS acquisition and support costs by producing its own Linux-based hardened OS known as SecurePlatform or SPLAT. SPLAT was originally based on the 2.4 variant of Red Hat Enterprise kernels, and later on kernel version 2.6.18. The price for SPLAT was included in the FW licenses[2], and the maintenance for both security products and the OS itself was all performed by Check Point itself, thus greatly reducing the possibility of a “finger-pointing” scenario.
Having its own OS for security products was a good compromise, but it also required platform certification. With Windows NT, Check Point was supported on any Windows-enabled box. However, with SPLAT, the hardware vendor had to make sure the required storage and network drivers were available, and could actually run on a particular configuration of hardware.
The Nokia Security Appliances resulted from what was by far the most successful partnership that Check Point ever had with its HW counterparties. Nokia was using its own OS called IPSO, which was based on FreeBSD. The popularity of Nokia Security Appliances varied by region. In many European countries, IPSO appliances were enjoying up to 90% penetration of the Check Point installed base. IPSO boxes were loved for their flexibility, improved clustering features (especially native VRRP), solid dynamic routing capabilities and native support of multicast routing. Effective maintenance and support plans directly provided by Nokia distributors and partners also contributed to the amazing success.
Nevertheless, the development challenges remained even for IPSO. Nokia was also partially responsible for software porting and testing. In many cases Nokia was late to release new versions of Check Point security products. In some isolated cases, such as with the VSX product, the IPSO release could be delayed for up to six months after general availability of that particular version had been announced by Check Point.
Pressured by competitive and internal development needs, Check Point finally introduced its own security appliance hardware in 2007. Strangely enough, SPLAT-based Check Point UTM-1 and Power-1 security appliances were competing directly with IPSO based Nokia Security Appliances for a period of time. Both had their own advantages. Check Point’s UTM-1/Power-1 appliances had more up-to-date hardware specifications, but lacked stable dynamic routing and multicast features. IPSO-based boxes, while exceling against Check Point appliance offerings in logistics and maintenance, were more expensive. The challenge of dual platform development for Check Point’s software also remained.
In 2009 Check Point acquired the Nokia Security Appliance business, and started working on merging the best of SPLAT and IPSO into a new OS platform called Gaia. Gaia is designed to work on all variations of Check Point security appliances, including the Nokia hardware. Although based on the RH Linux kernel (IPSO used the FreeBSD kernel), Gaia had the IPSO variant of dynamic routing and multicast features integrated into it.
Today Check Point has a wide spectrum of appliance offerings for all market segments: small and medium offices, enterprise, and high end. All Check Point appliances utilize Gaia as their OS platform, even in VMWare.
R80 brings major innovations for security management. For many years, the Check Point SmartConsole set of applications could only run on Windows machines. Nowadays more and more security administrators use something other than Microsoft operating systems, and would welcome a platform-independent security management interface.
Many Check Point competitors are already using a Web-based management UI with their own security solutions. Such browser-based interfaces do not depend on a particular OS platform. Unfortunately, these WebUI interfaces are usually Java or AJAX based. Most of them are dependent on a particular Java flavor and also have various limitations related to particular Web browsers.
With R80, Check Point developers presented a new architecture for the Security Management Server. It now uses web infrastructure libraries such as Java. Although the SmartConsole GUI tool is still Windows based, Check Point is making significant progress towards multi-platform management interfaces.
With the new SMS architecture, Check Point also removes the longstanding limitation of only a single user having write access to the management database. With R80 management, multiple administrative accounts can perform object and policy configuration changes at the same time.
Another area addressed by the R80 SMS solution is software-defined network security. Virtualization and automatic orchestration are essential requirements for modern security solutions. R80 provides effective management APIs that are replacing the “old school” OPSEC interfaces. With R80 management, API customers can engineer their own integration with Check Point security systems to leverage automated changes within their SDNs and cloud-based security solutions.
R80.X gateways bring vast changes in the enforcement capabilities. New Unified Policy with sub-layers, Content Awareness feature, redesigned SecureXL, and multi-core IPSec VPN functionality – these are just some of the new features and improvements.
One does not have to be a futurologist to make some predictions. It is clear that network and information security is now part of everyday reality. In our interconnected world, we care about privacy, intellectual property, accessibility, and continuity of access. We are bound to see more sophisticated attacks, new hacking tricks, new threats and also new technological solutions to prevent any of those and to protect our lives and businesses. While technology is changing our daily lives, Check Point helps making that change safe and continuous.
The author hopes this article may help you in understanding and appreciation of tremendous efforts and achievements Check Point made through the years. But the journey does not end here. Digital revolution is happening every day, and Check Point security solutions are part of it. They will continue to fascinate and amaze us.
Stay tuned, stay sharp, and prepare to be surprised.
The author thanks Dameon Welch Abernathy, Timothy Hall, Eric Anderson and Kishin Fatnani for their comments, ideas, support and assistance in writing this article.
[1] NG stands for Next Generation. The term Firewall-1 Next Generation should not be confused with NGFW (Next Generation Firewalls), the concept originally introduced by Palo Alto Networks in 2007. To avoid any potential ambiguity, we will be using the NG abbreviation only when referring to particular versions of Check Point software products.
[2] Originally, there was also an additional license for SecurePlatform Pro feature, discontinued later on.
The idea of filtering traffic between different networks is as old as routing itself. Most routers are capable of enforcing so-called “access lists” to define basic inter-network communication restrictions.
The first paper describing network packet filtering was published by Digital Equipment Corporation (DEC) in 1988. In 1992 DEC presented the very first commercial firewall: DEC SEAL. Early firewalls such as SEAL checked network addresses and sometimes the port numbers of a packet to determine whether that packet could be forwarded or should be discarded. This type of inspection is called Static Packet Filtering (SPF).
Figure 1: Static Filtering Enforcement - OSI Model
As shown on the diagram above, SPF acts on Layers 3 and 4 of OSI Networking Model. Its security decision is based on IP addresses and in some cases ports of IP packets.
Although packet filtering’s logic is very simple, is has a fundamental
...You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY
Understanding Check Point FireWall - Video 1
