Administrave Access Best Pracces

10.1

docs.paloaltonetworks.com
Contact Informaon
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support

About the Documentaon

• For the most recent version of this guide or for access to related documentaon, visit the Technical
Documentaon portal docs.paloaltonetworks.com.
• To search for a specific topic, go to our search page docs.paloaltonetworks.com/search.html.
• Have feedback or quesons for us? Leave a comment on any page in the portal, or write to us at
documenta[email protected].

Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com

© 2021-2022 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo
Alto Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks menoned herein may be trademarks of their respecve companies.

Last Revised
May 12, 2022

Administrave Access Best Pracces 10.1 2 ©2022 Palo Alto Networks, Inc.
Table of Contents
Administrave Access Best Pracces........................................................... 5
Plan Administrave Access Best Pracces............................................................................6
Deploy Administrave Access Best Pracces.......................................................................8
Select the Management Interface................................................................................ 8
Manage Administrator Access.................................................................................... 12
Isolate the Management Network.............................................................................16
Restrict Access to the Management Interface........................................................18
Replace the Cerficate for Inbound Traffic Management.................................... 21
Keep Content and Soware Updates Current........................................................21
Scan All Traffic Desned for the Management Interface..................................... 21
Maintain Administrave Access Best Pracces................................................................. 24

Administrave Access Best Pracces 10.1 3 ©2022 Palo Alto Networks, Inc.
Table of Contents

Administrave Access Best Pracces 10.1 4 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces
No network security system is secure if you don’t lock down administrave access to
network devices. This is especially true for firewalls and security management devices
such as Panorama because they are the gatekeepers and protectors of your network.
Aackers who gain administrave access to these devices can reconfigure them in
order to permit malicious access to your network remotely, facilitate the distribuon
of malware to endpoints, and even lock you out of your own network.
To safeguard your network from such aacks, follow the best pracces in this
document—scan administrave traffic for threats, and secure administrator and
programmac access to device management, the management network, and the
management interface.
This document contains a streamlined checklist of planning, deployment, and
maintenance best pracces so that you can secure administrave access to your PAN-
OS firewall and Panorama devices. Each secon includes links to detailed informaon
in the PAN-OS Admin Guide that shows how to configure different aspects of
administrave access in case you’re not familiar with some of the procedures.
This best pracce guide is wrien from the point-of-view of a new deployment to show
how to create a secure management network and configure secure access to firewall
and Panorama management interfaces. However, many enterprises have an exisng
management security strategy and implementaon. For exisng deployments, these are
the recommended best pracces to migrate to and to keep in mind if you overhaul your
management network security. If you haven’t adopted these best pracces in an exisng
framework, adopt them if possible to ghten security around administrave access.

> Plan Administrave Access Best Pracces

> Deploy Administrave Access Best Pracces
> Maintain Administrave Access Best Pracces

5
Administrave Access Best Pracces

Plan Administrave Access Best Pracces

If you’re in the planning stage of implemenng your management network, follow these best
pracces to prepare for a safe deployment that follows the principles of least privilege for all
management network access, and for access to the firewall and Panorama management interfaces.
If you already deployed your management network, compare your architecture to the best
pracce recommendaons and see if there is any way to further secure management access.
Aer you deploy these best pracces, your management network will allow access only to the
administrators, services, and APIs required to manage firewalls and Panorama.
Set up a bason host or a similarly hardened server for the sole purpose of providing access to
the private management network. Lock down the bason host as ghtly as possible because it
may allow access from administrators over the internet (via VPN) as well as internal access from
outside the management network. Using the bason host only for management network access
is safest because the more services the host handles, the more potenal vulnerabilies may be
present.
If you can’t set up a bason host, create or use an exisng management network specifically
for firewall and Panorama management and restrict access to that network to only the
administrators who have legimate need to manage firewalls and Panorama. Ensure that
administrators go through strict authencaon before they can access the management
network.
Set up User-ID on firewalls protecng the bason host(s) and management network(s) and
follow User-ID best pracce recommendaons. User-ID enables you to manage user group and
individual user access in Security policy rules to provide an addional level of idenficaon
and protecon along with specifying allowed IP addresses, zones, devices, and applicaons.
Combining these objects in Security policy enables you to lock down management access and
allow only the necessary traffic on device management interfaces.
Set up a centralized authencaon system such as a privileged account management (PAM) or
privileged identy management (PIM) soluon to centralize control of access privileges.
Understand which administrators need to access the firewall and Panorama and the level of
access that they need so that you can plan role-based access control (RBAC). Level of access
means not just considering read-only versus read-write access, it means liming administrave
rights to view or change only the specific areas of the device that they manage. Granular RBAC
requires individual administrator accounts so that you can use Admin Role profiles to control
the exact access level for each administrator and may also require passing RADIUS aributes to
the device.
Understand which services need management access to the firewall and Panorama. Allow only
necessary services to access the management network and device management interfaces.

