Discussion: Policy Structure

[tmorgan]

So over the last few years there has been changes around policy structure with the introduction of things like iLayers.

I personally follow the more 'classic' logic of two main layers "Network" and "Application". The idea being I drop as much traffic as I can on the Network Layer using just IP/Port based controls. I then pass traffic to the application layer where I get the firewall to perform the more heavy lifting such as Application, URL, Content etc.

Within the Network layer I leverage iLayers to identify traffic between "major" network sectors identified by elements such as firewall zones or the use of supernetting within the network. This helps to reduce the number of rules that have to be processed as part of this. I then tend to use iLayers in my application layer to make decisions more based on who the user is, eg HR users can get to Facebook etc, IT users can downlaod EXEs.

One of the advantages to this logic is it is normally fairly simple to migrate "brown field" installs towards. You don't need to tell the customer 'the worlds changed so here is a massive bill for the privilege'.  I then tend to keep green field aligned with this too to keep centralized support simple; you dont want two different groups of customers who have completely different policy styles.

Is my mindset outdated? Am I doing the right sort of things? What are you doing? What would you change?

[Timothy_Hall · Accepted solution]

This is a frequent topic of discussion in the CCSA classes I teach when we cover policy layers. 

Using the two separate Network and Application layers as you mentioned is what Check Point calls "Ordered" layers, and is how an existing Check Point configuration will be upgraded from R77.30 to R80+.  Furthermore I refer to implementations whose layers only have a single feature enabled in each individual Ordered layer (i.e. only Firewall in the 1st Network layer, only APCL/URLF enabled in second Application layer) layer as "pure" ordered layers.  Note that while APCL & URLF are technically separate blades, their configuration was unified in R75.40 so both blades are considered a single "feature" from a layer configuration perspective.  This is reinforced by the fact that it is very rare to use one of these two features without the other also being enabled.  While there can be more than one blade enabled in each Ordered layer, it is not too common.

The new option is called "Inline" (or sometimes "Unified") and allows all rules to been seen at once via the implementation of sub-rules.  Ordered and Inline are not mutually exclusive and many sites are using a combination of the two.  When researching my third book I created two policies that accomplished exactly the same policy configuration, but one was pure Ordered while the other was just Inline.  The compiled Unified Policy was virtually identical for the two policies and I couldn't identify any detectable rulebase lookup performance differences out on the gateway.

So as far as Ordered vs. Inline, my personal recommendation I present in class is that if you have a pure Ordered implementation (which was probably upgraded from R77.30 or earlier), the current Ordered implementation is working well for you, and you understand it fully, there is no urgent need to convert it to Inline.  Especially if the pure Ordered policy is very large as the amount of work required to convert it fully to Inline will be non-trivial, and there aren't really any tools to make this conversion for you that I am aware of. 

However, if you are constructing a brand new policy package for a new site or implementation, ABSOLUTELY I would recommend starting with Inline right from the beginning.  Your policy will be significantly shorter and easier to manage day to day in the long run.  I would also strongly recommend giving the use of Security Zones a hard look for a brand new policy, as they can help prevent having to maintain huge groups of network/host objects to represent different parts of your network, once again making the policy shorter and easier to understand.

The only thing to watch out for with Inline is making sure that only blade "Firewall" is enabled in the parent/top layer, and that only simple services (port numbers) are used there.  Save the application/category/content objects for the sub-rule layers.  Failure to do so will not show SecureXL Accept templates as disabled in the output of fwaccel stat, but they will always report 0% in fwaccel stats -s under Accelerated conns/total conns.  Note that Accept templates going to 0% just means that rulebase lookups cannot be cached for substantially similar repeated connections, and a full rulebase lookup will need to be done every time thus increasing overall rulebase lookup overhead.  This effect has absolutely nothing to with what traffic ends up slowpath/F2F or fastpath, that is something completely different.

This effect is covered in my Gateway Performance Optimization Class, and the SK that best sums up this issue is sk180633: Security Gateway accelerates 99% of traffic through the PSLXL, which also mentions another side effect of this which is abnormally high Medium Path Passive Streaming (PSLXL) percentages.  A new command option introduced in R81.20 can show precisely why the Accept templating rate is always zero: fwaccel templates -R.  Reason "Prevented by Policy Rules" shown by this command indicates this condition is present.

[tmorgan]

Firstly, thank you for taking the time to write up such a detailed response. This all makes perfect sense.

Am I right in saying there is no definitive statement "Check Point recommend you do it like this"? I have looked at the admin and ATRGs but I cant see anything that says ether way is preferred/recommended? It seems to be just a preference?

[the_rock]

Personally, I could explain this, but since I dont know anyone that explains it better than Tim, I wont embarrass myself 🙂

Best,

Andy

[RamGuy239]

