Saturday, June 4, 2016

Checkpoint R80



Checkpoint R80

CPX 2016 Summary

 SmartConsole
SmartLog (new stuff at the top)

 SmartView Tracker
Smart Log
Smart Dashboard  

 SmartTracker  (may go away in R80)

https://www.cpug.org/forums/showthread.php/21170-New-R80-publication-on-the-way
http://www.maxpowerfirewalls.com/addendums.html

Some topics discussed are:


Checkpoint R80 is released as Management only.  The Security Gateways will be released laster this year. 

Noted Changes/Enhancements:
1. New UI of SmartConsole as a single application
2.  Multiple admin access to the same database
3.  New MGMT API that is much more powerful than old
4. OPSEC almost obsolete


R80 GA materials are avaiable for download. They were originally posted on 31st of March. 

 A new book covering Check Point R80  has been in production for 5 months now and is nearing completion. This new book is the first of a series and has a working title of “New Frontier: Check Point R80”. It is a collaborative effort featuring four recognized professionals with quite a lot of Check Point expertise (in alphabetic order)

- Eric Anderson – USA
- Timothy Hall – USA
- Kishin Fatnani – India
- DK (author of this blog) 
- Valeri Loukine - Switzerland 

More information will be available soon, stay tuned!


Firewall Basics
----------------

Routing device with security policy enforcement capabilities
It allows controlling traffic between networks.
Firewall is part of the system Kernel
it resides before and after (inbound/outbound) the OS IP Stack
Packets cross the FW twice when going thru a security device
only exception is when traffic directed to or originated by the firewall appliance itself


Unix Based Box - IP Stack/Network Devices/NIC Card
Unix Based Box with Security - IP Stack/Firewall Kernel(inbound/Outbound)/Network Devices/NIC Card


Stateful Inspection/FW Kernel tables
-------------------------------------
stateful inspection was invented by Checkpoint and Gil Shwed.
Checkpoint Firewall -1 is the first stateful firewall
Patent Number USA  5,606668  Patent Date: Feb25, 1977

Static Packet Filtering
Unix based forward packet forwarding capabilities - Only IP address and ports are used to make security decision
Usually based on access list.
Not enough for proper security.

OSI Model
----------

Applicaiton  (HTP/FTP/SMTP)
Presentation (HTML/CSS/GIF)
Session      (RPC/SSL,SQL)
Transport    (TCP/UDP)
Network      (Packets  IPv4, IPv6)
Data Link    (Frames/MAC Address)
Physical     (Ethernet/ISDN/DSL)


Stateful Inspect from layer 3-7  (Dynamic Packet Filtering)
Stateful inspection -fw technology monitors and in forces the state of connections
Kernel Kernel - Dynamic Kernel Table  (Connection Table)

Firewall Security Enforcement

Source/Destination/Device/Action -accept-drop-reject/Tracking/

Packet  -> Firewall Kernel-> New Connection? -> Checks  Dynamic State Table -> Yes -> Found a Rule -> Yes -> Action -> Accept/Reject/Drop
Packet  -> Firewall Kernel -> New Connection? -> Checks Dynamic State Table - NO -> Packet Forwarded
                                   
Accept action do not require reulebase look-up for every packet in the connection after the very first one.                                     Dropped connection are not listed in the connection table
Accpet actins requires less efforts that Drop
differene between reject and drop
   
 
Source 

Best Practices/Optimization/Troubleshooting
firewall Maintenance
Packet flow
Address Translation
Stateful Inspection
Security Acceleration
Multi-Core Systems and CoreXL
Kernel debug



R80.10 Early Availability Program

As we are expanding our EA installations I would like to invite you to participate in the Early Availability Program of R80.10. Candidates should commit their Production environment in order to get on-site Early Availability engineer.

The registration process consists of filling out a short questionnaire to characterize the candidates for this EA program and NDA papers.
In order to register to the new R80.10 please fill in the following questionnaire (link below) and our early availability engineer will contact you.

WHAT’S NEW IN R80.10?

Check Point recently released Next Generation Security Management R80 setting the standard for reliability and ease-of-use in security management.