Administrave Access Best Pracces 10.1 6 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Audit, list, and understand all programmac access requirements that leverage the firewall and
Panorama APIs. For example:
• Network-as-code and policy-as-code tools that modify the configuraon, such as Ansible or
Terraform.
• Rulebase analysis and audit tools.
• PAM/PIM tools.
• DNS, DHCP, and IPAM (DDI) tools.
• IT operaons and service management tools.
• In-house scripts and tools.
• Any other programmac access to the management interface.
For each required programmac access, list:
• Admin accounts used.
• Method of access (HTTPS, SSH, or API).
• Source IP address or network of the access.

Filter the System logs for administrave login events to help with auding exisng
programmac access.
Ensure that your architecture enables you to inspect and log all inbound management traffic
and to regularly monitor the traffic for suspicious acvity.
To ensure that you can connect to and manage crical devices, including firewalls and
Panorama, during power outages and other events that prevent the use of normal
communicaon channels, design and implement an access strategy for business connuity.

Administrave Access Best Pracces 10.1 7 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Deploy Administrave Access Best Pracces

Deploying administrave access best pracces consists of seven tasks:
• Select the Management Interface
• Manage Administrator Access
• Isolate the Management Network
• Restrict Access to the Management Interface
• Replace the Cerficate for Inbound Traffic Management
• Keep Content and Soware Updates Current
• Scan All Traffic Desned for the Management Interface
The two most crical best pracces concepts to keep in mind as you deploy or update
management access are:
• Always apply the principle of least privilege access, which means:
• Enable management access only for the people and services that must have access to
manage the device.
• Limit access for each administrator and service to only the areas of the device and the
privileges required to perform the necessary management funcons. Use role-based access
control (RBAC) to define access privileges for each administrator.
• Isolate the management network and isolate the device’s management interface so that only
management traffic, administrators, and administrave services can access the management
network.
• Inspect all traffic desned for the management port.
• Apply Security policy rules that not only specify the IP addresses of administrators and
devices allowed access, but that also specify the applicaons allowed, the source and
desnaon zones allowed, and the users allowed. Granular Security policy enables you to
allow the right access to the right people and services on the right devices.
• Apply appropriate threat prevenon profiles to the traffic in Security policy.
• Log the traffic and forward the logs to the appropriate administrators and long-term storage.

Select the Management Interface

On PAN-OS firewalls, you can use either the dedicated Management (MGT) port or a dedicated
in-band dataplane (DP) port as the management interface. On Panorama, you can only use the
dedicated MGT port as the management interface. Regardless of which port you use as the
management interface, use an architecture that enables you to inspect and control inbound traffic
to the management interface with Security policy.

If you are deploying a firewall for the first me, you must perform the inial configuraon
using the MGT port.

You cannot apply Security policy rules directly to traffic that ingresses the dedicated MGT port.
However, you can route incoming traffic for the MGT port through a DP port to decrypt and

Administrave Access Best Pracces 10.1 8 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

inspect the traffic. You can use a variety of methods to route incoming MGT port traffic for
inspecon, such as:
• Looping back through a local DP port on the same device (MP to DP connecon).
• Connecng to a DP port on another firewall.
• Leveraging upstream roung/switching infrastructure to provide the appropriate isolaon and
the appropriate inspecon by firewalls.
When you use a DP port to inspect traffic desned for the MGT port, do not enable management
protocols on the DP port. Enable management protocols only on the MGT port. Understand the
external services and service routes for which you will need to set up access

PAN-OS allows you to configure access to management-related funcons such as the

web interface or SSH on DP ports, but that is different than isolang and inspecng
physical MGT port traffic on a DP interface. To ensure the highest level of security, limit
administrave access traffic such as web UI, API, and CLI to the dedicated management
interface unless site requirements prevent it.

If you can’t route traffic desned for the MGT port through a DP port interface on another firewall
for inspecon, configure a dedicated DP port to be the management interface so that you can
use Security policy to inspect the inbound management traffic. If you use the DP port as the
management interface, isolate it as described in this secon. Using a DP port as the isolated
management interface trades consuming a producon port for safeguarding management traffic.

If you choose to route inbound management traffic to the MGT port without prior
inspecon, understand the risks of not inspecng the traffic, which include unauthorized
access to device management, potenal malicious acvity, and unblocked threats. The
best pracce is always to inspect inbound management traffic because it controls and
configures your device.

Management networks that include more than one firewall (and Panorama)—Use the MGT
port as the management interface.
Route incoming management traffic through an isolated DP interface on a different firewall first
and use Security policy to inspect the traffic before forwarding it to the MGT port. This method
enables you to inspect and control traffic without consuming a dedicated DP port.
To use a DP port on a different firewall to inspect MGT port traffic before forwarding that
traffic to the managed firewall:
Configure a dedicated subinterface and a dedicated VLAN to isolate the traffic on the
inspecng firewall’s DP port. Allow only management traffic on that subinterface and in that
VLAN. Using a dedicated management subinterface with a dedicated management VLAN
enables you to use the rest of the port’s bandwidth for producon traffic while sll isolang
the management network traffic.
Configure Security policy rules (see Scan All Traffic Desned for the Management Interface)
that restrict access to the management interface based not only on IP addresses, but also
on users (User-ID), applicaons (App-ID), and zones, and aach a best pracce Vulnerability
Protecon profile.
A number of network architectures enable inspecng traffic desned for the management port,
many of which depend on company-specific needs. The following topology diagrams show two

