Policy Layers in R80.x

[Tomer_Sole]

I would like to clarify the use of layers in R80 Management Server and SmartConsole.

A layer is a set of rules, or a rule-base. R80 organizes the policy with ordered layers. For example, Gateways that have the Firewall and Application control blades enabled, will have their policies split into two ordered layers: Network and Applications. Another example is Gateways that have the IPS and Threat Emulation blades enabled, will have their policies split into two ordered layers: IPS and Threat Prevention. For Pre-R80 Gateways, this basically means the same enforcement as it always was, only in a different representation in the Security Management.

Ordered layers are enforced this way: When the Gateway matches a rule in a layer, it starts to evaluate the rules in the next layer.

The layers concept opens more options for policy management:

• Setting different view and edit permissions per layer for different administrator roles.
• Re-using a layer in different places: The same application control layer in different policy packages ( Sharing a layer across different policies  ), or the same inline layer for different scopes.
• Explaining global and local policies in Multi-Domain with the same feature set of layers: A domain layer will be the set of rules that are added in each domain by the domain administrator.

R80.10 Gateways and above will have the ability to utilize layers in new ways:

• Unifying all blades into a single policy (How to use the unified policy? )
• Segregating a policy into more ordered layers, not necessarily by blades
• Allowing sub-policies inside a rulebase, with the use of inline layers (How do I define diffrent policies to diffrent users? )

Message was edited by: Tomer Sole

[Tomer_Sole]

Quote from Jim Oqvist​:

R80 introduces a new policy concept called Layers to efficiently work with the rule base.

For Access Control Policy Two types of layers for maximum flexibility exists, inline layer and ordered layer. Where layers allow separating the security policy into multiple components. In this way creating better security and manageability. Support concurrent-admin's and segregation of duties, allow organizations to reuse of layer either as inline or ordered in multiple policy's to be more efficient.

• In Inline Layers only traffic matched/accepted on the parent rule will reach and be inspected by the inside layer rules.
• In Ordered Layers when an accept rule from the first layer is matched, the gateway goes over the rules in the next layer
  • For backward compatibility with pre-R80 gateway you will use ordered layers to manage the Firewall rule base and Application control rule base, where first layer needs to be Firewall layer and second layer needs to be Application control and URL Filtering layer.
  • During an upgrade from pre-R80 to R80 with gateways using policy packages that are using Firewall and Application control policy's, the existing policy will be separated to ordered Layer with Network Layer – Firewall policy rules as the first layer and  Application Layer – Application control policy rules as the second layer.

Here is an example of traffic matching using

Policy with Inline Layers		Policy with Ordered Layers	Policy mixed with Ordered and Inline Layers

[Rutger_Truyers]

Very clear thnx !

[Ed_Munoz]

Hi Tom,

Thanks for sharing, great summary. Few questions if you're ok

I wonder whether there is any kind of "layer priorities", for instance the inline layers case, what's the rule processing if there are contradictions between the layer rules?

Is there any best practices for R80 Rulebase Construction and Optimization similar to sk102812

What's the implication in the gateway side with other features such as SecureXL

Thanks

Regards

[Tal_Ben_Avraham]

Hi

Not sure I follow the question regarding “layer priorities” (for the priorities example – per layer the verification of rules is the same as in previous versions).

Regarding best practices, per layer sk102812 still applies.

However, the ability to use layers instead of sections exist.

The R80.10 admin guide should supply use cases and best practices.

Thanks,

Tal

[Martin_Raska]

Hello,

I have a question:

How many policy layers the Access Control Policy supports?

Thanks.

[Tomer_Sole]

See my reply from the Layer Design Patterns posts (which I should really add more to.. ) 

https://community.checkpoint.com/message/7100-layer-design-patterns-1-inspect-additional-content 

Enforcement with ordered layers is executed on the gateway in a way that does not add a performance impact with every new layer.

It is more likely that a large number of ordered layers will be harder to manage by the admin, before any performance impact will kick in (imagine that "Tree" of Access Control Policy composed of over 10 ordered layers.. Maybe not the best visibility).

[Paul_Gademsky]

Hi Tomer,

I have an R80.20 policy this is being applied to 2 gateways. It has the typical: Access Control - > Policy and NAT.  I want to add a shared 'Ordered Layer' called Mgt_Monitor) to it (and other policies) that have common rules for Network Management devices. When I have tested adding this, it changes the layout shows up as "Network" and Mgt_Monitor. So both layers are now there. This thread does not really address how to 'network type' layers will be processed by the firewall, and what happens with the clean up rules that are in existence.