Check Point R80.10 extends R80 functionality to complete our vision for security consolidation, unified policy, and integrated threat management..

R80.10 will include:

Unified Access & Data Policy


1. Unified Policy

  • Unified security rule-base for Access blades: Firewall, VPN, Application Control, URL Filtering, Data Awareness, Mobile Access Blade
  • Unified log for network, protocol, application, user, accessed resources, file and data types.



2. Powerful Policy Model Architecture

  • Layered policy to support delegation and segregation of duties
  • Sub policy to define a set of rules as one management unit, independent from the rest of the rule-base.
  • Security zones bound to network interfaces to simplify security policy management.



3. Firewall and Application Control Enhancement
  • Application criteria now includes match by recommended services and by application signature.
  • Service criteria now includes match by protocol signature and by service port.


4. Integrated Data Awareness

  • Data Awareness adds file types, data types, and direction in the new unified policy, combining data with other security policy objects for granular rules..



5. Additional Enhancements:

  • New FQDN mode, to match fully qualified domain name of Domain Objects.
  • Domain Objects and Dynamic Objects support SecureXL accept templates.





Identity Awareness:


  • Large scale Identity Awareness, for support of 200K users.
  • Identity Collector Agent to collect user information from different identity sources (AD/ISE).
  • Web REST API for IDA.
  • LDAPv3 support for better nested group handling.



Mobile Access:


  • Support Mobile Access in the unified rule base of R80 / R80.10.
  • Multiple Login Options, and multiple authentication factors, for Mobile Access and IPSec VPN. 


 VPN:


  • Multi-core for enhanced performance of VPN (Site-to-Site and Remote-Access VPN).
  • Security Gateways behind NAT use of NAT-T to initiate VPN site-to-site tunnel.


Threat Prevention:


  • IPS is now part of the Threat Prevention policy, with multiple profiles per gateway and all Threat Prevention blades managed in one rule.
  • Threat Prevention Policy installation time considerably improved.
  • Threat Prevention Policy support for multi-layers, adding flexibility. 


 Additional Features:


  • SandBlast Threat Extraction immediately provides users with clean, reconstructed files containing only known safe element
  • Support of TLS 1.2 in Mobile Access connections and portals that do not work through multi-portal system. 


 Upgrade Method:

  • Upgrade to R80.10 and onward will be available online & offline through Check Point’s upgrade engine (CPUSE).





Free "Max Power" Tips, Tricks & R77.30 Addendum Now Available

Hi Everyone,

I've posted a free addendum to my "Max Power: Check Point Firewall Performance Optimization" book at http://www.maxpowerfirewalls.com. This 14-page PDF addendum includes additional reader-submitted tips and tricks not included in the book, along with an overview of the new firewall performance-related features and fixes in R77.30. I have copy/pasted the additional material (with page number references) below with a minimum of formatting for the benefit of the Google site spiders and any community-based discussion that may ensue. To download a much more pretty version of these including more structured formatting, hotlinks to the relevant Check Point SK's, various screenshots, and a 2-page introduction to this content, it can be downloaded for free from http://www.maxpowerfirewalls.com. The PDF addendum document may be freely copied and distributed as long as its content and authorship remains intact.

I'd like to thank Phoneboy and Eric Anderson for reviewing this addendum and all the readers that submitted tips and feedback. Enjoy!

Supplementary Material by Page Number

Page 16: If your site does not have the Monitoring Blade present, be sure to check out
the nmon tool discussed in the Page 58 entry below.

Page 21: If you are unlucky enough to be forced to utilize Emulex NICs (driver name
be2net) on your firewall, be aware that a nasty firewall stability issue involving these
NICs was fixed in R77.30 and R77.20 jumbo hotfix Take 94 and later. You'll definitely
want to install this fix if using Emulex NICs on your firewall.