Most policies tends to get large and confusing over time. Changing existing "Ordered Policy" policy into a "Unified Policy" might end up being a huge task. Unless something is broke, I wouldn't mess with it. But if you have a upcoming policy review, I would recommend to have a conversion over to "Unified Policy" as a part of it.

Every new policy should, of course, aim to be "Unified" from the get-go. Sticking with "legacy" way of doing things when it's not needed is a bad practice.

In-line Layers shouldn't be confused with "Ordered" vs "Unified". You can deploy a unified policy without touching layers, and if I'm not entirely mistaken (haven't tried this myself) you can combine the use of in-line layers and ordered policy. I'm fairly sure that when using in-line layers in your "Network Policy", the traffic would still have to traverse your "Application" ordered layer if you design it this way.

Unified Policy should be more efficient compared to Ordered Policy. When you have Application Control and URL-filtering the "old" way using ordered layers, the traffic has to first match and arrive at a decision in the Network Policy, and then it has to do the same within the Application Control and URL-filtering policy. Regardless of whether or not the traffic needs to considered for Application Control, the firewall has to match against it to decided if the traffic is going to hit the "any any allow" you are most likely going to have at the bottom of the Application Control policy. Unless you are whitlisting, instead of blacklisting, which is a major pain due to unknown traffic/application.

With unified policy, you can mix and match rules containing applications and url-filtering within the very same policy. This removes the need for the firewall to consider and match all traffic twice and against two different ordered policies. To make it even more efficient you would normally not involve application control and URL filtering in the base policy, you only enable it on applicable in-line layers within the policy. Resulting in everything be even more efficient as basic network rules will be matching without having to take application control or URL filtering into consideration at all, and when it matches, it doesn't have to traverse a second ordered policy before hitting the final decision. You only use application control on layers where it makes sense to use them, making it so that the application and URL filtering blade is in use when actually needed.  With ordered layers it will be in use on every decision, regardless of it being needed or not.

[tmorgan]

Thanks for taking the time to respond. Lots of interesting points in there I am going to ponder.

[the_rock]

What I always recommend to people is this...IF you have small policy, say 100 rules or so, layering may not make much difference, but if you have 100s of rules, then you would definitely see the difference.

Best,

Andy

[the_rock]

Alright...here comes my explanation, though it will be probably 10 times worse than what @RamGuy239 and @Timothy_Hall provided, but take it for what its worth, as they say : - )

So, in the old days on Check Point, Im talking before R80 came out, you had unified policy, where regardless of what blades were enabled on the firewall, there was no ordered or inline layers, you would simly create one big or small policy and then modify it with time, however you desire.

Personally, I always though that was totally acceptable, but obviously, with layering approach, lots of things changed, for the better, in my opinion.

So, lets say before layering approach, if you had (just as an example) 500 rules, you would have norally had to put rules you knew would get hit the most towards the top, because otherwise, say if one that was hist a lot was say rule 490, it would have to process ALL the rules before that rule, before it gets hit. Now, normally, thats not such a big issue, if you had small office with, I dont know, 20 people working there and you had 10-15 rules, I mean, honestly, who cares, thats totally acceptable, but, if we are talking 100s of rules, you would have noticed the performance issues.

When R80 came along and ordered/inline layers, its totally new "ballgame". You can say have 1 ordered layer with only fw blade enabled, then 2nd ordered layer, with lets say urlf + appc blades on, then lets say 3rd layer with content awareness (as an example), BUT, you have to make sure that traffic is ALLOWED on every ordered layer, otherwise, it will never work. So, what most customers may do is say have 2 ordered layers, one network and other one url filtering and then have any any allow at the botton of 2nd ordered layer and block malicious sites in the rules above any any allow rule in the 2nd layer. 

Also, you can have multiple inline layers inside an ordered layer. So say if you have inline layer rule that say src internal zone (tied to internal interface), dst any, and then action you create a new zone, and add child rules below it, as they call them, ONLY traffic that hits that zone will be processed, so there is no "wasting time" to look through all the other rules. There is always by default the explicit cean up rule at the bottom of every inline layer when you create one, but I know clients who change them to any any allow to start with, if its a new segment they simply wish to test for the time being.

Anyway, apologies for long story, but wanted to make sure I cover all it was on my mind.

I attached a doc file with some screenshots I took in my lab. I have an excellent R81.20 https inspeciton lab, as well as Azure, so honestly, if you need help, please message me directly, I can show you.

This community is all about helping people, so dont hesitate if you require additional assistance.

Best,

Andy

Good reference.

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

[tmorgan]

Thanks for taking the time to respond and the extended offer of help. I think Check Mates is such a powerful selling point of Check Point and the responses on this thread demonstrate that. From a taking the concepts and making them work in reality I am quite comfortable with I have been working with Check Point and many other firewalls for too long at this point! 

[the_rock]

Its all about sharing ideas my friend :). Of course, people can disagree, but as long as its civilized and healthy discussion, thats good!

Best,

Andy