Check Point R77 Security Gateway Architecture | White Paper

September 2017

Check Point

Security Gateway Architecture

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
1
 Check Point R77 Security Gateway Architecture | White Paper

DOCUMENT GOAL
This document has been created to provide the Check Point technical community with an overview of the Check Point Security
Gateway architecture. The goal is to aggregate and summarize existing Check Point SecureKnowledge articles on our gateway
technology into one paper so that our technology can be more easily explained when talking with customers. For additional details
see the SecureKnowledge articles referenced in the document.

The document describes R77 gateway architecture. Look forward to a companion piece describing the R80 Security Gateway
architecture which is different in some ways. You may also be interested in the R80.10 Security Management Architecture
Overview.

Revision History
Date Revision
21 February 2017 First release of this document
9 March 2017 Added additional references to the packet flow diagram
Priority Queues description updated
27 May 2017 Updated file comparison hash used
25 September 2017 Anti-spoofing section updated

CONTRIBUTORS
This is a group effort. Thanks to the engineers from Check Point Research and Development, Sales, Solutions Center and
Technical Marketing who provided feedback on this document. Also thanks to all who have contributed to SecureKnowledge over
the years.

REFERENCES
Content for this document came from the following SecureKnowledge articles. More information is available in the SKs.
• SecureKnowledge sk98799: Kernel Debug [Advanced Access]
• SecureKnowledge sk104760: ATRG VPN Core. [Advanced Access]
• SecureKnowledge sk65133: Connection Table Format. [Advanced Access]
• SecureKnowledge sk98722: ATRG SecureXL. [Advanced Access]
• SecureKnowledge sk98737: ATRG CoreXL. [Advanced Access]
• SecureKnowledge sk95193: ATRG IPS. [Advanced Access]
• SecureKnowledge sk92264: ATRG Anti-Bot and Anti-Virus. [Advanced Access]

Most of these require Advanced Access. Customers can find related content here:
• SecureKnowledge sk98348: Best Practices - Security Gateway Performance. [General Access]
• Check Point Support Channel on YouTube: Security Gateway Performance Optimization

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
2
 Check Point R77 Security Gateway Architecture | White Paper

1. OVERVIEW
This document describes the packet flow in a Check Point Next Generation Threat Prevention gateway. Stateful inspection,
network and port address translation (NAT), Virtual Private Network (VPN) functions and forwarding are applied per-packet on the
inbound and outbound interfaces of the device. State-related information is extracted from packets and maintained in dynamic state
tables to evaluate subsequent connection attempts. When possible, throughput and session rate are accelerated by a security
acceleration (SecureXL) module.

Session-based processing enforces advanced access control and threat detection and prevention capabilities. To do this we
assemble packets into a stream, parse the stream for relevant content and then security modules (Software Blades) inspect the
content. When possible, a common pattern matcher does simultaneous inspection of the content for multiple security modules. In
multi-core systems this processing is distributed amongst the cores to provide near linear scalability on each additional core.

Security modules use a local cache to detect known threats. This local cache is backed up with real-time lookups of an online cloud
service. The result of cloud lookups are then cached in the kernel for subsequent lookups. Cloud assist also enhances unknown
threat detection and prevention. In particular a file whose signature is not known in a local cache is sent to our cloud service for
processing where compute, disk and memory are virtually unlimited. Our sandboxing technology, SandBlast Threat Emulation,
identifies threats in their infancy before malware has an opportunity to deploy and evade detection. Newly discovered threats are
sent to the cloud database to protect other Check Point connected gateways. When possible, active content is removed from files
and sent on to the user while the emulation is done.

2. INBOUND PACKET
The packet is taken from the wire by the firewall driver and enters a buffer. The packet is norrmalized in a structure called a chain
which represents both the original packet and its current state in firewall processing. Chains (normalized packets) pass through
chain modules, which can choose to pass a chain to the next module, drop or hold it.

Inbound Packet Flow (see Appendix A: Packet Flow Diagram)

Note: understanding chain modules is a useful debugging tool, see SecureKnowledge sk98799: Kernel Debug [Advanced Access]

2.1 VPN Decrypt