Page 26: The book recommended always using an even number of physical interfaces
in a bonded aggregate Ethernet interface. After some reader questions, I dug into it a
little further, as this has been an unofficial recommendation floating around for quite
some time. While I was not able to learn the exact nature of the issue, I was assured that
it was an Intel driver issue and that it was fixed in R77.30. However, of the four main
Intel drivers shipped with Gaia R77.20 (e1000, e1000e, igb, ixgbe), only the e1000e
driver was updated (from version 1.2.20 to 2.1.4) in the R77.30 release. So unless your
firewall is using the e1000e driver (igb and ixgbe are by FAR the most common though),
this recommendation does not appear to be valid. It is also possible that this
recommendation is a bit of a myth, created by the fact that some networking vendors do
not support using an odd number of physical interfaces when aggregating them using the
older EtherChannel technique. If you have further insights, or would like to keep abreast
of the evolving knowledge on this topic, stay tuned to this thread at CPUG:
https://www.cpug.org/forums/showthre...-Joining-Bonds

Page 34: One other potential STP-related issue pointed out by a student of mine, is that
different variants of the spanning tree algorithms don't mix well. As an example, if two
switches are connected together and one of them is using the original 802.1D standard
STP and the other is using Rapid STP, the various timers will be radically different
between the two and cause network stability issues.

Page 49: ICMP isn't just all about ping and traceroute; the various types and codes of
ICMP datagrams can sometimes indicate that performance-impacting conditions are
occurring within the network. Running a netstat -s on the firewall shows counters for
how many different types of ICMP messages have been received by the firewall.
Particular ones that can impact performance and be helpful to investigate further are:
- Fragmentation required but DF set (Type 1, Code 4)
- Precedence cutoff in effect (Type 1, Code 15)
- Source Quench (Type 4, Code 0) – very rare
- Redirect (Type 5)
- Time Exceeded (Type 11)

If nonzero values are noted for any of these in the netstat -s output, it is entirely
possible they came from the Internet and you have no control over their generation.
However, seeing these types of ICMP datagrams arriving on the firewall's internal
interfaces via tcpdump should be checked out. To display all ICMP traffic on an internal
interface that is not associated with ping testing traffic, use this command:
tcpdump -eni (interface name) icmp and not icmp[0]=0 and not icmp[0]=8

Page 58: One additional built-in CPU profiling tool brought to my attention is nmon:
Added to Gaia in R76, it serves many of the same functions as the top command
for monitoring CPU usage on the firewall, but in a more graphical format. As an
example, typing lowercase "L" provides a CPU usage graph; hitting "c" will show a
graph for a for multi-core systems. While most of these CPU monitoring statistics are
also available in top, a significant value-add of nmon is the ability to monitor and graph
disk usage, which is very handy if the wa percentage shown by top is excessive. Nmon
can also graph and monitor network interface activity, and serve as a useful stand-in for
the Traffic and System Counters reports that are available via the SmartView Monitor,
but only when a Monitoring Blade license is present. Thanks to Yasushi Kono of Arrow
ECS for submitting this tip.

Page 59: An easier way to see if cpwd has restarted any firewall processes since the
last cpstart or firewall boot is to run cpview then hit Overview. Down-arrow to the
bottom of the page, and you will see the counter "# of monitored daemons crashes since
last cpstart". If this value is nonzero, run cpwd_admin list to determine which daemon(s) are
having a problem.

Pages 59-60: If while running top you notice a process called kipmi0 consuming an
excessive amount of CPU on an open hardware firewall, this is a known issue and you
should consult sk104316: kipmi0 daemon consumes CPU at 100% on Open Servers
running Gaia OS.

Page 76: In addition to hitting “1” while running top to see individual core utilizations,
the command cpstat os -f multi_cpu can also be used to obtain this information.
Thanks to Yasushi Kono of Arrow ECS for submitting this tip.

Pages 84-87: Check Point has created an all-new SK documenting Security Policy
best practices here: sk106597: Best Practices - Rulebase Construction and Optimization.

Page 89: As stated in the book, setting fw_rst_expired_conn to 1 should always be
tried first to gracefully terminate application-based connections that aren't closing
properly and impacting perceived application performance. In some cases, however, this
will not fully remediate the situation, and you will be forced to go one step further with
this: fw ctl set int fw_reject_non_syn 1. A classic example of an application that
requires this firewall setting is SAP HANA traffic. This setting also handles client port
reuse out of state errors when RST packets from the server to the clients get lost (e.g. due
to policy install or packet loss).