Administrave Access Best Pracces 10.1 9 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

common high-level architecture examples of using a DP port on one firewall to inspect traffic
desned for the MGT port of a firewall in the management network. Both architectures have
these common components:
• A firewall administrator aempng to access a device. Administrators who are external to
the network access the network using a VPN.
• A bason host that authencates the administrator to prevent unauthorized access to the
management network and management devices.
• A firewall with a dedicated subinterface and a dedicated VLAN on a DP port to isolate the
management traffic. The firewall inspects management traffic before the traffic enters the
management network. No management protocols are enabled on the DP port.
• An isolated management network, protected by the bason host and the inspecng firewall.
• A device that the administrator manages using the MGT port.
Aer each diagram is a descripon of its packet flow.

Figure 1: Management Isolation Topology 1

Packet Flow
1. The firewall administrator (1) uses a VPN connecon to aempt to log in and manage a
firewall (5)
2. The bason host (2) authencates the administrator’s credenals.
3. If authencaon succeeds, the bason host (2) creates a new session and forwards the
traffic to the inspecng firewall (3), which protects the management network. The firewall
decrypts and inspects the traffic.
4. If Security policy on the inspecng firewall (3) allows the administrator to access the
firewall (5) in the management network, the inspecng firewall (3) forwards the traffic to
the management network (4) and is restricted to connecng only to the device (5) that
the administrator needs to manage. Security policy rules determine which devices the
administrator can access, from where, using which applicaons, and even when, and how

Administrave Access Best Pracces 10.1 10 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

to inspect the traffic. Role-based access profiles control the privilege level the administrator
has on each device.
5. All subsequent traffic between the administrator (1) and the managed device (5) is inspected
(3) for threats.

Figure 2: Management Isolation Topology 2

Packet Flow
1. The firewall administrator (1) uses a VPN connecon to aempt to log in and manage a
firewall (5)
2. The administrator’s traffic reaches the inspecng firewall (2) that protects the management
network. The firewall decrypts and inspects the traffic, and then forwards it (A) to the
bason host (3).
3. The bason host (3) authencates the administrator’s credenals.
4. If authencaon succeeds, the bason host (3) creates a new session and forwards it (B)
back to the inspecng firewall (2), where the traffic is inspected again.
5. If Security policy on the inspecng firewall (2) allows the administrator to access the
firewall (5) in the management network, the inspecng firewall (2) forwards the traffic to
the management network (4) and is restricted to connecng only to the device (5) that
the administrator needs to manage. Security policy rules determine which devices the
administrator can access, from where, using which applicaons, and even when, and how
to inspect the traffic. Role-based access profiles control the privilege level the administrator
has on each device.
6. All subsequent traffic between the administrator (1) and the managed device (5) is inspected
(2) for threats.

Management networks in which you cannot use another firewall’s DP port to inspect inbound
MGT port traffic—Dedicate one of the firewall’s DP ports as the management interface so
that you can apply Security policy to inspect and control management traffic (do not use the

Administrave Access Best Pracces 10.1 11 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

MGT port as the management interface). Do not allow any traffic on the DP port other than
management traffic.
The tradeoff is best security against not being able to use one DP port as a producon port.
If you can’t dedicate a firewall DP port to management traffic and must use the out-of-band
MGT port, understand the risks and follow the rest of the best pracces in this document to
isolate the management network and restrict administrator and service access to only those
that require access to manage the device.

When you can’t use a DP port interface on a different firewall to inspect the traffic,
dedicate a firewall DP port to management traffic or you won’t be able to apply
Security policy or Threat profiles to inbound management traffic. That means you can’t
inspect traffic, apply Vulnerability Protecon profiles, or use Security policy to restrict
MGT port access in a granular manner. You can use a loopback interface or another
method to route the traffic from the MGT port to a DP port on the same firewall, but
you sll need to dedicate the DP port to the management traffic to isolate it on the
device.

Manage Administrator Access

Controlling administrators and services that manage a device boils down to applying the principle
of least privilege access. Understand which administrators and services need which level of access
—ask yourself, does an administrator need to configure anything or is read-only access sufficient?
Which areas does each administrator manage?
The principle of least privilege access along with ensuring proper authencaon and acvity
monitoring is especially important for Panorama access because Panorama controls mulple
firewalls.
STEP 1 | Replace the default admin account.
The first me that you log into a firewall or Panorama, it forces you to change the default
admin account password. The most secure acon is to replace the default account with a new
local account because the username “admin” is well known. Configure one local account to
ensure that you can access the device if the network or the authencaon server goes down
and make it the only local account on the device. When you specify the new local account’s
login and password, make them as secure as possible.
If this is your first login to the device, perform the mandatory change to the default admin
account password. (See Step 5 of Perform Inial Configuraon).
Create a new local superuser account with a strong password. In Device > Administrators,
Add an administrator, create a strong password based on the recommendaons of Naonal

