Introduction This document describes the packet flow (partly also connection flows) in a Check Point R80.10 and above with SecureXL and CoreXL, Content Inspection, Stateful inspection, network and port address translation (NAT), MultiCore Virtual Private Network (VPN) functions and forwarding are applied per-packet on the inbound and outbound interfaces of the device. There should be an overview of the basic technologies of a Check Point Firewall. We have also reworked the document several times with Check Point, so that it is now finally available. Chapter Architecture:R80.x Security Gateway Architecture (Logical Packet Flow)R80.x Security Gateway Architecture (Content Inspection) R80.x Security Gateway Architecture (Acceleration Card Offloading) R80.x Ports Used for Communication by Various Check Point Modules Performance Tuning:R80.x Performance Tuning Tip - AES-NI R80.x Performance Tuning Tip - SMT (Hyper Threading) R80.x Performance Tuning Tip - Multi Queue R80.x Performance Tuning Tip - Connection Table R80.x Performance Tuning Tip - fw monitorR80.x Performance Tuning Tip - TCPDUMP vs. CPPCAP R80.x Performance Tuning Tip – DDoS „fw sam“ vs. „fwaccel dos“ Cheat Sheet:R80.x cheat sheet - fw monitor R80.x cheat sheet - ClusterXL More interesting articles:Article list (Heiko Ankenbrand) What's new in R80.10 and above R80.10 and above offer many technical innovations regarding R77. I will look at the following in this article:- new fw monitor inspection points for VPN (e and E)- new MultiCore VPN- UP Manager- Content Awareness (CTNT) R80.20 and above:- SecureXL has been significantly revised in R80.20. It now works in user space. This has also led to some changes in "fw monitor"- There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine.- Now SecureXL works in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing.- SecureXL supportes now Async SecureXL with Falcon cards- That's new in acceleration high level architecture (SecureXL on Acceleration Card): Streaming over SecureXL, Lite Parsers, Scalable SecureXL, Acceleration stickiness- Policy push acceleration on Falcon cards- Falcon cards for: Low Latency, High Connections Rate, SSL Boost, Deep Inspection Acceleration, Modular Connectivity, Multible Acceleration modules- Falcon card compatible with 5900, 15000 & 23000 Appliance Series > 1G (8x1 GbE), 10G (4x10 GbE) and 40G (2x40 GbE) R80.30 and above:- In R80.30+, you can also allocate a core for management traffic if you have 8 or more cores licensed, but this is not the default.- Active streaming for https with full SNI support. R80.40 and above:- Support for automatic allocation of CoreXL SNDs and Firewall instances that does not require a Security Gateway reboot.- CoreXL and Multi-Queue: Improved out of the box experience - Security Gateway automatically changes the number of CoreXL SNDs and Firewall instances and the Multi-Queue configuration based on the current traffic load.- Check Point's Security Gateway now support HTTP/2- A new Policy Layer in SmartConsole dedicated to TLS Inspection and different TLS Inspection layers can be used in different policy packages.- Enhanced NAT port allocation mechanism - on Security Gateways with 6 or more CoreXL Firewall instances, all instances use the same pool of NAT ports, which optimizes the port utilization and reuse.- Multiple CoreXL Firewall instances handle the SIP protocol to enhance performance.- Cluster Control Protocol encryption is now enabled by default. Flowchart basic Flowchart (new in R80.20+) SecureXL has been significantly revised in R80.20. This has also led to some changes in "fw monitor". There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine. Now SecureXL works in part in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing. The packet flow in R80.20+ is a little bit different from the flow lower than R80.20. Now it is possible to use async SecureXL and other new functions. This figure shows the new features with the reinjection of SecureXL packages. SecureXL supportes now also Async SecureXL with Falcon cards. That's new in acceleration high level architecture (SecureXL on Acceleration Card): Streaming over SecureXL, Lite Parsers, Scalable SecureXL, Acceleration stickiness. Whats new in R80.20+: Now there are several SecureXL instances possible. As a result, packets are reinjected with the new SecureXL ID into the correct SecureXL instance again after they have been allowed by access template or rule set. After the packet has been reinjected, the SecureXL ID is added to the SecureXL connetion table and the packet is forwarded to the correct SecureXL instance. Therefore the flow is slightly different to older version before R80.20. This new mechanism also offers the possibility to transfer packets into a new SecureXL instance on Falcon cards. PXL vs. PSLXL - Technology name for combination of SecureXL and PSL. PXL was renamed to PSLXL in R80.20. This is from my point of view the politically correct better term. For the new acceleration Falcon card architecture with R80.20+ and SecureXL offloading read this article:R80.x Security Gateway Architecture (Acceleration Card Offloading): VPN Decrypting a packet: R80.10 and R80.20 introduced MultiCore support (it is new in R80 and above) for IPsec VPN. An IPSec packet enters the Security Gateway. The decrypted original packet is forwarded to the connection CoreXL FW instance for FireWall inspection at Pre-Inbound chain "i" from SND. The decrypted inspected packet is sent to the OS Kernel. Encrypting a packet: Encryption information is prepared at Post-Outbound chain "O". The vpnk module on the tunnel CoreXL FW instance gets the packet before encryption at chain "e". The encryption packet is forwarded to the connection CoreXL FW instance for FireWall from SND. The packet is encrypted by vpnk module at chain "E". Afterwards the IPsec packet is sent out on interface. This fw monitor inspection points "e" and "E" are new in R80.10 and "oe" and "OE" are new in R80.20. Note: It's true, they only exist on the outbound side for encrypting packets not for decrypting packets on inbound side. Note: F2V - Describes VPN Connections via the F2F path. R80.20 VPN+SecureXL and above: (SK151114) Disabling acceleration by running fwaccel off will not have an immediate effect on IPsec acceleration, as it did before R80.20. Using fwaccel off, will cause every existing VPN connection to continue to be processed by the acceleration module (SecureXL), and only new connections will not be offloaded to the acceleration module. As long as there are accelerated VPN connections associated with the IPsec tunnel, all decryption/encryption operations will continue to be handled by the acceleration module. VPN before R80.20, VPN connections could be migrated between acceleration module and Firewall-1 instances due to synchronous communication between those modules. VPN since R80.20, fwaccel off does not stop the SecureXL device, and the communication between SecureXL and firewall-1 is now asynchronous. All connections that were accelerated will continue to be handled by PPAK. Furthermore, when new decryption/encryption keys are generated, the decision whether to accelerate the tunnel or not depends on whether there are accelerated connections associated with the tunnel. As a result, to disable VPN tunnel acceleration all outstanding related connections should be terminated. This behavior prevents disabling acceleration of tunnels as long as accelerated connections are associated with those tunnels. Firewall Core Inbound Stateless Check: 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. Anti-Spoofing: 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. Connection Setup: A core component of the Check Point R80.x 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. SecureXL SecureXL is a software acceleration product installed on Security Gateways. Performance Pack uses SecureXL technology and other innovative network acceleration techniques to deliver wire-speed performance for Security Gateways. SecureXL is implemented either in software or in hardware: SAM cards on Check Point 21000 appliances ADP cards on IP Series appliances Falcon cards (new in R80.20) on different appliances The SecureXL device minimizes the connections that are processed by the INSPECT driver. SecureXL accelerates connections on two ways. New in R80.10: In R80.10 SecureXL adds support for Domain Objects, Dynamic Objects and Time Objects. CoreXL accelerates VPN traffic by distributing Next Generation Threat Prevention inspection across multiple cores. New in R80.20: SecureXL was significantly revised in R80.20. It no longer works in Linux kernel mode but now in user space. In kernel mode resources (for example memory) are very limited. This has the advantage that more resources can be used in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing. On the 23900 in particular, we could not leverage all the processor cores due to this limitation. By moving all or most of SecureXL to user space, it's possible to leverage more processor cores as the firewall can entirely run in user space.It still doesn't by default in R80.20 in non-VSX mode, but it can be enabled. It also means certain kinds of low-level packet processing that could not easily be done in SecureXL because it was being done in the kernel now can. For VSX in particular, it means you can now configure the penalty box features on a per-VS basis. It also improves session establishment rates on the higher-end appliances. In addition, the following functions have been integrated in R80.20 SecureXL: SecureXL on Acceleration Cards (AC) Streaming over SecureXL Lite Parsers Async SecureXL Scalable SecureXL Acceleration stickiness Policy push acceleration 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 notification - SecureXL passes the relevant information about accelerated connections that match an accept template. Connection offload - Firewall kernel passes the relevant information about the connection from firewall connections table to SecureXL connections table. 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. QXL - Technology name for combination of SecureXL and QoS (R77.10 and above).This has no direct association with PXL. It is used exclusively for QoS. But also here it is possible to use the QoS path in combination with PSL. SAM card and Falcon card (R80.20 and above) - Security Acceleration Module card. Connections that use SAM/Falcon card, are accelerated by SecureXL and are processed by the SAM/Falcon card's CPU instead of the main CPU (refer to 21000 Appliance Security Acceleration Module Getting Started Guide)). SecureXL use the following templates: If templating is used under SecureXL, the templates are created when the firewall ruleset is installed. Accept Template - Feature that accelerates the speed, at which a connection is established by matching a new connection to a set of attributes. When a new connection matches the Accept Template, subsequent connections are established without performing a rule match and therefore are accelerated. Accept Templates are generated from active connections according to policy rules. Currently, Accept Template acceleration is performed only on connections with the same destination port (using wildcards for source ports). Accept Tamplate is enabled by default if SecureXL is used. Drop Template - Feature that accelerates the speed, at which a connection is dropped by matching a new connection to a set of attributes. When a new connection matches the Drop Template, subsequent connections are dropped without performing a rule match and therefore are accelerated. Currently, Drop Template acceleration is performed only on connections with the same destination port (does not use wildcards for source ports).Drop Template is disabled by default if SecureXL is used. It can be activated via smart Dashboard and does not require a reboot of the firewall. NAT Templates - Using SecureXL Templates for NAT traffic is critical to achieve high session rate for NAT. SecureXL Templates are supported for Static NAT and Hide NAT using the existing SecureXL Templates mechanism. Normally the first packet would use the F2F path. However, if SecureXL is used, the first packet will not be forwarded to the F2F path if Accept Tamplate and NAT Template match. Enabling or disabling of NAT Templates requires a firewall reboot. R80.10 and lower: NAT Template is disabled by default. R80.20 and above: NAT Template is enabled by design. SecureXL path: Fast path (Accelerated Path) - Packet flow when the packet is completely handled by the SecureXL device. It is processed and forwarded to the network.Note: In many discusions and images, the SXL path is marked with the "accelerated path". This also happened to me by mistake in this flowchart. Medium path (PXL) - The CoreXL layer passes the packet to one of the CoreXL FW instances to perform the processing (even when CoreXL is disabled, the CoreXL infrastructure is used by SecureXL device to send the packet to the single FW instance that still functions). When Medium Path is available, TCP handshake is fully accelerated with SecureXL. Rulebase match is achieved for the first packet through an existing connection acceleration template. SYN-ACK and ACK packets are also fully accelerated. However, once data starts flowing, to stream it for Content Inspection, the packets will be now handled by a FWK instance. Any packets containing data will be sent to FWK for data extraction to build the data stream. RST, FIN and FIN-ACK packets once again are only handled by SecureXL as they do not contain any data that needs to be streamed. This path is available only when CoreXL is enabled. Packet flow when the packet is handled by the SecureXL device, except for: IPS (some protections) VPN (in some configurations) Application Control Content Awareness Anti-Virus Anti-Bot HTTPS Inspection Proxy mode Mobile Access VoIP Web Portals. PXL vs. PSLXL - Technology name for combination of SecureXL and PSL. PXL was renamed to PSLXL in R80.20. This is from my point of view the politically correct better term. Medium path (CPASXL) - Now also CPAS use the SecureXL path in R80.20. CPAS works through the F2F path in R80.10 and R77.30. Now CPASXL is offered in SecureXL path in R80.20. This should lead to a higher performance. Check Point Active Streaming active streaming allow the changing of data and play the role of “man in the middle”. Several protocols uses CPAS, for example: Client Authentication, VoIP (SIP, Skinny/SCCP, H.323, etc.), Data Leak Prevention (DLP) blade, Security Servers processes, etc. I think it's not to be underestimated in tuning. Slow path or Firewall path (F2F) - Packet flow when the SecureXL device is unable to process the packet. The packet is passed on to the CoreXL layer and then to one of the Core FW instances for full processing. This path also processes all packets when SecureXL is disabled. New in R80.20: Inline Streaming path, Medium Streaming path, Host path and Buffer path - Are new SecureXL paths used in conjunction with Falcon cards. They are described in more detail in the following article "R80.x Security Gateway Architecture (Acceleration Card Offloading) ". Note to Falcon Cards: Theoretically and practically there are even more than these three paths. This has to do with the offloading of SAM and Falcon cards (new in R80.20) and with QXL (Quality of Service) and other SecureXL technologies. It's beyond the scope of this one. SecureXL chain modules (new in R80.20 and above) SecureXL has been significantly revised in R80.20. It now works in user space. This has also led to some changes in "fw monitor" There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine. The new fw monitor chain modules (SecureXL) do not run in the virtual machine (vm). SecureXL inbound (sxl_in) > Packet received in SecureXL from networkSecureXL inbound CT (sxl_ct) > Accelerated packets moved from inbound to outbound processing (post routing)SecureXL outbound (sxl_out) > Accelerated packet starts outbound processingSecureXL deliver (sxl_deliver) > SecureXL transmits accelerated packet There are more new chain modules in R80.20 vpn before offload (vpn_in) > FW inbound preparing the tunnel for offloading the packet (along with the connection)fw offload inbound (offload_in) > FW inbound that perform the offload fw post VM inbound (post_vm) > Packet was not offloaded (slow path) - continue processing in FW inbound CoreXL CoreXL is a performance-enhancing technology for Security Gateways on multi-CPU-core processing 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. The increase in performance is achieved without requiring any changes to management or to network topology. On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated copy, or FW instance, runs on one processing CPU core. These FW instances handle traffic concurrently, and each FW instance is a complete and independent FW inspection kernel. When CoreXL is enabled, all the FW kernel instances in the Security Gateway process traffic through the same interfaces and apply the same security policy. R80.20 CoreXL does not support these Check Point features: Overlapping NAT, VPN Traditional Mode, 6in4 traffic - this traffic is always processed by the global CoreXL FW instance #0 (fw_worker_0) and more (see CoreXL Known Limitations). Secure Network Distributor (SND) - Traffic entering network interface cards (NICs) is directed to a processing CPU core running the SND, which is responsible for: Processing incoming traffic from the network interfaces Securely accelerating authorized packets (if SecureXL is enabled) Distributing non-accelerated packets among Firewall kernel instances (SND maintains global dispatching table - which connection was assigned to which instance) SND does not really touch any packet. The decision to stick to a particular FWK core is done at the first packet of connection on a very high level before anything else. Depending on SXL settings and in most of the cases, SXL can be offloading decryption calculations. However, in some other cases, such as with Route-Based VPN, it is done by FWK. Firewall Instance (fw_worker) - On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each replicated copy, or Firewall Instance, runs on one CPU processing core. These FW instances handle traffic concurrently, and each FW instance is a complete and independent Firewall inspection kernel. When CoreXL is enabled, all the Firewall kernel instances on the Security Gateway process traffic through the same interfaces and apply the same security policy. Dynamic Dispatcher - Rather than statically assigning new connections to a CoreXL FW instance based on packet's IP addresses and IP protocol (static hash function), the new dynamic assignment mechanism is based on the utilization of CPU cores, on which the CoreXL FW instances are running. The dynamic decision is made for first packets of connections, by assigning each of the CoreXL FW instances a rank, and selecting the CoreXL FW instance with the lowest rank. The rank for each CoreXL FW instance is calculated according to its CPU utilization. The higher the CPU utilization, the higher the CoreXL FW instance's rank is, hence this CoreXL FW instance is less likely to be selected by the CoreXL SND. The CoreXL Dynamic Dispatcher allows for better load distribution and helps mitigate connectivity issues during traffic "peaks", as connections opened at a high rate that would have been assigned to the same CoreXL FW instance by a static decision, will now be distributed to several CoreXL FW instances. 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. When most of the traffic is accelerated by the SecureXL, the CPU load from the CoreXLSND instances can be very high, while the CPU load from the CoreXL FW instances can be very low. This is an inefficient utilization of CPU capacity. By default, the number of CPU cores allocated to CoreXL SND instances is limited by the number of network interfaces that handle the traffic. Because each interface has one traffic queue, only one CPU core can handle each traffic queue at a time. This means that each CoreXL SND instance can use only one CPU core at a time for each network interface. Check Point Multi-Queue lets you configure more than one traffic queue for each network interface. For each interface, you can use more than one CPU core (that runs CoreXL SND) for traffic acceleration. This balances the load efficiently between the CPU cores that run the CoreXL SND instances and the CPU cores that run CoreXL FW instances. Priority Queues - 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. Affinity - Association of a particular network interface / FW kernel instance / daemon with a CPU core (either 'Automatic' (default), or 'Manual'). The default CoreXL interface affinity setting for all interfaces is 'Automatic' when SecureXL is installed and enabled. If SecureXL is enabled - the default affinities of all interfaces are 'Automatic' - the affinity for each interface is automatically reset every 60 seconds, and balanced between available CPU cores based on the current load. If SecureXL is disabled - the default affinities of all interfaces are with available CPU cores - those CPU cores that are not running a CoreXL FW instance or not defined as the affinity for a daemon. The association of a particular interface with a specific processing CPU core is called the interface's affinity with that CPU core. This affinity causes the interface's traffic to be directed to that CPU core and the CoreXL SND to run on that CPU core. The association of a particular CoreXL FW instance with a specific CPU core is called the CoreXL FW instance's affinity with that CPU core. The association of a particular user space process with a specific CPU core is called the process's affinity with that CPU core. The default affinity setting for all interfaces is Automatic. Automatic affinity means that if SecureXL is enabled, the affinity for each interface is reset periodically and balanced between the available CPU cores. If SecureXL is disabled, the default affinities of all interfaces are with one available CPU core. In both cases, all processing CPU cores that run a CoreXL FW instance, or defined as the affinity for another user space process, is considered unavailable, and the affinity for interfaces is not set to those CPU cores. The default affinity setting for all interfaces is Automatic. Automatic affinity means that if SecureXL is enabled, the affinity for each interface is reset periodically and balanced between the available CPU cores. If SecureXL is disabled, the default affinities of all interfaces are with one available CPU core. In both cases, all processing CPU cores that run a CoreXL FW instance, or defined as the affinity for another user space process, is considered unavailable, and the affinity for interfaces is not set to those CPU cores. Passive Streaming Library (PSL) - IPS infrastructure, which transparently listens to TCP traffic as network packets, and rebuilds the TCP stream out of these packets. Passive Streaming can listen to all TCP traffic, but process only the data packets, which belong to a previously registered connection. PXL - Technology name for combination of SecureXL and PSL. The maximal number of possible CoreXL IPv4 FW instances: Version Check Point Appliance Open Server R80.10 (Gaia 32-bit) 16 16 R80.10 (Gaia 64-bit) 40 40 R77.30 (Gaia 32-bit) 16 16 R77.30 (Gaia 64-bit) 32 32 USFW - In kernel-mode FW, the maximum number of running cores is limited to 40 because of the Linux/Intel limitation of 2GB kernel memory, and because CoreXL architecture needs to load a large driver (~40MB) dozens of times (according to the CPU number, and up to 40 times). Newer platforms that contain more than 40 cores (e.g., 23900) are not fully utilized. Now it is possible to use more then 40 CoreXL cores in R80.10+ user mode firewall. For more informations see sk149973, Management Core - New in R80.30+, you can also allocate a core for management traffic if you have 8 or more cores licensed, but this is not the default. R80.30+ feature for separating management from data traffic via Routing Separation and Resource Separation as described in sk138672. R80.40+ (automatically changes CoreXL, SNDˋs and the Multi-Queue) New in R80.40+Support for automatic allocation of CoreXL SNDs and Firewall instances that does not require a Security Gateway reboot.CoreXL and Multi-Queue: Improved out of the box experience - Security Gateway automatically changes the number of CoreXL SNDs and Firewall instances and the Multi-Queue configuration based on the current traffic load. Changing CoreXL split between FW workers and SND on the fly based on CPU utilization Deciding keys:The average utilization of CoreXL SNDs and FWs are regularly sampled. If either CoreXL SNDs or FWs utilization is higher than the other, perform an estimate of utilization post “migrating” a CPU to the other group. Note when SMT is on, change is doubled. Supported on OS 3.10 (USFW/Kernel). Check Point appliances with 8 cores or more and VSX is currently a limitation. Supported on Cluster HA and VSLS is currently a limitation. Flows:If more SNDs are needed: Find least utilized CoreXL FW instance Stop dispatching new connections to the least utilized CoreXL FW instance Move the CoreXL FW instance to the CPU of next least utilized CoreXL FW instance Turn on a new MQ queue on the “evicted” CPUNote: Eligible CoreXL SNDs must have a MQ queue ready If more FWs (CoreXL) are needed: Choose the last “stopped” CoreXL FW instance Turn off MQ queue from the CPU it originally occupied Move the chosen CoreXL FW instance to the original CPU it occupied Start dispatching new connections to that CoreXL FW instanceNote: No more than the maximum number of FWs can be added FW Monitor Inspection Points There are new fw monitor inspection points (red) when a packet passes through a R80.20+ Security Gateway: Inspection point Name of fw monitor inspection point Relation to firewall VM Available since version i Pre-Inbound Before the inbound FireWall VM (for example, eth1:i) always I Post-Inbound After the inbound FireWall VM (for example, eth1:I) always id Pre-Inbound VPN Inbound before decrypt (for example, eth1:id) R80.20 ID Post-Inbound VPN Inbound after decrypt (for example, eth1:ID) R80.20 iq Pre-Inbound QoS Inbound before QoS (for example, eth1:iq) R80.20 IQ Post-Inbound QoS Inbound after QoS (for example, eth1:IQ) R80.20 o Pre-Outbound Before the outbound FireWall VM (for example, eth1:o) always O Post-Outbound After the outbound FireWall VM (for example, eth1:O) always e oe Pre-Outbound VPN Outbound before encrypt (for example, eth1:e) in R80.10 (for example, eth1:oe) in R80.20 R80.10 R80.20 E OE Post-Outbound VPN Outbound after encrypt (for example, eth1:E) in R80.10 (for example, eth1:OE) in R80.20 R80.10 R80.20 oq Pre-Outbound QoS Outbound before QoS (for example, eth1:oq) R80.20 OQ Post-Outbound QoS Outbound after QoS (for example, eth1:OQ) R80.20 The "Pre-Encrypt" fw monitor inspection point (e) and the "Post-Encrypt" fw monitor inspection point (E) are new in R80 and above. Note: It's true, they only exist on the outbound side for encrypting packets not for decrypting packets on inbound side. New in R80.20+: In Firewall kernel (now also SecureXL), each kernel is associated with a key witch specifies the type of traffic applicable to the chain modul. # fw ctl chain Key Function ffffffff IP Option Stip/Restore 00000001 new processed flows 00000002 wire mode 00000003 will applied to all ciphered traffic (VPN) 00000000 SecureXL offloading (new in R80.20+) Content Inspection For more details see article: R80.x Security Gateway Architecture (Content Inspection) Content inspection is a very complicated process, it is only shown in the example for R80.10 IPS and R80.10 App Classifier. It is also possible for other services. Please refer to the corresponding SK's. In principle, all content is processed via the Context Management Infrastructure (CMI) and CMI loader and forwarded to the corresponding daemon. 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 contexts and then security modules 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 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 and devices. When possible, active content is removed from files which are then sent on to the user while the emulation is done. Passive Streaming Library (PSL) -Packets may arrive out of order or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with Passive Streaming Library (PSL) technology. PSL is an infrastructure layer, which provides stream reassembly for TCP connections. The gateway makes sure that TCP data seen by the destination system is the same as seen by code above PSL.This layer handles packet reordering, congestion handling and is responsible for various security aspects of the TCP layer such as handling payload overlaps, some DoS attacks and others. The PSL layer is capable of receiving packets from the firewall chain and from SecureXL module. The PSL layer serves as a middleman between the various security applications and the network packets. It provides the applications with a coherent stream of data to work with, free of various network problems or attacks The PSL infrastructure is wrapped with well defined APIs called the Unified Streaming APIs which are used by the applications to register and access streamed data. Protocol Parsers - The Protocol Parsers main functions are to ensure compliance to well-defined protocol standards, detect anomalies if any exist, and assemble the data for further inspection by other components of the IPS engine. They include HTTP, SMTP, DNS, IMAP, Citrix, and many others. In a way, protocol parsers are the heart of the IPS system. They register themselves with the streaming engine (usually PSL), get the streamed data, and dissect the protocol.The protocol parsers can analyze the protocols on both Client to Server (C2S) and Server to Client (S2C) directions. The outcome of the protocol parsers are contexts. A context is a well defined part of the protocol, on which further security analysis can be made. Examples of such contexts are HTTP URL, FTP command, FTP file name, HTTP response, and certain files. Context Management Infrastructure (CMI) and Protections - The Context Management Infrastructure (CMI) is the "brain" of the content inspection. It coordinates different components, decides which protections should run on a certain packet, decides the final action to be performed on the packet and issues an event log.CMI separates parsers and protections. Protection is a set of signatures or/and handlers, where Signature - a malicious pattern that is searched for Handler - INSPECT code that performs more complex inspection CMI is a way to connect and manage parsers and protections. Since they are separated, protections can be added in updates, while performance does not depend on the number of active protections. Protections are usually written per protocol contexts - they get the data from the contexts and validate it against relevant signatures Based on the IPS policy, the 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. When a protection is activated, it can decide whether the given packet or context is OK or not. It does not decide what to do with this packet. 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 (Prevent, Detect, Inactive) Exceptions either on traffic or on protection Bypass mode status (the software fail open capability) Troubleshooting mode status Are we protecting the internal network only or all traffic CMI Loader - collects signatures from multiple sources (e.g. IPS, Application Control,...) and compiles them together into unified Pattern Matchers (PM) (one for each context - such as URL, Host header etc.). Pattern Matcher -The Pattern Matcher is a fundamental engine within the new enforcement architecture. Pattern Matcher quickly identifies harmless packets, common signatures inmalicious packets, and does a second level analysis to reduce false positives. Pattern Matcher engine provides the ability to find regular expressions on a stream of data using a two tiered inspection process. UP Manager - The UP Manager controls all interactions of the components and interfaces with the Context Management Infrastructure (CMI) Loader, the traffic director of the CMI. The UP Manager also has a list of Classifiers that have registered for “first packets” and uses a bitmap to instruct the UP Classifier to execute these Classifier Apps to run on the packet. The “first packets” arrive directly from the CMI. Parsing of the protocol and streaming are not needed in this stage of the connection. For “first packets” the UP Manager executes the rule base. Classifier - When the “first packet” rule base check is complete Classifiers initiate streaming for subsequent packets in the session. The “first packet” rule base check identifies a list of rules that possibly may match and a list of classifier objects (CLOBs) that are required to complete the rule base matching process. The Classifier reads this list and generates the required CLOBs to complete the rule base matching. Each Classifier App executes on the packet and tells the result of the CLOB to the UP Manager. The CMI then tells the Protocol Parser to enable streaming. In some cases Classifier Apps do not require streaming, e.g. the first packet information is sufficient. Then the rule base decision can be done on the first packet. Dynamic Objects Domain Objects Only the firewall is enabled On subsequent packets the Classifier can be contacted directly from the CMI using the CMI Loader infrastructure, e.g. when the Pattern Matcher has found a match it informs the CMI it has found application xyz. The CMI Loader passes this information to the Classifier. The Classifier runs the Classification Apps to generate CLOBs required for Application Control and sends the CLOBs to the Observer. Observer - The Observer decides if enough information is known to publish a CLOB to the security policy. CLOBs are observed in the context of their transaction and the connection that the transaction belongs to. The Observer may request more CLOBs for a dedicated packet from the Classifier or decides that it has sufficient information about the packet to execute the rule base on the CLOB, e.g. if a file type is needed for Content Awareness and the gateway hasn’t yet received the S2C response containing the file. Executing the rule base on a CLOB is called “publishing a CLOB”. The Observer may wait to receive more CLOBs that belong to the same transaction before publishing the CLOBs. Security Policy - The Security Policy receives the CLOB published by the Observer. The CLOB includes a description of the Blade it belongs to so that matching can be performed on a column basis. The security policy saves the current state on the transaction Handle; either to continue the inspection or final match. The first packets are received directly from the UP Manager. Subsequent packets are received by the rule base from the Observer. Handle - Each connection may consist of several transactions. Each transaction has a Handle. Each Handle contains a list of published CLOBs. The Handle holds the state of the security policy matching process. The Handle infrastructure component stores the rule base matching state related information. Subsequent Packets - Subsequent packets are handled by the streaming engine. The streaming engine notifies the Classifier to perform the classification. The Classifier will notify the UP Manager about the performed classification and pass the CLOBs to the Observer. The CLOBs will then be received by the Observer that will need to wait for information from the CMI. The CMI sends the information describing the result of the Protocol Parser and the Pattern Matcher to the Classifier. The Classifier informs the UP Manager and sends the CLOB to the Observer. The UP Manager then instructs the Observer to publish the CLOBs to the Rule Base. The Rule Base is executed on the CLOBs and the result is communicated to the UP Manager. The CLOBs and related Rule Base state are stored in the Handle. The UP Manager provides the result of the rule base check to the CMI that then decides to allow or to drop the connection. The CMI generates a log message and instructs the streaming engine to forward the packets to the outbound interface. Content Awareness (CTNT) - is a new blade introduced in R80.10 as part of the new Unified Access Control Policy. Using Content Awareness blade as part of Firewall policy allows the administrator to enforce the Security Policy based on the content of the traffic by identifying files and its content. Content Awareness restricts the Data Types that users can upload or download.Content Awareness can be used together with Application Control to enforce more interesting scenarios (e.g. identify which files are uploaded to DropBox). References SecureKnowledge: SecureXL SecureKnowledge: NAT Templates SecureKnowledge: VPN Core SecureKnowledge: CoreXL SecureKnowledge: CoreXL Dynamic Dispatcher in R77.30 / R80.10 and above SecureKnowledge: Application Control SecureKnowledge: URL Filtering SecureKnowledge: Content Awareness (CTNT) SecureKnowledge: IPS SecureKnowledge: Anti-Bot and Anti-Virus SecureKnowledge: Threat Emulation SecureKnowledge: Best Practices - Security Gateway Performance SecureKnowledge: MultiCore Support for IPsec VPN in R80.10 and above Download Center: R80.10 Next Generation Threat Prevention PlatformsDownload Center: R77 Security Gateway Packet FlowDownload Center: R77 Security Gateway ArchitectureSupport Center: Check Point Security Gateway Architecture and Packet Flow Checkmates: Check Point Threat Prevention Packet Flow and Architecture Checkmates: fw monitor inspection point e or E Infinity NGTP architecture Security Gateway Packet Flow and Acceleration - with Diagrams R80.x Security Gateway Architecture (Content Inspection) Questions and Answers Q: Why this diagram with SecureXL and CoreXL?A: I dared to map both worlds of CoreXL and SecureXL in a diangram. This is only possible to a limited extent, as these are different technologies. It's really an impossible mission. Why!- CoreXL is a mechanism to assign, balance and manage CPU cores. CoreXL SND makes a decision to "stick" particular connection going through to a specific FWK instance.- SecureXL certain connections could avoid FW path partially (packet acceleration) or completely (acceleration with templates) Q: Why both technologies in one flowchart?A: There are both technologies that play hand in hand. The two illustrations become problematic, e.g. in the Medium Path. Q: Why in the Medium Path?A: Here, the packet-oriented part (SecureXL) cannot be mapped with the connection-based part (CoreXL). Therefore, the following note from an new Check Point article from Valeri Loukine (Security Gateway Packet Flow and Acceleration - with Diagrams - 08-07-2018) and original article from Moti Sagey (Check Point Threat Prevention Packet Flow and Architecture - 04-25-2017) :When Medium Path is available, TCP handshake is fully accelerated with SecureXL. Rulebase match is achieved for the first packet through an existing connection acceleration template. SYN-ACK and ACK packets are also fully accelerated. However, once data starts flowing, to stream it for Content Inspection, the packets will be now handled by a FWK instance. Any packets containing data will be sent to FWK for data extraction to build the data stream. RST, FIN and FIN-ACK packets once again are only handled by SecureXL as they do not contain any data that needs to be streamed. Q: What is the point of this article?A: To create an overview of both worlds with regard to the following innovations in R80.x:- new fw monitor inspection points in R80 (e and E)- new MultiCore VPN with dispatcher- new UP Manager in R80 Q: Why is there the designation "Logical Packet Flow"? A: Since the logical flow in the overview differs from the real flow. For example, the medium path is only a single-logical representation of the real path. This was necessary to map all three paths (F2F, SXL, PXL) in one image. That is why the name "Logical Packet Flow". Q: What's the next step? A: I'm thinking about how to make the overview even better. Q: Wording? A: It was important for me that the right terms from Check Point were used. Many documents on the Internet use the terms incorrectly. Therefore I am grateful to everyone who still finds wording errors here. Q: What's the GA version? A: This version has approved by Check Point representative, and we agreed that this should be the final version. Versions Version R80.40: 1.4a - update - automatically changes the number of CoreXL SNDs and Firewall instances and the Multi-Queue (02.09.2019) 1.4b - update - http/2 support (03.09.2019)Version R80.30: 1.3a - update R80.30 managment core ( 25.07.2019 ) 1.3b - update R80.30 https SNI (28.07.2019)1.3c - update R80.20 new async flowchart (15.08.2019)1.3d - update R80.20 packet reinjection (20.08.2019) Version R80.20: 1.2a - article update to R80.20 (16.11.2018)1.2b - update inspection points id, iD and more (19.11.2018)1.2c - update maximal number of CoreXL IPv4 FW instances (20.11.2018)1.2d - update R80.20 new functions (05.11.2018)1.2e - bug fix (06.01.2019)1.2f - update fw monitor inspection points ie/ IE (23.01.2019)1.2g - update sk 151114 VPN+SecureXL (20.04.2019)1.2h - update fw monitor inspection points (10.07.2019) Version R80.10: 1.1b - final GA version (08.08.2018)1.1c - change words to new R80 terms (08.08.2018)1.1d - correct a mistak with SXL and "Accelerated path" (09.08.2018)1.1e - bug fixed (29.08.2018)1.1f - QoS (24.09.2018)1.1g - correct a mistak in pdf (26.09.2018)1.1h - add PSLXL and CPASXL path in R80.20 (27.09.2018)1.1i - add "Medium Streaming Path" and "Inline Streaming Path" in R80.20 (28.09.2018)1.1j - add "new R80.20 chain modules" (22.10.2018)1.1k - bug fix chain modules (04.11.2018)1.1l - add "chaptures" (10.11.2018)1.1m - add R80.20 fw monitor inspection points "oe" and "OE" (17.12.2018) EA Version: 1.0a - final version (28.07.2018)1.0c - change colors (28.07.2018)1.0d - add content inspection text (29.07.2018)1.0e - add content inspection drawing (29.07.2018)1.0f - update links (29.07.2018)1.0g - update content inspection drawing flows and action (30.07.2018)1.0h - change SecureXL flow (30.07.2018)1.0i - correct SecureXL packet flow (01.08.2018)1.0j - correct SecureXL names and correct "fw monitor inspection points" (02.08.2018)1.0k - add new article "Security Gateway Packet Flow and Acceleration - with Diagrams" from 06.08.2018 to "References and links" (06.08.2018)1.0l - add "Questions and Answers" (07.08.2018) Copyright by Heiko Ankenbrand 1994 - 2019