The first of these modules checks whether the packet is part of an IPsec VPN and decrypts if necessary.
• The VPN kernel module decrypts the packet.
• The decrypted (original) packet is inspected.

Note: for additional information on VPN processing, see SecureKnowledge sk104760: ATRG VPN Core. [Advanced Access]

2.2 Inbound Stateless Checks

The firewall does preliminary “stateless” checks that do not require context in order to decide whether to accept a packet or not.
For instance we check that the packet is a valid packet and if the header is compliant with RFC standards.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
3
 Check Point R77 Security Gateway Architecture | White Paper

3. CONNECTION SETUP
A core component of the Check Point Next Generation Threat Prevention gateway is the stateful inspection firewall. A stateful
firewall tracks the state of network connections in memory to identify other packets belonging to the same connection and to
dynamically open connections that belong to the same session. Allowing FTP data connections using the information in the control
connection is one such example. Using Check Point INSPECT code the firewall is able to dynamically recognize that the FTP
control connection is opening a separate data connection to transfer data.

When the client requests that the server generate the back-connection (an FTP PORT command), INSPECT code extracts the port
number from the request. Both client and server IP addresses and both port numbers are recorded in an FTP-data pending request
list. When the FTP data connection is attempted, the firewall examines the list and verifies that the attempt is in response to a valid
request. The list of connections is maintained dynamically, so that only the required FTP ports are opened.

In a Check Point firewall state tables include information about current connections, hosts, users and other information and are
implemented as dynamic hash tables in kernel memory. The connection table includes a 5-tuple key to lookup the connection. The
5-tuple key from the packet is checked against the connection table to see if it matches an existing connection table entry.

The 5-tuple key:

• Source IP, Source Port, Destination IP, Destination Port, Protocol Number

In this example connection table entry notice that connection table entries hold additional information about the connection such as
the packet direction, connection type (C2S, S2C, etc.), connection flags (SYN, SYN-ACK, etc.), the security policy rule that
matches the connection, the log UUID, and the interface.

<direction,5-tuple-key;
r_ctype,r_cflags,rule,service_id,handler,uuid1,uuid2,uuid3,uuid4,ifncin,ifncout,ifnsin,i
fnsout,bits1,bits2,connection_module_kbufs@ttl/timeout>

Note: for more information about the connection table, see SecureKnowledge sk65133: Connection Table Format. [Advanced
Access]

Before there is a connection table entry, the firewall must first check the connection against the firewall security policy to see if the
connection is allowed. One of two drivers will handle the first connection; SecureXL or firewall INSPECT.

Simplified Example of SecureXL Process

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
4
 Check Point R77 Security Gateway Architecture | White Paper

The SecureXL device is implemented either in software, or in hardware and minimizes the connections that are processed by the
INSPECT driver. SecureXL accelerates connections on two ways.

Throughput Acceleration: The first packets of a new TCP connection require more processing when processed by the firewall
module. If the connection is eligible for acceleration, after minimal security processing the packet is offloaded to the SecureXL
device associated with the proper egress interface. Subsequent packets of the connection can be processed on the accelerated
path and directly sent from the inbound to the outbound interface via the SecureXL device.

Connection Rate Acceleration: SecureXL also improves the rate of new connections (connections per second) and the
connection setup/teardown rate (sessions per second). To accelerate the rate of new connections, connections that do not match a
specified 5 tuple are still processed by SecureXL. For example, if the source port is masked and only the other 4 tuple attributes
require a match. When a connection is processed on the accelerated path, SecureXL creates a template of that connection that
does not include the source port tuple. A new connection that matches the other 4 tuples is processed on the accelerated path
because it matches the template. The firewall module does not inspect the new connection, increasing firewall connection rates.

SecureXL and the firewall module keep their own state tables and communicate updates to each other.
• Connection offload - Firewall kernel passes the relevant information about the connection from firewall connections table
to SecureXL connections table.
• Connection notification - SecureXL passes the relevant information about accelerated connections that match an accept
template.

In addition to accept templates the SecureXL device is also able to apply drop templates which are derived from security rules
where the action is drop. In addition to firewall security policy enforcement, SecureXL also accelerates NAT, and IPsec VPN traffic.