Administrave Access Best Pracces 10.1 12 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Instute of Standards and Technology (NIST) or local regional standards bodies, and
applicable compliance regulaons. Set the Administrator Type as Dynamic and Superuser.
Log out of the firewall or Panorama and then log back in with the new, more secure local
admin account that you just configured.
Delete the default admin account so that your new local superuser account is the only local
account on the device. In Device > Administrators, select the default admin account and
then Delete the account.
Store the new local login and password credenals in the safest storage your enterprise has
available in case emergency access is required.

If for business reasons you must have more than one local account on the firewall,
follow the best pracces for password construcon and usage later in this secon.
However, mulple local admin accounts are not a security best pracce because
each local account increases the risk of credenal compromise resulng in
unauthorized access.

STEP 2 | For all management access other than the default local administrator account, including
API access, Configure a Firewall Administrator Account, use an external authencaon
system (see Configure Local or External Authencaon for Firewall Administrators) with
a password manager that generates passwords automacally and configure Mul-Factor
Authencaon (MFA) to prevent the unauthorized use of stolen credenals. The mandatory
local superuser account is the only local account that you should have on the device (to use
in case of emergency).
NIST Special Publicaon 800-63B Digital Identy Guidelines describes standard best pracces
for digital authencaon management in the U.S. Other regions may have local enes that
provide standard best pracces.

If you cannot implement the best pracce of using an external authencaon system
and must configure local administrators, Configure Cerficate-Based Administrator
Authencaon to the Web Interface and Configure SSH Key-Based Administrator
Authencaon to the CLI to increase security. Always use MFA to protect against
compromised credenals.

Enable MFA for all management access with external authencaon and authorizaon using
RADIUS or SAML and corporate credenals (use your exisng authencaon system if you
have one). If available, use privileged account management (PIM) and/or privileged identy
management (PIM) soluons to secure credenals externally.
If you have a strong authencaon system using smart cards, Configure Cerficate-
Based Administrator Authencaon to the Web Interface and Configure SSH Key-
Based Administrator Authencaon to the CLI. If your system can’t use MFA, import the
cerficate from the SAML provider to ensure secure access. If you manage cerficates
through a cloud provider, use client cerficates to provide secure login access. Use client
cerficates for on-premise access to help protect servers against DoS aacks.
Ensure that the password manager follows industry recommendaons for construcng
strong passwords, such as those published by NIST in NIST Special Publicaon 800-63B
Digital Identy Guidelines and Easy Ways to Build a Beer P@$5w0rd, and follow

Administrave Access Best Pracces 10.1 13 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

compliance regulaons. Some regions may have local enes that require compliance
regulaons.
Follow industry password usage best pracces such as those published by NIST (or local
standards authories and compliance regulaons).
Change the master key on the device to prevent the default master key from being
compromised and used to decode passwords. Take the following acons when you change
the master key:
Back up your configuraon before you change the master key.
In HA firewall configuraons (standalone or Panorama-managed), disable Config Sync on
both firewalls before you change the master key, and then configure the same master key
on both devices before you re-enable Config Sync.
On Panorama, WildFire and Log Collector devices must use the same master key as
Panorama.
Reseng the master key results in down me, so do it during a normal maintenance
period.
As with the local admin account, store the master key in the safest storage your
enterprise has. You need the current master key to reset the master key (periodically
reset the master key because eventually it runs out of unique encrypons). If you lose the
master key, the only way to reset it is to reset the system to the factory default.

If you lose the master key and factory reset the device and the default master
key was changed before the reset, your backed up configuraon won’t work on
the device aer the reset because the master key is different.
Securing API access is similar to securing administrator access. The main difference is that
aer you configure administrator accounts and role-based access control (RBAC, see Step
4), you generate an API key, which contains an API’s authencaon details, and use the key
for subsequent API access instead of subming the username and password credenals
every me.
Using API keys is a best pracce because it enables you to Configure API Key Lifeme to
enforce regular key rotaon and harden your security posture. When you enable API key
lifemes on firewalls or Panorama, ensure that the systems and scripts which access those

Administrave Access Best Pracces 10.1 14 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

