Security Policy Management with Panorama Tech Note PAN-OS 4.1

Transcription

1 Security Policy Management with Panorama Tech Note PAN-OS 4.1 Overview This document describes the best practices for using Panorama for central security policy management. Panorama can provide a central repository to create and push security policies to multiple firewalls and virtual systems. This provides better efficiency and allows for larger scale firewall deployments. This also helps ensure a consistent policy across a large, geographically dispersed network. The high level strategy for using Panorama to manage security policy is as follows: 1. Group firewalls and Virtual Systems by function into Device Groups 2. Create common zones for each Device Group 3. Create common policy for each Device Group 4. Choose a method for managing local versus central rules (if required) 5. Move or create rules in Panorama 6. Commit and test Panorama Rules Prerequisites and Strategy Before Panorama can be used effectively, the grouping of firewalls and Virtual Systems must be carefully planned. Panorama combines firewalls in to Device Groups. This allows Panorama to create common security policy for multiple firewalls and improves the efficiency of managing large quantities of firewalls. Device Groups are a key benefit to Panorama. By managing a group of firewalls together rather than individually, a common policy can be created (and maintained) for dozens or even hundreds of firewalls. This provides economies of scale and makes managing large quantities of firewalls far more efficient. Device Groups consist of physical firewalls and virtual systems. A Virtual System is one virtual firewall instance on a physical chassis. If Panorama is managing a firewall that does not have any virtual systems configured, then the default Virtual System (VSYS1) is the managed object. The PA-200 and the PA-500 does not support multiple Virtual Systems but they still contain the default Virtual System VSYS1.Each Virtual System may only belong to exactly one Device Group. It is possible that one physical firewall could have multiple Virtual Systems that are each members of different device groups. Figure 1 shows an example. Revision B 2012, Palo Alto Networks, Inc.

2 Figure 1 The above example divides three physical firewalls, each containing three Virtual Systems into three Device Groups. This is also shown in tabular format in Table 1. Device Group Device Group Members 1 FWA, VSYS1 FWB, VSYS1 FWC, VSYS1,2 2 FWA, VSYS2,3 FWB, VSYS2 3 FWB, VSYS3 FWC, VSYS3 Table 1 For maximum benefit, careful planning is required prior to central policy management with Panorama. For a large firewall deployment, device groups should be selected based on the type of resources the firewall will be protecting i.e. group by function (not other characteristics like size or physical location.) For example, all firewalls used to protect branch offices will typically require similar or identical polices and make a good choice for one device group. Figure 2 shows an example of a logical device group strategy for several different firewall roles. And Table 2 shows how each Zone and Virtual System is mapped to each Device Group in this example. 2012, Palo Alto Networks, Inc. [3]

3 Figure 2 Device Group Member Virtual Systems Attached Zone Attached Zone Branch Device Group Branch1, Branch2, Branch3, Branch4, Branch5, Branch6 Branch LAN WAN WAN Device Group HQ1, HQ2, HQ3, HQ4 WAN Intranet Data Center Device Group DC1, DC2, DC3, DC4 Intranet Data Center LAN Table 2 One thing to note in this example is the WAN Device Group. All of these HQ firewalls separate the Intranet from external networks. However, the HQ1 and HQ2 firewalls connect directly to the Internet whereas HQ3 and HQ4 connect to dedicated, point-to-point links. The security requirements for Internet connectivity versus dedicated connectivity are likely quite different. There are three common ways to handle this situation: One option is to create device specific exceptions to the group policy. This allows for an overall device group policy with firewall specific deviations. This achieved using targets rules (which is covered in the section Order of Precedence.) Another option is to split the device group into two, smaller more granular device groups such as Internet WAN and Carrier WAN. Then each smaller Device Group can have more granular policy applied. The disadvantage with this option is there are more device groups to manage and reduced economies of scale. 2012, Palo Alto Networks, Inc. [4]

4 A third option is to keep all four firewalls in the WAN Device Group and create a common policy that is restrictive enough for Internet connectivity and apply it to all of the firewalls. Some of the rules needed for HQ1 and HQ2 may not be relevant to HQ3 and HQ4 and the rule set will have more protection than is needed for HQ3 and HQ4. It is important that every member (Virtual System) of a single device group have the same zone configuration (name and function.) For example if the branch firewalls each have a branch LAN and a WAN zone, then Panorama can centrally push policies based on those zones and local variations in port/media types, platform types and even logical addressing will not be relevant to the policy configuration. There may be additional, device specific zones that are not shared across the Panorama device group. This is fine as long as the zones used for the primary policy are the same across the device group. Zones must be configured locally on each firewall prior to creating rules in Panorama security policy. Panorama does not have the ability to poll firewalls for Zone names/configurations. Therefore, the first time a zone is referenced in Panorama, the user will need to carefully type the zone name (which is case sensitive.) Subsequent references to this zone are then available in the drop down zone list. See Figure 3 and Figure 4 for an example of a zone reference in Panorama before and after the first time manual entry. Figure 3 Figure 4 Once the zones and Device Groups have been created, the policy should be documented. This aids in the configuration of Panorama particularly in a large deployment. From the example above, a sample policy (greatly simplified for illustrative 2012, Palo Alto Networks, Inc. [5]

5 purposes) might be to allow branch users file services (Server Message Block) to and from HQ and HTTP/SSH access to the Data Center. Also, the DC may need HTTP access to HQ and HQ might require FTP and SSH to the DC. For troubleshooting purposes, ping may be allowed everywhere. Table 3 shows what such a policy would look like in a summarized table. From HQ From Branch From DC To HQ: (Always allowed) Allow SMB, ping and HTTP Allow ping and HTTP To Branch: Allow SMB and ping (Always allowed) Allow ping To DC: Allow FTP, SSH and ping Allow SSH and ping (Always allowed) Table 3 Order of Precedence Panorama provides economies of scale by creating a central location to manage and publish security policy. If some of the firewall rules are in Panorama and some are locally configured on the firewall, the economies of scale can t be realized. For this reason, there should be as few rules as possible in the local configuration ideally none. If locally configured rules are required, the location of rules in Panorama is important. A firewall can have security policy rules that are from multiple sources. A rule can come from: a local configuration a Panorama pre-rule a Panorama post-rule a Panorama device specific or targeted pre or post rule Pre Rules are applied ahead of the locally configured rules and the Post Rules are applied after the locally configured rules as shows in Figure 5. Figure 5 The final rule set is evaluated like any rule set: from the top down. Once a match is found, the remaining rules (if any) are ignored. For example a match in the Pre Rules will negate evaluation of the Local and Post Rules. This will drive whether Pre Rules or Post Rules should be used. If local control of the firewall is required (i.e. for troubleshooting), then Panorama Post Rules should be used. This would allow a local administrator to add a local rule that would be evaluated before any Panorama rules. To prevent local firewall administrators from overriding central policy, all rules could be configured in the Panorama Pre Rule set with the final Pre Rule to be deny all. This would prevent any local rules from ever being evaluated. The local 2012, Palo Alto Networks, Inc. [6]

