What is the point of ordered layers for Accept rules?

[Vehemont]

I am playing around with ordered layers but I am struggling to understand the use. I have a simple setup, one policy with two ordered layers with only firewall enabled on each ordered layer. The first ordered layer named "Test" is a shared layer. I want an ordered layer to be shared across multiple policies with the objective to allow a server to ping and RDP to a workstation.

Here is my policy for the shared ordered layer named "Test" and a single rule named "Allow Servers to Workstation", and an implicit cleanup rule of Accept. The "Network" policy does NOT contain a rule to accept the "Allow servers to workstation" rule traffic. 

Trying to ping from the WindowsServer to the WindowsWorkstation results in a drop log, and in the "matched rules" section I see an accept for the "Test" layer, but a drop for the "Network" layer.

Now that this has been established, I can move onto my questions. In the R81.20 Security Management Admin guide I see the following line under the explanation of ordered layers. 

"When a packet arrives at the Security Gateway, the Security Gateway checks it against the rules in the first Ordered Layer, sequentially from top to bottom, and enforces the first rule that matches a packet."

I agree the packet is checked against the rules in the first ordered layer, sequentially from top to bottom, but I do not agree that the Security Gateway enforces the first rule that matches the packet, as proven by the log above. The log was accepted by the first rule that matched the packet and this was not enforced, then was dropped in a later layer which was then enforced, even though the packet had already matched on an accept rule above. Further down there is another line:

"If the Action of the matching rule is Drop, the Security Gateway stops matching against later rules in the Policy Rule Base and drops the packet. If the Action is Accept, the Security Gateway continues to check rules in the next Ordered Layer."

So in order to have traffic be accepted with the use of a shared layer, I need to have two firewall rules. One in the Test layer, and one in the Network layer. At the top of the admin guide there is a section for "The Need for Ordered Layers and Inline Layers" and another line states:

"- Improve performance by reducing the number of rules in a Layer."

Here are my questions:

- How does having to create two firewall rules reduce the number of rules?

- Is there a setting to actually enforce the first match or am I missing something else?

[_Val_]

First, if you don't like or need the Inline layers, nobody is forcing you to use them 🙂

The main purpose is to speed up rulebase matching and also to simplify the management of the network security policies. 

Many customers are routinely using so-called sections in the policy rulebase, where some sections describe different types of connectivity and restrictions.

Imagine, you have 20 rules for your office to internet connectivity, then 20 for data center access, and another 20 for anything else, 60 in total.

in a regular policy, when matching rule 59 which describes the most important connectivity for your internal networks, you will also have to attempt matching all rules above it, before accepting a connection.

With a layered policy, you can collapse two sections above, by making an inline layer for the Internet access, and data center connectivity behind two parent rules. 

Internet rules will only be considered for matching if the main parent rule is applicable, and the same for DC access.

So in our previous case with matching rule 59, instead of considering all 58 before it, you will consider only 58-20-20=18 rules. 

Also, when you get used to Inline Layers logic, you will see it protects you from making a mistake and blocking deep policy rules with a new one above. Those "mistake" rules will only be effective if the layer is matched, and most probably will not affect the rest of your policy. Also, it just makes the general section management easier.

Yet, if you are not convinced, see the very first statement of my post.

[Vehemont]

Hi Val!

Thank you for the in-depth response. It does answer some questions for me and I appreciate it. My post was about ordered layers, not inline layers. I agree inline layers are very useful and have an established purpose. I use them in policies. As for ordered layers, are they generally just used as an App & URLF layer? For an example, you have two ordered layers, one named URLF and another named "Network". the URLF ordered layer could be used to filter internet traffic by URLF objects or domain objects, then it goes to the network policy to ensure that users workstation is allowed outbound. This makes sense to me. 