devices update their API keys at the end of the configured lifeme to prevent disrupng
access.
For SNMP access, if your infrastructure supports it, use SNMPv3 instead of SNMPv2c.
SNMPv3 has many security improvements that are best pracces to implement. SNMPv3:
• Enables granular, per-manager and per-agent access to MIB objects, so you can restrict
access to the areas that the manager or agent needs to access. (SNMPv2c gives access to
all MIBs to all managers and agents.)
• Enables granular, per-manager and per-agent authencaon requirements.
• Provides encrypon instead of transming data in cleartext and has stronger hashing
algorithms.
Create the appropriate SNMP accounts and configure the firewall or Panorama to
communicate with the SNMP Manager to Monitor Stascs Using SNMP.
You can route SNMP traffic through the MGT port or through a DP port (must be a layer 3
Ethernet interface). If you use the MGT port, first send inbound traffic through a DP port
on the same firewall or on another firewall so that you can control and inspect the incoming
traffic using Security policy rules. Create a dedicated subinterface and a dedicated VLAN on
the DP port to isolate the SNMP traffic.

If the SNMP Manager is outside of the management network, route SNMP

traffic through the bason host or a similarly hardened server at the edge of the
management network.

If you use SNMP to manage routers or switches that are behind the firewall,
configure the appropriate Security policy rule to allow the traffic.

STEP 3 | Limit access to users and services that manage the firewall.
Only allow access for people and services that need to manage the device.

STEP 4 | Assign an Admin Role Profile (Device > Admin Roles) to each administrator or group or
department of administrators who have the same role and to each service or group of
services that require the same access. Configure each profile sot that it limits access to only
the areas of the device that each administrator, group of administrators, service, or group
of services manages. Create individual, unique accounts for each administrator and for each
service (for example, Terraform, Ansible, Tufin, etc.).
Configure administrave access only for people and services that need to manage the
device.
Configure a unique firewall administrator account for each administrator and for each
service so that you can control and idenfy them individually. Administrave Role Types
describes the access roles you can assign to administrators. Don’t use the same account for
more than one administrator or for more than one service. API access for services works
similarly to access for human administrators, including using role-based access.
Apply the appropriate Admin Role Profile to each individual account.
Configure Admin Role Profiles and apply them to individual administrator and service
accounts to control access privileges granularly. Profiles determine what the administrator(s)
or service(s) can do and how they can do it (CLI, API, UI). Configure each profile to limit

Administrave Access Best Pracces 10.1 15 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

administrave privileges to only the areas of the device that an administrave group,
department, individual, or service needs to manage. Do not over-provision administrators or
services; allow only the required access privileges. Reference: Web Interface Administrator
Access describes the web access privileges that you can assign or deny to administrators on
the firewall and on Panorama.
In Panorama, Configure Access Domains to control administrave access to specific Device
Groups, templates, Log Collector Groups, etc.
Add a Commit Descripon when you commit changes so that others can understand the
reason for the change or addion.

STEP 5 | Configure a login meout (Idle Timeout) to prevent administrators from leaving idle sessions
open too long, specify a number of Failed Aempts to prevent brute force aempts to log in,
and specify a Lockout Time to prevent further immediate access aempts aer reaching the
Failed Aempts limit.
Configure global meout sengs for the device in Device > Setup > Management >
Authencaon Sengs or configure more granular sengs for Failed Aempts and
Lockout Time in Device > Authencaon Profile.
Check NIST Special Publicaon 800-63B Digital Identy Guidelines or local regional
standards bodies or applicable compliance regulaons for recommended sengs.
If you allow API access, Configure API Key Lifeme based on what makes sense for your
deployment to enforce regular key rotaon—don’t over-provision the key lifeme.

STEP 6 | Configure Administrator Acvity Tracking and send the logs to an external server for auding
and monitoring.

STEP 7 | Configure System logs and use Log Forwarding to send them to an external server for
auding and monitoring. Use a method that nofies administrators of events so that they can
take acon in a mely manner.

STEP 8 | Use the Administrator Login Acvity Indicators to Detect Account Misuse such as a high
number of failed login aempts.

STEP 9 | Enforce audit comments in policy rules so that you can understand why an administrator
created or modified a rule.

Isolate the Management Network

To help prevent unauthorized access to devices, allow only management traffic, device
administrators, and management services on your dedicated management network.

Enable access to the management interface only from within your dedicated management
network. Do not enable access to your management interface from the internet or from
other zones inside your enterprise security boundary.

STEP 1 | Use a bason host (or a similarly hardened host dedicated only to management network
access) with screen recording and the strongest authencaon and access control to provide
secure external access to your dedicated management network. Figure 1: Management

Administrave Access Best Pracces 10.1 16 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Isolaon Topology 1 and Figure 2: Management Isolaon Topology 2 show example

topologies with a bason host.
Only allow external connecons to the firewall management interface from the bason host
so that all incoming management traffic is authencated, regardless of whether that traffic
originates in the internet or in a non-management zone in your internal network. This makes
the secure bason host the only authencaon gateway to the management network. It
also makes the bason host’s IP address(es) and the secure management network the only
IP addresses that need to access the management interface. Only allow access to device
management ports from the management network zone—do not enable direct access from
the internet or from any other zones.
For example, external administrators and services can use a VPN to authencate to and
access the management network through the bason host. Aer logging in to the bason
host, with the proper permissions, the administrator or service can then log in to the firewall
or Panorama.

