Introduction
PaloAlto Firewalls are typically deployed on very complex and large networks. These are amazing Next-Generation appliances; however, they may become a nightmare to manage if there are hundreds or thousands of rules and objects to be reviewed. The following technique permits firewall administrators to reduce the number of redundant rules by grouping them with the help of templates in a hierarchical structure.
Since all networks are unique, any specifics will be omitted and we’ll focus only on the logic. You must use your best judgment and knowledge to determine whether it’ll work in your network. Any step-by-step instructions can be found on the PaloAlto web site.
Prerequisites:
- PaloAlto Panorama deployed to centrally manage your appliances.
Nice to have:
- Continuous sub-netted network address range will significantly reduce the complexity of firewall rules and contribute to more organized architecture that is easy to memorize.
Template Hierarchy Logic
Panorama allows us to define rules in templates and push them to firewalls. It also allows to nest templates into each other. This is the feature we’ll be taking advantage of.
It is important to understand that every time you create a rule in the template, it’ll be placed in either “Pre” or “Post” rules section of the template. Let’s pretend we have two templates: “GLOBAL Template” and “GLOBAL Internet Access Template“. Once “GLOBAL Internet Access Template” is set to be a child of “GLOBAL Template“, all rules from the child template will be inserted after “Pre” rules and before “Post” rules. In other words, nested rules are positioned in the middle of the parent template. (See the diagram below)
Certain templates may not have “Pre” or “Post” rules defined. In this case, your child template rules will be either at the top or at the bottom respectively. This is illustrated in the diagram below for “GLOBAL Internet Access Template” and “IaaS Access Template“.
Pre Rules
Applied at the beginning.
Targeted Rules
Global rule that targets groups of devices.
Device Specific Templates
Applied to specific appliance or an HA group.
Post Rules
Applied at the end
Object Names
Ensure that object and object group names are descriptive, intuitive and easy to read. It shall reduce frustration from clicking through them to view values if you have several thousands of objects to deal with. Make it a priority to define a logical pattern that will work best for your team and reports. It is a good idea to update object names before optimizing rules.
Patterns such as “Type“_”Environment“_”Purpose“_”IP” allows seeing the value of the object without going into its details.
Example
SVR_PROD_SQL_10.0.1.15 --> SQL server in Production with IP 10.0.1.15 LAN_USER_FINANCE_10.0.4.0 --> Sub-net assigned to Finance department users with the network address 10.0.4.0/24 NET_TOR_10.0.0-7.0 --> Entire network range assigned to the office in Toronto with the network address 10.0.0.0/21
Object name patterns help to save time to review rules and make it easy to spot opportunities to reduce complexity. They just need to make sense and tell the story about an object.
Sometimes, Panorama will have many duplicate objects. This happens when the configured firewall is imported. As you go through rule review, you’ll need to keep an eye for duplicate objects and merge/replace them.
Optimize Rules
Rules optimization can begin with a blank GLOBAL template. It will hold all general rules that are the same across all appliances.
Example
Implicit deny rule must be positioned in Post Rules at the bottom.
The next child template may group all rules governing access to the Internet. Once again, determine where each of your common internet access rules goes and position them in the “Pre” or “Post” rules.
Continue to grow template hierarchy, as well as create sibling templates if required. Try to create siblings closer to the bottom of the hierarchy. Branching at the high-level may create more redundant rules.
Try to group similar rules into the same template if possible. This approach helps to avoid accidental deletion or modification of the wrong rule type. The deeper template resides in the hierarchy, the more detailed rules are.
Eventually, you get to the policy that will be appliance specific. This is where you can define rules applicable only to the network segment protected by the corresponding firewall. By now, the number of rules on that appliance should be significantly smaller and become more manageable.
Summary
- Identify common global rules and define them closer to the top of the hierarchy;
- Give logical and descriptive names to all objects;
- Split your rules into logical groups and define a template for each group;
- Merge identical rules into one and use object groups to reduce complexity;
- Create template siblings closer to the bottom of the hierarchy;
- Aim for appliance template to hold only unique rules that cannot be grouped or applied across multiple appliances.
PAN-OS also allows color-coded tags. Though this will add more work; however, Colors help to ID rules visually without reading what object values are. Structure tags to tell the story about your rule as you read them.