Explanation of the policy verification function of Check Point.

Problem:

Check Point utilizes a policy verifier which verifies the firewall / NAT policy for you. This is an extremely handy feature that not many firewalls have, that saves you from having extraneous rules or rules that can’t be hit due to blocking rules above it.

This is the first part of the policy installation process, and a policy WILL NOT install if verifier fails for any reason (it will not even continue to attempt to).

You can also run the verifier by itself, by going to Menus > “Policy” menu > “Verify…”.

This is important to understand as just moving the rule to make the policy install is possible (by moving the conflicting / hidden rule above the other rule), but especially in the case of hidden rules, this creates extraneous load on the firewall FOR NO REASON. Keep in mind that EVERY new connection is evaluated against the firewall rulebase, so if you have a rule that permits a lot of connections, so just move a different less-broadly-permitting rule above that, then you are making EVERY new connection that would normally hit that broadly-permitting get evaluated by the lesser-permitting rule too.

Best practice is making new rules at the bottom of the permitting rulebase (IE above any “cleanup” rules) so verifier can confirm this. If the rulebase is sectionalized, then make new rules at the bottom of the correct section (EG, if the new rule has an internal source and the destination is an external host, then belongs in “outbound”).

Solution:

There are two common types of verification failures as pertains to firewall and NAT policy:

1) Rule X HIDES rule Y for service(s) A B C …

This means that a rule above rule Y actually already permits this connection, so including those services in rule Y IS EXTRANEOUS, so those services must be removed from the rule. You will only get a hides verifier failure if rule X has sources AND destinations that encompasses ALL sources AND destinations of rule Y. For example, if srcY is a host 10.10.10.10 and dstY is 1.1.1.1, then srcX can be a network of 10.10.0.0/16 and dstY can be ANY. Like sources and destinations, services can be encompassing, but as Check Point treats services as separate entities, usually only an ANY or a group including the specific service will count as encompassing. IE service ranges will not hide a specific service.

Resolve by investigating rule X, does it include all the services that you are trying to make rule Y for? If yes, then that entire rule is extraneous and can be removed. If not, then just remove the services which rule X hides. The exception to this is a requirement of logging. If there is a requirement to log Rule Y and Rule X does not have logging then you must move Rule Y above Rule X to have it log the connection, but PLEASE VERIFY THE REQUIREMENT FOR LOGGING. Logging may not be required so the extraneous load may still be for no reason…

2) Rule X CONFLICTS with Rule Y (for services A B C)

This means that Rule X is a higher BLOCKING rule to the permitting rule of Y, which creates the conflict.

Resolve by moving rule Y above rule X, BUT please get an engineer to review this RFC! (post-completion is ok, but we need to determine why the conflict and if the requirement of the block supersedes the RFC, such as by creating an unnecessary security risk).