Panorama Design and Planning Guide Tech Note PAN-OS 4.1 Revision A ©2012, Palo Alto Networks, Inc www.paloaltonetworks.com Contents Overview Device Groups Design Shared Objects Pre and Post Rule Configuration Admin Roles and Authentication ©2012, Palo Alto Networks, Inc [2] Overview Panorama provides centralized management for the configuration and updating of multiple Palo Alto Networks firewalls This document provides recommendations to assist customers with the design and planning of their Panorama deployments This document assumes the Panorama server has been installed, the management settings have been configured and the Panorama OS has been upgraded to the latest version The installation and initial configuration of the Panorama server is described in the Panorama Installation Guide Device Groups Design Managed firewalls are assigned to a device group that will share global rule and object configurations Common device group designs will group firewalls based on similar functionality, their geographic region and their domain membership Similar functionality: Grouping by functionality is the most common approach used This device grouping allows for the provisioning of similar rules and device specific objects across firewalls classified as: Firewall Function Edge/corporate/remote firewalls or VPN gateways Data center firewalls Partner facing firewalls Domain membership Other functional classification Description These firewalls are deployed as the Internet security gateways for the corporate and remote offices Firewalls deployed at the data center Firewalls to allow secure partner access (see description below) Other specific use firewalls based on customer requirements This grouping allows for the configuration of shared global rules for all corporate firewalls, while at the same time you can maintain configuration for a separate global rule base for the data center firewalls, which will have completely different security requirements from the corporate firewalls Domain membership: If the firewalls managed under Panorama falls under different authentication domains (whether Active Directory or LDAP based), they can be grouped based on their domain membership if Panorama will be used to configure user and/or user-group based rules Firewalls are recognized as standalone firewalls or as a VSYS (Virtual System) The use of Pre and Post rules and the option to allow locally defined rules are discussed later in this document Geographic region: Hierarchically, device groups can also be tiered, grouped first by their geographic region and then grouped by their functionality ©2012, Palo Alto Networks, Inc [3] Example of grouping device groups by geographic region and by functionality is shown below The associated device groups are represented in the Panorama view shown below ©2012, Palo Alto Networks, Inc [4] Shared Objects The use of ‘Shared’ objects reduces the duplication of objects used across device groups Objects most commonly shared are: • • • • Address objects and ranges Address groups Service objects and ranges Service groups When creating objects in Panorama, the shared option is disabled As a best practice, objects should be created as device group specific if they will only be used within a single device group If objects will be used within multiple device groups, the objects should be created as a shared object to prevent duplication of the same object in multiple device groups In the releases of Panorama OS 4.1.x and earlier, the default behavior when a commit is performed from Panorama is to push all shared objects to the devices, whether used or unused on an active policy on that firewall Shared objects are pushed to the target firewalls to support the feature that allows the firewalls’ local configuration to reference the Panorama managed (shared and device-group specific) objects As each Palo Alto Networks firewall model has its own object limits, pushing objects that are not used in the local or Panorama managed configurations can result in the local firewalls’ object limit to be exceeded Note: Panorama 5.0 adds a user configurable feature to control when Panorama shared objects are pushed to the firewalls Even if an object is created as shared, the new feature will only push objects (shared or not shared) to the firewall that is used in the Panorama rules This is the case when the rules are configured as ‘Shared’ or ‘Device Group’ specific Panorama 5.0 is backwards compatible allowing management of firewalls running PAN-OS 4.0 and 4.1.x The options to control when shared objects are pushed or not pushed can be enabled in ©2012, Palo Alto Networks, Inc [5] mixed environments where a Panorama running OS 5.0 is managing firewalls running PANOS 4.0.x and 4.1.x Pre and Post Rule Configuration Rules in Panorama can be added as ‘Pre’ or ‘Post’ rules within each device group Administrators can decide to manage rules as Pre, Post or use a combination of both, including the insertion of locally added rules, which are placed in order between the Pre and Post rules managed from Panorama Version 5.0 includes a new rulebase, called ‘Shared’ rules which are used to manage rules that can be applied to firewalls across multiple device groups Additional information on the use of the ‘Shared’ rules will be available in the PANOS 5.0 Administrators Guide Rules are checked from top to bottom with the Pre rules checked first in order, followed by the local rules, then the Post rules Pre Rules: Pre rules are inserted at the top of the rule order and are checked first in the configuration in the pre-rulebase, before the post or locally defined rules Examples on the use of pre rules are to insert global use rules such as blocking peer-to-peer traffic for all users, or allowing DNS traffic for all users Additional factors used to decide to use pre only rules are administrative restrictions that not allow rules to be created locally on the firewalls To prevent local firewall rules from allowing unwanted traffic, it is recommended that you create default deny rules in the pre-rulebase The default deny policies should be inserted at the bottom of the order of the pre-rulebase Post Rules: Post rules are inserted at the bottom of the rule order and are checked in their configuration order in the post-rulebase, after the pre and locally defined rules Examples of post ©2012, Palo Alto Networks, Inc [6] rule use are global deny rules, either by appID/service/user/IP based or a combination of, or to create default zone to zone deny rules to use for logging of all blocked traffic When planning for rule management, it is recommended that Panorama is used to manage a post rule database if admins will be configuring rules locally on the firewall If the rule administration design will allow for both local rules and centrally managed pre and post rules, the pre-rulebase should not contain global default deny rules Instead, any deny rules in the pre-rulebase should be created as appID/service/user/IP specific or a combination of those Admin Roles and Authentication Panorama provides granular role based administrator controls based on configuration and distributed device level access Used together, administrator access can be locked down to provide a sub-administrator controlled configuration access applied only to a specific set of firewalls In most cases, the administration of the firewalls will be managed by the members of a core security team For cases where administrative access must be given to members outside of the core security team, it is recommended to evaluate the specific needs of the administration request and to lock down access based on a list of operational features the administrator will need access to, and possibly to which devices they will need administrative privileges Examples include configuring role based access for HR to view and run user reports, executive level access to view the ACC, and NOC and SOC personnel who require access to mine data in the traffic and other logs The ‘Admin Role Profile’ shown below is used for NOC/SOC personnel to meet the requirements defined in the following table Authentication for administrator accounts can reside locally on the Panorama server, or the admin credentials can be forwarded to RADIUS, via LDAP or a Kerberos exchange NOC /SOC Access Requirements View the Dashboard, ACC, Logs (all logs) PDF and Reports (All) All policies and Objects: Network Interface and Routing Create Panorama Administrators Device and device group management Edit the HA settings on the device From Panorama apply OS and content upgrades Commit CLI Access Device Access ©2012, Palo Alto Networks, Inc Privilege Allowed Blocked Read-Only Read Only Blocked Read Only Blocked Blocked Allowed Read Only Limit access only to the ‘Americas_DC’ firewalls [7] The following screen captures show the admin role configuration used to meet the requirements for the NOC/SOC admin The ‘Device Group’ option is used to assign the role based access privileges to a specific set of firewalls, as shown in the ‘Access Domain’ profile that follows ©2012, Palo Alto Networks, Inc [8] Upon login, the NOC admins privileges will be enforced, based on the Admin Role configuration The screen below show the NOC admin able to only view the ‘Americas_DC’ firewall policies, but not able to edit and apply changes ©2012, Palo Alto Networks, Inc [9] ... the configuration in the pre-rulebase, before the post or locally defined rules Examples on the use of pre rules are to insert global use rules such as blocking peer-to-peer traffic for all users,... recommended that you create default deny rules in the pre-rulebase The default deny policies should be inserted at the bottom of the order of the pre-rulebase Post Rules: Post rules are inserted at the... rules and centrally managed pre and post rules, the pre-rulebase should not contain global default deny rules Instead, any deny rules in the pre-rulebase should be created as appID/service/user/IP