6 firewall administrative interface will allow a local rule to be added after a deny all pre-rule but it will never be evaluated and you will see a warning in the commit confirmation window as in Figure 6. Figure 6 A Panorama targeted rule will be applied to a subset of the device group. It will be part of the Pre Rules or Post Rules depending on configuration context and will be in the order specified by the administrator in that rule set. To target a rule to a Device Group subset, use the Target tab as shown in Figure 7. Figure 7 By default, all Virtual Systems in a Device Group are targeted for (will receive) a Security Policy rule. However, the Virtual Systems listed in the Target tab will all be unchecked. Even though the Target tab displays all Virtual Systems without a checkbox by default, that actually means all Virtual Systems will receive the rule. Checking one or more boxes means only those checked will be targeted (receive the rule). Checking Install on all but specified devices will invert the effect. On the local firewall, Panorama defined security policy rules can be viewed (in summary) but not edited, disabled, cloned or deleted. Migrating Local Security Policy to Panorama Often, Panorama is installed after some firewalls are already in production. It is important to prep the existing, locally configured firewalls before migrating to Panorama. Because it is required to have a common set of zone names, as mentioned previously, it is worth the effort to migrate to a common zone strategy for each device group before migrating to Panorama. For every configuration subsection that will be managed by Panorama, any locally configured items must not have the same name as what will be delivered from Panorama or the commit will fail. For example, a local security policy rule with the name deny all and a device group Panorama security policy rule with the name deny all will result in a commit error. Another way to allow for a smoother transition is to initially use only Post Rules in Panorama (removing any locally configured deny all rules.) During a test window, temporarily disable a subset (or all) of the original, local rules. This will test the Panorama rules. If testing fails, re-enable the local rules to quickly restore functionality. Then check the new rules and repeat the test. After all testing has succeeded, the Post Rules can be moved to Pre Rules if desired to eliminate local administration and the local rules can be deleted. Below is a high level list of activities to consider when migrating from local administration to Panorama: 2012, Palo Alto Networks, Inc. [7]

7 1. Plan Device Groups by logically grouping devices (actually virtual systems) according to the policies they will enforce. 2. For each virtual system of each device group defined in step 1, migrate the local configurations to a common set of zones. 3. For each virtual system of each device group defined in step 1, migrate the local configurations to a common set of rules. This list will likely be a carefully ordered super set of the original rules. 4. Configure each device for Panorama management. 5. Add each local device serial number to Panorama and verify Panorama connectivity. 6. Create Pre Rules for the device group to be tested. 7. Disable all but one Pre Rule and then commit to the local firewalls. 8. Test the first rule. 9. If the testing is successful, enable another rule and retest. 10. Repeat step 9 until all rules are tested. 11. After all Panorama rules have been running successfully for an extended period, remove all local rules as they are no longer used or needed. Adding or Updating Security Rules with Panorama Adding and editing security rules in Panorama is very similar to the local firewall configuration method. One key difference is the Device Group must be selected first as in Figure 8. Figure 8 When changes are made to a device group security policy in Panorama, clicking the Commit link does not change the configuration on the firewall(s). The commit link only saves the candidate configuration to the Panorama server. For the configuration changes to take affect on the firewalls themselves, they have to be committed to the virtual system or to the entire device group. This is done by clicking the icon for each virtual system or for each device group on the Panorama > Managed Devices page as shown in Figure 9. Figure 9 One thing to note, if a physical firewall has two or more virtual systems that are configured in Panorama in two or more Device Groups, and if those two or more Device Groups require an update to be committed, you will need to wait for the first commit to completely finish before starting to commit the second device group since one physical firewall can only commit one Virtual System at a time. The last column in the Panorama > Managed Devices page will show the Last Commit State which can be used to verify commit completion. 2012, Palo Alto Networks, Inc. [8]

8 Figure 10 shows and example of a variety of commit results. Figure 10 The results in the Last Commit State column are clickable and the user can view the details of the last successful (or failed) commit action. Conclusion Panorama is a powerful tool for creating a central point of policy management. It is a useful method of creating common policy across geographically disparate firewalls and it is also an important tool for scaling to a large firewall deployment. Revision History Date Revision Comment May 23, 2012 B Changed the contents of device group to show it supports both FW and VSYS 2012, Palo Alto Networks, Inc. [9]