Checkpoint_Technology

A Quick Recap

CheckPoint security revolves around 3 key components

• GUI Clients – This is is mainly SmartConsole and it’s contained applications such as Update, Tracker and Dashboard. All release candidates for this are a separate track to the main product suite and HFAs for this set are independent of the main software release. These are effectively the software configuration and interaction between the user and the SMS/Gateways/Reporting
• Security Management – Responsible for all management of the CheckPoint system. It interacts in User-Mode Processes (Explained later) in order to configure all product suites and relies on the following (most significant) processes
  • FWM
  • FWD
  • CPD
  • FWSSD
  • CPWD
• Gateway – The gateway is the device that enforces your security policy. It is really just a computer running software including an OS as normal (IPSO, SPLAT,GAIA etc.) and as such is technically vulnerable. To get around this the firewall runs in the Kernel of the system, separating the hardware from the OS and protecting itself. The above listed processes run as User-Mode processes in the OS. Traffic flow is therefore NIC -> Kernel -> OS (Including IP stack) -> User-Mode features

User and Kernel Mode Processes

So what’s the difference between the two? The Kernel is in effect the binder for the Hardware to Software traffic flow. It intercepts all traffic and provides the interaction between the Modules and Drivers. Modules here (in the Firewall-1 Kernel) would included processes for NAT, Security Enforcement, Encryption and Decryption. Pretty much the things we think of that make it a firewall. Every bit of data (or packet) that arrives at the firewall will hit the Kernel and be inspected. the inspection decides what happens to it, whether it be dropped, forwarded or some other operation applied such as crypto functions.

On top of this (almost literally!) resides the User-Mode. These processes allow the Gateway to utilise functions of the underlying operating system in a protected environment. An example of these are the processes listed earlier such as FWM and FWD.

Communication is handled from the Kernel to User-Mode using traps (Think SNMP) and from User-Mode to Kernel using IOctl, allowing the entity to call a function in the Kernel and write to it.

This entire segregation here is necessary and understanding it allows you to debug effectively. For example, if your log server is no longer receiving logs, why? The Security Policy (In the Kernel) looks fine and you have enough disk space. Start debugging the right User-Mode process and it will usually direct you where to look – FWD. This can save a lot of time.

By Process of Elimination

The core process we find on every CheckPoint product is CPD. This is the life of the devices and handles many things. The primary features we may see it handling are:

• SIC
• Status (AMON status pulled from GW/SMS and sent to SmartEvent)
• Message handling between Firewall-1 processes
• Policy installation on Gateways

I suppose you could think of it as a conductor, it calls and controls how other parts of the system interact.

FWM is a management process that exists on all management products such as the SMS. Some of the functions it does are:

• Talking between the GUI and SMS (SmartConsole)
• Database Editing; adding objects, users rules etc.
• Security Policy Compilation
• Log display
• Management HA Sync between SMSs

Logging to internal and external servers including the management server is handled by FWD(TCP/257). It also handles calling some child processes such as VPND and interacts with policy installation. FW commands in the shell such as fw ctl chain are also handled here

FWSSD is spawned by FWD as a child process and runs the Security Servers. There are multiples of these that run, one for each service and are labelled as in.xxx or out.xxx where xxx = service (such as DLP or SMTP). Some examples are:

• in.asmtpd = SMTP Security Server
• in.ahttpd = HTTP Security Server
• in.emaild.smtp
• in.emaild.pop3

You can view these by entering Expert mode and running

cat $FWDIR/conf/fwauthd.conf

THE EBB AND FLOW (PLUS CHAINS)

One of Checkpoints’ inventions as they like to tout (and rightly so) is the idea of Stateful Inspection, which we have looked at before. The overview here is that it allows a packet to be identified not only by it’s IP and Port, but also by it’s state, flow and extensibility. This allows us to allow our firewall to add in permit statements as and when needed based upon the conversation it is having – allow traffic to the Internet from your LAN and return traffic is allowed by default, but only once verified and by conversation. The other thing to note is that passing traffic based upon a state table is MUCH faster than sequentially querying a rule base each time a packet comes in (providing it has already been identified). We will cover this more later.