Bason hosts authencate external traffic to the management network. However,

not all inbound traffic comes through the bason host. For example, internal
management network traffic (originang in the management zone) does not
authencate through the bason host. User-ID, EDLs, and some other types of
traffic usually reach the firewall using a service route or from within the dedicated
management network.
For Panorama, ensure that all managed firewalls are in the dedicated management
network(s). Expose the Panorama MGT port only to the management network(s).
Ensure that administrators and services that require management access are allowed to
access the bason host so that you don’t accidentally cut off access for essenal services.
If you can’t use a bason host as a single point of access to the management network,
create a dedicated management network and allow management access only from hosts in
that IP network. Include only the administrators and services that manage devices and the
management interfaces of the devices in the management network. Do not allow access
for anyone or any service that does not manage devices in the network. Require MFA for
all management access. (For restricng permied IP addresses on the firewall or Panorama
management interface, see Step 2 in Restrict Access to the Management Interface.)

STEP 2 | Enable access to the management network only from the management zone (including the
bason host). Do not allow direct access to the management network from the internet or
other zones.

Administrave Access Best Pracces 10.1 17 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

STEP 3 | Require strict user authencaon to access the management network.

Authencate mulple mes. Authencate at the bason host and authencate again at the
firewall.
Always require MFA to prevent aacks based on stolen credenals.
If you need remote access to device management, use a VPN tunnel and authencate
through the bason host and again through the firewall.
If you don’t have a bason host, use Authencaon policy with MFA.
Regardless of where access originates, follow the same process: allow least privilege access
through the bason host (or equivalent hardened server dedicated to management network
access), authencate, and require MFA.

Restrict Access to the Management Interface

Although the most crical concept for safeguarding the management interface is not to allow
direct access from outside of your dedicated management network, there are also many other
acons to take to secure the management interface.
STEP 1 | Allow direct inbound management interface access only from within the dedicated
management network.
Route internet access via VPN through a bason host (or similarly hardened server that enables
screen recording) for authencaon to protect the management interface and network. If
you can’t use a bason host, allow access to the management interface only from within the
management network. Do not allow direct access to the management interface from outside of
the management network and never expose the management interface directly to the internet.

STEP 2 | Configure management interface sengs to restrict the available services and to restrict the
allowed IP addresses.
1. If you use the MGT port as the management interface (mandatory on Panorama),
configure Management Interface Sengs (Device > Setup > Interfaces > Management)
to restrict the services and IP addresses available on the management interface.
Enable HTTPS and SSH, and if you want to test connecvity to the device or use
monitoring and scanning tools, enable ping. Do not allow cleartext protocols (HTTP,
Telnet).

When enabling services, follow the principle of least privilege access—allow

only the services you need to manage the device.
Specify the Permied IP Addresses. Ideally, the only allowed IP addresses are
the bason host’s IP addresses and required IP addresses within the management
network. If you don’t have a bason host or similarly hardened server to act as

Administrave Access Best Pracces 10.1 18 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

the border guard for your management network, allow only IP addresses in the
management network to access the management port.

Because you must use the MGT port as the Panorama management interface,
you may need to specify IP addresses to allow the necessary services to
access the device. You also may need to open Ports Used for Panorama to
allow necessary services. Allow only the IP addresses and open only the ports
for required services and follow the principle of least privilege access.
Route incoming MGT port traffic to a DP interface on another firewall or on the same
firewall (as described in Select the Management Interface with the examples Figure
1: Management Isolaon Topology 1 and Figure 2: Management Isolaon Topology
2) so that you can apply Security policy to the traffic. Do not configure management
protocols on the DP interface you use to inspect the traffic desned for the MGT
port. Configure the same type of Security policy rule for inbound traffic as described
in Step 3 in Scan All Traffic Desned for the Management Interface.
For SNMP access, follow the recommendaons here.
2. If you use a firewall DP port as the management interface, configure an Interface
Management Profile (Network > Network Profile > Interface Mgmt) to restrict the
services and IP addresses available on the management interface.
Enable only the services that you require to manage the device (principle of least
privilege access). For example, enable HTTPS for web UI access and SSH for CLI
access. If you want to test connecvity to the device or use monitoring and scanning
tools, enable ping. If you use the management port for SNMP, enable SNMP, etc. Do
not allow cleartext protocols (HTTP, Telnet).

Panorama may require allowing certain ports to support services.

For firewalls that Panorama manages, if you require administrators to context

switch on Panorama for web UI (HTTPS) access, then only enable SSH access
on the firewall and enable both HTTPS and SSH access on Panorama.
Specify the Permied IP Addresses. Ideally, the only allowed IP addresses are
the bason host’s IP addresses and required IP addresses within the management
network. If you don’t have a bason host or similarly hardened server to act as
the border guard for your management network, allow only IP addresses in the
management network to access the management port.
Create a Security policy rule for inbound traffic to the management interface (see Step
3 in Scan All Traffic Desned for the Management Interface).
3. Treat and inspect external access the same way you treat and inspect internal access.
Traffic from VPNs and external services should access the management interface
through the bason host or equivalent so that the traffic is treated and inspected the
same way as internal traffic. Never expose the management interface directly to the
internet.
If you don’t have a bason host, route access through the dedicated management
network, authencate with MFA, and inspect the traffic. Don’t allow a VPN or