The end goal of what I'm after is being able to do a similar effect as the Global Policy in a MDS/CMA except this is a CMA and I want to be able to share the ordered layer among the various policies in the CMA.

A clearer understanding or example of using multiple 'network' type layers and how they interact would be very helpful.  I have opened an SR but don't have answer from that yet, but thought you might have a better handle on how this was designed to operate.

Thank you,

PG

[DIEHARD]

To add to this question more.....

This use case is a layer of rules that would be applied to many firewalls to provide access for devices behind them to central management systems.

I can not think up anything I can match on that does not cause other existing rules in the individual firewalls policies to break due the the layer cleanup drop.

In a layered policy the cleanup rule basically only being matched to Allow or Drop. There is no possibility of say.. the option to simply exit the layer and continuing down the rules of a parent layer for a match? That would be an awesome option to have! 😉

If there is some way to currently do this using policy layers I would love to know.

[Scott_Paisley]

Did you get an answer to this, as I have the same question.

Assume I have 2 rules in my current policy that allow traffic between 2 subnets on different ports.

Rule 1 allows HTTP from subnet A to subnet B so users can browse websites.

Rule 2 allows SSH so admins can administer those websites.

If I put an inline rule after rule 1 that has more specific hosts in each subnet, what happens with the cleanup?

If it's an explicit allow, is all traffic allowed?

If it's an explicit deny, does traffic that would have previously hit rule 2 get dropped?

[Rodney_Hopkins2]

I'd like to see an answer to this question too.

I want to use an ordered Network layer to sort of serve similarly to a procedure or function in a programming language to handle a group of rules that related to management functions and are common across all of my firewalls.  Flow through the first ordered ruleset, if an Accept occurs, match and move on to the next non-Access policy ordered rule set.

The Drop/Accept in an Ordered policy prevents this due to the fact that if an accept is made in the first ordered ruleset, an accept must also be made in all following ordered policies in order for the flow to be allowed.

So far the best I've been able to come up with is several small inline rules that don't really feel like they should be inline rules because I'm not delegating their management to any one else, nor are there a lot of rules between the parent rule and the inline Drop rule.  Each inline rule is basically 3 lines, the parent rule, the actual rule (which usually very closely mirrors the parent rule) and the cleanup rule.  There's not enough in common between these dozen or so rules that I can make one parent rule that covers all or even a majority of them.

[cosmos]

@Rodney_Hopkins2 I would argue your inline example is using an inline layer for the sake of it, having the inline layer match the parent rule serves no purpose - you might as well spare the inline layer for an accept on the parent rule. If the inline rule matches the parent, the inline cleanup rule will never be hit, regardless of accept or drop because the more specific inline rule matches all traffic for that layer.

You could use a common (shared), ordered  Access Control layer with firewall blade for management functions with an accept cleanup action as long as the last ordered access layer has your standard drop cleanup rule - this way traffic that matches a management function will be accepted by the first access control layer, all other traffic hits the accept action in the first Access Control layer and is subject to evaluation by subsequent [Access Control] layers until it either matches an accept on the last Access Control layer or a drop (no other layers are evaluated if the flow hits a drop rule).

I'm only just learning this myself and labbing it, coming from about 15 years managing non-unified policies it's a bit of a curve (if you teach what you learn, you get to learn it twice!). I'm sure @PhoneBoy will correct me if I'm wrong anyway 🙂

[PhoneBoy]

The easy way to think of it is that for every layer (inline, ordered) a packet is evaluated against, the packet must hit in accept in all of them to pass.
One drop, and it's game over.

Inline layers have obvious use cases (e.g. a common Internet access policy across an organization).
I know I haven't fully scratched the surface of it.

Ordered layers have always been "kind of" supported if you think about the separate Firewall and App Control policies in R77.x and earlier.
Or even the global policies in Multi-Domain.

[Rodney_Hopkins2]

I believe the issue with this approach is exactly what Dameon said in reply to your message: "the packet must hit in accept in all of them to pass.  One drop, and it's game over."