Bear in mind, however, that this setting is quite likely to make your “Allsafe
Cybersecurity” auditor/penetration tester upset with you, since the firewall will now issue
a TCP RST for all received packets that are out of state and have the ACK flag set. An
auditor running a TCP ACK nmap scan will have it light up like a Christmas tree, with
tens of thousands of ports showing up as filtered instead of closed. For this reason,
setting fw_reject_non_syn to 1 is generally not recommended on an Internet perimeter
firewall, but may be acceptable on internal firewalls. Thanks to Andrew Craick of
Dimension Data for submitting this tip.

Page 90: The TCP State Logging function was introduced in R77, and is not available
on older firewalls. An alternative to this feature on pre-R77 firewalls is using the
Account option in the Track column of a rule. When this option is set for a rule, an
Accept entry is created at the start of the connection, just as it is when the Track is set to
Log. However, once the connection finishes (FIN, RST, idle time out etc.), the existing
log entry is converted from a Log type to an Account type. Additional statistics are then
provided for the connection, including the connection duration and number of
payload/data bytes sent and received by the connection. These statistics can be used to
infer the connection's behavior and assist in troubleshooting.

Page 97: R77.30 has added the ability to set the “Magic MAC” value via the Gaia web
interface, instead of by hand-editing the fwkern.conf file. During the firewall's postinstallation
dialog in the Gaia web interface, if “Unit is part of a cluster” is checked, the
new field “Cluster Global ID” will become editable:
The Cluster Global ID should be set identically on all members of the same
cluster, but be a unique value for different clusters. The Cluster Global ID can also be
configured and verified from the CLI in R77.30 and later. The command cphaconf
cluster_id get will display the current setting, and cphaconf cluster_id set <Cluster
ID Value> can be used to modify it. See sk25977: Connecting multiple clusters to the
same network segment (same VLAN, same switch) for more information. Thanks to Eric
Anderson of Netanium for submitting this tip.

Page 139: Some additional commands to check CoreXL licensing status are:
[Expert]# fw ctl get int fwlic_num_of_allowed_cores
fwlic_num_of_allowed_cores = 8
[Expert]# fw ctl get int fwlic_num_of_allowed_cpus
fwlic_num_of_allowed_cpus = 8
Thanks to Yasushi Kono of Arrow ECS for submitting this tip.

Pages 141 & 146: On these pages it was mentioned that SecureXL can accelerate
some IPSec VPN encryption/decryption operations. If SecureXL is enabled on your
firewall and you'd like to check if this is occurring, run fwaccel stats. Nonzero or
rapidly incrementing values in the Accelerated VPN Path section of the output indicate
that SecureXL acceleration of IPSec traffic is occurring.

Pages 149-151: I'm pleased to report that R77.30 has added the option to substantially
improve Firewall Worker Core load distribution via the new Dynamic Dispatcher Feature
(sk105261: CoreXL Dynamic Dispatcher in R77.30). This new Firewall Worker Core
load-balancing feature is disabled by default in R77.30; as a general rule of thumb you
should consider enabling this feature when the following conditions are present*:
- Firewall has 6 or more total cores
- Firewall Worker CPU loads consistently vary from each other by >10% **
- Firewall is NOT using a SAM card (i.e. 21000 series)

* Enabling this feature may break VoIP traffic being processed by the firewall
without a special hotfix, see sk106665: VoIP traffic, or traffic that uses reserved
VoIP ports is dropped after enabling CoreXL Dynamic Dispatcher.

** Keep in mind that all IPSec VPN and VoIP traffic can only be processed on
the lead (lowest-numbered) Firewall Worker Core as specified on page 141 (this
limitation has still not been lifted in R77.30). If there is substantial IPSec and/or
VoIP traffic traversing the firewall, exclude the lead Firewall Worker Core from
consideration when applying the 10% rule of thumb above.

Page 162: When attempting to re-enable SecureXL with IPSec VPNs present, watch
for this issue: sk102742: When SecureXL is enabled, traffic through the VPN trusted
interface is sent encrypted instead of clear. A separate hotfix must be obtained (this fix
does not appear to be included in the current R77.20 jumbo hotfix) or you can upgrade to
R77.30.