Administrave Access Best Pracces 10.1 19 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

anything else that originates outside of the dedicated management network to access
the management interface directly.
If you have Panorama devices that manage firewalls in different networks, treat the
traffic similarly to other external traffic—inspect the traffic and limit connecvity
following the principle of least privilege access (Ports Used for Management Funcons
describes the ports and protocols for management funcons).

STEP 3 | Allow access using only the most secure version of Transport Layer Security (TLS) encrypon
and most secure encrypon sengs.
If you use the MGT port as the management interface, Configure an SSL/TLS Service
Profile (Device > Cerficate Management > SSL/TLS Service Profile) that uses strong
encrypon to restrict access to the web interface and protect against weak protocols.
Set the Min Version to TLSv1.2 and the Max Version to Max. Seng TLSv1.2 as the Min
Version automacally blocks the weak 3DES and RC4 encrypon algorithms and MD5
authencaon algorithm.
Depending on applicable compliance regulaons, you may want to block other
authencaon, encrypon, and key exchange algorithms, which you can do in the CLI using
the configuraon command set shared ssl-tls-service-profile <profile-
name> protocol-settings.
Configure an SSH Service Profile (Device > Cerficate Management > SSH Service
Profile and Add a management server profile) to restrict SSH access to the CLI to only the
encrypon cipher, authencaon, and key exchange algorithms that meet your compliance
regulaons. If you don’t configure this profile, all algorithms are allowed, including weak
encrypon algorithms that you should block.

STEP 4 | As described in Step 5 of Manage Administrator Access, prevent brute force aacks on
administrator logins and prevent leaving idle sessions open too long.

STEP 5 | Treat external services such as DNS, NTP, authencaon, and Palo Alto Networks Services
the same way that you treat other external traffic desned for the MGT port: run the traffic
through a firewall DP port to inspect it before it reaches the MGT port.
By default, the firewall uses the dedicated MTG port to access services that are outside of
the management network. If you can’t access the required services through the management
network and inspect them, Configure Service Routes (Device > Setup > Services > Service

Administrave Access Best Pracces 10.1 20 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Route Configuraon) that use a DP port instead of the MGT port so that you can inspect the
traffic. When you configure services routes:
Follow the principle of least privilege access and allow only the services you need.
Create a dedicated subinterface and a dedicated VLAN on the DP interface to isolate the
services traffic.
Customize service routes by specifying a source interface and source address on the firewall
or Panorama that does not have management access enabled.
Apply Security policy to the traffic (see Scan All Traffic Desned for the Management
Interface).

Use App-ID in Security policy to ensure that only the required service applicaons
are allowed. There are App-IDs for many common services (such as DNS) that you
can use to lock down access and prevent unnecessary applicaons from accessing
the device.

Some services, such as SNMP, cannot use service routes. For these services, the
same advice applies: before the traffic reaches the MGT port, run the traffic through
a firewall DP port on a dedicated subinterface and a dedicated VLAN to isolate the
traffic, and apply Security policy to control and inspect the traffic.

Replace the Cerficate for Inbound Traffic Management

Replace the default cerficate for inbound management traffic that the firewall automacally
generates on the first boot up with a new cerficate issued specifically for your enterprise. Use a
cerficate signed by your enterprise CA (if you have an enterprise PKI) for best security.

Keep Content and Soware Updates Current

Ensure that content and soware updates are current so that the device receives the latest
security patches and threat updates.
STEP 1 | Subscribe to content update emails, security advisories, and soware updates on the
Customer Support Portal.

STEP 2 | Read the latest Release Notes before you upgrade PAN-OS.

STEP 3 | Follow Best Pracces for Applicaons and Threats Content Updates when updang to the
latest content release version.

Scan All Traffic Desned for the Management Interface

Apply Security policy rules that scan all inbound traffic to the management interface. To scan the
inbound traffic on the management interface, you must run traffic desned for the MGT port
through a firewall DP port for inspecon first or you must use a DP port as the management
interface, as described in Select the Management Interface. You cannot apply Security policy
directly to traffic on the MGT port, you must run the traffic through a DP port.

Administrave Access Best Pracces 10.1 21 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

STEP 1 | Create Security policy rules to allow access to the web and CLI interfaces.
If you use a bason host as the only gateway to your management network, configure a rule
to allow traffic from the bason host to the managed device. Configure rules to allow traffic
from necessary users and services within the management network (restricted to only the
necessary applicaons, etc.).
If you do not use a bason host, create the required rules to allow access only from the
management zone, using only the necessary applicaons and allowing only the necessary
users or services. All management traffic should come from within the management zone.
Inspect traffic entering the network from a VPN or other secure tunnel before it enters the
management zone.