Just had a fun geeky conversation with Dameon Welch Abernathy (AKA Phoneboy) Jony Fischbein , Jeff Schwartz and Michael Poublon (over 100 accumulated years of experience in Check Point products) , on what are our favorite & most useful commands in a Check Point environment.Below are my 3 , plz add yours in the comments (we will do a poll for the top 5 after getting your feedback ... ). 1) fw ctl zdebug drop used to quickly see all dropped connections and more importantly the reason (e.g. anti-spoofing, IPS , FW rule , ....) 2) cpstat fwquickly see stats of number of connections (accepted,denied,logged) with a breakdownif the FW was under a high load i would usually run " watch --interval=1 'cpstat fw' " (would see a real-time to see the interface that is causing this) 3) fw tab -s -t connections allowed me to quickly see how much load is (and was i.e "peak" ) on the FW that's it (i have more , but i want to hear yours ...)plz add yours in the comments (we will do a poll for the top 5 after getting your feedback ... )

R80.20, part of the Check Point Infinity architecture, delivers the most innovative and effective security that keeps our customers protected against large scale, fifth generation cyber threats.The release contains innovations and significant improvements in:Gateway performanceAdvanced Threat PreventionCloud Security Access policy Consolidated network and endpoint management capabilitiesAnd much more This release is initially recommended for customers who are interested in implementing the new features. We will make it the default version (widely recommended) after significant adoption and make it available in the 'Showing Recommended Packages' section in the CPUSE tab in Gaia portal. Performance Enhancements MorePerformance EnhancementsHTTPS Inspection performance improvementsSession rate improvements on high-end appliances (13000, 15000, 21000 & 23000 Security Gateway models).Acceleration remains active during policy installation, no impact on Security Gateway performance.VSX GatewaysSignificant boost to Virtual Systems performance, utilizing up to 32 CoreXL FW instances for each Virtual System.Dynamic Dispatcher - Packets are processed by different FW worker (FWK) instances based on the current instance load.Changes in the number of FW worker instances (FWK) in a VSLS setup do not require downtime.SecureXL Penalty Box supports the contexts of each Virtual System, see sk74520. Significant Improvements & New Features MoreAdvanced Threat PreventionEnhanced configuration and monitor abilities for Mail Transfer Agent (MTA) in SmartConsole for handling malicious mails.Configuration of ICAP Server with Threat Emulation and Anti-Virus Deep Scan in SmartConsole.Automatic download of IPS updates by the Security Gateway.SmartConsole support for multiple Threat Emulation Private Cloud Appliances.SmartConsole support for blocking archives containing prohibited file types.Threat ExtractionFull ClusterXL HA synchronization, access to the original files is available after a failover.Support for external storage.Advanced Threat Prevention Indicators (IoC) APIManagement API support for Advanced Threat Prevention Indicators (IoC).Add, delete, and view indicators through the management API.Advanced Threat Prevention LayersSupport layer sharing within Advanced Threat Prevention policy.Support setting different administrator permissions per Advanced Threat Prevention layer.MTA (Mail Transfer Agent)MTA monitoring, e-mails history views and statistics, current e-mails queue status and actions performed on e-mails in queue.MTA configuration enhancementsSetting a domain object as next hop.Ability to create an access rule to allow SMTP traffic to a Security Gateway.Create a dedicated Advanced Threat Prevention rule for MTA.MTA enforcement enhancementsReplacing malicious links in an email with a configurable template.Configurable format for textual attachments replacement.Ability to add a customized text to malicious e-mails' body or subject.Tagging malicious-mails using X-headerSending a copy of the malicious e-mail to a predefined recipients listImprovements in policy installation performance on R80.10 and above Security Gateways with IPSPerformance impact of "Suspicious Mail Activity" protection in Anti-Bot was changed to "High" and is now off by defaultCloudGuard IaaS EnhancementsAutomated Security Transit VPC in Amazon Web Services (AWS) - Automatically deploy and maintain secured scalable architecture in Amazon Web Services.Integration with Google Cloud Platform.Integration with Cisco ISE.Integration with Nuage Networks.Automatic license management with the CloudGuard IaaS Central Licensing utility.Monitoring capabilities integrated into SmartView.Data center objects can now be used in access policy rules installed on 41000, 44000, 61000 and 64000 Scalable Platforms.Access PolicyUpdatable Objects – a new type of network objects that represent an external service such as Office 365, Amazon Web Services, Azure GEO locations and more, and can be used in the Source and Destination columns of an Access Control policy. These objects are dynamically updated and kept up-to-date by the Security Gateway without the need to install a policy.Wildcard network object in Access Control that represents a series of IP addresses that are not sequential.Only for Multi-Domain Server: Support for scheduled policy installation with cross-Domain installation targets (Security Gateways or Policy Packages).Rule Base performance improvements, for enhanced Rule Base navigation and scrolling.Global VPN Communities (previously supported in R77.30).Support for using NAT64 and NAT46 objects in Access Control policy.Security Management Server can securely connect to Active Directory through a Security Gateway, if the Security Management Server has no connectivity to the Active Directory environment and the Security Gateway does.Identity AwarenessIdentity Tags support the use of tags defined by an external source to enforce users, groups or machines in Access Roles matching.Improved SSO Transparent Kerberos Authentication for Identity Agent, LDAP groups are extracted from the Kerberos ticket.Two Factor Authentication for Browser-Based Authentication (support for RADIUS challenge/response in Captive Portal and RSA SecurID next Token/Next PIN mode).Identity CollectorSupport for Syslog Messages - ability to extract identities from syslog notifications.Support for NetIQ eDirectory LDAP Servers.Additional filter options - "Filter per Security Gateway" and "Filter by domain".Improvements and stability fixes related to Identity Collector and Web API.New configuration container for Terminal Servers Identity Agents.Active Directory cross-forest trust support for Terminal Servers Agent.Identity Agent automatic reconnection to prioritized PDP gateways.Security Management Server can securely connect to Active Directory via a Security Gateway if the Security Management Server has no connectivity to the Active Directory environmentHTTPS InspectionHardware Security Module (HSM) support – outbound HTTPS Inspection stores the SSL keys and certificates on a third party dedicated applianceAdditional ciphers supports for HTTPS Inspection (for more information, see sk104562)Mirror and DecryptDecryption and clone of HTTP and HTTPS trafficForwarding traffic to a designated interface for mirroring purposesClusteringNew CCP Unicast - a new mode in which a cluster member sends the CCP packets to the unicast address of a peer memberNew Automatic CCP mode - CCP mode is adaptive to network changes, Unicast, Multicast or Broadcast modes are automatically applied according to network stateEnhanced cluster monitoring capabilitiesEnhanced cluster statistics and debugging capabilitiesEnhanced Active/Backup BondSupport for more topologies for Synchronization Network over Bond interfacesImproved cluster synchronization and policy installation mechanismNew grace mechanism for cluster failover for improved stabilityNew cluster commands in Gaia ClishImproved clustering infrastructure for RouteD (Dynamic Routing) communicationGaia OSUpgraded Linux kernel (3.10) - applies to Security Management Server onlyNew file system (xfs)More than 2TB support per a single storage deviceEnlarged systems storage (up to 48TB)I/O related performance improvementsSupport of new system tools for debugging, monitoring and configuring the systemiotop (provides I/O runtime statistics)lsusb (provides information about all devices connected to USB)lshw (provides detailed information about all hardware)lsscsi (provides information about storage)ps (new version, more counters)top (new version, more counters)iostat (new version, more counters)Advanced Routing:Allow AS-in-countIPv6 MD5 for BGPIPv4 and IPv6 OSPF multiple instancesBidirectional Forwarding Detection (BFD) for gateways and VSX, including IP Reachability detection and BFD MultihopOSPFv2 HMAC-SHA authentication (replaces OSPFv2 MD5 authentication)ICAP ClientIntegrated ICAP Client functionality Security Management Enhancements MoreSmartConsoleSmartConsole Accessibility featuresKeyboard navigation - ability to use the keyboard alone to navigate between the different SmartConsole fieldsImproved experience for the visually impaired, color invert for all SmartConsole windowsRequired fields are highlightedMultiple simultaneous sessions in SmartConsole. One administrator can publish or discard several SmartConsole private sessions, independently of the other sessions.Logging and MonitoringLog Exporter - an easy and secure method to export Check Point logs over Syslog to any SIEM vendor using standard protocols and formatsAbility to export logs directly from a Security Gateway (previously supported in R77.30)Unified logs for Security Gateway, SandBlast Agent and SandBlast Mobile for simplified log investigationEnhanced SmartView in browser:Log viewer with log card, column profile and statisticsExport logs with custom or all fieldsAutomatic-refresh for viewsRelative time frame supportImproved log viewer with cards, profiles, statistics and filtersI18N support for 6 languages (English, French, Spanish, Japanese, Chinese, Russian)Accessibility support - keyboard navigation and high contrast themeSmartProvisioningIntegration with SmartProvisioning (previously supported in R77.30)Support for the 1400 series appliancesAdministrators can now use SmartProvisioning in parallel with SmartConsoleMobile AccessSupport for reCaptcha, keep abusive automated software activities from interfering with regular portal operationsSupport for One Time Password (OTP) without any hardware tokensEndpoint Security Management ServerEndpoint Security Server is now part of the main train.Support for SandBlast Agent, Anti-Exploit and Behavioral Guard policiesSandBlast Agent push operation to move/restore files from quarantineDirectory Scanner initial scan and full rescan takes significantly less timeStability and performance enhancements for Automatic Synchronization (High Availability)Endpoint Security Management features that are included in R77.30.03:Management of new Software Blades:SandBlast Agent Anti-BotSandBlast Agent Threat Emulation and Anti-ExploitSandBlast Agent Forensics and Anti-RansomwareCapsule DocsNew features in existing Software Blades:Full Disk EncryptionOffline ModeSelf Help PortalXTS-AES EncryptionNew options for the Trusted Platform Module (TPM)New options for managing Pre-Boot UsersMedia Encryption & Port ProtectionNew options to configure encrypted containerOptical Media ScanAnti-Malware:Web ProtectionAdvanced DisinfectionComplianceUser can create custom best practices based on scriptsSupport for 35 regulations including General Data Protection Regulation (GDPR)Download and release information here: Check Point R80.20

