Check Point configuration mistakes - Top 10

[Danny]

When reviewing Check Point security configurations I often experience similar configuration mistakes. Below is my Top 10 list of very typical mistakes with R77.x installations. Please share yours.

1. Missing documentation of actual configuration (network map, recent migration documents, comment fields)

2. Use of Non-standard ASCII characters or reserved words (improved in R80)
(sk105708, sk40768, sk104077, sk85540, sk106573, sk40179, sk34990)

3. On-board NICs, Broadcom NICs or Non-Intel NICs in use (Open Server)
(HCL NIC limitations, sk44584, Max Power Firewalls)

4. Missing segmentation of firewall management (SmartCenter) to secure the firewall infrastructure

5. Direct login into Bash shell for admin account or identical passwords for Clish login (User Mode) and Bash login (System Mode)
(most often to enable SCP file transers, because SCP-only shell is not known)

6. Missing firewall stealth rules in header of rulebase
(How to create a stealth rule)

7. Unidentified bridges between networks / Unidentified error messages in log files
(e.g. central firewall management was configured as gateway instead as host object and has two or more physical networks connected)

8. VPN tunnels are not consistently secured with VPN certificates
(How to set up certificate based VPNs with Check Point appliances)

9. Stateful inspection or IP address spoofing is disabled

10. Missing optimizations (CoreXL, SecureXL, drop & capacity optimization, rules not ordered by hit count, no use of color codes, missing naming convention etc.)

[Tomer_Sole]

I would like to share Check Point's vision in avoiding such mistakes. One of our guidelines is to create a product which can save users from potential misconfigurations while maintaining the occasional exceptions, as sometimes the business need is stronger than the ideal security.

Some of the items that you mentioned were a result of the Management Platform of R77. With R80 security management architecture, we made 2 improvements that prevent this scenario (And we will update the SK's to clarify that):

1. An improved validations mechanism (see page 12)

2. Automatic translation of nonstandard characters

2. Use of Non-standard ASCII characters or reserved words
(sk105708, sk40768, sk104077, sk85540, sk106573, sk40179, sk34990)

Another item that you mentioned was:

rules not ordered by hit count

I would like to share that the new R80.10 Gateway comes with a new packet matching mechanism which eliminates the need to order rules by their hit count. This has been tested at customers' production environments and was found to bring new performance improvements with their existing security policies.

The following items can be avoided when using Compliance Blade:

1. Missing documentation of actual configuration

6. Missing firewall stealth rules in header of rulebase
(How to create a stealth rule)

9. Stateful inspection or IP address spoofing is disabled

We are actively improving Compliance blade in order to include other potentials of misconfigurations. 

This community is a great resource for helping us to improve! 

[Sven_Glock]

May be this is a good place to drop an advertisement for Check Point Compliance blade! 

As far as I know compliance blade can help to avoid some of the above mistakes.

[Kristof_Vermael]

Missing segmentation of firewall management (SmartCenter) to secure the firewall infrastructure

Segmentation is not enough as the implied rules will allow traffic from everybody when not setting the "GUI Clients" correctly in cpconfig.

I've seen customers with firewall configured rule for access to Smartcenter, but not a single hit due to implied rules.

So : not configuring "GUI Clients" is for me a top 10 mistake.

[peter_schumache]

Here are some more typical mistakes:

Not using the external (public) IP as the general IP in the VPN Gateway object

Defining 3rd-party VPN Gateways as "externally managed Check Point Gateways"

Defining bi-directional NAT-rules for unidirectional traffic

Performing NAT where NOT required

(especially with automatic NAT rules)

Mixing up encryption domains with security rules

(e.g. define an encryption domain as a set of hosts which appear in security rule)

Inconsistent routing tables in clusters (Gaia Level)

Definining bidirectional traffic for "many to one" and "one to many" in same rule

(enables undesired "many to many")