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, I have been doing this for awhile. I find this method 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 use numbers. Especially when you might have a lot of ACLs and or a lot of zones. Numbers keep it simple. If we look at an example of a firewall that has two zones, and inside and and outside zone
I would usually 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 relying on the default deny at the bottom of the policy is to put in a default deny at the bottom of 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 building out the rules into a framework which 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 that 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 because 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 creating and naming rules. This is what I have done, in the past and present and hopefully helps you find a balance in between. Personally I've been working with 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. Although sometimes painful and time consuming at first, creating these rules will pay off in the end.