Introduction This document describes the content inspection in a Check Point R80.10 and above gateways. Context Management Infrastructure (CMI) is the "brain" of the content inspection and use more different modules (CMI Loader, PSL vs. PXL, Protocol Parsers, Pattern Matcher, Protections and new in R80.10 NGTP Architecture) for content inspection. Chapter Architecture:R80.x Security Gateway Architecture (Logical Packet Flow)R80.x Security Gateway Architecture (Content Inspection) R80.x Security Gateway Architecture (Acceleration Card Offloading) R80.x Ports Used for Communication by Various Check Point Modules Performance Tuning:R80.x Performance Tuning Tip - AES-NI R80.x Performance Tuning Tip - SMT (Hyper Threading) R80.x Performance Tuning Tip - Multi Queue R80.x Performance Tuning Tip - Connection Table R80.x Performance Tuning Tip - fw monitorR80.x Performance Tuning Tip - TCPDUMP vs. CPPCAP R80.x Performance Tuning Tip – DDoS „fw sam“ vs. „fwaccel dos“ Cheat Sheet:R80.x cheat sheet - fw monitor R80.x cheat sheet - ClusterXL More interesting articles:Article list (Heiko Ankenbrand) What’s new in R80.10 UP Manager Unified policys NGTP Architecture Content Awareness (CTNT) Context Management Infrastructure This picture should show a block overview and not all components are included. It is intended for explanatory purposes only. Context Management Infrastructure - The Context Management Infrastructure (CMI) is the "brain" of the content inspection. It coordinates different components, decides which protections should run on a certain packet, decides the final action to be performed on the packet and issues an event log.CMI separates parsers and protections. Protection is a set of signatures or/and handlers, where Signature - a malicious pattern that is searched for Handler - INSPECT code that performs more complex inspection CMI is a way to connect and manage parsers and protections. Since they are separated, protections can be added in updates, while performance does not depend on the number of active protections. Protections are usually written per protocol contexts - they get the data from the contexts and validate it against relevant signatures. Based on the policy, the 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. CMI Loader - collects signatures from multiple sources (e.g. IPS, Application Control,...) and compiles them together into unified Pattern Matchers (PM). 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. Streaming serves - an important function in the NGTP software architecture. The streaming process creates an ordered packet stream and directly performs a number of security functions on the stream. NGTP can assemble packets into a stream in two ways, passive or active, depending on the nature of the traffic. Each has advantages and disadvantages. The passive mode gives little opportunity for modifying the traffic stream. In contrast, the active mode can modify the connection. Active mode essentially proxies the TCP connection and is necessary when performing HTTPS inspection. Active streaming also facilitates timing and buffering when inspecting content such as large files. Keeping the goals of integrated, high security effectiveness and performance in mind, Check Point chose to provide the option to do passive and active streaming, which provides the best balance of security and optimized performance based on actual usage conditions. Passive Streaming Library (PSL) PSL - Packets may arrive out of order or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with Passive Streaming Library (PSL) technology. PSL is an infrastructure layer, which provides stream reassembly for TCP connections. The gateway makes sure that TCP data seen by the destination system is the same as seen by code above PSL.This layer handles packet reordering, congestion handling and is responsible for various security aspects of the TCP layer such as handling payload overlaps, some DoS attacks and others. The PSL layer is capable of receiving packets from the firewall chain and from SecureXL module. The PSL layer serves as a middleman between the various security applications and the network packets. It provides the applications with a coherent stream of data to work with, free of various network problems or attacks The PSL infrastructure is wrapped with well defined APIs called the Unified Streaming APIs which are used by the applications to register and access streamed data For more details - how a connection comes into the PSL modul - see article:R80.x Security Gateway Architecture (Logical Packet Flow) PSL is visible in the input and output fw monitor chain as "passive streaming (pass_str)". PXL vs. PSLXL - Technology name for combination of SecureXL and PSL. PXL was renamed to PSLXL in R80.20. This is from my point of view the politically correct better term. QXL - Technology name for combination of SecureXL and QoS (R77.10 and above). This has no direct association with PXL. It is used exclusively for QoS. But also here it is possible to use the QoS path in combination with PSL. This picture shows an example of http. PSL/ Protocol Parsers and Pattern Matcher include http, SMTP, DNS, IMAP, Citrix, and many others protocols. 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. 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. The content is normalized before inspection to thwart attempts to evade detection. The protocol parser detects and prevents protocol anomalies. The parsers main purpose is to extract ‘contexts’ from the streams to prepare for the next level of inspection. 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. 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. The Pattern Matcher is a fundamental engine within the enforcement architecture. Pattern Matcher quickly identifies harmless packets, common signatures inmalicious packets, and does a second level analysis to reduce false positives. Pattern Matcher engine provides the ability to find regular expressions on a stream of data using 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 it passes the connection to the second tier to do a second level analysis, thus increasing the confidence that there is indeed an attack. The first tier will never decide on it’s 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 INSPECTv2 technology when some patterns are matched. 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. Content Security Policy and Inspection - When enabling advanced security features like Application Control, URL Filtering, Content Awareness, IPS, Anti-Bot, Antivirus and SandBlast Threat Emulation (sandboxing); the security gateway inspects content using the contexts derived from the protocol parser. The gateway’s local cache is augmented with real-time cloud updates and zero-day threat protection. During policy installation, signatures are compiled into Pattern Matchers (PM) with one PM for each context such as URL, Host header etc. The PM quickly identifies harmless packets, common signatures in malicious packets, and if needed, does a second-level analysis to reduce false positives. 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, it passes the connection to the second tier to do a second level analysis. This increases confidence there is indeed an attack. It is worth noting that in some cases, the determination is a simple comparison. For instance, minimal processing time is needed to check an IP, a URL, a domain, or a file checksum against a known list. These comparisons are done first. 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. 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 cloud service is checked. URL Filtering is another example where if the context is not found in cache, then the cloud service is checked. URL categorization occurs mostly in the kernel. When not found in the local cache, the cloud service is checked and the result is then cached in the kernel.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 cloud service is checked and the cache is updated with the result. URL Filtering checks for the URL category in the local cache. If not found, then the cloud service is checked. The cache is then updated with the result. Threat Emulation is a special case where the Pattern Matcher can be bypassed. If the checksum of a file is not cached, then the sandbox needs to receive a complete file. The protocol parser extracts the file and sends the file to our cloud service for processing where compute, disk and memory are virtually unlimited. If the protocol requires immediate delivery as in the case of HTTP/S, we offer user agents to notify the user and deliver only safe content to the user while the emulation happens in the background. Newly discovered threats are added to the local cache and sent to the cloud database to protect other Check Point platforms. 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. 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. Picture from Check Point article. 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 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. Active Streaming (CPAS) Active Streaming (CPAS) - Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.). An application is register to CPAS when a connection start and supply callbacks for event handler and read handler. Several protocols uses CPAS, for example: Client Authentication, VoIP (SIP, Skinny/SCCP, H.323, etc.), Data Leak Prevention (DLP) blade, Security Servers processes, etc. In some scenarios, HTTP is also using CPAS, when IPS Web Intelligence protections are enabled. As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F. CPAS works through the F2F path in R80.10 and R77.30. Now CPASXL is offered in SecureXL path in R80.20. This should lead to a higher performance. General overview: CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.) An application is register to CPAS when a connection start and supply callbacks for event handler and read handler. On each packet, CPAS send the application the packet data with cpas_read, allow the application to change the data as it like, and send the data forward with cpas_write. As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F. Since all the packet will pass SecureXL (even if they were F2F) it need to offload the connection to SecureXL. The offload is done on the outbound, without CPAS, the offload will occur when the SYN packet leave to the server, because CPAS break the connection, the first outbound will occur on the SYN-ACK that is sent to the Client CPAS does not synchronize connection between cluster members. If a failover occur and the connection was handled by CPAS then the connection will terminate. The only exception is VOIP connection. CPAS is visible in the input fw monitor chain as "TCP streaming (cpas)" and in the output chain as "TCP streaming (cpas)" and "TCP streaming post VM (cpas)". Active Streaming – https: With PSL, connection that is encrypted with SSL (TLS) was not supported, the reason for this is that the encryption keys are known only to the Client and Server since they are the one that initiated the connection (preformed the SSL handshake), because of this we couldn’t get the data out of the packet and the application couldn’t scan it for malicious information. CPAS plays the rule of “man in the middle”, because of this, it can intercept the SSL handshake and change the keys so he will be able to understand the encryption. The Client preform an SSL handshake with the gateway (thinking it is the Server) while the Server preform SSL handshake with the gateway (thinking he is the Client). The gateway have both keys and he’s able to open the encryption, check the packet and re-encrypt the packet with the corresponding keys. In order to encrypt / decrypt the SSL connection, CPAS add another layer before the application queue. The new layer will send the packet to the SSL engine for decryption/encryption and then resume the normal flow. Active Streaming – https content step by step: Packets of SSL handshake are passed to the SSL engine to exchange keys. When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets. When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS. The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue. The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server). HTTPS - Inspection Check Point's Active Streaming infrastructure (CPAS) supplies applications above it the means of handling the TCP data stream, without having to care about the implementation below (e.g. 3 way handshake enforcement, retransmissions, checksums, etc.). CPAS, as opposed to PSL, supplies means of modifying the data passed, such as enabling the changing of data, removing parts of it, and even injecting completely new data. These capabilities where once achieved through the Security Servers. This included folding the connection to the firewall and having context switches to and from user-space. Since CPAS is implemented completely in the kernel, there is no more need for context switches, hence a performance increase. In order to inspect HTTPS encrypted traffic, we implement man-in-the-middle on the SSL protocol. The Security Gateway poses as a client with the server, and as a server with the client (for this purpose the Security Gateway creates a fake server certificate with all fields equals to the origin except the public key, issuer, issuer signature and CRL DP). Thus the Security Gateway creates two different sets of keys: one (CF key) to encrypt/decrypt client side traffic, another (SF key) to encrypt/decrypt server side traffic.The HTTPS Inspection RuleBase runs mostly in the kernel. The enforcement is done completely in the kernel, while policy installation is done partially in the kernel and partially in user space. There is no dedicated process. SSL Inspection requires CPAS streaming to be initialized. CPAS (active) streaming is a much more resource-consuming infrastructure than PSL (passive) streaming, therefore we try to avoid CPAS streaming initialization, as soon as possible. In order to avoid CPAS streaming initialization, when we do not really need it, we run HTTPS Inspection rulebase twice on the same connection. The first time it is run on the SYN packet, as part of the Security Rulebase execution. Thus, if HTTPS Inspection Rulebase returns NO MATCH, then SSL Inspection will not influence the steaming type decision (PSL will be used in most cases), but if HTTPS Inspection Rulebase returns MATCH/POSSIBLE MATCH (we cannot make final decision), then active (CPAS) streaming will be initialized. The second time it is run on the Client Hello packet (https_inspection_exe_rulebase function). This time, we make the final match (URL is taken from DN cache or from previous CONNECT request), calculate the action that should be performed (according to action from the matched rule, blades defined on the matched rule and exceptions) and perform the action (INSPECT/BYPASS) on the connection.Connection could be held during HTTPS Inspection rulebase execution due to Identity Awareness (IDA) or RAD/URL Filtering request for a sync execution. HTTPS Inspection supports the following software blades: Application Control, URL Filtering, IPS, Anti-Virus, Anti-Bot, Threat Emulation, Data Loss Prevention (DLP). Unified policies Check Point R80.10, part of Check Point Infinity, takes security to new levels, merging security into a single system which enables administrators to easily identify security risks across the organization. Unified policies in R80.10 gateways enables organizations to translate their security definitions into a simple set of rules, which then streamline policy administration and enforcement throughout the organization. Policy layers provide the ability to separate the policy into independent segments, which can be independently managed and automated. In the kernel the rule base is represented as a database table. This enables the gateway security policy to automatically adapt as dynamic objects change, providing simple automated security across physical, virtual and cloud environments. NGTP Architecture - 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 contexts and then security modules 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 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 and devices. When possible, active content is removed from files which are then sent on to the user while the emulation is done. UP Manager - The UP Manager controls all interactions of the components and interfaces with the Context Management Infrastructure (CMI) Loader, the traffic director of the CMI. The UP Manager also has a list of Classifiers that have registered for “first packets” and uses a bitmap to instruct the UP Classifier to execute these Classifier Apps to run on the packet. The “first packets” arrive directly from the CMI. Parsing of the protocol and streaming are not needed in this stage of the connection. For “first packets” the UP Manager executes the rule base. Classifier - When the “first packet” rule base check is complete Classifiers initiate streaming for subsequent packets in the session. The “first packet” rule base check identifies a list of rules that possibly may match and a list of classifier objects (CLOBs) that are required to complete the rule base matching process. The Classifier reads this list and generates the required CLOBs to complete the rule base matching. Each Classifier App executes on the packet and tells the result of the CLOB to the UP Manager. The CMI then tells the Protocol Parser to enable streaming. In some cases Classifier Apps do not require streaming, e.g. the first packet information is sufficient. Then the rule base decision can be done on the first packet. Dynamic Objects Domain Objects Only the firewall is enabled On subsequent packets the Classifier can be contacted directly from the CMI using the CMI Loader infrastructure, e.g. when the Pattern Matcher has found a match it informs the CMI it has found application xyz. The CMI Loader passes this information to the Classifier. The Classifier runs the Classification Apps to generate CLOBs required for Application Control and sends the CLOBs to the Observer. Observer - The Observer decides if enough information is known to publish a CLOB to the security policy. CLOBs are observed in the context of their transaction and the connection that the transaction belongs to. The Observer may request more CLOBs for a dedicated packet from the Classifier or decides that it has sufficient information about the packet to execute the rule base on the CLOB, e.g. if a file type is needed for Content Awareness and the gateway hasn’t yet received the S2C response containing the file. Executing the rule base on a CLOB is called “publishing a CLOB”. The Observer may wait to receive more CLOBs that belong to the same transaction before publishing the CLOBs. Security Policy - The Security Policy receives the CLOB published by the Observer. The CLOB includes a description of the Blade it belongs to so that matching can be performed on a column basis. The security policy saves the current state on the transaction Handle; either to continue the inspection or final match. The first packets are received directly from the UP Manager. Subsequent packets are received by the rule base from the Observer. Handle - Each connection may consist of several transactions. Each transaction has a Handle. Each Handle contains a list of published CLOBs. The Handle holds the state of the security policy matching process. The Handle infrastructure component stores the rule base matching state related information. Subsequent Packets - Subsequent packets are handled by the streaming engine. The streaming engine notifies the Classifier to perform the classification. The Classifier will notify the UP Manager about the performed classification and pass the CLOBs to the Observer. The CLOBs will then be received by the Observer that will need to wait for information from the CMI. The CMI sends the information describing the result of the Protocol Parser and the Pattern Matcher to the Classifier. The Classifier informs the UP Manager and sends the CLOB to the Observer. The UP Manager then instructs the Observer to publish the CLOBs to the Rule Base.The Rule Base is executed on the CLOBs and the result is communicated to the UP Manager. The CLOBs and related Rule Base state are stored in the Handle. The UP Manager provides the result of the rule base check to the CMI that then decides to allow or to drop the connection. The CMI generates a log message and instructs the streaming engine to forward the packets to the outbound interface. R80.10 unified access control policy - defines firewall, application control, URL filtering, mobile access and now content awareness in one policy rule. Content awareness adds visibility and control over data using data types based on content, file types and direction as the content transverses the network. In R80.10 you can also group interfaces of gateways into security zones in source and destination definitions. Core IPS protections are included in the access control policy while other IPS protections are now included in the Threat Prevention policy unifying IPS, Antivirus, Anti-Bot, Threat Extraction, and Threat Emulation into one threat prevention profile. Likewise the threat prevention policy can include multiple profiles for each security gateway to apply more granular Threat Prevention policies. Layers in the R80.10 policy are a new way to organize security. A policy can have one or more layers as its building blocks. You can use combinations of Ordered Layers, Inline Layers, and Domain Layers (in Multi-Domain environments). Build a rule base with layers, each with a set of the security rules. Layers are inspected in the order in which they are defined, giving control over the rule base flow and precedence of security functionality. If an "Accept" action is done in a layer, inspection continues in the next layer. Sub-Policies are sets of rules that you attach to specific rules. If the rule is matched, inspection continues in the sub-policy attached to the rule. If the rule is not matched, the sub-policy is skipped. For example, a sub-policy can manage a network segment or branch office. Unified policy - In R80.10 the unified policy classifies subsequent packets against the column definitions until enough information is known to identify the traffic. Like column-based rule matching as more is known about the connection, then rules are eliminated from the matched rules array. Example classification objects are application, access role source, access role destination, content and file. Applications and Recommended Services- We have seen how R80.10 Service objects and application signatures are combined. Likewise, R80.10 applications now include recommended services such as HTTP and HTTPS in the application definition simplifying the unified policy configuration. For instance the R80.10 Facebook application definition includes the Web services where it is common to see Facebook traffic; HTTP/S over port 80/443 and HTTP/S proxy connections over port 8080. In the UI you can see the services included in the application definition. Content Awareness Content Awareness - (CTNT) is a new blade introduced in R80.10 as part of the new Unified Access Control Policy. Using Content Awareness blade as part of Firewall policy allows the administrator to enforce the Security Policy based on the content of the traffic by identifying files and its content. Content Awareness restricts the Data Types that users can upload or download. Content Awareness can be used together with Application Control to enforce more interesting scenarios (e.g. identify which files are uploaded to DropBox). During policy installation, the CMI Loader collects signatures from multiple sources (e.g. IPS, CTNT, APPI, ...) and compiles them together into unified Pattern Matchers (PM) (one for each context - such as URL, Host header, etc.). Picture from Content Awareness SK. The CMI process calls for Content Awareness blade for install policy process: Read data types and other settings information retrieved from the Security Management server. Registered to FileApp contexts. Load all Data Types signatures and CPcodes into CMI. Get the latest list of supported file types. Download all policy information to the kernel. Afterwards, FileApp parser updates the File Signatures (file type identification method) to its latest version to support new file types. FileApp - is able to extract text from Microsoft Office 2007 and above files (.docx, .pptx, .xlsx, ...), .zip/.gzip and text files. For other file types (such as .pdf), FileApp sends the file to User Mode for extraction. Anti-Bot and Anti-Virus Malware detection (AntiBot and AntiVirus) - Check Point's comprehensive Threat Prevention solution offers a multi-layered, pre- and post-infection defence approach and a consolidated platform that enables enterprise security to deal with modern malware: Anti-Virus - Pre-infection detection and blocking of malware at the gateway. The Anti-Virus Software Blade is continuously updated from ThreatCloud. It detects and blocks malware by correlating multiple detection engines before users are affected. Anti-Bot - Post-infection detection of bots on hosts. Prevents bot damages by blocking bot C&C (Command and Control) communications. The Anti-Bot Software Blade is continuously updated from ThreatCloud, a collaborative network to fight cybercrime. Anti-Bot discovers infections by correlating multiple detection methods. AntiBot - A bot is malicious software that can invade your computer. There are many infection methods. These include opening attachments that exploit a vulnerability and accessing a web site that results in a malicious download. One bot can often create multiple threats. Bots are frequently used as part of Advanced Persistent Threats (APTs) where cyber criminals try to damage individuals or organizations. The Anti-Bot Software Blade detects and prevents these bot and botnet threats. A botnet is a collection of compromised and infected computers. The Anti-Bot Software Blade uses these procedures to identify bot infected computers: Identify the C&C addresses used by criminals to control bots - These web sites are constantly changing and new sites are added on an hourly basis. Bots can attempt to connect to thousands of potentially dangerous sites. It is a challenge to know which sites are legitimate and which are not. Identify the communication patterns used by each botnet family - These communication fingerprints are different for each family and can be used to identify a botnet family. Research is done for each botnet family to identify the unique language that it uses. There are thousands of existing different botnet families and new ones are constantly emerging. Identify bot behavior - Identify specified actions for a bot such as, when the computer sends spam or participates in DoS attacks. AntiVirus - Malware is a major threat to network operations that has become increasingly dangerous and sophisticated. Examples include worms, blended threats (combinations of malicious code and vulnerabilities for infection and dissemination) and Trojans. The Anti-Virus Software Blade scans incoming and outgoing files to detect and prevent these threats. It also gives pre-infection protection from malware contained in these files. The Anti-Virus Software Blade: Identifies malware in the organization using the ThreatSpect engine and ThreatCloud repository: Prevents malware infections from incoming malicious files types (Word, Excel, PowerPoint, PDF, etc.) in real-time. Incoming files are classified on the gateway and the result is then sent to the ThreatCloud repository for comparison against known malicious files, with almost no impact on performance. Prevents malware download from the internet by preventing access to sites that are known to be connected to malware. Accessed URLs are checked by the gateway's caching mechanisms or sent to the ThreatCloud repository to determine if they are permissible or not. If not, the attempt is stopped before any damage can take place. Uses the ThreatCloud repository to receive binary signature updates and query the repository for URL reputation and Anti-Virus classification. ThreadSpect Engine and ThreadCloud - The ThreatSpect engine is a unique multi-tiered engine that analyzes network traffic and correlates information across multiple layers to find bots and other malware. It combines information on remote operator hideouts, unique botnet (a collection of compromised computers) traffic patterns and behavior to identify thousands of different botnet families and outbreak types. Reputtion Layer - Analyzes the reputation of URLs, IP addresses and external domains that computers in the organization access. The engine searches for the known or suspicious activity, such as Command and Control (C&C).The Reputation layer classifies per connection: IP address - from handle first packet before security rule base. Only in kernel, not in the cloud. DNS - host from DNS request (for both TCP and UDP) URL - complete URL from the HTTP request After the discovery of bot infected machines, the Anti-Bot Software Blade blocks outbound communication to C&C sites based on the Rule Base. This classification has 3 stages: First, every URL is searched in the local database, located in $FWDIR/conf/urlrep.eng file that contains some malware data - commonly used signatures, URLs, and their related reputations.Local database is loaded to the kernel, and compiled to one Pattern Matcher (PM) that is executed on the incoming URLs to find a match.If the URL is found there, a response to the client is returned.If there is no match against local database, continue to next Step. RAD (Resource ADvisor) cache (for DNS and URL only), that gives answers to 99% of URL reputation requests. RAD (Resource ADvisor) service in the cloud (for DNS and URL only) If the URL was not found in the cache, a request is sent out to RAD and a response is returned (asynchrony) back to the client, and the relevant data is kept in the cache. Anti-Bot Resource Classification mode for DNS is overridden to "background" on the Security Gateway. These settings override the existing default settings in the SmartDashboard. The Resource Classification settings for Anti-Bot are now configurable from the Security Gateway using the malware_config file. Using the Security Gateway configuration file provides more granularity and divide classification to DNS, HTTP and SMTP. There are three values for each option: hold - for hold classification bg - for background classification policy - for classification according to Security policy The default values for HTTP and SMTP is policy, but for DNS the default is now background. Application Control The use of internet applications comes with risks that administrators must know about: Malware threats: Application use can open networks to threats from malware. Popular applications like Twitter, Facebook, and YouTube can cause users to download viruses unintentionally. File sharing can easily cause malware to be downloaded into your network. Bandwidth hogging: Applications that use a lot of bandwidth, for example, streaming media, can limit the bandwidth that is available for important business applications. Loss of Productivity: Employees can spend time on social networking and other applications that can seriously decrease business productivity. Employers do not know what employees are doing on the internet and how that really affects them. The Check Point Solution for Application Control Check Point's latest firewall innovation brings the industry's strongest application and identity control to organizations of all sizes. You can easily create policies which detect or block thousands of applications. Granular Application Control: Identify, allow, or block thousands of applications. This provides protection against the increasing threat vectors and malware introduced by internet applications. Application control and Custom applications signatures are kept in the Application Database (APP DB), based on two files, C and appi_custom_db.C, located on the Security Gateway. User defined URLs and HTTPS Inspection User defined URLs data is kept in the Security Gateway database. We integrated URL Filtering together with Application Control, and both features are set in the Application Control engine (Application Control) rulebase.URL Filtering is represented by a new CMI application client: URL Filtering. This client behaves like an Application Control client. It uses Application Control DB for metadata, but instead of using signatures, it uses the application detection engine (RAD) service. (RAD (Short for Resource Advisor) is responsible for the detection of Social Network widgets, e.g Mafia Wars).) URL Filtering Check Point's provied strongest URL Filtering, application and identity control to organizations of all sizes. You can easily create policies which detect or block thousands of applications and internet sites. The URL Filtering software blade uses a hosted categorization service (cloud-based categorization) that is being constantly updated to cope with the dynamic nature of the web. The Security Gateway is not required to download updates, the categorization database is not limited by the storage space on the Security Gateway, and customers receive the latest categorization to keep policies current. As requests are being sent to the cloud, responses are being cached locally on the Security Gateway so that subsequent requests for the same sites will not query the cloud, but will be answered by the local cache. In deployments of R75.20 URL Filtering, we have seen that more than 99% of requests are being met by the cache, providing customers with the most up-to-date categorization (with the cloud) on the one hand and minimal latency (as most requests are being met by the cache), on the other.When there are critical updates, for example, a previously benign site has been hacked and is now used to spread malware, the cache is invalidated and forced to retrieve updates from the cloud. Custom Applications, Sites, Categories and Groups -You can create applications, websites, categories and groups that are not in the Application and URL Filtering Database for use in the policy. Use these custom objects to create a Rule Base that meets your organization's requirements. It is also possible to contact Check Point to create customized application signatures that can be imported into the database. This file can contain, for example, a database with an organization's internal applications that are not necessarily web-based. URL Filtering - The URL Filtering blade uses a single user mode process called RAD ($FWDIR/bin/rad) to communicate with the URL Filtering service. The process is initiated once application control, or URL filtering blades, are active on the Security Gateway. Whenever RAD successfully categorizes a URL, it caches it in its kernel cache. The URL Filtering kernel cache holds the entire URL Family (i.e. all the URLs within the same host). Whenever there is a request for a new URL categorization, RAD sends to the categorization service only the host part of the URL and receives the entire URL family. The response is then cached for future use. Web categorization - You can select the Web categorization mode that is used for web site categorization: Background: requests are allowed until categorization is complete. When a request cannot be categorized with a cached response, an uncategorized response is received. Access to the site is allowed. In the background, the Check Point Web Service continues the categorization procedure. The response is then cached locally for future requests (default). This option reduces latency in the categorization procedure. Hold: requests are blocked until categorization is complete. When a request cannot be categorized with the cached responses, it remains blocked until the Check Point Web Service completes categorization. IPS Starting from R80, IPS Software Blade is part of Threat Prevention solution. Check Point IPS is an Intrusion Prevention System (IPS). IPS is a complete IPS cyber security solution, for comprehensive protection against malicious and unwanted network traffic, which focuses on application and server vulnerabilities, as well as in-the-wild attacks by exploit kits and malicious attackers. The IPS Software Blade delivers complete and proactive intrusion prevention. It delivers 1,000s of signatures, behavioral and preemptive protections. It gives another layer of security on top of Check Point firewall technology. IPS protects both clients and servers, and lets you control the network usage of certain applications. The hybrid IPS detection engine provides multiple defense layers which allows it excellent detection and prevention capabilities of known threats, and in many cases future attacks as well. It also allows unparalleled deployment and configuration flexibility and excellent performance. Elements of protection - included in IPS protection: Detection and prevention of specific known exploits. Detection and prevention of vulnerabilities, including both known and unknown exploit tools, for example protection from specific CVEs. Detection and prevention of protocol misuse which in many cases indicates malicious activity or potential threat. Examples of commonly manipulated protocols are HTTP, SMTP, POP, and IMAP. Detection and prevention of outbound malware communications. Detection and prevention of tunneling attempts. These attempts may indicate data leakage or attempts to circumvent other security measures such as web filtering. Detection, prevention or restriction of certain applications which, in many cases, are bandwidth consuming or may cause security threats to the network, such as Peer to Peer and Instant Messaging applications. Detection and prevention of generic attack types without any pre-defined signatures, such as Malicious Code Protector. Check Point constantly updates the library of protections to stay ahead of emerging threats.Capabilities of IPS - The unique capabilities of the Check Point IPS engine include: Clear, simple management interface. Reduced management overhead by using one management console for all Check Point products. Integrated management with SmartConsole. Easy navigation from business-level overview to a packet capture for a single attack. Up to 15 Gbps throughput with optimized security, and up to 2.5 Gbps throughput with all IPS protections activated. First security coverage for Microsoft and Adobe vulnerabilities. Resource throttling so that high IPS activity will not impact other blade functionality. Complete integration with Check Point configuration and monitoring tools in SmartConsole, to let you take immediate action based on IPS information. For example, some malware can be downloaded by a user unknowingly when he browses to a legitimate web site, also known as a drive-by-download. This malware can exploit a browser vulnerability to create a special HTTP response and sending it to the client. IPS can identify and block this type of attack even though the firewall may be configured to allow the HTTP traffic to pass. PS uses the CoreXL technology which leverages multi-core. Each firewall instance can run on a separate core and many instances can run in parallel. The IPS code runs in a monolithic part of the firewall kernel. Each such per-core instance runs firewall and IPS and Dispatchers are bound to a network interface using IRQ affinity. IPS use the 4 layers: Passive Streaming Library (PSL) Protocol Parsers Context Management Interface layer (CMI) Protections Based on the IPS policy, the 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 example, if the IPS policy is activating server protections only, then the HTTP parser will not analyze the server to client (S2C) traffic. When a protection is activated, it can decide whether the given packet or context is OK or not. It does not decide what to do with this packet. 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 (Prevent, Detect, Inactive) Exceptions either on traffic or on protection Bypass mode status (the software fail open capability) Troubleshooting mode status Are we protecting the internal network only or all traffic Threat Emulation (SandBlast) Threat Emulation (SandBlast) can protect your network against new malware, zero-day vulnerabilities and targeted attacks with Sandbox technoligies. SandBlast customers with Check Point gateway R77 or higher can offload Threat Emulation to a dedicated SandBlast Appliance (TEX) or ThreatCloud. Threat Emulation - gives networks the necessary protection against unknown threats in files that are downloaded from the Internet or attached to e-mails. When emulation is done on a file: The file is opened on more than one virtual computer with different operating system environments. The virtual computers are closely monitored for unusual and malicious behavior, such as an attempt to change registry keys or run an unauthorized process. Any malicious behavior is immediately logged and you can use Prevent mode to block the file from the internal network. The cryptographic hash of a new malicious file is saved to a database and the internal network is protected from that malware. Information about malicious files and malware is shared with the Check Point ThreatCloud (administrator can disable this) and helps protect all ThreatCloud users. Sandboxing: Inspect all incoming files to an organization and send them to a safe virtual environment Open the files in the virtual environment to see what would happen if someone inside of the organization would open this file Prevent the malicious files from entering the organization CPU-Level Emulation - Monitoring CPU buffer and finding exploits to preventing malware before it executes: New leading edge technology unique to Check Point Next generation of sandboxing to catch more malware No guesswork required, detection is definitive Not based on heuristics or statistics Resistant to evasions Fast and effective Supported on Threat Emulation appliances (TE100X, TE250X, TE1000X, TE2000X) OS-Level Emulation - is a Traditional sandboxing technology whit will give a very good emulation report. It is most times effective, but are susceptible to evasions and longer you emulate the file, the better catch rate you will get. It works by: Monitoring System Registry Monitoring Network Connections Monitoring File System Activity Monitoring System Processes SandBlast emulation on gateway components: DLPU - File arrives at the kernel and we decide whether we need to scan it or not (according to the policy). The file is sent to the correlating DLPU process instance in the user space. The DLPU process handles the file reassembly. Once DLPU finishes file reassembly, it is send it to TED (Threat Emulation Daemon). Threat Emulation Daemon (TED) - Receives the complete file and processes it through file type checks to understand if emulation is needed. Next steps: Checks cache if the file was already emulated. Checks system resources (CPU/Memory) to create an emulation queue if needed. Static analysis Executes emulation according to policy settings Collects forensics details from the VM activity agent Collects statistics of the emulation environment Local logging/reporting and shares data with ThreatCloud Handling Mode - While Threat Emulation processes the file, it can apply the following handling modes: Background - The connection over HTTP / SMTP is allowed and the file is sent to the destination even if the Threat Emulation analysis is not finished. Hold - A connection over HTTP / SMTP that must have emulation is blocked and Threat Emulation holds the file until the Threat Emulation analysis is finished (default minimum is 60 sec). Custom - Allows configuration of "Background" and "Hold" modes independently for HTTP and SMTP protocols. ThreatCloud: When sending files to the Check Point ThreatCloud: Security Gateway detects that a file was received from the Internet or an external network. The Security Gateway compares the cryptographic hash of the file with the database. Security Gateway encrypts the file and sends (over an SSL connection) to the ThreatCloud. Frontend servers at the ThreatCloud Pod perform Support Contract verification against Check Point User Center. ThreatCloud Pod transfers the file (over an SSL connection) to a Check Point Emulator located on a dedicated protected Check Point site. Check Point Emulators decrypts the file and runs emulation on the file. After this Check Point Emulator sends a report (over an SSL connection) to a ThreatCloud Pod, which saves it in the shared database. Afterward ThreatCloud Pod sends a report (over an SSL connection) to the customer's Security Gateway for the applicable action. Local Threat Emulation Appliance: When emulating files on the local Threat Emulation Appliance (TE100X, TE250X, TE1000X, TE2000X/HPP) installed on your network: The Local Emulation appliance receives the files for emulation. The Local Emulation appliance compares the cryptographic hash of the file with the database. The file is inspected in Threat Emulation engine, including static analysis, resource checking on the appliance to see that the appliance can accommodate the scanning, checking the metadata of the file for intelligence and then emulating the file in the sandbox environment. Afterward the file is emulated according to policy on the relevant OS. During the emulation, there are behaviour indicators that allow Threat Emulation to determine whether the file is malicious or benign. When the investigation ends, a verdict is returned to sending Security Gateway. Short excursion to the local emulaton: DLPU + DLP kernel module - The parsers (Web, Mail) whitch deeply inspect the connections for traffic. Afterwards the DLPU (DLP Kernel module), witch transfers the file parts to the DLPU daemon (one per CoerXL instance) and the DLPU process reassamble the file and write it to „$FWDIR/tmp/te“. Cache - The cache is very lightweight, but has an enormous positive effect on the performance. Static Analysis - The static analysis is composed of python processes, whitch is aimed on skipping emulation of files that we can be sure with very high level of confidence, that they don’t contain malware. It is relatively heavy in IO. Emulation (qemu) - The emulation ist he most recource intensive process in the system and runs the qemu based virtuel machines as well as the fake internet server (python). MTA The MTA can run on a SandBlast appliance or on a gatway (cluster). Traffic to the MTA can easily conntroled by the firewall or Sandblast appliance. The MTA works as next hop between Internet mail servers and internal Mail Server. It does not use PSL but works as a real MTA. A PostFix server receives and handles the emails. Emails are forwarded to the in.emaild.mta daemon, which parses the emails and passes the attachments to the scrubd or TED process, if needed. The scrubd or TED process returns the mail to the in.emaild.mta daemon. The in.emaild.mta daemon forwards the email to its destination. scrubd - The scrubd daemon pro-actively cleans potential threats from incoming documents (Threat Extraction). The scrubd process returns the Safe copy of the original threat. scrub_cp_file_convertd - Used to convert-to-PDF, or extract potentialy malicious content from various file formats. Parser in CoreXL FW Instance -> Postfix -> in.emaild.mta -> TED -> in.emaild.mta -> Postfix: More coming soon. R80.20 Falcon Acceleration Path Now we have three new acceleration path in R80.20 Falcon cards: Host Path - No acceleration connections (eg. local connections) and connections on now-AC interface. Buffer Path - HTTP request, HTTP response header and TSL handshakes Inline Path - HTTP response body (until 1 tier match) and TSL bulk encryption and decryption. More coming soon. Other Security Blades Coming soon: DLP References SecureKnowledge: Application Control SecureKnowledge: URL Filtering SecureKnowledge: Content Awareness (CTNT) SecureKnowledge: IPS SecureKnowledge: Anti-Bot and Anti-Virus SecureKnowledge: Threat Emulation SecureKnowledge: Threat Extraction SecureKnowledge: Check Point Active Streaming (CPAS) and Passive Streaming Layer (PSL)SecureKnowledge: HTTPS Inspection FAQ SecureKnowledge: Best Practices - Security Gateway PerformanceDownload Center: R80.10 Next Generation Threat Prevention PlatformsDownload Center: R77 Security Gateway Packet FlowDownload Center: R77 Security Gateway ArchitectureSupport Center: Check Point Security Gateway Architecture and Packet Flow Checkmates: Check Point Threat Prevention Packet Flow and ArchitectureCheckmates: Infinity NGTP architecture R80.x Security Gateway Architecture (Logical Packet Flow)Checkmates: R80.x Security Gateway Packet Flow and Acceleration - with Diagrams Versions EA Version: 0.1f - final version (08-15-2018)0.1g - add "https inspection" (08-15-2018)0.1h - add "Anti-Bot and Anti-Virus" +change flow colors (08-16-2018)0.1k - add more pictures (08-20-2018)0.1h - add "CPAS" (08-20-2018)0.1i - add "IPS, AC, URLF" (08-21-2018)0.1j - add "TE" (08-25-2018)0.1k - bug fixed (08-28-2018)0.1l - add local Threat Emulation (09-03-2018)0.1m - bug fixed (09-06-2018)0.1n - QoS (09-24-2018)1.1o - correct a mistak in picture (09-26-2018)1.1p - add CPASXL and PSLXL path in R80.20 (09-27-2018)1.1q - add Falcon acceleration path in R80.20 (10-09-2018)1.1r - bug fixed Falcon card wording (11-04-2018)1.2a - new forum format (03-17-2019) Copyright by Heiko Ankenbrand 1994-2019