Page 169: While fwaccel stats -s provides useful acceleration packet counters
showing total number of packets processed by the SXL/PXL/F2F processing paths, you
can also view live throughput numbers for each of the three paths expressed in pps and
Mbps. Run cpview then hit Advanced...Network...Path:

Page 173: There are a plethora of stability fixes for 21000-series firewall models that
utilize a SAM card in R77.30. If using a SAM card, upgrading to R77.30 (or at least
loading the latest R77.20 jumbo hotfix) is highly recommended.

Page 176-178: Correction: Changing the IPS Scope setting from “Perform Inspection
on all Traffic” to “Protect internal hosts only” does NOT potentially make more traffic
eligible for the Accelerated Path. Setting “Protect internal hosts only” has a similar effect
to creating an IPS Exception, in that it can save CPU time in the Medium Path (PXL). So
while changing this setting does have a positive impact on performance (by potentially
saving CPU time in the Medium Path), it is not for the reason originally stated in the
book (that more traffic is made eligible for Accelerated Path).

Page 194: This section of the book spends a great deal of time trying to reduce firewall
CPU load on the Firewall Worker Cores, most of which occurs in the Medium Path
(PXL) on the vast majority of real-world firewalls. R77.30 has introduced an exciting
ability to view the top connections by CPU usage. This capability is a subset of the new
R77.30 Firewall Priority Queues feature (sk105762: Firewall Priority Queues in R77.30),
and the good news is that this helpful information can be obtained without having to fully
enable this feature. To obtain this ability, run the following command: fw ctl multik
set_mode 1 and reboot the firewall. Now, when running cpview, hit CPU...Top
Connections to see the top individual connections by CPU consumption.

Page 208: The book indicates that fw ctl zdebug drop can be used to determine
what non-logged IPS signatures are inappropriately dropping traffic. This statement is
not completely accurate, because the default reason for the drop shown by zdebug will be
very generic, and simply indicate it had something to do with IPS enforcement.
Warning: The following procedure will substantially increase the size and
memory requirements of enforcing the compiled policy on the firewall.
Use with caution on production systems.
To obtain the actual IPS signature name in the zdebug output, launch the
SmartConsole tool GUIdbedit and under Table...Global Properties...Properties change
variable enable_inspect_debug_compilation from false to true, and reinstall policy to
the firewall. This setting will cause additional debug information to be compiled into the
firewall's policy, such that the actual offending IPS signature name will be displayed in
the zdebug output.

Page 213: If the Website Categorization Mode has been set to Hold as recommended
in the book, and an unacceptable level of latency is encountered categorizing websites for
the URL Filtering function, additional statistics can be enabled in the Resource Advisor
Daemon (RAD). The RAD process handles interaction between the firewall and the
Check Point cloud for dynamic lookups of content such as URLs. Note that this daemon
is also used to update signatures and verify content for the Application Control, Anti-
Malware, and Anti-Virus software blades; therefore statistics are available for these other
three functions as well. To enable statistics for the URL filtering function specifically,
execute the command rad_admin stats on urlf. To view URL caching and cloud
interaction statistics, run cpview and hit Advanced...RAD:
Don't forget to turn off the statistics gathering with the rad_admin stats off
urlf command when finished!

Pages 220-221: The HTTPS Inspection feature was significantly enhanced in R77.30.
While many of the relevant fixes are included in the R77.20 jumbo hotfix, it appears that
there are many enhancements exclusive to R77.30 that can improve the functionality and
performance of the HTTPS Inspection feature. While the bulk of R77.30 HTTPS
Inspection operations appear to still occur in the Firewall Path, the firewall performance
impact of Bypass actions and SSL negotiation have been substantially improved.

Page 234: Alternatively, to view the firewall's New Connection Rate
(Connections/sec) from the CLI, run the cpview command and hit Network.

