Layers and the cleanup rule

[Tomer_Sole]

An important aspect in R80.10 security management and gateways is the clean-up rule at the end of every layer.

Ordered and Inline layers in R80.10 always end with a clean-up rule. This makes sure that there is always a match.

So even if a user tries to remove the last rule:

He will get this message that basically says there's an implicit cleanup rule on the gateway.

(you can actually follow-up on the best practice to keep an explicit cleanup rule by using the Compliance blade)

So what's new?

In our previous versions, the clean-up rule was a constant value:

• Any, any, drop at the end of the Firewall layer
• Any, any, accept at the end of the Applications layer

(either as an implicit rule or explicitly visible in SmartDashboard/SmartConsole)

With R80.10:

• You get better visualization of that behavior (as seen in the screenshot above)
• You can configure the action: accept or drop.

You can control the action of that implicit cleanup rule by editing the layer. This will only matter if there's no explicitly defined cleanup rule at the end of the layer.

Let's see how this can look like in different usages of layers:

Inline Layers:

The fact that there is always a match in the inline layer, eliminates any impact of the inline layer's rules outside the inline layer.

In this example, rule 5 has an inline layer.

• When changing the inline layer's rules, we can't change the enforcement for rules 1-4, because they will always be matched before rules 5-12.
• When changing the inline layer's rules, we can't change the enforcement for rules 6-11, because matching on rule 5 always ends with matching any of the rules 5.1-5.7. There will always be a match, because the cleanup is always present.

Ordered Layers:

Some ordered layers can work in whitelist mode, while others can work in blacklist mode. For example, you can work with an ordered layer of "blocked unaccepted traffic" which accepts only on the last rule.

Or you can work with an ordered layer of "accepted specific web applications" which blocks the rest of the web applications.

Either way, it is OK to put an "any, any, accept" rule as the clean-up rule for an ordered layer while still ensuring unexpected traffic will be dropped, by providing an additional ordered layer with an "any, any" drop" rule.

Read more about using layers here: Layers in R80 

Note: Multi-domain layers work differently here.

A local policy can have global rules and a "Domain layer" between them. When the gateway evaluates the rules in the local policy, if there was no match for the global rules at the top of the rulebase, it starts to evaluate the rules from the domain layer. If there was still no match for those rules, the global rules that were created below the domain layer are evaluated. So there is no cleanup rule before or after the domain layer.

Read more about Domain Layers here: https://community.checkpoint.com/thread/1102 

[PhoneBoy]

I really do appreciate the cue from SmartConsole on the implicit rule (both the fact it automatically creates one and tells you what happens if you delete/misconfigure it).

One other visual cue that would be nice to add is when you use ordered layers is something that tells you that "Accept" really means "move to next layer." 

So, for example, where you are managing a pre-R80 gateway, the Access layer rule has actions that say "Accept (Move to Application Layer)" or something similar.

[Kurt_Abela]

In the thread High CPU after upgrade from 77.30 to 80.10 Timothy Hall was explaining that configuring an explicit clean-up rule 'Allow All' application control layer causes all traffic to pass through PXL.

I believe this should no longer be an issue with Layers as taking the above example, rule 5 has destination 'Internet'. But what above the clean-up rule at the end (bottom) of the policy, will this have the same impact as before?

[Timothy_Hall]

I assume you are looking at the last screenshot above.  Parent rule 5 can only catch traffic from the internal network to the Internet (this assumes the firewall's topology is completely and correctly defined and object "Internet" is being calculated correctly) and that is typically where we want APCL/URLF processing in PXL as a result. 

If there is an explicit cleanup rule at the end of this policy with a destination of "Any" and an action of Accept, it could cause internal-to-internal traffic to get sucked into PXL at LAN speeds depending on how the Source is defined.  A destination of "Any" in an ordered APCL/URLF layer rule should definitely ring alarm bells for optimization.  In an inline layer capable of APCL/URLF use of "Any" in a destination could also be cause for concern, but not in sub-rule 5.7 above because the firewall can't reach that rule unless the destination has already matched "Internet" (not Any) on parent rule 5.

Hopefully I'm understanding your question correctly.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Daniel_Collins]

Thank you for this. 

This is me commenting more for other people to see, that have perhaps tried to do something that I have:~

If you want to create an ordered layer, such as a "Management"  layer before your access control policy it will not behave the way you expect. When you have multiple access control ordered layers, traffic must be accepted by all of them in order to work. If traffic is dropped by the first layer though, that's it - it will be dropped but accepts must be matched in BOTH rulebases. 

I can't see a scenario where I'd actually ever use a tiered access control policy like this, for that reason. Except for perhaps some global drop rules you might want to apply across multiple policies but for accept traffic, it makes the logic complicated and doesn't behave the way you would expect it to. 

Like others, I was trying to replicate the functionality of the global policy and I just don't think this is possible with the way the rule-matching and ordered layers work. 

I am guessing this is intentional, so that customers with those needs use the MDSM product with the Global Policy. Otherwise the layers are there for you to segregate out certain blades, more than policies - like having a portable, modular Application Control policy that you can re-use. I would say, I don't think the way I have configured it would ever work yet I can certainly see people trying to use it like that - it is perplexing why it'd let you create a second ordered layer "Firewall" policy when it wouldn't behave the way most people would expect.

[Daniel_Collins]

Oh and to add, the implicit action of accept is needed - for unmatched traffic to flow down into the next layer. So the implicit clean-up action, defines whether we drop the traffic at the end of the layer or it proceeds to the next layer for further matching. An accept in the first ordered layer means it moves onto the next for a second match etc.