Packet Flow

A firewall has two main directions that traffic can flow, and most of the time it will abide by both. Simply this is “Inbound” and “Outbound”. Sounds simple, and really it is – a packet heading to the firewall is inbound and traffic exiting the firewall is outbound. This is an important consideration when reflected upon as follows. We receive a reply packet that has traversed over a VPN from a partner company. What do we do with it? Common sense says “decrypt the packet and apply to to a rule base”. Common sense would mostly be right, but let’s say the packet was NATd originally on our firewall, what then? Looking at this logically allows you to mostly guess what happens, but the real order of operation comes from what is known as an FW CTL Chain, or Firewall Control Chain. These are similar between gateways but can vary depending on the blades you’re running. Some basic facts around these

• The Kernel makes no assumptions – just because another part of the kernel may have inspected it before, it takes no chances and will do so again
• Some functionality occurs both inbound and outbound
• Each direction has its own chain modules and they will vary slightly
• The modules known as Handlers, each decide whether to pass or drop the traffic based upon their inspection role
• Inspection is performed on virtually defragged packets

The gateway will assume however that if something didn’t come IN an interface (or chain) then it (the gateway) generated the packet. Likewise, if it came through an inbound module then it didn’t send it.

Some example chain modules are:

• IP Options (strip in)
• IP Options (strip out)
• VPN Decrypt (Inbound)
• IP Options Restore
• HA forwarding
• VPN Encrypt (Outbound)
• TCP Streaming

Expert@CPGW-01]# fw ctl chain
in chain (20):
0: -7ffffff0 (f163cf00) (00000001) tcpt inbound (tcp_tun)
1: -7f800000 (f21eadc0) (ffffffff) IP Options Strip (in) (ipopt_strip)
2: -7d000000 (f1644440) (00000003) vpn multik forward in
3: – 2000000 (f162ab50) (00000003) vpn decrypt (vpn)
4: – 1fffff8 (f16358e0) (00000001) l2tp inbound (l2tp)
5: – 1fffff6 (f21ec0c0) (00000001) Stateless verifications (in) (asm)
6: – 1fffff5 (f2788530) (00000001) fw multik VoIP Forwarding
7: – 1fffff4 (f229f6f0) (00000001) fw early SIP NAT (sipnat)
8: – 1fffff2 (f16515d0) (00000003) vpn tagging inbound (tagging)
9: – 1fffff0 (f1628bd0) (00000003) vpn decrypt verify (vpn_ver)
10: – 1000000 (f2241650) (00000003) SecureXL conn sync (secxl_sync)
11: 0 (f219ae00) (00000001) fw VM inbound (fw)
12: 1 (f2204d00) (00000002) wire VM inbound (wire_vm)
13: 2000000 (f162b8b0) (00000003) vpn policy inbound (vpn_pol)
14: 10000000 (f2247410) (00000003) SecureXL inbound (secxl)
15: 7f600000 (f21e14e0) (00000001) fw SCV inbound (scv)
16: 7f730000 (f232e6b0) (00000001) passive streaming (in) (pass_str)
17: 7f750000 (f2497090) (00000001) TCP streaming (in) (cpas)
18: 7f800000 (f21eb150) (ffffffff) IP Options Restore (in) (ipopt_res)
19: 7fb00000 (f2459170) (00000001) HA Forwarding (ha_for)
out chain (17):
0: -7f800000 (f21eadc0) (ffffffff) IP Options Strip (out) (ipopt_strip)
1: -78000000 (f1644420) (00000003) vpn multik forward out
2: – 1ffffff (f1629c80) (00000003) vpn nat outbound (vpn_nat)
3: – 1fffff0 (f2496f10) (00000001) TCP streaming (out) (cpas)
4: – 1ffff50 (f232e6b0) (00000001) passive streaming (out) (pass_str)
5: – 1ff0000 (f16515d0) (00000003) vpn tagging outbound (tagging)
6: – 1f00000 (f21ec0c0) (00000001) Stateless verifications (out) (asm)
7: 0 (f219ae00) (00000001) fw VM outbound (fw)
8: 1 (f2204d00) (00000002) wire VM outbound (wire_vm)
9: 2000000 (f162b360) (00000003) vpn policy outbound (vpn_pol)
10: 10000000 (f2247410) (00000003) SecureXL outbound (secxl)
11: 18000000 (f22cf850) (00000001) fw record data outbound
12: 1ffffff0 (f1635570) (00000001) l2tp outbound (l2tp)
13: 20000000 (f1629ef0) (00000003) vpn encrypt (vpn)
14: 60000000 (f163d160) (00000001) tcpt outbound (tcp_tun)
15: 7f700000 (f2499100) (00000001) TCP streaming post VM (cpas)
16: 7f800000 (f21eb150) (ffffffff) IP Options Restore (out) (ipopt_res)