What I notice more and more in the last years is CPAS (Check Point Active Streaming). With increased https, the firewall workers are more and more stressed if https inspection is enabled. Now also CPAS use the SecureXL path in R80.20. CPAS works through the F2F path in R80.10 and R77.30. Now CPASXL is offered in SecureXL path in R80.20. This should lead to a higher performance. "fwaccel stats -s" shows the new path in R80.20. I think PXL was renamed to PSLXL. This is from my point of view the politically correct better term. Check Point Active Streaming active streaming allow the changing of data and play the role of “man in the middle”. Several protocols uses CPAS, for example: Client Authentication, VoIP (SIP, Skinny/SCCP, H.323, etc.), Data Leak Prevention (DLP) blade, Security Servers processes, etc. I think it's not to be underestimated in tuning. # fwaccel stats -s We have already discussed this here with Timothy Hall Security Gateway Performance Optimization Excerpt. Maybe Check Point can give us more information here. I had adapt CPASXL and PSLXL to the following article: R80.x Security Gateway Architecture (Logical Packet Flow) R80.x Security Gateway Architecture (Content Inspection)

Dear Mates,This is not a technical but it is more based on your exeperience with Checkpoint solutions.What can one do when it is tasked with the responsability to become the admin of the checkpoint firewalls of a big company for the first time. What should one be busy with on his first weeks? take into account that the former admin is not willing to share any information and the new comer is certified CCSE but with limited experience.Any help will be appreciated.