My management ordered layer has rules that are not duplicated in the following network layer.  So, although traffic may be accepted by specific rules the management ordered layer, it then proceeds to the network ordered layer, doesn't find a corresponding allow in that layer and gets dropped by the final clean up rule.

[cosmos]

I see what you mean. Any drop rule that matches on a subsequent layer will drop the traffic regardless of what's accepted in the first (management) layer.

This being the case, there' some fundamental principles we need to consider e.g.
1. Only use 1 ordered Access Control layer in a given policy, with a default deny (positive security model, 1st line of defence)
2. Subsequent ordered layers could be used to further control what's accepted by the AC layer i.e. content, data etc. and possibly follow a negative security model (i.e. deny known bad, accept everything else)

Following this pattern, additional ordered access layers don't add any value as they would need to allow the same traffic defined in any other access control layer and vice versa.

An inline layer may work but as you say you're not getting any benefit from it from an ops perspective, as you still need to define the parent rule in each policy. Only if the parent rule is broad (e.g. grp-management-servers to grp-management-clients) and the shared, inline access layer is complex (SCCM to SCCM-clients/DCOM, Nagios to clients/SNMP etc.) do you have an advantage.

Another option would be a Global access layer on a MDS, i.e. a shared policy that provides a top-down, first match on generic / management traffic that doesn't need an accept rule in a CMA policy layer to take effect. But you need an MDS for that.

Or new logic in R80 that "stacks" ordered layers of the same type into one serial 'effective' policy, so rather than having to evaluate both policies, if traffic matches an accept in the first layer any subsequent layers of the same type are not evaluated as if they were rules in the same policy. I know another firewall vendor that does this, and works very well for shared rulesets. Perhaps it is worth Check Point to consider feature parity? 🙂

[PhoneBoy]

I'm not aware of a specific limit in this area.

That said, I struggle to see a use case where you'd need more than a few.

Can you articulate the use case you're thinking of?

[Martin_Raska]

It's a question from CCSA exam study guide

r80-system-administrator-study-guide.pdf

BR

Martin

[Timothy_Hall]

As someone who teaches the CCSA class I think I can provide some insight here.

In the CCSA R80 class, there was a question like this and the answer was "up to two" ordered layers.  At the time only R77.30 gateways were available and this was correct, due to gateway limitations you could not have more than two Access Control Policy ordered layers (Network & APCL/URLF).

However in the CCSA R80.10 courseware, the answer was changed to "one or more ordered layers" due to the availability of R80.10 gateways.  With R80.10 gateway there could now be more than two ordered layers in the Access Control Policy.  However for an R77.30 gateway managed with R80+, the answer is still "up to two" ordered layers. 

The question needs to be clarified with context as to the gateway version, so I'm mentioning certification manager Jason Tugwell in the hope that he'll see this thread.

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

[Martin_Raska]

Thank you for your effort Tim.

Your book is awesome.I have a hard copy.

BR 

Martin

[Jason_Tugwell]

@TIm Hall @Martin Raska, 

The explanation Tim provided was spot on!  

While I am not the authority on the subject, the exam content is based on the course ware and after consulting with that team the context of the question is based on the R80.10 gateway.  

Regards,

Tug

Certification FAQ

[Stadt_Heidelber]

HI all,

will it be possible to layer SSL Inspection Policy in the future, too ? 

We have a use case where our First Level Support should be able to create SSL Bypass Rules. 

Thanks!

Alex

[Tomer_Sole]

Hi,

We plan to improve the user experience of HTTPS Inspection and we will update once we have information that we can share.

[Tal_Ben_Avraham]

Hi Stadt,

In practice you can think of SSL Inspection policy as a different layer.

And in the future it will also remain as a separate fixed layer.

Can you elaborate on your use case?

Thanks,

Tal

[Nicholas_Scott]

Thank you for your posts, Tomer! Very clear and very helfpul.

Cheers,

Nick

[Juan_Concepcion]

So I have a customer that has the following configuration:

Layer 1: Network management has a policy

Rule 1:

Source: Admin Network

Destination: Firewalls

Action: Accept

Layer is set to implicit “Accept”

Layer 2: Network Policy

Rule 1

Source: Internal Networks (does not cover admin network)

Destination: Any

Action: Accept

Rule 2:

Source: Any

Destination: Any

Action: Drop

The traffic from admin network to firewalls gets dropped on Layer 2/Rule 2 is this how this is supposed to work??

[lulu]

me also as same