Maximum number of rules in R80.40 and above

[S_E_]

Hi,

I would like to start a (naive) discussion regarding the amount of rules in a R80.40 policy (and/or above).

In case there are requirements to have a very, very granular rule base and modified with an external tool.

Is there a limitation of rules? Is there any drawback having more than 10.000 or 30.000 Rules inside a policy? 

There is no need to have a human readable, section based policy structure as we do it now. But for worst case, SmartConsole should work of course.

Does anybody of you have such a huge policy set?

According to this 6 year old thread, it might be just a compilation time issue. 

https://community.checkpoint.com/t5/Management/What-is-the-Maximum-number-of-rules-in-R80/m-p/2580#M... 

Thank You

Regards

[Chris_Atkinson]

Could you please share some more information about your hypothetical situation, is this policy representative of the entire organizations security policy or that of a single gateway?

[S_E_]

Hi

inside one domain /CMA: one gateway cluster out of 5 cluster.

Other domains do have Global Policy approach.

Regards

[the_rock]

Put it this way...yes, officially, there is no set limit, though I recall back 10-15 years ago, number 10000 was floating around all the time, but that was really never confirmed. In my 15 years dealing with CP, I had ONLY once seen customer with 1500 rules, thats it. I cant think of a reason why anyone would need that many rules, honestly.

[Jung_Patrick]

Hello.

This is Korea. I am a 9 year cp engineer. About 5-7 years ago, I saw a customer using about 8300 rules. The install policy time took too long, so the veryfing feature was removed, and after a while, the customer was informed that they had changed to fortigate. Even now, among the customers I care for, there are customers who use more than 3000 rules. If the network is large, there will be a lot more customers who use the rules more than you think. In my opinion, security officers don't organize rules and just add rules by host. So there's a problem.

[Magnus-Holmberg]

Would seriously consider how the rulebase is built.
We see similar with 15-30K rules within other vendors when using like tufin/algosec to admin rules for nsx-t / public cloud what ever.
But they are fundamentally wrong according to me.
When cleanup has been done 50% or more can be removed only due to "duplicates" 

Building rules with IA objects and Dynamic objects/groups will make the rule base much much smaller and more effective.
I would be really surprised if they go above 1500 rules then. and if so maybe they should consider some other design principles.
Such as having all user rules within "office firewall" and then have all server rules within a "server firewall"
And within the server firewall you do have a permit ANY within the "server firewall" from office network as the rules are already covered within the "office firewall"

If they still are above 1500 rules for servers, well maybe they need to split it up within prod/stage/dmz etc...
Decide where to have the rules if traffic need to pass multiple firewalls.

Have done projects where it was 3K+ rules and ended up with less then 500 when using IA rules.
Similar within Datacenters from 3K+ to less then 500 when starting to use dynamic objects and groups.
if you have 10K rules in one firewall/policy, something is wrong in your design 🙂
Alternative, cleanup of rules are never ever done (because very few ppl actually order a decom of a firewall rule even if they decom the server)

[the_rock]

Well said @Magnus-Holmberg 

[_Val_ · Accepted solution]

There is no hard technical limit, but large policies affect negatively both MGMT and GW performance. Depending on the needs, you could run reasonably well with 3-5k rules, but in my personal book even that is way too long.

In my performance optimization series, I have a real world example of a policy that had 2k rules, that were optimised into less than 300, and I have see quite a few cases like that in the field over 20 years. 

Having more than 500 is already hard to manage, and when your policy grows over 1k, it is a sign of issues with security management definitions and audit. In many cases, large policies are created when security management is outsourced to a third party, which then never clean up obsolete rules. 

Do you best to keep it economical, review policies regularly and clean up them as part of routine management procedures.

[S_E_]

Hi

Thanks for your valuable and reasonable input.

The (external) requirements and my personal preference and experience are not always the same 🙂

Thanks again!

Regards

Just had a look into a public available data sheet of a competitor and there is 65000 lines mentioned. Wondering why CheckPoint can't provide meaningful datasheet (with limits routing table size/ max numbers). But this is a different thread.