The Portable SmartConsole is also available for R80.20. Portable SmartConsole is a version of the SmartConsole client which is deployed without the installer of SmartConsole.This package encapsulates all content into the directory where it is deployed so that it can be carried around in a portable device.Another advantage of this version is that it allows side by side versions of the SmartConsole of the same release on the same computer. The following SK Portable SmartConsole for R80.x describes the download and installation. Tip 1 There are new features that you can use independently. For example with R80.20, there are 2 user interfaces when looking at Check Point logs. Thus it is possible to use both log views independently: - The default viewer when opening the SmartConsole application on your Windows machine. - The default viewer when opening the logs on your web browser. Tomer Sole describes this very well in the following article How to switch to the new log viewer inside SmartConsole (and maybe get a little performance improvement). Furthermore, it is possible to change various settings for your Smartconsole and Portable SmartConsole in the file: SmartConsole.exe.config This allows, for example, both log views to be used in two consoles. Or you can use one console by default and adapt the other one to your needs. --- Tip 2 Or you can start SmartConsole with different credentials automatically: SmartConsole.exe -p SmartConsole.LoginParams For this purpose create the following file "SmartConsole.LoginParams". Format of the XML (none of these parameters is mandatory😞 <?xml version="1.0" encoding="utf-8"?><RemoteLaunchParemeters xmlns:xsi="http😕/www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http😕/www.w3.org/2001/XMLSchema"><Username>username</Username><ServerIP>1.2.3.4</ServerIP><DomainName>BerlinDomain</DomainName><ReadOnly>False</ReadOnly><CloudDemoMode>False</CloudDemoMode><Password>password</Password> <<< Should be used with caution!!!</RemoteLaunchParemeters> Tip 3 Now it is possible to start portable SmartConsole and the regular SmartConsole at the same time. So you can e.g. view the logs and edit the policy at the same time with different SmartConsole settings (e.g. old and new log view). Important! You must use two different admin accounts for this hack. Tip 4 Each administrator can manage multiple SmartConsole sessions at the same time in R80.20+. To enable working in multiple sessions: 1) Open the relevant permission profile.2) Make sure the Manage Sessions permission is selected on the Management page.3) Open SmartConsole > Manage & Settings View > Sessions > Advanced.4) Select Each administrator can manage multiple SmartConsole sessions at the same time.5) Publish the change. Or look at this video: (view in My Videos)