Page 275-276: I'm pleased to report that R77.30 has an available built-in fix for the
Hide NAT port allocation failures that are much more likely to occur when Hyperspect is
enabled, as discussed in #8. Ports used for Hide NAT source port reallocation can be
dynamically pooled among the Firewall Worker Cores, instead of being statically
assigned. This new feature is not enabled by default. It involves setting the
fwx_nat_dynamic_port_allocation variable from 0 to 1. There is a separate hotfix
available for R77.20 to add this functionality, however it does not appear to be a part of
the R77.20 jumbo hotfix yet. See sk103656: Dynamic NAT port allocation feature for
more details.

Page 282: If performing lab benchmarking of Check Point firewalls, be sure to enable
the following feature: sk105261: CoreXL Dynamic Dispatcher in R77.30. Network load-testing
traffic is infamous for its non-uniqueness, which can cause an imbalance of
Firewall Worker Core loading and severely crimp firewall throughput results. Also, if
performing benchmarking of HTTPS Inspection on a Check Point firewall, be sure to
enable HTTPS Inspection in “Test Mode” as detailed here: sk104717: HTTPS Inspection
Enhancements in R77.30. HTTPS Inspection Test Mode compensates for similar quirks
in HTTPS load-testing traffic and ensures accurate performance results.

Page 283: If you've reached this section of the book and can't obtain acceptable
performance from your firewall despite following all the tuning recommendations, and no
immediate relief is in sight in the form of newer, faster hardware, consider employing this
new R77.30 feature discussed in the Introduction to help make the most of what you do
have: sk105762: Firewall Priority Queues in R77.30.
Last edited by ShadowPeak.com; 2015-08-03 at 11:19. Reason: fixed typo p. 169
--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.




HTTPS Inspection Enhancements in R77.30
Solution
R77.30 introduces the following improvements and enhancements for HTTPS Inspection (which is supported on Security Gateways running only Gaia OS and SecurePlatform OS):
  • SSL Handshake Acceleration
  • Perfect Forward Secrecy (PFS)
  • Support for AES-GCM
  • Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass
  • Passive HTTPS Inspection - HTTPS Inspection Test Mode

SSL Handshake Acceleration

  • Overview:

    Public Key cryptographic operations, such as RSA and ECDH, require performing many mathematical operations, which causes a high load on CPU. By using the CPU's 64-bit instruction set, the operations can be done significantly faster than with 32-bit instructions.
    PKXLD is a 64-bit process that can run on a 64-bit operating system and perform the required cryptographic operations. It was added in order to achieve SSL handshake acceleration for HTTPS Inspection.
    Note: PKXLD process can not run on 32-bit operating system.

  • Enabling and disabling the usage of PKXLD process

    Usage of PKXLD process is enabled by default on Gaia 64-bit. The PKXLD process will be executed as needed by the WSTLSD process, if Gaia OS is running in 64-bit mode.
    Gateway
    mode    		To disable SSL Handshake AccelerationTo re-enable SSL Handshake Acceleration
    Security
    Gateway
    # touch $FWDIR/conf/pkxl_disable
# reboot

    # rm -i $FWDIR/conf/pkxl_disable
# reboot
    VSX
    # vsenv 0
# touch $FWDIR/conf/pkxl_disable
# reboot

    # vsenv 0
# rm -i $FWDIR/conf/pkxl_disable
# reboot
    Notes:
    • In VSX mode, the commands have to be executed in the context of VSX Gateway itself (context of VS0), and will affect all Virtual Systems.
    • In cluster, the commands need to be executed on each of the cluster members.
      Note: It is allowed to have some cluster members with PKXLD enabled, and some cluster members with PKXLD disabled.