For another scenario, in a policy named "HQ" we have two ordered layers with one named "Management" that is shared across all the other policies and another named "Datacenter" that is not shared. Both ordered layers only have the firewall blade enabled. In order for traffic to be accepted I would need to have two firewall rules for traffic to not be dropped. One firewall rule in the "Management" ordered layer, and another firewall rule in the "Datacenter" ordered layer. Why doesn't the first rule that matches in the "Management" ordered layer accept the traffic and stop matching against rules? This does not make sense to me. I wasn't sure if I was misunderstanding something. If this just isn't what ordered layers could be used for, that is fine.

I understand the MDS global policy exists for a similar functionality, but this doesn't exist on typical management server deployments that are non-MDS. It would be nice to be able to share an ordered layer across policies to be able to have a "global" like policy that enforces the first rule that matches a packet, and not be forced to ensure a rule exists across all ordered layers within a policy and create duplicate rules.

[_Val_]

Uh, my bad then. Here, the layered logic allows you to separate policies and manage different segments/layers independently I will leave the rest to other community members. In my personal experience, I did not see any field examples of the layered packages, but the sole reason they are available is that someone asked for this functionality. 

[the_rock]

Its definitely valid question, for sure. For the reference:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SecurityManagement_AdminGuide/Topi...

I will try explain it in my own way, hope it makes sense : - ). So, lets just say that you have 3  interfaces on your fw, external, internal and dmz. Well, if you have rulebase without layers, internal or ordered ones, what will happen, in order for the rule to be matched, it would need to verify all 100 rules, unless obviously, the rule in question is towards the top and it will be accepted. Now, thats all great and dandy, but what happens, if you have say 500 rules or so, it gets harder to manage and "sort" them out correctly.

Thats where layers come in. You create say inline layer in network layer (with fw blade only) and you reference zone inside it, so say src internal zone, dst any, service any, then action create new layer. Then, you create sub rules according to your needs, so ONLY traffic that comes to internal interface will go through that layer and its supposed to be accepted, will be accepted, and if not, then it will be dropped on clean up EXPLICIT rule, which is one at the bottom of that layer, NOT implicit one, which is last one in the rulebase. This surely saves time when processing traffic, as @_Val_ indicated.

Now, what most people do is they create another ordered layer with say appc and urlf blades and you can utilize that for such traffic. Just MAKE SURE that if traffic is supposed to be allowed, its allowed on EVERY ordered layer, otherwise, it will never work.

What I mean by that is say if you had 10 ordered layers and traffic is accepted on 9 of them, but last one has any any drop rule, NOTHING would work, as all the traffic would get dropped on that last layer.

Anyway, hope its bit more clear, but if not, I have real good lab with this configured, so happy to show you.

Cheers,

Andy

[Bob_Zimmerman]

I mostly see ordered layers used to allow multiple teams to manage part of the rules. For example, an incident response team manages a layer with a blocklist, an application-centric team manages a layer with normal firewall rules, and a web filtering team manages a layer with Application Control/URL Filtering.

Ordered layers rarely reduce the number of rules you need to define. The only way I could see a reduction in defined rules is if you use a shared layer. Using my earlier examples, the incident response team could manage a single blocklist layer which is then referenced in 20 policy packages. Define the blocklist entry once, and all 20 packages have it. Without the ordered layer, someone might need to define the blocklist entry on all 20 policies.

It also lets you have multiple logging settings without affecting how the traffic is eventually handled. Again, using the blocklist example, the incident response team could add a rule to alert if certain clients try to connect at all. Whether the clients are able to connect would then be decided by later rules.

[Vehemont]

Thank you for the input. That is a good use of ordered layers. It seems drop rules are an effective way to share an ordered layer, but accept rules not so much. 

[Bob_Zimmerman]

With ordered layers, drop is final. Further layers will not be evaluated. Accept is more like "Continue"; it ends that layer's evaluation, then the next layer gets a chance to drop it.

[the_rock]

Bob is 100% right. Going back to my example, say if you have 5 ordered layers and 2nd one had drop rule at the bottom, it will never evaluate other remaining 3.