What is AES-NI Intel‘s AES New Instructions AES-NI is a encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data in many processor familys. Comprised of seven new instructions, AES-NI gives your environment faster, more affordable data protection and greater security. Chapter Architecture:R80.x Security Gateway Architecture (Logical Packet Flow)R80.x Security Gateway Architecture (Content Inspection) R80.x Security Gateway Architecture (Acceleration Card Offloading) R80.x Ports Used for Communication by Various Check Point Modules Performance Tuning:R80.x Performance Tuning Tip - Intel HardwareR80.x Performance Tuning Tip - AES-NI R80.x Performance Tuning Tip - SMT (Hyper Threading) R80.x Performance Tuning Tip - Multi Queue R80.x Performance Tuning Tip - Connection Table R80.x Performance Tuning Tip - fw monitorR80.x Performance Tuning Tip - TCPDUMP vs. CPPCAP R80.x Performance Tuning Tip – DDoS „fw sam“ vs. „fwaccel dos“ Cheat Sheet:R80.x cheat sheet - fw monitor R80.x cheat sheet - ClusterXL More interesting articles:Article list (Heiko Ankenbrand) Appliances and Open Servers with AES-NI Better throughput can be achieved by selecting a faster encryption algorithm. For a comparison of encryption algorithm speeds, refer to sk73980 - Relative speeds of algorithms for IPsec and SSL. AES-NI is Intel's dedicated instruction set, which significantly improves the speed of Encrypt-Decrypt actions and allows one to increase AES throughput for: Site-to-Site VPN Remote Access VPN Mobile Access HTTPS Interception The general speed of the system depends on additional parameters. Check Point supports AES-NI on many appliances, only when running Gaia OS with 64-bit kernel. On these appliances AES-NI is enabled by default. AES-NI is also supported on Open Servers. Affected encryption algorithms include: AES-CBC (128-bit and 256-bit) AES-GCM (128-bit and 256-bit), which shows the most significant improvement - with AES-NI, it is faster than AES-CBC, when both sides support AES-NI. Without AES-NI support, it is slightly slower than AES-CBC + HMAC-SHA1. Check if AES-NI is activated # dmesg | grep "AES-NI" If it is not available, the following message is displayed: If AES-NI is not enabled, it must be turned on in the BIOS (if available). Typical way for Open Servers. It can also be checked if the CPU provides AES-NI. For this the following command should be executed. Here "aes" should now be displayed. # grep -m1 -o aes /proc/cpuinfo AES-NI performance measurement A little bit of reverse engineering. Check Point uses OpenSSL as library. Therefore the command "openssl" is provided as "cpopenssl". This gives us the possibility to execute all openssl commands. With this I tested a little bit and came to the conclusion that performance measurements are possible with the following command. So you can test the performance differences with enabled and disabled AES-NI. Warning notice: If you execute this command you have 100% CPU usage on the firewall for 20 sec. # cpopenssl speed aes-256-cbc Enabled AES-NI: Disabled AES-NI: After these results I would always recommend to activate AES-NI and AES is preferred to 3DES because it offers many performance advantages through the hardware acceleration.With the following command you can test and compare all encryption methods. After these results I would always recommend to activate AES-NI and AES is preferred to 3DES because it offers many performance advantages through the hardware acceleration. Warning notice: If you execute this command you have 100% CPU usage for a long time! # cpopenssl speed This makes it possible to compare encryption algorithms. It shows that e.g. AES 256 is more performant than DES. Therefore AES 256 should rather be used for VPN connections than DES or 3DES. This is also well described in the following SK Relative speeds of algorithms for IPsec and SSL. References Relative speeds of algorithms for IPsec and SSL Best Practices - VPN Performance vSEC Virtual Edition (VE) Gateway support for AES-NI on VMware ESX Best Practices - VPN Performance MultiCore Support for IPsec VPN in R80.10 and above Copyright by Heiko Ankenbrand 1994-2019