STEP 2 | Create a best pracce Vulnerability Protecon profile by cloning the preconfigured strict
Vulnerability profile and then modifying it so that it only scans the signatures from the
requesng server.
Aer you clone and modify the best pracce Vulnerability Protecon profile, delete the
profile rules that have client as the Host Type because you only need to scan the inbound
traffic.
Aach the Vulnerability Protecon profile to every Security policy rule that controls
inbound access to the management interface.

STEP 3 | Tighten each Security policy rule to allow only the necessary users, services, and
applicaons.
Allow only the IP addresses you specified in the Interface Management Profile.
Specify the management network zone(s) as both the source and desnaon zones (both
the bason host and the device’s management port are in the management network
zone(s)).
Allow only the applicaons and services that you need to manage the device (use App-ID).
Specify user groups and/or individual users (you must implement User-ID).
Include the modified best pracce Vulnerability Protecon profile (Step 2).
Log traffic that matches the rule (this is enabled by default) and forwards logs to external log
storage to be available for analysis (you must Configure Log Forwarding).
If temporary access is required, for example for a contractor, configure a non-recurring
schedule (Objects > Schedules) to specify when that access is allowed and when it stops.
Aach the schedule to the Security policy rule that allows the temporary access.

Administrave Access Best Pracces 10.1 22 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

STEP 4 | Decrypt inbound traffic to the management interface so the firewall can inspect it. If you use
the MGT port as the management interface, you must first route the traffic through the DP
port of a firewall to decrypt and inspect the traffic (see Select the Management Interface).
Apply an SSL Inbound Inspecon Decrypon profile to the traffic.
Follow Decrypon Best Pracces to eliminate weak ciphers and algorithms based on
applicable compliance regulaons.

Do not decrypt management or service route traffic from the firewall to Panorama.
Do not configure SSL Forward Proxy decrypon to decrypt outbound management
traffic from the firewall or Panorama.

Administrave Access Best Pracces 10.1 23 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Maintain Administrave Access Best Pracces

Ensure that your administrave access deployment remains up-to-date and is not over-
provisioned or under-provisioned, and remain alert to aempts to compromise the deployment.
STEP 1 | When administrave personnel change, update access so that people who no longer
administrate firewalls and Panorama cannot access the management interface and network
and so that new administrators have the appropriate access with the appropriate RBAC
configuraon.
Remove people who no longer administrate the firewall or Panorama from user groups that
have management interface access permissions.
Remove the IP addresses of people who no longer administrate the firewall or Panorama
device from Security policy allow rules for management interface access.
If you created best pracce Admin Role Profiles, if an administrator no longer manages the
device, review the profile that administrator used to determine if the profile needs to be
modified or deleted:
• Verify if any other administrators use the profile. Do not delete the profile if other
administrators use it for access or you may disrupt service or inadvertently change
access.
• Do you need to modify the profile? If other administrators use the profile, changes may
inadvertently allow or deny access to those administrators.
• If no other administrators use the profile, should you delete it or do you need it for a new
administrator who will have the same responsibilies as the previous administrator?
If people no longer manage any devices in your management network, remove their
management network access.
Add new administrators to the appropriate user group, add their IP addresses to the
Security policy allow rules for management access, and configure RBAC privileges that allow
access only to the porons of the device that they manage.

STEP 2 | When services or API access for management tools changes, update Security policy rules
that allow access accordingly.
Similar to changes in administrave personnel, in firewall and Panorama Security policy and for
access to the management network, ensure that you:
Remove access privileges for services and tools that you no longer use.
Add access privileges for new services and tools using the most granular policy to permit
only the necessary connecon (principle of least privilege access).

Administrave Access Best Pracces 10.1 24 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

STEP 3 | Monitor System logs for administrators to idenfy abnormal account acvity, especially
for administrators with roles that permit changing key areas such as management access,
administrave users, or Security policy.
Configure Log Forwarding for specific log events and types. Use a method that nofies
administrators of events so that they can take acon in a mely manner. Abnormal acvity may
indicate a compromised administrator account. Look for acvity such as:
An excessive number of login aempts.
Repeated login aempts at unusual mes of day for the administrator.
Login aempts from unusual IP addresses or locaons.
Creaon of new user accounts (ensure that the new account is legimate).
Addion of new users to groups (ensure that the addion is legimate).
Unexpected password changes.
Policy and permission changes (Security policy, users, Security profiles, Admin Role Profiles,
etc.).
Unscheduled commits.

STEP 4 | On the Dashboard, use the administrator login acvity indicators to detect account misuse.
These acvity indicators enable you to quickly view the last login details of administrators and
locate hosts that aempt to log into the firewall or Panorama management server.

Administrave Access Best Pracces 10.1 25 ©2022 Palo Alto Networks, Inc.
Administrave Access Best Pracces

Administrave Access Best Pracces 10.1 26 ©2022 Palo Alto Networks, Inc.