Perfect Forward Secrecy (PFS)

  • ECDHE cipher suites

    ECDHE cipher suites were added to Multi-Portals and HTTPS Inspection, providing PFS support for those two products.
    R77.30 adds support for the following cipher suites within HTTPS Inspection:
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ID 0x00C02B)
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ID 0x00C02F)
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ID 0x00C013)
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ID 0x00C014)
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ID 0x00C009)
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ID 0x00C00A)
    R77.30 adds support for the following cipher suites within Multi-Portals (Software Blades Portals):
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ID 0x00C02F)
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ID 0x00C013)
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ID 0x00C014)

  • Configuration

    Important Notes:
    • The commands provided in this section must be run on Security Gateway / each cluster member in Expert mode.
    • These commands require complete restart of Check Point services ('cpstop;cpstart'), which will stop all traffic, and in cluster might cause a fail-over.
    • In VSX mode, the configuration is performed per Virtual System.
    • These commands survive reboot (changes are saved in Check Point Registry file - $CPDIR/registry/HKLM_registry.data).


    		DesignTo propose ECDHETo disable ECDHE proposal
    HTTPS connection from client machine to gatewayBy default, ECDHEis accepted, butAES-GCM with RSAis preferred.# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE 1# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE 2
    HTTPS connection from gateway to serverECDHE is proposed only if other proposals fail.# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE 1# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE 2

Support for AES-GCM

