Firewall ACL Naming
One thing that can be suggestive is naming conventions... It has to have meaning to you and the organization. I have seen some pretty interesting naming conventions and although I make no promises that what I have is the end all of naming conventions, but since I have been doing this for while I find this a pretty good system and easy to understand. So let's get started!
Over the years I have found that numbers are infinite vs words. So instead of naming an ACL with a word sometimes numbers are better. Especially when you might have a lot of ACLs and or a lot of zones, so to keep it simple if we look at a firewall that has lets say two zones, and inside and and outside zone
I would usually name start naming the rules something like this: FW_INSIDE_OUTSIDE_000005 and continue counting up. Which tells me its sourced from the INSIDE zone and going to the OUTSIDE zone followed by a counter. This makes it easy to build, you can put all rules that are tied to the same zone together and just continue counting.
The table below is a reference:
| Rule # | Rule Name |
|---|---|
| 1 | FW_INSIDE_OUTSIDE_000005 |
| 2 | FW_INSIDE_OUTSIDE_000010 |
| 3 | FW_INSIDE_OUTSIDE_000015 |
| 4 | FW_INSIDE_OUTSIDE_000020 |
| 5 | FW_OUTSIDE_INSIDE_000005 |
| 6 | FW_OUTSIDE_INSIDE_000010 |
| 7 | FW_OUTSIDE_INSIDE_000015 |
| 8 | FW_OUTSIDE_INSIDE_000020 |
So from the table above you can see that rules 1-4 are INSIDE to OUTSIDE and then from rules 5-8 these are OUTSIDE to INSIDE rules.
Another thing that I have been doing is instead of relaying on the default deny at the bottom of the policy is to put in a default deny at the bottom of the each zone. So for example if I have all my INSIDE to OUTSIDE rules defined, I would put in a deny statement at the bottom of this policy. Something like this: FW_INSIDE_OUTSIDE_999999. Again this helps with building it out makes it easy to drill down on traffic only hitting that deny policy instead of the entire firewall.
| Rule # | Rule Name |
|---|---|
| 1 | FW_INSIDE_OUTSIDE_000005 |
| 2 | FW_INSIDE_OUTSIDE_000010 |
| 3 | FW_INSIDE_OUTSIDE_000015 |
| 4 | FW_INSIDE_OUTSIDE_000020 |
| 5 | FW_INSIDE_OUTSIDE_999999 |
| 5 | FW_OUTSIDE_INSIDE_000005 |
| 6 | FW_OUTSIDE_INSIDE_000010 |
| 7 | FW_OUTSIDE_INSIDE_000015 |
| 8 | FW_OUTSIDE_INSIDE_000020 |
| 9 | FW_OUTSIDE_INSIDE_999999 |
Because we are explicably putting in a deny rule for each zone this not only helps us make sure that any rules not called out are denied, but also these groups of rules within each zone can also be shuffled around without the risk of blocking or allowing something above or below each zone.
Tip
The more zones a firewall has the more possibilities traffic can pass between zones. N × (N - 1) With N being the number of zones. So this really depends on what your environment requires, if every zone needed to talk to every other zone this expands very quickly. As an example if I had a firewall with five zones and all zones needed to talk among each other there would be 20 (twenty) zone-to-zone traffic flows.
So we need to understand what really needs to talk to what otherwise we get into explosion of rules. Understanding what is really needed and between which zones will help us cut down on the amount of rules we need... Ok status check, did I solve the complexities of ACL naming or just make it more complicated now? 😆
Every company and person has their own way of doing things, this is what I have done, in the past and present, hopefully helps you find a balance. Personally I've been working this type of rule making for awhile and I've seen more often than not that this helps environments get streamlined and ready for zero-trust and micro-segmentation. You need a strong foundation of rules on firewalls to be able to build on top of zero-trust and micro-segmentation. Layers in security although sometimes painful at building will pay off in the end.