NOTE: for additional information on SecureXL processing, see SecureKnowledge sk98722: ATRG SecureXL. [Advanced Access]

Connection Setup (see Appendix A

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
5
 Check Point R77 Security Gateway Architecture | White Paper

3.1 Anti-Spoofing Check

Anti-Spoofing verifies that the source IP of each packet matches the interface, on which it was encountered. On internal interfaces
we only allow packets whose source IP is within the user-defined network topology. On the external interface we allow all source
IPs except for ones that belong to internal networks. This occurs after the connection table match; in SecureXL and the Firewall
Path.

• When a packet arrives that doesn’t match a connection, then anti-spoofing is checked before the connection is recorded. If
the packet arrives on the wrong interface, then the packet is dropped and no connection is recorded.
• When a packet arrives that matches a connection, then we check the anti-spoofing cache which allows us to make a very
efficient check by comparing two numbers that normally passes most packets.
o If the packet arrives from the same interface as the previous one and from the same direction, then the packet is
allowed.
o If the packet arrives on another interface, we check the topology since it’s possible for more than one interface to
be valid for a given source IP.

3.2 Network Address Translation (NAT)

On inbound packets we apply destination NAT replacing the destination IP address and or port to the translated IP address and or
port.

4. MULTI-CORE PROCESSING
CoreXL is a performance-enhancing technology for security gateways on multi-core platforms. CoreXL enhances security gateway
performance by enabling the processing CPU cores to concurrently perform multiple tasks. CoreXL provides almost linear
scalability of performance, according to the number of processing CPU cores on a single machine.

On a security gateway with CoreXL enabled, the firewall kernel is replicated multiple times. Each replicated copy, or firewall
instance, runs on one processing CPU core. These firewall instances handle traffic concurrently, and each firewall instance is a
complete and independent firewall inspection kernel. When CoreXL is enabled, all the firewall kernel instances in the security
gateway process traffic through the same interfaces and apply the same security policy.

Check Point also supports Simultaneous Multi-Threading (SMT), Intel Hyper-Threading. When enabled, SMT doubles the number
of logical CPUs on the security gateway, which enhances physical processor utilization. When SMT is disabled, the number of
logical CPUs equals the number of physical cores. SMT improves performance up to 30% in IPS, Application Control and URL
Filtering and threat prevention by increasing the number of CoreXL firewall instances based on the number of logical CPUs.

Traffic is distributed by one or more Secure Network Distributor (SND) working with a SecureXL instance to the firewall instances
running on the other cores.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
6
 Check Point R77 Security Gateway Architecture | White Paper

Dynamic Dispatcher
The dynamic despatcher is responsible for monitoring not only the current load of each CPU core but also the anticipated future
load based on traffic queued for processing. When a stream or connection is dispatched to a particular core for processing it builds
a table to ensure that subsequent packets within the same connection retain affinity to the same core.

Multi Queue
Network interfaces on a security gateway typically receive traffic at different throughputs; some are busier than others. At a low
level, when a packet is received from the NIC, then a CPU core must be “interrupted” to the exclusion of all other processes, in
order to receive the packet for processing. To avoid bottlenecks we allow multiple buffers, and therefore CPU cores, to be affined
to an interface. Each affined buffer can “interrupt” its own CPU core allowing high volumes of inbound packets to be shared across
multiple dispatchers.

Priority Queues
We know that in some situations a security gateway can be overwhelmed; in circumstances where traffic levels exceed the
capabilities of the hardware, either legitimate traffic or from a DOS attack, it is vital that we can maintain management
communications and continue to interact with dynamic routing neighbors. The Priority Queues functionality prioritizes control
connections over data connections based on priority.

4.1 A Note About Paths

The SecureXL device and the firewall module enforce security policy based on source, destination and port information. In Check
Point documentation you will hear about 3 paths; Fast, Slow and Medium Path, where Fast Path refers to SecureXL and Slow Path
refers to the firewall module. Medium Path refers to content security inspection where packets are received directly from the
SecureXL device.

We have discussed how multiple firewall instances run on separate cores in a multi-core system and how many instances can run
in parallel. In the Check Point architecture, content security inspection runs in a monolithic part of the firewall kernel. When content
security inspection is needed, then packets can be received from the SecureXL device or from the firewall module. Receiving
packets directly from the SecureXL device uses less CPU resources, thus the name medium path.

NOTE: for additional information on CoreXL processing, see SecureKnowledge sk98737: ATRG CoreXL. [Advanced Access]

5. PRE-CONTENT SECURITY INSPECTION

5.1 Stream Assembly
In order to identify more sophisticated threats we need to do additional inspection of the initial and subsequent packets within a
session. The Streaming Engine processes the individual packet chains, creates an ordered packet stream and directly performs a
number of security functions on the stream. One is to validate the TCP stream, e.g. looking for retransmissions with modified data
or TCP connection packets with no handshake. The streaming engine passes assembled stream to the protocol parsers.

The engine has two modes depending on the nature of the traffic. In the passive mode there is limited opportunity to modify the
traffic stream itself. The active mode however, is able to modify the connection. This mode essentially proxies the TCP connection
and is necessary when performing HTTPS man-in-the-middle inspection. Active streaming also facilitates timing and buffering
when it’s necessary to inspect content such as large files.

Content Inspection Needed (see Appendix A)

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
7
 Check Point R77 Security Gateway Architecture | White Paper

5.2 Protocol Parsers

Protocols include HTTP, SMTP, DNS, IMAP, Citrix, and many others. Protocol parser instances register with the streaming engine
in order to receive ordered streams of data, both client-to-server (C2S) as well as server-to-client (S2C) streams. They test for
conformance to RFCs and look for anomalies. An example of a protocol anomaly would be where, for example, there is a non-
existing HTTP method instead of GET, POST etc. in the HTTP header.

Another job of the parsers is to normalize content. For instance characters within a URL like an uppercase “A” may be encoded as
%41. The parser will normalize this content before passing the URL to the protections for inspection.

The parsers main purpose is to extract ‘contexts’ from the streams to prepare for the next level of inspection. A context is best
described by example:

6. CONTENT SECURITY INSPECTION

When advanced security features are enabled like Application Control, URL Filtering, Data Loss Prevention (DLP), IPS, Anti-Bot,
Antivirus and SandBlast Threat Emulation (sandboxing) the security gateway performs content inspection on the contexts derived
from the protocol parser.

A Context Management Infrastructure (CMI) connects parsers with pattern matchers. CMI determines which protections should be
activated on every context discovered by a protocol parser. If policy dictates that no protections should run, then the relevant
parsers on this traffic are bypassed in order to improve performance and reduce potential false positives. For instance, if the IPS
policy is activating server protections only, then the HTTP parser will not analyze the server to client (S2C) traffic. After the security
module analysis is done, their verdict is passed to the CMI to perform the final action to be done on the various contexts.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
8
 Check Point R77 Security Gateway Architecture | White Paper

6.1 Pattern Matcher

Security modules each have a distinct function and they register with the CMI to receive particular context types. The CMI Loader
maintains a register table of all security modules and the contexts they want to inspect. This registration process occurs at policy
install time.

During policy installation, the CMI collects signatures from multiple sources (e.g. IPS and Application Control) and compiles them
together into Pattern Matchers (PM) (one for each context - such as URL, Host header etc.). The CMI Pattern Matcher quickly
identifies harmless packets, common signatures in malicious packets, and does a second level analysis when needed to reduce
false positives.

DNS Host Context URL Context File SHA1 Context Other Contexts
Application Control   
URL Filtering  
IPS 
Antivirus   
Anti-Bot   
SandBlast Threat Emulation 

The engine uses a two tiered inspection process. The first tier quickly filters out the vast majority of traffic which is clearly harmless
by looking for signatures that are simple to find at a low CPU cost. If the first tier identifies a common attack signature a second
level analysis is done, thus increasing the confidence that there is indeed an attack. The first tier will never decide on its own that a
packet is malicious. It can only decide that a packet is clearly harmless. The second tier can also be instructed to activate further
inspection using INSPECT technology when some patterns are matched.

6.2 Protections
Protections are composed of signatures that identify malicious activity. There are three types of signatures;
• Regular expression like patterns
• INSPECT code
• Compound Signature Identification (CSI)

Regex signatures are done first followed by INSPECT and CSI if needed. CSI can address signatures on multiple parts of a packet,
multiple parts of the protocols such as URL and an HTTP header, multiple parts of a connection, such as CIFS request and
response, or multiple connections, such as VoIP control and data connections. In its operation, CSI constructs complex signatures
that are triggered only if a certain logical condition over multiple contexts is matched. The logical expression can use AND, OR,
NOT or ORDERED-AND to construct the logical expression.

6.3 Cache with Cloud Backup

After a match by the Pattern Matcher, the CMI is notified by the relevant module like Application Control, URL Filtering, Antivirus,
Anti-Bot and Threat Emulation that its signature was matched. Additional processing is done as needed by the security module. For
instance Application Control retrieves all the data regarding the application (its categories, priority, etc.) from a cache based on the
signature that was matched. If a match is not found or social network widget detection is needed, then the online cloud service is
checked. URL Filtering is another example where if the context is not found in cache, then the online cloud service is checked. URL
categorization occurs mostly in the kernel. When not found in the local cache, the online cloud service is checked and the result is
then cached in the kernel.

6.4 File Handling

In some situations we need to inspect an entire file for malicious behavior. In these cases the file is sent directly to Threat
Emulation, Threat Extraction and Antivirus for processing. If the SHA1 of the file is not cached, then these modules may need to
receive a complete file. Files can be extracted from streams and security gateways have the option to act as a mail relay (Mail
Transfer Agent), which allows us to inspect encrypted SMTP traffic over TLS. With SMTP inspection users don’t notice delays
whilst inspection like that required in Threat Emulation (sandboxing) of large or complex attachments is carried out.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
9
 Check Point R77 Security Gateway Architecture | White Paper

When files are transferred over HTTP/HTTPS, then users may notice a delay while Threat Emulation occurs. SandBlast Threat
Extraction technology eliminates threats by removing exploitable content and reconstructing documents using known safe
elements. Safe content is delivered to the user. Users are allowed access to original files after Threat Emulation completes its
analysis.

Content Inspection (see Appendix A)

6. 5 Final Decision
After the security module analysis is done, their verdict is passed to the CMI to perform the final action. The CMI is responsible for
the final action to be performed on the packet, given several considerations. The considerations include:
• Activation status of the protection. e.g. IPS prevent, detect or inactive
• Exceptions either on traffic or on IPS protection
• Bypass mode status (the software fail open capability)
• Troubleshooting mode status
• Are we protecting the internal network only or all traffic

6.6 UserCheck
In the Application Control, URL Filtering and DLP security policy, the action Ask User presents users with a UserCheck dialog
window prompting them to confirm they wish to complete the connection and if needed provide a reason. For example they may be
visiting a risky site or sending confidential content to an external recipient. Depending upon their response the connection will be
allowed or denied.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
10
 Check Point R77 Security Gateway Architecture | White Paper

7. OUTBOUND PACKET
7.1 Network Address Translation
On outbound packets we apply source NAT replacing the source IP address and or port to a translated IP address and or port.

7.2 Encryption
Encrypting a packet
• The outgoing packet is inspected by the firewall (at Pre-Outbound chain "o").
• The VPN kernel module encrypts the packet (at Post-Outbound chain "O").

Outbound Packet Flow (see Appendix A)

8. SUMMARY
The Check Point Security Gateway operates a single parse engine which derives contexts that are available for inspection by
security modules. This modular approach offers great flexibility to add functionality if the nature of threats change over time and
require new approaches such as with Threat Emulation and Extraction. We employ acceleration technologies that minimize latency
and maximize efficient hardware utilization.

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
11
 Check Point R77 Security Gateway Architecture | White Paper

APPENDIX A: PACKET FLOW DIAGRAM

©2017 Check Point Software Technologies Ltd. All rights reserved. [Protected] Non-confidential content | September 25, 2017
12