The following AES-GCM cipher suites are now supported with TLS 1.2 in Multi-Portals and HTTPS Inspection, improving throughput on platforms that support AES-NI *:
  • TLS_RSA_WITH_AES_128_GCM_SHA256 (ID 0x00009C)
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ID 0x00C02B)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ID 0x00C02F)
Notes:
  • AES-NI is supported by Check Point 12400 / 12600 / 13x00 / 21x00 / 41000 / 61000 appliances and by some Open Servers (refer to server's CPU specifications).
  • On platforms that do not support AES-NI, AES-GCM is similar in performance to AES-CBC + HMAC-SHA1.

Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass

Important Note: Probe Bypass should not be used if there is a proxy between the Security Gateway and the Internet.
Limitations of HTTPS Inspection Bypass Mechanism without Probe Bypass:
  • Every first connection to a site is inspected even if it should have been bypassed according to the policy.
  • Non-Browser Applications connections are dropped when HTTPS Inspection is enabled (even if bypass is configured).
  • Client certificate connections are dropped when HTTPS Inspection is enabled (even if bypass is configured).
Improvements introduced by Probe Bypass:
  • Bypass mechanism was improved to better reflect policy and resolve the above limitations:
    • Stop the inspection of the first connection to bypassed sites.
    • Allow bypass of Non-Browser Applications connections.
    • Allow Bypass of connections to servers that require client certificate.
  • New probing mechanism eliminates the need to inspect the first connection to an IP address unless it is required by the policy.
Status of Improved HTTPS Inspection Bypass feature (Probe Bypass) is controlled by the value of kernel parameter enhanced_ssl_inspection:
ValueExplanation
0Default value.
Probe Bypass is disabled.
1Probe Bypass is enabled.
Note: The steps below will affect all Virtual Systems in VSX mode.
To enable the Improved HTTPS Inspection Bypass feature (Probe Bypass) on Security Gateway / each cluster member, set the value of kernel parameterenhanced_ssl_inspection to 1.
  • To check the current value of a kernel parameter:
    [Expert@HostName]# fw ctl get int enhanced_ssl_inspection
  • To set the desired value for a kernel parameter on-the-fly (does not survive reboot):
    [Expert@HostName]# fw ctl set int enhanced_ssl_inspection 1
  • To set the desired value for a kernel parameter permanently:
    Follow sk26202 (Changing the kernel global parameters for Check Point Security Gateway).
    For Gaia / SecurePlatform OS:
    1. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not already exit):
      [Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf
    2. Edit the $FWDIR/boot/modules/fwkern.conf file in Vi editor:
      [Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf
    3. Add the following line (spaces are not allowed):
      enhanced_ssl_inspection=1
    4. Save the changes and exit from Vi editor.
    5. Check the contents of the $FWDIR/boot/modules/fwkern.conf file:
      [Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf
    6. Reboot the Security Gateway / each cluster member.
To disable the Probe Bypass on Security Gateway / each cluster member., follow the steps above to set the value of kernel parameter enhanced_ssl_inspection to 0.

HTTPS Inspection Test Mode

  • Background

    Under full HTTPS Inspection test load, the CPU usage of the Security Gateway is well under 100%.
    Performance measurements performed by testing equipment (such as Avalanche and Breaking Point) such as CPS, showed that throughput and latency behave irregularly.

  • Cause

    The cause for this irregularity is non-standard HTTPS implementation by the testing equipment in order to improve capacity and performance.
    Check Point's Active Inspection follows standard HTTPS.

  • Solution

    Passive HTTPS Inspection (HTTPS Inspection Test Mode) solves interoperability issues with testing equipment.
    However, it is important to note these limitations:
    • Intended only for lab use.
    • Supports inspection of inbound traffic.
    • Supports detection only - should be used only for testing purposes.
    • Performance results measured in Test Mode may slightly differ from real-world results.
    • ECDHE cipher suites can not be used in Test Mode because Passive decryption does not support PFS.

  • Configuration of HTTPS Inspection Test Mode

    Status of HTTPS Inspection Test Mode is controlled by the value of kernel parameter fwtls_passive_decrypt:
    ValueExplanation
    0Default value.
    Test Mode is disabled.
    1Test Mode is enabled.
    Note: The steps below have to be performed before the machine is placed under traffic load. If Test Mode is enabled during traffic load, existing connections may be dropped.
    To enable the Test Mode on Security Gateway / each cluster member, set the value of kernel parameter fwtls_passive_decrypt to 1.
    • To check the current value of a kernel parameter:
      [Expert@HostName]# fw ctl get int fwtls_passive_decrypt
    • To set the desired value for a kernel parameter on-the-fly (does not survive reboot):
      [Expert@HostName]# fw ctl set int fwtls_passive_decrypt 1
    • To set the desired value for a kernel parameter permanently (not recommended):
      Follow sk26202 (Changing the kernel global parameters for Check Point Security Gateway).
      For Gaia / SecurePlatform OS:
      1. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not already exit):
        [Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf
      2. Edit the $FWDIR/boot/modules/fwkern.conf file in Vi editor:
        [Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf
      3. Add the following line (spaces are not allowed):
        fwtls_passive_decrypt=1
      4. Save the changes and exit from Vi editor.
      5. Check the contents of the $FWDIR/boot/modules/fwkern.conf file:
        [Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf
      6. Reboot the Security Gateway / each cluster member.
    To disable the Test Mode on Security Gateway / each cluster member, follow the steps above to set the value of kernel parameter fwtls_passive_decrypt to 0.

  • Additional configuration for Session Rate optimization in HTTPS Inspection Test Mode

    To optimize the Session Rate in HTTPS Inspection Test Mode, increase the maximal number of entries in the following kernel tables:
    • fwtls_state_map
    • cptls_sessions
    Follow these steps:
    Important Note: These changes will affect all Security Gateway / Clusters managed by the involved Security Management Server / Multi-Domain Security Management Server.
    1. Connect with SmartDashboard to Security Management Server / Domain Management Server.
    2. Go to 'File' menu - click on 'Database Revision Control...' - create a revision snapshot.
    3. Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).
    4. Connect to command line on Security Management Server / Multi-Domain Security Management Server.
    5. On Multi-Domain Security Management Server, switch to the context of the involved Domain Management Server:
      [Expert@HostName]# mdsenv Domain_Name
    6. Backup and edit the relevant table.def file per sk98339 - Location of 'table.def' files on Security Management Server.
    7. Change:
      from
      /*********
 * fwtls *
 *********/

fwtls_state_map = dynamic keep limit 100000 hashsize 32768;
cptls_sessions = dynamic expires 3600 limit 100000 hashsize 32768 sync kbuf 2;
      to
      /*********
 * fwtls *
 *********/

fwtls_state_map = dynamic keep limit 1000000 hashsize 32768;
cptls_sessions = dynamic expires 600 limit 1000000 hashsize 32768 sync kbuf 2;
    8. Save the changes in the relevant table.def file.
    9. Connect with SmartDashboard to Security Management Server / Domain Management Server.
    10. Install the policy onto the relevant Security Gateway / Cluster object.

Related solutions:

Applies To:
  • 01418393 , 01456436 , 01467522 , 01470952 , 01471765 , 01474667 , 01479662 , 01510285 , 01516601 , 01522323 , 01546352 , 01551219 , 01556280 , 01577129
  • 01482072


Posted by at