Andy

[Tomer_Noy · Accepted solution]

Indeed, ordered layers are most useful for restricting / dropping certain traffic. Especially if such a restrictive policy is relevant to multiple policy packages.
It's useful to separate the logic to its own layer, and you have the safety that if you do accept some traffic, it will still be inspected by the rule definitions in the next ordered layers, so it will not violate the organization's policy.

Even some of Check Point's own products use this mechanism. Playblocks adds an ordered layer to dynamically quarantine infected hosts or block suspicious external attackers. IoT uses an ordered layer to define which domains each IoT device is allowed to access (usually by vendor).

Some customers use ordered layers with an "Accept" cleanup rule. For example if defining an Internet Access policy, you want to allow or block certain categories or sites, but unless stated explicitly, you traffic to the Internet will be allowed. Such a layer will not conflict with other ordered layers as it's not blocking by default.

Cool tip:
It's not commonly known, but when a connection matches on multiple rules (each in a different ordered layer), the logging logic will aggregate the Track option in all the matched rules. This means that you can add an ordered layer just for increasing the logging level on certain traffic (even if the primary layer set Track=None on the matching rule), which can be useful for troubleshooting.

So for example, you can have an ordered layer with just three Accept rules, the first with Track=Detailed Log, second with Track=Log and third with Track=None.

You can use static objects (networks / groups) to define which source / destination will have more logging, but for an even cooler effect, you can use the dynamic object of your choice (such as Network Feeds, Generic DataCenter or simple gateway-resolved dynamic objects).

If you are troubleshooting and need detailed logs, just add the relevant network to the dynamic object contents, and without having to push policy, the gateway will immediately start sending detailed logs on those connections.
When searching for these logs in the log view, just copy the rule UID (right-click on the rule) then paste it in the log view search, and you'll see all logs that matched that rule (which will include various matches in the primary ordered layer).
You can even paste the UID in a SmartView report to filter a full report just for the traffic that you are now troubleshooting.

[the_rock]

Excellent explanation @Tomer_Noy  👍

[RamGuy239 · Accepted solution]

When using ordered layers, all accepted traffic will have to traverse all ordered layers before a final decision is made. It doesn't help if "Test" allows the traffic if "Network" does not. The acceptance will only allow the traffic to move from "Test" to "Network", where the final decision will be made.

To me, it sounds like what you want is to use a shared inline layer. You could create a "test" inline layer, share this between policies and make all RDP to Workstation traffic match this layer. The change will be reflected on all other policies using the same layer whenever you change this inline layer.

I end up using shared inline layers between policies for various traffic. This makes it easier for administrators as they don't have to replicate the same rules in several policies. The drawback is that this allows someone who doesn't fully understand how this layer is being shared to create rules that might allow or block traffic on gateways where they don't intend to.

The idea of inline layers reducing complexity for policy-based matching and making it more efficient for the firewall results from you creating smaller subnets of your policy. If everything is flat without layers, the matching must consider your entire policy, which might include rules using non-FQDN domain objects, applications, and services disabling acceleration such as ALL_DCE_RPC. When moving things into layers, you break the matching into smaller pieces, creating scenarios where the matching can conclude that this traffic belongs to this specific layer; it doesn't have to consider the rest of your rules and start only matching towards the rules within this inline layer. This allows you to define inline layers containing rules that will enable less efficient matching so that this traffic won't affect all other traffic.

Take "ALL_DCE_RPC" as an example; having this in a flat policy will disable policy acceleration from this rule. If this is rule 5, all rules going from rule 6 and below won't be able to accelerate due to this service being used in rule 5. If rule 5 contains the relevant source and destinations for the ALL_DCE_RPC traffic, and you point it to an inline layer. Then you place the service "ALL_DCE_RPC" within this inline layer instead. In that case, acceleration will only be disabled for the rules after "ALL_DCE_RPC" within its inline layer instead of affecting the rest of your policy.