Above is an example of the chains

X – Module location in chain (Serial Number)

X – Chain Position

X – Function Pointer

X – Mode: Stateful Mode

X – Mode: Wired Mode

X – Mode All Packets (00000003 & ffffffff are identical)

X – Chain Name

The location of modules within the chains are relative and can differ between gateways depending on the modules installed. the Chain Position is an absolute number and never changes between gateways

INSPECT AND INSTALL PROCESS

Some of the sections we go over are going to be partial recaps on others. A lot of the course does this, especially considering how closely they are tied together within processes (not to mention my less than professional writing ability). After looking at the inspection areas, lets have a look at the “complete” packet flow.

1. Packets arrive at the NIC on the appliance inbound, for the sake of assumption it’s from an internal client accessing the web
2. The firewall kernel will process inspection on the packet
3. Once a packet is matched against the rulebase a log is sent to the Gateways’ user-mode FWD process
4. The GW FWD process sends a log to the SMS FWD process using the CPD daemon
5. FWM on the SMS logs to SmartConsole (SmartviewTracker)
6. Lastly the packet is routed (usually, unless it’s VPN for example) using the OS to the relevant outbound NIC where the kernel intercepts and does its outbound work

The policy installation process is am ore interesting one, simply because compared to certain other firewalls, there is rule computation, compilation and composition based upon a number of internal files within the units. This is also an extremely good reason (There are many) to have a distributed deployment as opposed to standalone. Have your SMS sitting on a secured internal VM where it doesn’t matter what happens to the gateways – you can’t recover as easily from a failure by just copying and pasting config like you can on an ASA or NetScreen. Here’s an overview of policy installation:

1. Create your policy within Smart Dashboard – let’s assume it’s just some outbound rules and a few manual NATs with a policy called SUPERSECURE
2. When you save you create a new file called SUPERSECURE.W within $FWDIR/conf. All these aresaved within rulebases_5_0.fws
3. The fwm_gen process then compiles your selected policy (SUPERSECURE.W) into a .pf file within the same location.

The .pf files themselves are composites from a number of files: *.W and objects.C and are stored in machine language within $FWDIR/conf. Objects.C is also a file specific to the policy installation only, it exists in $FWDIR/database and is relevant to that gateway only. Objects_5_0.C contains all objects defined, whether in use within that policy or not and exists on the SMS under $FWDIR/conf

One reason for this is as such: if you have an SMS, say a Smart-1 that is managing multiple nodes, they may share the same objects. Each gateway may have VPNs between them so will need to know the CheckPoint Gateway objects, their subnets, ports etc. The objects_5_0C file means that you only need to have them specified once, why duplicate? Each gateway then borrows the relevant parts from this file and has its own objects.C file created for it.

