blog
    Palo Alto Networks Firewa ...
    05 February 21

    Palo Alto Networks Firewall – Management Best Practices

    Posted byPiotr Kaluzny
    facebooktwitterlinkedin
    news-featured


    One of the first things to consider when deploying a new firewall (and any other network device) into the network is secure administrative access. If management access is not secured properly, you can’t really use your firewall to detect and defend against vulnerability exploits that could lead to infiltration and/or the loss of sensitive data.


    Many organizations decide to manage their IT infrastructure through a dedicated network channel that is physically (or logically) separated from the Data Plane. This is known as Out-Of-Band (OOB) management. Palo Alto Next-Generation Firewalls natively support OOB through a dedicated Management interface. Access to the Management interface (or possibly any other data interface designated for administration) should be always restricted and never enabled for connections originating in untrusted zones, such as the Internet.

    Some of the key best practices for secure firewall administration we will look at in this article include the following:

    • Management network isolation
    • Management port restrictions
    • Access control enforcement
    • Management traffic inspection

    Management Network Isolation


    Ideally, the OOB management network should be implemented using a dedicated set of switches that are independent and physically separated from the data network. As an alternative, you can rely on logical separation and provide isolation by implementing segregated VLANs.

    The management network should connect your firewalls and other network devices through dedicated management interfaces. In addition, the management subnet deployed for the segment should operate under an address space that significantly differs from the rest of the production data network. This facilitates the enforcement of controls, such as making sure the management network is not advertised by any routing protocols. Some network platforms will natively block data packets received on the management ports, but some will not and that’s why routing control configuration (passive interfaces, route filtering) should be in place.

    The topology below shows a high-level example of an isolated network segment designated for administration:


    Management Port Restrictions

    The two key elements that should be enforced at the management port level are:

    1. Allowed management protocols/services
    2. Trusted IP addresses designated for administration


    Even if your firewall is on a dedicated management network you can secure the firewall further by restricting the source IP addresses that can access the management interface to those of your administrators (network/security operations, IT administrators, etc.). Some organizations go even beyond that and designate a special machine (or machines), aka “Jump Host” or “Bastion Host”, as the only valid station(s) being allowed to manage the network infrastructure. This way as you configure IP restrictions the only address you need to take into account is one of the Jump Host (securing access to the Jump Host itself is a different story - strong authentication, access control or screen recording are a few examples of what may be needed here).

    The configuration below (all configurations shown in this article are performed using regular Firewall GUI – Panorama configurations would be very similar) shows how to restrict management access on the management port to a single subnet (10.7.7.0/24) used by administrators (Device -> Setup -> Interfaces -> Management):

     

     

    According to the “Least Privilege” principle, you should also restrict the protocols allowed for management, ideally leaving only the secure versions of Telnet & HTTP - so SSH (CLI) and HTTPS (GUI):

     

     

    Network Services are optional and allowing/blocking them depends on your security policy & needs.

    Access Control Enforcement


    Another important thing to consider is Authentication, Authorization & Accounting (AAA) design. In case of small companies, with just a few firewalls, it may be sufficient to define administrative accounts (including their corresponding authorization rights) locally on the firewall units themselves. Larger organizations, or basically companies that are looking to expand, should aim for a centralized solution (referred to as “External Authentication” by Palo Alto) that is scalable and easier to manage. Examples of commonly used external AAA databases include RADIUS, TACACS+ and LDAP.

    Local Authentication is also typically deployed as a fallback method (in case AAA server is down). Just remember that by default the firewall is preconfigured with an administrative account (“admin”) that provides full read-write access (“superuser access”) to the system. Depending on your Security Policy and/or compliance requirements, this account may need to be removed and replaced with a custom account (Device -> Administrators).

     

     

    Remember that a process of defining administrative accounts should be ideally preceded with a creation of strict password policy (Device -> Setup -> Management -> Minimum Password Complexity). A recent industry-approved strategy suggests creating a long passphrase rather than a complex password. A long (minimum of 15 characters) unique passphrases that you will remember easily (using whatever characters you want, including dictionary words) are believed to compensate for the use of dictionary words. For most people it will work better than creating convoluted and complex passwords that are easy to forget (and many times stuck to a person’s monitor).

     

     

    More details about this topic, including examples, can be found in our “Palo Alto Firewall Advanced Technologies” series available to INE subscribers.

     

    Management Traffic Inspection

    As an additional precaution you may also implement a special Security Policy rule to inspect the management traffic. An important thing to note is that since Security and Decryption Policies do not evaluate management plane traffic, you cannot directly scan the management port for threats (but you can do this with data ports enabled for management). If you are using the management port as your management interface, consider routing traffic destined for the port through a data port or through another firewall so that you can perform the inspection.

    Security Policy configuration snapshot below shows a simple rule used to allow management traffic only from the ADMIN zone (10.7.7.0/24) to the FW-MGMT zone (firewall’s management IP address) for GUI and CLI access (panos-web-interface & ssh applications):

     

     

    To increase security of the solution even further, Palo Alto Networks recommends to deploy decryption. This, along with Vulnerability Protection (enabled above), would be useful to further protect the inspected session against buffer overflows, illegal code execution, legacy ciphers and other vulnerabilities.




    Want to dive further into Palo Alto Firewall technologies? Check out our entire suite of
    Palo Alto training, including both novice and advanced training - all part of your INE subscription. 


    {{cta('7dd1b55e-fd09-4b7b-8d9b-def18660c805')}}



    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo