Check Point
for Beginners
Security Basics
In the History article, we mentioned that Stateful Inspection technology is much more efficient and secure than Static Packet Filtering. Let’s try to prove this statement and understand its technological basis.
Static Packet Filtering (SPF) is a method to control network access by checking the IP header of a packet and comparing its data with an access list, which contains access restrictions and allowances. Practically any UNIX, BSD, or Linux machine is capable of performing this function natively. With SPF, the security decision is made by the kernel’s IP stack in conjunction with an IP forwarding decision. This function is always performed on a per packet basis.
Static Packet Filtering is incapable of enforcing anything more complex than just a simple verification of Layers 3 and 4 parameters, such as IP addresses and sometimes port numbers. It also has performance drawbacks, as the security decision has to be made for every forwarded or discarded IP packet. On the other hand, since this security function is quite simple, the OS kernel is capable of performing it without any extra help.
The Check Point Stateful Inspection engine provides enforcement using much more elaborate networking communication details. It is capable of controlling traffic by reviewing and enforcing parameters of the OSI model’s multiple layers, from Layer 3 up to Layer 7[1].
It is important to point out here that Stateful Inspection itself does not have full control over Layer 7. For example, it cannot control application data flow without additional technological help (for example, from a feature called Application Control and some others).
To make Stateful Inspection possible, Check Point inserts an additional enforcement layer – the INSPECT Engine – into the OS kernel between the IP stack and network interface drivers.
Figure 1: Traffic crossing Check Point Firewall kernel
The INSPECT Engine deals with so-called “connections” and not with separate packets. It also deals effectively with complex protocols, such as FTP, VoIP, and streaming. From the INSPECT Engine’s perspective, a single rulebase match may include multiple communication flows in both directions. For example, an FTP session includes an initial client-to-server TCP connection on port 21, and also multiple client-to-server or server-to-client connections for transferring files, using various ports, depending on whether FTP passive or active mode is used.
Representing network traffic as connections instead of as a collection of independent IP packets requires some additional technological means. The INSPECT Engine uses Dynamic State Tables to keep records of all accepted connections and their protocols’ state. For example, if a single TCP session is allowed by a security policy, the INSPECT Engine will make sure that the TCP 3-way handshake is properly completed by allowing only a sequence of SYN, SYN-ACK, and ACK packets (in that precise order) between a client and a server at the beginning of a communication session. After the TCP handshake completes, the enforcement engine will correlate sequence numbers with a pre-set TCP window size to enforce the state of the connection. The INSPECT Engine will also respect idle timeouts and other RFC-based parameters for each networking protocol. Any change in the connection state will result in changes to the Dynamic State Tables’ records.
The representation of connections in a state table allows simplification of the security policy rules, among other things, as compared to SPF. With Static Packet Filtering an administrator has to describe both client to server and server to client allowances in an access list to permit simple FTP connectivity. In Check Point, a single rule allowing FTP to be initiated from a client to a server will suffice.
Let’s see how Check Point policy enforcement works. To do so, we need to recall how a security policy rule looks in the Check Point rulebase.
Figure 2: Sample rulebase
All policy rules have Source, Destination, and Network Services columns. These three columns describe allowed or restricted traffic. The Action column defines a security decision for the matched traffic. It can be Accept, Drop or Reject. We assume the readers of this paper already have some basic understanding of security policies. If you are new to Check Point environment, we advise you to refer to Check Point Security Administration course offered by a Check Point Authorized Training Center (ATC) for more details.
Let’s see how INSPECT Engine traffic enforcement works:
Figure 3: Simplified INSPECT Engine logic
When a new packet arrives at the FW kernel, the INSPECT Engine checks if there is already a connection in the Dynamic State Tables that this packet matches. If yes, that means that a positive security decision (Accept) has already been made. If the packet state is otherwise not considered a threat, it will be forwarded, and state records in the Dynamic State Tables are updated. If there is no record of a known connection associated with this packet, the INSPECT Engine tries to find a matching rule, going through the rulebase from top to bottom. To find the match, all three rule parameters: Source, Destination, and Service[2] are compared with the details of IP packet headers. If a matching rule is found the appropriate action: Accept, Drop, or Reject is performed. If the matched action is Accept, the INSPECT Engine adds a new set of records into the Dynamic State Tables.
Stateful Inspection improves the performance outcome for a security decision. In the case of an accepted connection, only the first packet requires a rulebase lookup. The rest of the packet flow within an accepted connection only needs state table verification. This approach is much more effective than SPF which requires making a security decision separately for each IP packet of the traffic.
Nevertheless, if the connection is not accepted, every subsequent packet associated with the connection attempt (including retransmissions) must be matched to a Drop rule in the rulebase, even in case of Check Point Stateful Inspection is in use.
One more drawback of Stateful Inspection is about maintaining the stability of the OS kernel. The INSPECT Engine is part of the system kernel; hence Dynamic State Tables reside in Kernel Memory space. To prevent corruption of these tables, each set of Kernel Tables can only be accessed and updated by a single CPU core[3].
All these potential limitations are addressed with the SecureXL and CoreXL features in modern Check Point firewall systems[4].
To manage the policy rulebase installed on a Security Gateway and to control Check Point security systems as a whole, one needs a Security Management Server. As already mentioned in the History paper (found at http://papers.cpug.org), having a Management Server as a separate component of the security system is a defining and integral characteristic of Check Point security products. Interacting with a Management Server requires a third component: a Windows-based SmartConsole application. These three components: the SmartConsole GUI client, Security Management Server and Security Gateway are part of the Check Point Three Tier Architecture. Any Check Point-based security system has all three components.
In a typical Check Point Security system implementation, the Security Management Server and Security Gateway(s) are deployed on separate machines. This type of deployment is known as Distributed.
However, in a very limited number of scenarios both the Management and Gateway components of the Three Tier Architecture can be installed on the same machine. This alternative type of deployment is called a Standalone. Even in this case the Management and Gateway functionality are acting separately and using the same communication principles that are in use in case of a Distributed deployment.
The Three Tier Architecture requires a communication mechanism allowing the Security Management Server to exchange information such as policy configurations and logs with Gateways. This communication platform is called Secure Internal Communication (SIC). SIC is based on TLS (Transport Layer Security) technology[5]. It provides an encrypted and secured channel for policy installation and status information delivery within a managed Security System. TLS authentication is based on internally signed certificates. The primary Management Server acts as an Internal Certificate Authority (ICA). It issues certificates for managed Gateways and other components of Check Point Security deployments. To initiate SIC with a new Gateway, one-time password is required to be defined both on the Gateway and on the Management Server sides.
Check Point’s Software Blade Architecture term needs to be explained from two different points of view: technology and licensing. From a technology standpoint, the term “Software Blade” is interchangeable with a more common term: “a feature”. Arguably, there is no technological or even architectural change in the Check Point products that would justify use of the term “blade” from a functionality perspective. We will be using Software Blade terminology in the CPUG Papers in regards to security features, only because Check Point is using it in the product documentation, online help, and marketing papers.
However, the licensing model for Software Blades is quite different from any other previous Check Point licensing models, and in that discourse, the “Blade” term does demonstrate a particular value.
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] More details about stateful Inspection functionalities in regards to OSI model can be found in Check Point’s technical documentation. Some external sources consider Stateful Inspection’s capabilities to be limited up to Layer 6, not 7. The confusion is probably caused by different interpretations of the OSI model itself and not by misrepresentation of Stateful Inspection technology. For example, HTTP and FTP are considered to be part of Layer 6 or Layer 7 of OSI, according to different authors and schools of thought. In this paper, we are sticking to the Check Point's view on the matter. However, it is important to point out that some other authors and security vendors may use different methods of OSI networking model representation.
[2] VPN column appearing in a Simplified VPN rulebase may also be part of matching conditions, when applicable.
[3] This is true even in the case of CoreXL, where each CPU core has its own set of connections to handle.
[4] To get more information about SecureXL and CoreXL we recommend the “Max Power: Check Point Firewall Performance Optimization” book by Timothy Hall, who is co-author of the papers you are reading now.
[5] TLS's predecessor SSL has been deprecated due to security concerns.
In the History article, we mentioned that Stateful Inspection technology is much more efficient and secure than Static Packet Filtering. Let’s try to prove this statement and understand its technological basis.
Static Packet Filtering (SPF) is a method to control network access by checking the IP header of a packet and comparing its data with an access list, which contains access restrictions and allowances. Practically any UNIX, BSD, or Linux machine is capable of performing this function natively. With SPF, the security decision is made by the kernel’s IP stack in conjunction with an IP forwarding decision. This function is always performed on a per packet basis.
Static Packet Filtering is incapable of enforcing anything more complex than just a simple verification of Layers 3 and 4 parameters, such as IP addresses and sometimes port numbers. It also has performance drawbacks, as the security decision has to be made for every forward
...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