Actually installing the policy goes through an umber of steps:

1. Initiation – You click your install button within SmartDashboard to start the process and provide information it needs (such as the gateway it needs to install on, does it matter if it fails one one, DB revision?)
2. Verification – This is where the SMS goes over your policy to ensure it meets a number of rules before continuing. An example here might be flagging up one rule specifically hiding another and it will fail (or pass if it’s fine)
3. Conversion – The databases have their relevant information taken and converted to separate formats needed by later processes
4. Compilation & generation – Here the policy is translated to the INSPECT language and then passed to the INSPECT compiler to be…compiled!
5. CPTA – CheckPoint Transfer Agent uses SIC to send the relevant policy to the necessary gateways
6. Commit – The gateway loads up its new policy

The processes themselves handle the process as follows:

1. SmartConsole CPMI sends the policy installation command to FWM on the SMS
2. FWM then does its verification and compiling of the policy elements. This is then sent to CPD
3. CPD generates the necessary code  and compiles it before initiating CPTA to forward the policies to the relevant gateways for installation
4. CPD on the gateway receives the compiled policy and verifies it
5. FWD then updates the relevant processes – VPND and FWSSD for example, with the new policy elements CPD then starts the work of replacing the kernel
6. As the new policy is getting ready for replacing, the GW starts to queue all incoming traffic and stops forwarding
7. The Atomic load (What a cool name) then starts where by the kernel is replaced
8. Queued traffic is now forwarded through the new policy

KERNEL TABLES (BITS TO CHECK)

Although we have mentioned the  Kernel a fair bit and identified that certain processes run in User Mode or Kernel Mode, we haven’t touched on a massively practical application of knowing this (other than using them to identify the possible cause of  an issue). Checkpoint units themselves have a lot of tables – you can see this list easily enough using the command

fw tab -s | more

That gives you a summary list similar to:

Fair bit of info, but what we really want to interrogate is the contents of some of the tables. Lets look at the connections table

[Expert@CPGW-01]# fw tab -t connections -f | more
Using cptfmt
Formatting table’s data – this might take a while…

13:06:25 xx.xx.xx.xx > : ———————————–(+); Direction: 0; Source: 172.23.117.111; SPort: 53874; Dest: 192.168.10.202; DPort: 161; Protocol: udp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 172.23.117.111; SPort_1: 53874; Dest_1: 172.20.140.202; DPort_1: 161; Protocol_1: udp; FW_symval: 17; product: VPN-1 & FireWall-1;

13:06:25 xx.xx.xx.xx > : ———————————–(+); Direction: 1; Source: yy.yy.yy.yy; SPort: 80; Dest: 172.19.201.16; DPort: 3555; Protocol: tcp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 172.19.201.16; SPort_1: 3555; Dest_1: yy.yy.yy.yy; DPort_1: 80; Protocol_1: tcp; FW_symval: 5; product: VPN-1 & FireWall-1;

These are great. Lets digest what we can see.

The examples shows us:

• Direction: O, so we know it is inbound from an external source initially.
• We can see the source and destination IPs and port numbers
• We can see the protocol type too
• Direction: 1, this is outbound
• Notice the difference between the way the UDP and TCP connections are listed. I don’t know why this is but think it’s to do with the connection-oriented/connectionless style of the protocols and linking to their previous packet.

We can’t see anything relating to the information on it’s interface or sequence number. I actually struggled to find anything solid about how to interpret this table, there just doesn’t seem much out there, even on other blogs or the CP support knowledge base. I have my own assumptions but as I can;t prove them, I won’t pass information around.

The connections table itself achieves some very important goals for firewall security and performance:

• It’s faster to pass traffic based upon an entry in the state table than it is querying the firewall policy as part of the INSPECT module
• Replies are allowed back – this means we don’t need to add specific reply entries in to our rule base
• Stateful items such as TCP sequencing, AAA, NAT etc. can all be handled within the table