[_Val_]

I would advise to take those competitive references with a grain of salt. There are plenty of use cases, when very granular access lists with tens of thousands of entries can be replaced with a single security policy rule 🙂 With more rules, you do not necessarily have better security. Sometimes, it is actually the opposite. One funny example of that was a customer who tried to reverse-engineer the access policies based on traffic logs. They ended up with several thousands of rules, but the cleanup was kept "any-any-access" for almost a decade. 

For the external requirements, I have seen that a lot, and even there, there are ways to keep the actual policies reasonably sized. @Magnus-Holmberg has provided a very good example above

[HeikoAnkenbrand]

This is an exciting topic:-)
I think that the rules and regulations should be clearly laid out. This is basically a design question.

The unified policy is used for processing rules from R8x onwards.

The Access Policy is processed in according to:
1) Source IP
2) Destination IP
3) Protocol (TCP, UDP,...)
4) Source port
5) Destination port

And the possible match are always sorted out and processed further. Therefore, policy processing is much faster than with older versions R6x and R7x. Therefore, large sets of rules are no longer so critical. I think there are other points to consider, which may be more time-critical (IPS, AV, ...). 

@_Val_  has a presentation describing the unified policy processing:
"Performance Optimization Part 1 Introduction"

PS:
But I am also a fan of smaller and more manageable rules.

[_Val_]

@HeikoAnkenbrand, you know my urge to add to your statements 🙂

You said: "Therefore, large sets of rules are no longer so critical." 

Just a small clarification here. Size still matters. It is true that policy lookup logic in R8x has been changed, and it allows more effective lookup through the rules, but larger the policy, more CPU cycles will still be done. 

[the_rock]

I was going to comment on this too, but for sake of keeping it "clean", I wont...but made me laugh though : - )

[abihsot__]

Very interesting topic. I was wondering how could you go down from 2k to 300 rules? I mean for core services like dns, dhcp, mail etc you would use groups and open for all networks. So this is quite efficient and should not generate lots of rules.

However when it comes to server to server communication and if company has let's say 500 of them, naturally number of rules goes up very quickly, unless firewall is filtering only between high level zones and further restrictions comes down to individual server to deny/allow in their local firewall.

In short, unless policy was extremely inefficient, it is hard to imagine how you can reduce number of rules so significantly in fairly big environment.

[the_rock]

Well, I get your argument, but grouping in case like that is the key. This is why CP approach in R80+ with layered rules makes sense, as that allows people to create "parent layered rules" based on the zones and its way more secure that way than pre R80. In all honesty, as @Magnus-Holmberg said in this thread, if you have thousands of rules, you have way bigger problems with your design.

[_Val_]

What are you trying to say? 

in the case I mentioned, their security admin was creating two rules per remote office, one inbound, one outbound. 1000 remote offices resulted in 2000 basically identical rules that could be replaced with only two. They had some other reasonable requirements that ended up with less that 300 rules after optimization. 

grouping, as other people already mentioned 

[abihsot__]

My point is that 2k > 300 seems impressive, however without explanation is just nice figures. People here having thousands of rules might be thinking they are doing something wrong.

1000 offices having separate rules is quite an extreme situation. I wish I had so much room for improvement 🙂 Thanks for sharing background information about this case.

[_Val_]

Depending on the network design, security requirements and policy management routines in place, they may or may not do something wrong. I stress again, with rulebases of 500 rules and up, especially if you are not using inline layers, you should seriously consider an optimization exercise and also question your policy logics. 

This statement is based on 20+ years of personal experience with various customers in all types of industries, around the globe.

I will tell you even more. Lack of periodical cleanup, outdated rules, "reverse engineered" policies when customers try building rules based on traffic logs are the worst enemies of policy optimization. Another reason is having a huge core FW serving many security zones at once, instead breaking it down into "smaller" virtual GWs.

And now the small print. @abihsot__ , the company you are working for now was my customer for a decade, and during that time was not having huge policies on their FWs. I sincerely hope that did not change recently 🙂