- Local User Groups
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:
R80.10 Gateways and above will have the ability to utilize layers in new ways:
Message was edited by: 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.
Here is an example of traffic matching using
|Policy with Inline Layers
||Policy with Ordered Layers||Policy mixed with Ordered and Inline Layers|
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
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.
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.
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.
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?
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.
@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 🙂
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.
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?
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
@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.
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.
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?
So I have a customer that has the following configuration:
Layer 1: Network management has a policy
Source: Admin Network
Layer is set to implicit “Accept”
Layer 2: Network Policy
Source: Internal Networks (does not cover admin network)
The traffic from admin network to firewalls gets dropped on Layer 2/Rule 2 is this how this is supposed to work??