SMT (Hyper Threading) Hyper Threading Technology is a form of Simultaneous Multithreading Technology (SMT) introduced by Intel. Architecturally, a processor with Hyper-Threading technology consists of two logical processors per core, each of which has its own processor architectural state.Each logical processor can be individually halted, interrupted or directed to execute a specified thread, independently from the other logical processor sharing the same physical core. Unlike a traditional dual-processor configuration that uses two separate physical processors, the logical processors in a hyper-threaded core share the execution resources. These resources include the execution engine, caches, and system bus interface; the sharing of resources allows two logical processors to work with each other more efficiently, and allows a logical processor to borrow resources from a stalled logical core (assuming both logical cores are associated with the same physical core). A processor stalls when it is waiting for data it has sent for so it can finish processing the present thread. The degree of benefit seen when using a hyper-threaded or multi core processor depends on the needs of the software, and how well it and the firewall. Hyper-Threading works by duplicating certain sections of the processor - those that store the architectural state - but not duplicating the main execution resources. This allows a hyper-threading processor to appear as the usual "physical" processor and an extra "logical" processor to the firewall. The number of concurrent threads can be decided by the chip designers. Two concurrent threads per CPU core are common. Because it is really an efficiency technique that inevitably increases conflict on shared resources, measuring or agreeing on its effectiveness can be difficult. Chapter Architecture:R80.x Security Gateway Architecture (Logical Packet Flow)R80.x Security Gateway Architecture (Content Inspection) R80.x Security Gateway Architecture (Acceleration Card Offloading) R80.x Ports Used for Communication by Various Check Point Modules Performance Tuning:R80.x Performance Tuning Tip - AES-NI R80.x Performance Tuning Tip - SMT (Hyper Threading) R80.x Performance Tuning Tip - Multi Queue R80.x Performance Tuning Tip - Connection Table R80.x Performance Tuning Tip - fw monitorR80.x Performance Tuning Tip - TCPDUMP vs. CPPCAP R80.x Performance Tuning Tip – DDoS „fw sam“ vs. „fwaccel dos“ Cheat Sheet:R80.x cheat sheet - fw monitor R80.x cheat sheet - ClusterXL More interesting articles:Article list (Heiko Ankenbrand) Preview to Intel Architecture The following statement is also often discussed on the Internet: SMT can increase message rate for multi process applications by having more logical cores. This increases the latency of a single process due to lower frequency of a single logical core when hyper-threading is enabled. This means interrupt processing of the NICs will be slower, load will be higher and packet rate will decrease. I think that's why Check Point doesn't recommend SMT in pure firewall and VPN mode. From my point of view, it only accelerates software balades. Therefore I use it if necessary, if many blades are activated. I'd like to discuss that with Check Point. Small example with basic viewing: This presentation is very simplified and should illustrate the issues. If SMT channel 2 uses all core resources with I/O operations, channel 1 must wait for the core resources. This can reduce the performance with enabled SMT. The same effect can occur with multi-queue and enabled SMT. The problem can be fixed by adjusting the Check Point affinity or disable SMT. What we see here, many Intel architecture issues can affect SMT and therefore the firewall performance. Check Point and SMT SMT is a feature that is supported on Check Point appliances running Gaia OS. 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% on software blades such as IPS, Application & URL Filtering and Threat Prevention by increasing the number of CoreXL FW instances based on the number of logical CPUs. Turning on SMT can have some side effects in terms of multi-queue and affinity. After turning on SMT the affinity should normally be adjusted. There are also some cases in which SMT should not be used: if only firewall/VPN blades are used if these blades are enabled: DLP Anti Virus if these features are enabled Using services with resources in firewall policy use hide NAT extensively -> Refer to sk88160 - Dynamic NAT port allocation feature to mitigate this limitation. more see SK93000 Following information must also be observed before turning on SMT: Changing SMT state requires reboot. For supported appliance refer to "Supported Appliances". If you have two ports on any of the aforementioned appliances to handle most of the traffic, it is recommended to enable the multi-queue feature to increase SMT performance. For R77.30 versions only! If the VPN blade is enabled and a significant amount of IPSec VPN traffic passes through the security gateway, then follow the steps in SK93000. For the best performance, it is recommended that user space processes not be affined to the same physical CPU core as the secure network distributors (SNDs), but rather that they be affined to the firewall workers CPUs (more see SK93000, SK98737). If necessary, the affine has to be adjusted here (more see SK93000). Enabling SMT will load additional CoreXL FW instances. These instances consume memory and the maximal connection capacity may decrease by up to 10%. (info from Check Point Ofir S. ) more limitations see SK93000 Supported configurations for SMT: only on Check Point appliances only on security gateways running Gaia OS with 64-bit kernel supported for R77 release and later Tip! On some open servers SMT (HT) must be disabled in the BIOS for the gateway installation. This is documented in the HCL for Server see link HCL. For example for "HP ProLitan DL360 Gen9" refert to SK Required steps before installing Gaia OS on HP ProLiant Gen9 servers. Supported Appliances Attention! SMT is supported only on following Check Point appliances not on Open Server. Appliance Comment 3100 3200 No hardware support for SMT. 5100 5200 5400 5600 No hardware support for SMT. 58005900 Is already shipped with enabled SMT feature in the BIOS. SMT is recommended with all blades. Installation of the hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization. Enabling of SMT feature in 'cpconfig' (refer to "Enable SMT" section). 12400 Requires 8 GB of RAM.Refer to these solutions: sk68700 for instructions for "12400 Appliance Installing and Removing Memory" sk71001 for instructions on how to upgrade to 64-bit Gaia computers Requires enabling of SMT feature both in the BIOS (1) and in 'cpconfig' (refer to "Enable SMT" section). 12600 Requires enabling of SMT feature both in the BIOS (1) and in 'cpconfig' (refer to "Enable SMT" section). 1350013800 Is already shipped with enabled SMT feature in the BIOS. Requires enabling of SMT feature only in 'cpconfig' (refer to "Enable SMT" section). 1540015600 Is already shipped with enabled SMT feature in the BIOS. SMT is recommended with all blades. Installation of the hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization. Enabling of SMT feature in 'cpconfig' (refer to "Enable SMT" section). 214002160021700 SAM Acceleration card is not supported with SMT Requires enabling of SMT feature both in the BIOS (1) and in 'cpconfig' (refer to "Enable SMT" section). 21800 Is already shipped with enabled SMT feature in the BIOS. Requires enabling of SMT feature only in 'cpconfig' (refer to "Enable SMT" section). 2350023800 Is already shipped with enabled SMT feature in the BIOS. SMT is recommended with all blades. Installation of the hotfix from sk109772 - R77.30 NGTP, NGTX and HTTPS Inspection performance and memory consumption optimization. Enabling of SMT feature in 'cpconfig' (refer to "Enable SMT" section). 23900 Hyper Threading is hard-coded to be disabled on R77.30 and R80.10, with no impact on performance TE250XTE1000XTE2000X Is already shipped with enabled SMT feature in the BIOS. Requires enabling of SMT feature only in 'cpconfig' (refer to "Enable SMT" section). On these appliances, SMT is recommended with all blades. 40K 60K SGM220 no SMT support SGM200T no SMT support SGM260 SMT support (20 physical cores / 40 with enabled SMT) SGM400 SMT support (28 physical cores / 56 with enabled SMT) (1) Note: To enable SMT in the BIOS, contact Check Point Support or contact Check Point Professional Services to get confirmation and approval beforehand. Check if SMT is activated Check if SMT is activated and check current SMT status on security gateway: # cat /proc/smt_status Either SMT is not supported on this machine or SMT is disabled in the BIOS. SMT is enabled in the BIOS, but disabled in 'cpconfig' SMT is enabled in BIOS and in 'cpconfig' If SMT is activated this command shows the nummbers of CPUs, cores and SMTs: # grep -E "cpu cores|siblings|physical id" /proc/cpuinfo | xargs -n 11 echo |sort |uniq Enable SMT 1) Check the number of cores # fw ctl multik stat 2) Check the number of cores in the gateway license.# cplic print 3) Enable SMT in the BIOS + Reboot 4) Enable SMT in Check Point software and reboot the gateway. Attention! 1) If multi-queue and affinity are not adjusted or used, this can lead to performance problems in combination with SMT. 2) Before enabling SMT, follow the instructions in SK93000 to verify that the Security Gateway can support SMT safely and check if there is enough memory available for the FW_Worker. # cpconfig Choose 'Configure Hyper-Threading' Select 'yes' # reboot 5) Check the number of CoreXL FW instances # fw ctl multik stat If the number of CoreXL FW instances did not increase automatically, then configure the CoreXL. # cpconfig Choose 'Configure Check Point CoreXL' Set the desired number of CoreXL FW instances (for example 3 CoreXL FW instances) Attention! With a ClusterXL, the core number must be the same on all gateways. Otherwise ClusterXL problems will occur. # reboot 6) Check again the number of CoreXL FW instances # fw ctl multik stat Disable SMT 1) Disable SMT in Check Point software and reboot the gateway. # cpconfig Choose 'Configure Hyper-Threading' Select 'No' # reboot 2) Check the number of CoreXL FW instances # fw ctl multik stat Q&A Q: Which appliances were tested with SMT enabled. A: 5800 / 5900 / 15400 / 15600 / 23500 / 23800 / TE250X / TE1000X / TE2000X Q: I have an Open Server. Can I enable SMT in the BIOS and use it? A: SMT is supported only on Check Point appliances. Q: Is any degradation expected when enabling SMT?A: Enabling SMT will load additional CoreXL FW instances. These instances consume memory and the maximal connection capacity may decrease by up to 10%. Q: On which appliances is SMT enabled by default in the BIOS? A: Only on 13500 / 13800 / 15400 / 15600 / 21800 / 23500 / 23800 / TE250X / TE1000X / TE2000X appliances Q: What to do if multi-queue is enabled? A: If using Multi-Queue, once the final CoreXL split has been set be sure to run cpmq reconfigure and reboot again, this will help ensure the new allocation of SND/IRQ cores are properly deployed for SoftIRQ processing on the Multi-Queue-enabled interfaces. References SMT (HyperThreading) Feature GuideBest Practices - Security Gateway PerformanceATRG: CoreXL Dynamic NAT port allocation feature Copyright by Heiko Ankenbrand 1994-2019