New Gateway Ping Test

if you build a new gateway and wants to test connectivity across the interfaces and the ping test does not work, do the following:

[Expert@myfw-fwa:#   fw unloadlocal
[[Expert@myfw-fwa:#  cpstop
[Expert@myfw-fwa:#   sbin/sysctl -w net.ipv4.ip_forward=1

The History of Stateful Inspection

Stateful Inspection, who invented it, really?

Patent rights to Stateful Inspection belong to Check Point and Gil Shwed, according to US patent 5,606,668. The patent application was filed in 1993.

However,  Palo Alt's  Nir Zuk does not hesitate crediting himself for developing Stateful Inspection.
Here is the quote from Palo Alto web site: "Nir was... a principal engineer at Check Point Software Technologies, and was one of the developers of stateful inspection technology."

It is very accurate, isn't it? "One of the developers..." Of course he was, he worked with Check Point from 1994 till 1999. He could not possible invent it, considering half a year gap between filing the patent application and his start in Check Point.

Should not confuse us much, right? It must be something else.

In Nir's interview to IT World in April 2010 when talking about his Check Point years he says:  "We invented a technology called stateful inspection, on which all network security technology today is based." This is a bigger statement, but again, if by "we" he means "we, Check Point", there is probably nothing wrong there.

The article itself is peculiar. There he also claims he single-handedly developed Floodgate product in 1999 and then was practically pushed out of the company by Israeli developers for doing so. I will not comment on that, as we are discussing Stateful Inspection topic only.

There is one more article from 2008 published by InformationWeek. The title is very promising: "Who invented the firewall".

Believe it or not, the very first sentence credits Nir Zuk. It says: "Nir Zuk says he developed the technology used in all firewalls today." The article is brilliant, it its own way.

The author, Kelly J. Higgins is apparently not fluent with FW technical terms. I would not blame her much, although her attempt to crack the case does not deserve full marks, in my humble opinion. She quotes one of the experts in the article though, saying: "Zuk was the father of the stateful firewall product at Check Point…"

Funny, Check Point is only mentioned in the article if if referenced to Nir Zuk. Here is another example: "Meanwhile, Zuk, who helped build Check Point's firewall technology, isn't shy about taking credit for the first commercial firewall."

If I would read this without any background, it would be clear to me: Nir does it all. He is the father, developer, inventor and, finally, helper. All praise Nir.

Well, the whole story is a very good example of bold PR (If you have ever seen Palo Alto marketing presentation, you know what I am referring to) and inaccurate journalism.

Nir Zuk was one of the developers, all right. The rest is just noise on the channel

Article Credit:

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:

1. Checkpoint R80

2. Sandblast Solution and Endpoint-Sandblast-Agent

3. Checkpoint New Product Line

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 Valeri Loukine

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

Rate This

Solution ID	sk104717
Product	HTTPS Inspection
Version	R77.30
OS	Gaia, SecurePlatform 2.6
Platform / Model	All
Date Created	19-May-2015
Last Modified	21-Feb-2016

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 Acceleration	To 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).
  
  

  	Design	To propose ECDHE	To disable ECDHE proposal
  HTTPS connection from client machine to gateway	By 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 server	ECDHE 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:

Value	Explanation
0	Default value. Probe Bypass is disabled.
1	Probe 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:
  

  Value	Explanation
  0	Default value. Test Mode is disabled.
  1	Test 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:

• sk108202 - Best Practices - HTTPS Inspection
• sk104562 - Supported cipher suites for HTTPS Inspection
• sk101223 - MultiCore Support for SSL in R77.20 and above
• sk107744 - Unable to access some HTTPS sites after enabling HTTPS Inspection "Probe Bypass" mechanism
• sk108654 - How to control support for SSLv2 handshake in HTTPS Inspection

Applies To:

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