Hi all,I am planning on migrating from a Smart-1 77.30 HA SMS to a Virtual 77.30 SMS with a new IP and ideally new hostname. The gateways managed by the smart-1 SMS perform site-to-site vpns and remote access vpns with the checkpoint client. Also, checkpoint utm edge servers and smb devices are managed by the Smart-1 SMS; these devices are also configured with site-to-site VPNs. I have seen other articles that explain that you need to retain the same IP on the new manager, perform configuration changes e.g. licensing, firewall rules, migrate-import, then you can use the new IP. A couple of questions. How do I connect to the new Virtual SMS with the old IP to make those changes when it is not routable to that part of the network? Second what is the correct procedure to perform this migration? Also what would be the rollback?Thanks for your help.

Hi all,I have a topology running multicast:router1(multicast receiver)----checkpoint r80----router2(RP)---router3(multicast sender)all devices run pim-sm.above network run fine without nat.but when i set static nat on firewall: IP of router1---> translate to a.b.c.dthen on router1, I send "igmp join" toward to RP(router2). On log , i see that igmp packet is forwarded to firewall, but packet is not nated to a.b.c.d (above ip address). And not forwarded through firewall.So my question is if checkpoint r80 supports multicast nat source? If yes , how i can config it? Thank you!!

Hello friends,I have multicast topology like this:Router1(receiver multicast)------>Checkpoint R80------->Router2-----Router3(Multicast sender)All devices run PIM-SM mode.On router1: I join group 239.9.9.9On router2: ping to 239.9.9.9Result: Not successI check log on firewall and see that this error Please help meThanks a alot!!

Dear MatesThis is not a technical question but it is more like a general question in which I would really appreciate your feedback.We are an ISP, and we provide services to many enterprises, we clients are usually finding the IP address we allocate to them in some blacklists, which sometimes prevents them from using certain services on the Internet, until the IPs are removed from the blacklist.Taking into account that we do not have control over what our clients do to get tham blacklisted, I would like to know whether there is something we as the ISP can do in order to minimize the risk of our clients get blacklisted.Thanks in Advance

Hello All,Can you advise me, i have read various docs on Checkpoints website & various knowledge boards.I my initial understanding is that if i wanted to upgrade from R77.30 to R80.30 i would have to build a new server & run through the upgrade verifier, export & import database steps.But as i have started to read more there seems to be a straightforward upgrade path via CPUSE. Or am i reading the the documentation wrong.Thanks for any advise Extract from Installation and Upgrade Guide R80.30From R7X to R80.30:Upgrade the Primary Security Management Server.Perform a clean install of the Secondary Security Management Server.Connect the Secondary Security Management Server to the Primary Security Management Server.Step 2. Why ???? there is no explanation

Hi Team,I refer sk101573 (How to configure Gaia OS to work with a TACACS+ server)Below is the configuration details.VMware:12 ProNOTE: We successfully login with GAIA portal using TACACS user (User define in TACACS+ Server).But unable to login with SmartConsole. Configuration Step Taken :File Name : tac_plus.conf (Location : /etc/tacacs+/tac_plus.conf)Step1Step2Step3Step4Step5Configuration for SmartConsole LoginSTep6STep7Step9Unable to find any logs on messages file.Step10As I know for "Authentication to server failed" logs are not generated in the messages file.Please confirm is this a right configuration because , we unable to login with Smartconsole but able to login with GAIA portal.Thank you Regards@Chinmaya_Naik

Hello everyone, I have a task to upgrade a firewall appliance from 1GB to 10GB on their interfaces. The issue I have is this appliance is running r75.30 on SPLAT. I haven't used SPLAT in a very long time. Does anyone know what the commands even are to do this? Another question is what is the SPLAT command to get the configuration of the appliance. In GAIA its simply show configuration. Don't know what the command is in SPLAT. Any help is appreciated. Thanks. Regards!

Hi Community!after upgrading to R80.20 i verified the session tables of our fw gateways, with the "fw ctl conntab" command.I found out that all upgraded gateways have random TCP session timeouts for a session displayed, and not the actually configured value for the service.I checked it on more than 20 different gw´s it´s always the same. for a global value of 7200 sec, there is sometimes 4642 or even as low as 1058 sec, or higher 7205 etc. in the output next to the TTL - same rule/same service.In older versions like 77.20 it´s always exactly the configured value for example 7200sec in the output.Can anyone verify this, is this only cosmetic or could this lead to sessions falling out of the table to soon?Attached you can find screenshots with example output of a R77.20 and R80.20 gateway.

Hi Community,I am trying to deploy cloudguard in Azure via ARM templates, but I am hitting an issue with the artifacts location parameters.As I can see in the template, the artifacts location is no longer hard coded, instead it is using the deployment function to call the artifacts uri.Long store short, when I run the template installation from local files on my computer, I get the error below saying that the templateLink doesn't exist:Apprantly it happens because the deployment function does not respond with the templateLink information if you run the deployment using local templates.Anyone ran into this issue before? Trying to install r80.30 using ARM template version below:"templateVersion": "20190805"thanks in advance.

I have several VPNs against AWS, it happens that at random there is no more traffic. When the fault occurs, there are the following symptoms: -Up Tunnel -Phase 1 and Phase 2 established The problem is resolved when we restart Ike at the checkpoint (vpn tu - 7), but after a while it happens again. The configuration of my Tunnel is as follows: IKv1 Phase I. -Encryption Algorithm: AES-128 -Data Integrity: SHA1 Diffie-Hellman group: Group 2 (1024bit) Phase II -AES-128 Data Integrity: SHA1 IKE Security Association (Phase2): Use perfect Forward Secrecy (group 2) Ike Phase I. Renegotiate IKE Security associations every (minutes): 480 IPsec (Phase 2): Renegotiate IPsec security associations every (seconds): 3600 Nat: Disable NAT inside the VPN community DPD configured in the Cluster and AWS Community VPI and Ping interfaces on static routes Tunnel Management -Permanent tunnels: establish permanent tunnels: in all the tunnels of the community. -VPN Tunnel Sharing: One VPN tunnel per Gateway pair. VPN ROUTING: to center or, even the center, other satellites, the Internet and other VPN objectives DPD configured in the Cluster and AWS Community VPI and Ping interfaces on static routes when I see the records, it's dropping by rule clean up please your support, the tac still does not find the cause

Hi All, We are upgrading MDS from R77.30 to R80.10. Currently Splunk is integrated with R77.30 MDS. Do we need to perform any step on R80.10 MDS to make the Splunk work with R80.10 CMA. Some document says Splunk Add-On for Checkpoint needs to be installed on Splunk itself. But some document says Log exporter also needs to be installed on R80.10 MDS. Please share your thoughts. Thanks,Arvind Singh

Hello All,I have a task of upgrading some Checkpoint firewalls none of the firewalls have internet connectivity from the CPUSE software, but i have managed to download the updated software to my laptop & then import to the firewalls.But one firewall is not playing ball, in the CPUSE GUI it doesnt even have the IMPORT option. R77.30 Deployment Agent build 1677.But i can import the software via the backup software panel, so the software is on the firewall in the following path/var/log/CPbackup/backups/Check_Point_R77_30_JUMBO_HF_1_Bundle_T345_FULL.tgz &/var/log/CPbackup/backups/Check_Point_R77_30_JUMBO_HF_1_Bundle_T345_FULL.tarSo i am now trying too follow the document below.https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92449#How%20to%20work%20with%20CPUSE%20-%20How%20to%20install%20a%20CPUSE%20packageHostName:0> lock database overrideImport the package from the hard disk:Note: When import completes, this package is deleted from the original location.Import package from hard disk ???????? How ?? To me this doc bypasses the most import bit of info ???I will keep looking for info aswell. TaAny ideas, Thanks anyone.

Thought I would share a situation we dealt with yesterday and into the wee early morning hours of today.We started receiving reports that users were having intermittent issues with multiple google.com sites (drive, cse, apps, etc.). While troubleshooting with curl and openssl on the cli, we discovered that the issue was the app/url blade was dropping connections (erroneously) on some Google IP addresses(dropped by: fwpslglue_chain Reason: PSL Drop: ASPII_MT in fw ctl zdebug drop), while correctly passing the traffic on others.For those that don't know, with HTTPS Categorization (not Inspection) the determining factor that the gateways use for a permit or drop is the CN in the certificate that is returned from the server. It does not (supposedly) rely on IP addresses. It doesn't see the FQDN being requested as it's encrypted traffic.After hours (and multiple shift changes) working with support there was still no solution in sight. We rolled back APP/URL policies to a know good date to no avail. We failed over, we rebooted, and failed back over. We cleared out the APP/URL local cache on the gateways and set them to clear on policy installation. Running debugs on app/url, and rad, etc......We performed packet captures on both the working and non working traffic. We pulled the cert (*.google.com) out of the capture and verified the certs were identical in both the working and not working captures. We, as well as CP support were surprised that the certs were identical. If the CN is the deciding factor, why would an identical cert behave differently based on what IP address the FQDN was resolving to? We thought for sure the cert would be different.At this point we debugged wstlsd while still running curl/openssl tests. To our surprise, none of our test traffic was showing up in the debug. Finally, this tipped of our support rep and the magic command came was issued:fw tab -t cptls_server_cn_cache -x -y"The cache saves mapping between IP+Port to CN (Certificate's Canonical Name) and a flag if the CN is valid. The table will go up to 10,000 entries and be cleared automatically to make room for new entries."There's not much in the support portal regarding this cache. Only pertinent match was: sk120775Eureka, after running this command we were fully functional on all the Google IPs we were testing. There either had to be:1) A miscategorized association between IP+Port & CN2) A corrupted entry for the aboveAfter we resolved this it was apparent why a failover/reboot/failover did not resolve anything, the connections/caches all stayed in sync/active with the invalid information.After so many hours (11 I think?) chasing this down, we did not pursue a RCA on why the cache entries were victimizing us. We were just glad we found them and could go to bed.Hopefully someone will run across this article and it saves their bacon (and 11 hours).TL;DR: HTTPS Categorization doesn't use IP addresses directly for categorization purposes, but it sure does cache them.

Hello Checkpoint Experts, I need some direction on the following issue:We have had to rebuild our Security Management Server because the VM was accidentally deleted, and guess what, with no backup of the Management Server so, it cannot be restored. We are in the process of building the new management server now and I am wondering how can i get the Policies which are currently active on the Gateways back on the management server.Please advise. Note: the Gateways are in production and are working fine at the moment.RegardsRishi

Just had a fun geeky conversation with Dameon Welch Abernathy (AKA Phoneboy) Jony Fischbein , Jeff Schwartz and Michael Poublon (over 100 accumulated years of experience in Check Point products) , on what are our favorite & most useful commands in a Check Point environment.Below are my 3 , plz add yours in the comments (we will do a poll for the top 5 after getting your feedback ... ). 1) fw ctl zdebug drop used to quickly see all dropped connections and more importantly the reason (e.g. anti-spoofing, IPS , FW rule , ....) 2) cpstat fwquickly see stats of number of connections (accepted,denied,logged) with a breakdownif the FW was under a high load i would usually run " watch --interval=1 'cpstat fw' " (would see a real-time to see the interface that is causing this) 3) fw tab -s -t connections allowed me to quickly see how much load is (and was i.e "peak" ) on the FW that's it (i have more , but i want to hear yours ...)plz add yours in the comments (we will do a poll for the top 5 after getting your feedback ... )

While we have a number of things to perfect over the next several days and weeks, some of what you're after can be found using standard URLs every Lithium community has. I'm attaching the Khoros/Lithium article on it, if you want to dig deeper, but I'll post the most relevant links here, personalized for CheckMates: All messages posted across entire community (sorted by most recent): https://community.checkpoint.com/t5/forums/recentpostspage/post-type/message All threads posted across entire community (sorted by origination date): https://community.checkpoint.com/t5/forums/recentpostspage/post-type/thread Unanswered posts in the community: https://community.checkpoint.com/t5/forums/unansweredtopicspage/node-id/community:1 I may add additional ones I find useful to this message at a later time.

Not to be confused with the Acclaim badges Check Point has been giving out, you can now earn badges for community activity! Specifically for the following activity: Originating a post Replying to a post Giving Kudos Receiving Kudos Uploading Images Uploading Videos At the moment, they do not appear on your Profile page—hopefully we can fix this in short order. That said, if you earned one or more, you will receive a notification that you did. And, of course, we may add more as time goes on. Stay tuned!

Hello, I would like to know what are new Ranks within new platform. I tried to search for it, but I have found only general info provided within New Ranks and Badges Coming in Migration to Lithium. What exactly is needed in order to level up ? How many Kudos/replies/new posts have to be fulfilled ? Thank you for the list and criteria for each of them.