Palo Alto Notes
Palo Alto Notes
Interface Deployments
A Palo Alto Networks firewall can operate in multiple deployments at once because the deployments occur at the interface level. The following sections describe the deployments.
Virtual Wire Deployments
In a virtual wire deployment, the firewall is installed transparently on a network segment by binding two ports together and should be used only when no switching or routing is needed.
A virtual wire deployment allows the following conveniences:
Simplifies installation and configuration. Does not require any configuration changes to surrounding or adjacent network devices.
The virtual wire deployment shipped as the factory default configuration (default-vwire) binds together Ethernet ports 1 and 2 and allows all untagged traffic. You can, however, use a virtual wire to connect any two ports and configure it to block or allow traffic based on the virtual LAN (VLAN) tags; the VLAN tag “0” indicates untagged traffic. You can also create multiple subinterfaces, add them into different zones and then classify traffic according to a VLAN tag, or a combination of a VLAN tag with IP classifiers (address, range, or subnet) to apply granular policy control for specific VLAN tags or for VLAN tags from a specific source IP address, range, or subnet.
Figure: Virtual Wire Deployment
Virtual Wire Subinterfaces
Virtual wire subinterfaces provide flexibility in enforcing distinct policies when you need to manage traffic from multiple customer networks. It allows you to separate and classify traffic into different zones (the zones can belong to separate virtual systems, if required) using the following criteria:
VLAN tags —The example in Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only), shows an Internet Service Provider (ISP) using virtual wire subinterfaces with VLAN tags to separate traffic for two different customers. VLAN tags in conjunction with IP classifiers (address, range, or subnet) — The following example shows an ISP with two separate virtual systems on a firewall that manages traffic from two different customers. On each virtual system, the example illustrates how virtual wire subinterfaces with VLAN tags and IP classifiers are used to classify traffic into separate zones and apply relevant policy for customers from each network.
| Configure two Ethernet interfaces as type virtual wire, and assign these interfaces to a virtual wire. | |
| Create subinterfaces on the parent Virtual Wire to separate CustomerA and CustomerB traffic. Make sure that the VLAN tags defined on each pair of subinterfaces that are configured as virtual wire(s) are identical. This is essential because a virtual wire does not switch VLAN tags. | |
| Create new subinterfaces and define IP classifiers. This task is optional and only required if you wish to add additional subinterfaces with IP classifiers for further managing traffic from a customer based on the combination of VLAN tags and a specific source IP address, range or subnet. You can also use IP classifiers for managing untagged traffic. To do so, you must create a sub-interface with the vlan tag “0”, and define sub-interface(s) with IP classifiers for managing untagged traffic using IP classifiers |
 | IP classification may only be used on the subinterfaces associated with one side of the virtual wire. The subinterfaces defined on the corresponding side of the virtual wire must use the same VLAN tag, but must not include an IP classifier. |
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only)
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags only) depicts CustomerA and CustomerB connected to the firewall through one physical interface, ethernet1/1, configured as a Virtual Wire; it is the ingress interface. A second physical interface, ethernet1/2, is also part of the Virtual Wire; it is the egress interface that provides access to the Internet. For CustomerA, you also have subinterfaces ethernet1/1.1 (ingress) and ethernet1/2.1 (egress). For CustomerB, you have the subinterface ethernet1/1.2 (ingress) and ethernet1/2.2 (egress). When configuring the subinterfaces, you must assign the appropriate VLAN tag and zone in order to apply policies for each customer. In this example, the policies for CustomerA are created between Zone1 and Zone2, and policies for CustomerB are created between Zone3 and Zone4.
When traffic enters the firewall from CustomerA or CustomerB, the VLAN tag on the incoming packet is first matched against the VLAN tag defined on the ingress subinterfaces. In this example, a single subinterface matches the VLAN tag on the incoming packet, hence that subinterface is selected. The policies defined for the zone are evaluated and applied before the packet exits from the corresponding subinterface.
 | The same VLAN tag must not be defined on the parent virtual wire interface and the subinterface. Verify that the VLAN tags defined on the Tag Allowed list of the parent virtual wire interface ( Network > Virtual Wires) are not included on a subinterface. |
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags and IP Classifiers) depicts CustomerA and CustomerB connected to one physical firewall that has two virtual systems (vsys), in addition to the default virtual system (vsys1). Each virtual system is an independent virtual firewall that is managed separately for each customer. Each vsys has attached interfaces/subinterfaces and security zones that are managed independently.
Figure: Virtual Wire Deployment with Subinterfaces (VLAN Tags and IP Classifiers)
Vsys1 is set up to use the physical interfaces ethernet1/1 and ethernet1/2 as a virtual wire; ethernet1/1 is the ingress interface and ethernet1/2 is the egress interface that provides access to the Internet. This virtual wire is configured to accept all tagged and untagged traffic with the exception of VLAN tags 100 and 200 that are assigned to the subinterfaces.
CustomerA is managed on vsys2 and CustomerB is managed on vsys3. On vsys2 and vsys3, the following vwire subinterfaces are created with the appropriate VLAN tags and zones to enforce policy measures.
| Customer | Vsys | Vwire Subinterfaces | Zone | VLAN Tag | IP Classifier |
|---|---|---|---|---|---|
| A | 2 | e1/1.1 (ingress) e1/2.1 (egress) | Zone3 Zone4 | 100 100 | None |
| 2 | e1/1.2 (ingress) e1/2.2 (egress) | Zone5 Zone6 | 100 100 | IP subnet 192.1.0.0/16 | |
| 2 | e1/1.3 (ingress) e1/2.3 (egress) | Zone7 Zone8 | 100 100 | IP subnet 192.2.0.0/16 | |
| B | 3 | e1/1.4 (ingress) e1/2.4 (egress) | Zone9 Zone10 | 200 200 | None |
When traffic enters the firewall from CustomerA or CustomerB, the VLAN tag on the incoming packet is first matched against the VLAN tag defined on the ingress subinterfaces. In this case, for CustomerA, there are multiple subinterfaces that use the same VLAN tag. Hence, the firewall first narrows the classification to a subinterface based on the source IP address in the packet. The policies defined for the zone are evaluated and applied before the packet exits from the corresponding subinterface.
For return-path traffic, the firewall compares the destination IP address as defined in the IP classifier on the customer-facing subinterface and selects the appropriate virtual wire to route traffic through the accurate subinterface.
 | The same VLAN tag must not be defined on the parent virtual wire interface and the subinterface. Verify that the VLAN tags defined on the Tag Allowed list of the parent virtual wire interface ( Network > Virtual Wires) are not included on a subinterface. |
Layer 2 Deployments
In a Layer 2 deployment, the firewall provides switching between two or more networks. Each group of interfaces must be assigned to a VLAN object in order for the firewall to switch between them. The firewall will perform VLAN tag switching when layer 2 subinterfaces are attached to a common VLAN object. Choose this option when switching is required.
Figure: Layer 2 Deployment
Layer 3 Deployments
In a Layer 3 deployment, the firewall routes traffic between multiple ports. An IP address must be assigned to each interface and a virtual router must be defined to route the traffic. Choose this option when routing is required.
Figure: Layer 3 Deployment
In addition, because the firewall must route traffic in a Layer 3 deployment, you must configure a virtual router. See Virtual Routers.
Point-to-Point Protocol over Ethernet Support
You can configure the firewall to be a Point-to-Point Protocol over Ethernet (PPPoE) termination point to support connectivity in a Digital Subscriber Line (DSL) environment where there is a DSL modem but no other PPPoE device to terminate the connection.
You can choose the PPPoE option and configure the associated settings when an interface is defined as a Layer 3 interface.
 | PPPoE is not supported in HA active/active mode. |
DHCP Client
You can configure the firewall interface to act as a DHCP client and receive a dynamically assigned IP address. The firewall also provides the capability to propagate settings received by the DHCP client interface into a DHCP server operating on the firewall. This is most commonly used to propagate DNS server settings from an Internet service provider to client machines operating on the network protected by the firewall.
 | DHCP client is not supported in HA active/active mode. |
For more information, see DHCP.
Tap Mode Deployments
A network tap is a device that provides a way to access data flowing across a computer network. Tap mode deployment allows you to passively monitor traffic flows across a network by way of a switch SPAN or mirror port.
The SPAN or mirror port permits the copying of traffic from other ports on the switch. By dedicating an interface on the firewall as a tap mode interface and connecting it with a switch SPAN port, the switch SPAN port provides the firewall with the mirrored traffic. This provides application visibility within the network without being in the flow of network traffic.
 | When deployed in tap mode, the firewall is not able to take action, such as block traffic or apply QoS traffic control. |
File Blocking Profiles
File Blocking Profiles
The firewall uses file blocking profiles two ways: to forward files to WildFire for analysis or to block specified file types over specified applications and in the specified session flow direction (inbound/outbound/both). You can set the profile to alert or block on upload and/or download and you can specify which applications will be subject to the file blocking profile. You can also configure custom block pages that will appear when a user attempts to download the specified file type. This allows the user to take a moment to consider whether or not they want to download a file.
You can configure a file blocking profile with the following actions:
Alert —When the specified file type is detected, a log is generated in the data filtering log.Block —When the specified file type is detected, the file is blocked and a customizable block page is presented to the user. A log is also generated in the data filtering log.Continue —When the specified file type is detected, a customizable response page is presented to the user. The user can click through the page to download the file. A log is also generated in the data filtering log. Because this type of forwarding action requires user interaction, it is only applicable for web traffic.Forward —When the specified file type is detected, the file is sent to WildFire for analysis. A log is also generated in the data filtering log.Continue-and-forward —When the specified file type is detected, a customizable continuation page is presented to the user. The user can click through the page to download the file. If the user clicks through the continue page to download the file, the file is sent to WildFire for analysis. A log is also generated in the data filtering log.
Keys and Certificates
To ensure trust between parties in a secure communication session, Palo Alto Networks devices use digital certificates. Each certificate contains a cryptographic key to encrypt plaintext or decrypt cyphertext. Each certificate also includes a digital signature to authenticate the identity of the issuer. The issuer must be in the list of trusted certificate authorities (CAs) of the authenticating party. Optionally, the authenticating party verifies the issuer did not revoke the certificate (see Certificate Revocation).
Palo Alto Networks devices use certificates in the following applications:
User authentication for Captive Portal, GlobalProtect™, Mobile Security Manager, and web interface access to a Palo Alto Networks device.Device authentication for GlobalProtect VPN (remote user-to-site or large scale).Device authentication for IPSec site-to-site VPN with Internet Key Exchange (IKE).Decrypting inbound and outbound SSL traffic.
A firewall decrypts the traffic to apply policy rules, then re-encrypts it before forwarding the traffic to the final destination. For outbound traffic, the firewall acts as a forward proxy server, establishing an SSL/TLS connection to the destination server. To secure a connection between itself and the client, the firewall uses a signing certificate to automatically generate a copy of the destination server certificate.
The following table describes the keys and certificates that Palo Alto Networks devices use. As a best practice, use different keys and certificates for each usage.
Table: Palo Alto Networks Device Keys/Certificates
Application Level Gateways
The Palo Alto Networks firewall does not classify traffic by port and protocol; instead it identifies the application based on its unique properties and transaction characteristics using the App-ID technology. Some applications, however, require the firewall to dynamically open pinholes to establish the connection, determine the parameters for the session and negotiate the ports that will be used for the transfer of data; these applications use the application-layer payload to communicate the dynamic TCP or UDP ports on which the application opens data connections. For such applications, the firewall serves as an Application Level Gateway (ALG), and it opens a pinhole for a limited time and for exclusively transferring data or control traffic. The firewall also performs a NAT rewrite of the payload when necessary.
As of Content Release version 504, the Palo Alto Networks firewall provides NAT ALG support for the following protocols: FTP, H.225, H.248, MGCP, MySQL, Oracle/SQLNet/TNS, RPC, RTSP, SCCP, SIP, and UNIStim.
 | When the firewall serves as an ALG for the Session Initiation Protocol (SIP), by default it performs NAT on the payload and opens dynamic pinholes for media ports. In some cases, depending on the SIP applications in use in your environment, the SIP endpoints have NAT intelligence embedded in their clients. In such cases, you might need to disable the SIP ALG functionality to prevent the firewall from modifying the signaling sessions. When SIP ALG is disabled, if App-ID determines that a session is SIP, the payload is not translated and dynamic pinholes are not opened. See Disable the SIP Application-level Gateway (ALG). |
The firewall provides IPv6-to-IPv6 Network Prefix Translation (NPTv6) ALG support for the following protocols: FTP, Oracle, and RTSP. The SIP ALG is not supported for NPTv6 or NAT64.
Enable Log Forwarding from Panorama to External Destinations
Panorama allows you to forward aggregated logs, email notifications, and SNMP traps to external servers. Forwarding logs from Panorama reduces the load on the firewalls and provides a reliable and streamlined approach to combine and forward syslogs/SNMP traps/email notifications to remote destinations.
Use the following table to configure log forwarding from Panorama:
Table: Log Forwarding from Panorama to External Destinations
| Platform/Deployment | Forward Panorama Logs | Forward Firewall Logs |
|---|---|---|
| Panorama virtual appliance | To forward Panorama logs: Panorama > Log Settings > System Panorama > Log Settings > Config | To forward firewall logs, select Panorama > Log Settings and select the tab for each log type: System, Config, HIP Match, Traffic, Threat, and WildFire. |
| Distributed Log Collection Deployment with: Panorama M-100 appliance with default Collector and/or Managed Collectors or Panorama virtual appliance with Managed Collectors | To forward both Panorama local logs and Managed Collector logs, select: Panorama > Log Settings > System Panorama > Log Settings > Config | To forward firewall logs that Panorama aggregates on a Collector Group, select Panorama > Collector Groups, select a Collector Group, select the Collector Log Forwarding tab, and select the tab for each log type: System, Config, Traffic, Threat, HIP Match, and WildFire. |
 | To forward firewall logs from Panorama, you must have completed the task Enable Log Forwarding to Panorama. On a Panorama virtual appliance running Panorama 5.1 or earlier releases, you can use Secure Copy (SCP) commands from the CLI to export the entire log database to an SCP server and import it to another Panorama virtual appliance: refer to the PAN-OS Command Line Interface (CLI) Reference Guide. A Panorama virtual appliance running Panorama 6.0 or later releases, and M-100 appliances running any release, do not support these options because the log database on those platforms is too large for an export or import to be practical. |
| Set up server profiles for each external destination to which you want to forward logs. | Set up one or more of the following server profiles: SNMP: Select Panorama > Server Profiles > SNMP Trap. Email: Select Panorama > Server Profiles > Email. Syslog: Select Panorama > Server Profiles > Syslog. To forward logs to a syslog server, you can configure the transport medium to use UDP, TCP or SSL. By default, the header format for each syslog entry uses the FQDN (hostname and domain name), if configured, of the appliance that forwards the logs (Panorama or a Managed Collector). The log data includes the unique identifier of the firewall that generated the log entry. Choosing the header format provides more flexibility in filtering and reporting on the log data for some Security Information and Event Management (SIEM) servers. To change what is listed in the syslog header, select Panorama > Setup > Management, edit the Logging and Reporting section, select the Log Export and Reporting tab and, in the Syslog HOSTNAME Format drop-down, select FQDN, hostname, ipv4-address, or ipv6-address.  This is a global setting and applies to all syslog server profiles configured on the appliance. |
If the Syslog server requires client authentication, generate the certificate for secure communication.  | To verify that the sending device (firewall or Panorama) is authorized to communicate with the syslog server, you must enable the following: The server and the sending device must have certificates that are signed by the same trusted CA. Alternatively, you can generate a self-signed certificate on Panorama or the firewall, export the certificate from the firewall/Panorama and import it in to the syslog server. Use the trusted CA or the self-signed certificate to generate a certificate with the IP address of the sending device (as the Common Name) and enabled for use in secure syslog communication. The syslog server uses this certificate to verify that the firewall or Panorama is authorized to communicate with the syslog server. Use the following steps to generate the certificate on the firewall or Panorama: Select Panorama > Certificate Management > Certificates. Click Generate to create a new certificate that will be signed by a trusted CA or the self-signed CA. Enter a name for the certificate. In Common Name, enter the IP address of the device sending logs to the syslog server. Select Shared if you want the certificate to be a shared certificate on Panorama or to be shared by all virtual systems in a multiple virtual system firewall. In Signed by, select the trusted CA or the self-signed CA that is trusted by both the syslog server and the sending device. Click Generate. The certificate and the keypair will be generated. Click the link with the name of the certificate and enable the Certificate for Secure Syslog check box for secure access to the syslog server. In the Certificates page, verify the certificate details. In the Usage column, verify that it is marked as Certificate for Secure Syslog. |
| (Only for Managed Collectors) On Panorama, select the certificate to use for secure syslog communication. You must have imported the trusted CA certificate in to Panorama or generated it on Panorama. The certificate must be enabled for use as a Certificate for Secure Syslog. | Select Panorama > Managed Collectors. Click Add to add a new Managed Collector or select the link to edit the configuration for a Managed Collector. Select General, and choose the certificate from the Certificate for Secure Syslog drop-down.  You can only select from the certificate that are available on Panorama > Certificate Management > Certificates. |
| Configure Panorama to forward logs. | To forward logs for your platform/deployment, see Table: Log Forwarding from Panorama to External Destinations. |
Keys and Certificates for Decryption Policies
Keys are strings of numbers that are typically generated using a mathematical operation involving random numbers and large primes. Keys are used to transform other strings—such as passwords and shared secrets—from plaintext to ciphertext (called encryption) and from ciphertext to plaintext (called decryption). Keys can be symmetric (the same key is used to encrypt and decrypt) or asymmetric (one key is used for encryption and a mathematically related key is used for decryption). Any system can generate a key.
X.509 certificates are used to establish trust between a client and a server in order to establish an SSL connection. A client attempting to authenticate a server (or a server authenticating a client) knows the structure of the X.509 certificate and therefore knows how to extract identifying information about the server from fields within the certificate, such as its FQDN or IP address (called a common name or CN within the certificate) or the name of the organization, department, or user to which the certificate was issued. All certificates must be issued by a certificate authority (CA). After the CA verifies a client or server, the CA issues the certificate and signs it using its private key.
With a decryption policy configured, an SSL/TLS session between the client and the server is established only if the firewall trusts the CA that signed the server’s certificate. In order to establish trust, the firewall must have the server’s root CA certificate in its certificate trust list (CTL) and use the public key contained in that root CA certificate to verify the signature. The firewall then presents a copy of the server certificate signed by the Forward Trust certificate for the client to authenticate. You can also configure the firewall to use an enterprise CA as a forward trust certificate for SSL Forward Proxy. If the firewall does not have the server’s root CA certificate in its CTL, the firewall will present a copy of the server certificate signed by the Forward Untrust certificate to the client. The Forward Untrust certificate ensures that clients are prompted with a certificate warning when attempting to access sites hosted by a server with untrusted certificates.
For detailed information on certificates, see Certificate Management.
 | To control the trusted CAs that your device trusts, use the Device > Certificate Management > Certificates > Default Trusted Certificate Authorities tab on the firewall web interface. |
Table: Palo Alto Networks Device Keys and Certificates describes the different keys and certificates used by Palo Alto Networks devices for decryption. As a best practice, use different keys and certificates for each usage.
Table: Palo Alto Networks Device Keys and Certificates
| Key/Certificate Usage | Description |
|---|---|
| Forward Trust | The certificate the firewall presents to clients during decryption if the site the client is attempting to connect to has a certificate that is signed by a CA that the firewall trusts. To configure a Forward Trust certificate on the firewall, see Step 2 in the Configure SSL Forward Proxy task. By default, the firewall determines the key size to use for the client certificate based on the key size of the destination server. However, you can also set a specific key size for the firewall to use. See Configure the Key Size for SSL Forward Proxy Server Certificates. For added security, store the forward trust certificate on a Hardware Security Module (HSM), see Store Private Keys on an HSM. |
| Forward Untrust | The certificate the firewall presents to clients during decryption if the site the client is attempting to connect to has a certificate that is signed by a CA that the firewall does not trust. To configure a Forward Untrust certificate on the firewall, see Step 3 in the Configure SSL Forward Proxy task. |
| SSL Exclude Certificate | Certificates for servers that you want to exclude from SSL decryption. For example, if you have SSL decryption enabled, but have certain servers that you do not want included in SSL decryption, such as the web services for your HR systems, you would import the corresponding certificates onto the firewall and configure them as SSL Exclude Certificates. See Exclude a Server From Decryption. |
| SSL Inbound Inspection | The certificate used to decrypt inbound SSL traffic for inspection and policy enforcement. For this application, you would import the server certificate for the servers for which you are performing SSL inbound inspection, or store them on an HSM (see Store Private Keys on an HS |
Role-Based Access Control
Role-based access control (RBAC) enables you to define the privileges and responsibilities of administrative users (administrators). Every administrator must have a user account that specifies a role and authentication method. Administrative Roles define access to specific configuration settings, logs, and reports within Panorama and firewall contexts. For Device Group and Template administrators, you can map roles to Access Domains, which define access to specific device groups, templates, and firewalls (through context switching). By combining each access domain with a role, you can enforce the separation of information among the functional or regional areas of your organization. For example, you can limit an administrator to monitoring activities for data center firewalls but allow that administrator to set policies for test lab firewalls. By default, every Panorama appliance (virtual appliance or M-Series appliance) has a predefined administrative account (admin) that provides full read-write access (superuser access) to all functional areas and to all device groups, templates, and firewalls. For each administrator, you can define the minimum password complexity, a password profile, and an authentication profile that determines how Panorama verifies user access credentials.
 | Instead of using the default account for all administrators, it is a best practice to create a separate administrative account for each person who needs access to the administrative or reporting functions on Panorama. This provides better protection against unauthorized configuration changes and enables Panorama to log and identify the actions of each administrator. |
Administrative Roles
You configure administrator accounts based on the security requirements of your organization, any existing authentication services with which to integrate, and the required administrative roles. A role defines the type of system access that is available to an administrator. You can define and restrict access as broadly or granularly as required, depending on the security requirements of your organization. For example, you might decide that a data center administrator can have access to all device and networking configurations, but a security administrator can control only security policy definitions, while other key individuals can have limited CLI or XML API access. The role types are:
Dynamic Roles —These are built-in roles that provide access to Panorama and managed devices. When new features are added, Panorama automatically updates the definitions of dynamic roles; you never need to manually update them. The following table lists the access privileges associated with dynamic roles.
| Dynamic Role | Privileges |
|---|---|
| Superuser | Full read-write access to Panorama |
| Superuser (read-only) | Read-only access to Panorama |
| Panorama administrator | Full access to Panorama except for the following actions: Create, modify, or delete Panorama or device administrators and roles. Export, validate, revert, save, load, or import a configuration in the Device > Setup > Operations page. Configure Scheduled Config Export functionality in the Panorama tab. |
Admin Role Profiles —To provide more granular access control over the functional areas of the web interface, CLI, and XML API, you can create custom roles. When new features are added to the product, you must update the roles with corresponding access privileges: Panorama does not automatically add new features to custom role definitions. You select one of the following profile types when you Configure an Admin Role Profile.
| Admin Role Profile | Description |
|---|---|
| Panorama | For these roles, you can assign read-write access, read-only access, or no access to all the Panorama features that are available to the superuser dynamic role except the management of Panorama administrators and Panorama roles. For the latter two features, you can assign read-only access or no access, but you cannot assign read-write access. An example use of a Panorama role would be for security administrators who require access to security policy definitions, logs, and reports on Panorama. |
| Device Group and Template | For these roles, you can assign read-write access, read-only access, or no access to specific functional areas within device groups, templates, and firewall contexts. By combining these roles with Access Domains, you can enforce the separation of information among the functional or regional areas of your organization. Device Group and Template roles have the following limitations: No access to the CLI or XML API No access to configuration or system logs No access to VM information sources In the Panorama tab, access is limited to: Device deployment features (read-write, read-only, or no access) The device groups specified in the administrator account (read-write, read-only, or no access) The templates and managed devices specified in the administrator account (read-only or no access) An example use of this role would be for administrators in your operations staff who require access to the device and network configuration areas of the web interface for specific device groups and/or templates. |
Authentication Profiles and Sequences
An authentication profile specifies the authentication service that validates the credentials of an administrator during login and defines how Panorama accesses the service. If you create a local administrator account on Panorama, you can authenticate the administrator to the local database, use an external service (RADIUS, TACACS+, LDAP, or Kerberos server), or use Kerberos single sign-on (SSO). If you use an external service, you must configure a server profile before you Configure an Admin Role Profile. If you want to use an external service for both account administration (instead of creating local accounts) and for authentication, you must Configure RADIUS Vendor-Specific Attributes for Administrator Authentication.
Some environments have multiple databases for different users and user groups. To authenticate to multiple authentication sources (for example, local database and LDAP), configure an authentication sequence. An authentication sequence is a ranked order of authentication profiles that an administrator is matched against when logging in. Panorama checks against the local database first, and then checks each profile in sequence until the administrator is successfully authenticated. The administrator is denied access to Panorama only if authentication fails for all the profiles defined in the authentication sequence.
Access Domains
Access domains control administrative access to specific device groups (to manage policies and objects) and templates (to manage network and device settings), and also control the ability to switch context to the web interface of managed firewalls. Access domains apply only to administrators with Device Group and Template roles. By combining access domains with Administrative Roles, you can enforce the separation of information among the functional or regional areas of your organization.
You can manage access domains locally or by using RADIUS Vendor-Specific Attributes (VSAs). To use RADIUS VSAs, your network requires an existing RADIUS server and you must configure a RADIUS server profile to define how Panorama accesses the server. On the RADIUS server, you define a VSA attribute number and value for each administrator. The value defined must match the access domain configured on Panorama. When an administrator tries to log in to Panorama, Panorama queries the RADIUS server for the administrator access domain and attribute number. Based on the response from the RADIUS server, the administrator is authorized for access and is restricted to the firewalls, virtual systems, device groups, and templates that are assigned to the access domain.
For the relevant procedures, see:
Administrative Authentication
The following methods are available to authenticate Panorama administrators:
Local administrator account with local authentication —Both the administrator account credentials and the authentication mechanisms are local to Panorama. To further secure the local administrator account, create a password profile that defines a validity period for passwords and set Panorama-wide password complexity settings. For details on how to configure this type of administrative access, see Configure an Administrator with Kerberos SSO, External, or Local Authentication. Local administrator account with certificate- or key-based authentication —With this option, the administrator accounts are local to Panorama, but authentication is based on Secure Shell (SSH) keys (for CLI access) or client certificates/common access cards (for the web interface). For details on how to configure this type of administrative access, see Configure an Administrator with Certificate-Based Authentication for the Web Interface and Configure an Administrator with SSH Key-Based Authentication for the CLI. Local administrator account with external authentication —The administrator accounts are managed on Panorama, but existing external authentication services (LDAP, Kerberos, TACACS+, or RADIUS) handle the authentication functions. If your network supports Kerberos single sign-on (SSO), you can configure external authentication as an alternative in case SSO fails. For details on how to configure this type of administrative access, see Configure an Administrator with Kerberos SSO, External, or Local Authentication. External administrator account and authentication —An external RADIUS server handles account administration and authentication. To use this option, you must define Vendor-Specific Attributes (VSAs) on your RADIUS server that map to the administrator roles and access domains. For a high-level overview of the process, see Configure RADIUS Vendor-Specific Attributes for Administrator Authentication. For details on how to configure this type of administrative access, refer to Radius Vendor-Specific Attributes (VSAs).
Configure the Key Size for SSL Forward Proxy Server Certificates
When responding to a client in an SSL Forward Proxy session, the firewall creates a copy of the certificate that the destination server presents and uses the copy to establish a connection with the client. By default, the firewall generates certificates with the same key size as the certificate that the destination server presented. However, you can change the key size for the firewall-generated certificate as follows:
| Select Device > Setup > Session and, in the Decryption Settings section, click SSL Forward Proxy Settings. |
Select a Key Size: Defined by destination host —The firewall determines the key size for the certificates it generates to establish SSL proxy sessions with clients based on the key size of the destination server certificate. If the destination server uses a 1,024-bit RSA key, the firewall generates a certificate with that key size and an SHA-1 hashing algorithm. If the destination server uses a key size larger than 1,024 bits (for example, 2,048 bits or 4,096 bits), the firewall generates a certificate that uses a 2,048-bit RSA key and SHA-256 algorithm. This is the default setting. 1024-bit RSA —The firewall generates certificates that use a 1,024-bit RSA key and SHA-1 hashing algorithm regardless of the key size of the destination server certificates. As of December 31, 2013, public certificate authorities (CAs) and popular browsers have limited support for X.509 certificates that use keys of fewer than 2,048 bits. In the future, depending on security settings, when presented with such keys the browser might warn the user or block the SSL/TLS session entirely. 2048-bit RSA —The firewall generates certificates that use a 2,048-bit RSA key and SHA-256 hashing algorithm regardless of the key size of the destination server certificates. Public CAs and popular browsers support 2,048-bit keys, which provide better security than the 1,024-bit keys.  Changing the key size setting clears the current certificate cache. |
| Click OK and Commit. |
Export a Certificate and Private Key
| Select Device > Setup > Session and, in the Decryption Settings section, click SSL Forward Proxy Settings. |
Palo Alto Networks recommends that you use your enterprise public key infrastructure (PKI) to distribute a certificate and private key in your organization. However, if necessary, you can also export a certificate and private key from the firewall or Panorama. You can use an exported certificate and private key in the following cases:
Administrator authentication to the device web interface GlobalProtect agent/app authentication to portals and gateways SSL Forward Proxy decryption Certificate signing requests (CSRs)
Administrator authentication
You can configure the following types of administrator authentication:
| Account Type | Authentication Method | Description |
|---|---|---|
| Local | Local database | Both the administrator account credentials and the authentication mechanisms are local to the firewall. You can further secure a local administrator account by creating a password profile that defines a validity period for passwords and by setting firewall-wide password complexity settings. If your network supports Kerberos single sign-on (SSO), you can configure local authentication as a fallback in case SSO fails. For details, see Configure Kerberos SSO and External or Local Authentication for Administrators. |
| Local | SSL-based | The administrator accounts are local to the firewall, but authentication is based on SSH certificates (for CLI access) or client certificates (for web interface access). For details, see Configure SSH Key-Based Administrator Authentication to the CLI and Configure Certificate-Based Administrator Authentication to the Web Interface. |
| Local | External service | The administrator accounts are local to the firewall, but external services (LDAP, Kerberos, TACACS+, or RADIUS) handle the authentication functions. If your network supports Kerberos single sign-on (SSO), you can configure external authentication as a fallback in case SSO fails. For details, see Configure Kerberos SSO and External or Local Authentication for Administrators. |
| External | External service | An external RADIUS server handles account management and authentication. You must define Vendor-Specific Attributes (VSAs) on your RADIUS server that map to the administrator role, access domain, user group (if applicable), and virtual system (if applicable). For details, see Configure RADIUS Vendor-Specific Attributes for Administrator Authentication. |
https://live.paloaltonetworks.com/t5/Management-Articles/IPSec-and-tunneling-resource-list/ta-p/67721
The Benefits of Palo Alto Networks Firewall Single Pass Parallel Processing (SP3) and Hardware Architecture
What makes Palo Alto Networks Next-Generation Firewall (NGFW) so different from its competitors is its Platform, Process and Architecture. Palo Alto Networks delivers all the next generation firewall features using the single platform, parallel processing and single management systems, unlike other vendors who use different modules or multiple management systems to offer NGFW features.
More technical and how-to articles covering Palo Alto's Firewalls can be found in our Palo Alto Networks Firewall Section
Palo Alto Networks Next-Generation Firewall’s main strength is its Single Pass Parallel Processing (SP3) Architecture, which comprises two key components:
- Single Pass Software
- Parallel Processing Hardware
Figure 1. Palo Alto Networks Firewall Single Pass Parallel Processing Architecture
Single Pass Software
Palo Alto Networks Next-Generation Firewall is empowered with Single Pass Software, which processes the packet to perform functions like networking, user identification (User-ID), policy lookup, traffic classification with application identification (App-ID), decoding, signature matching for identifying threats and contents, which are all performed once per packet as shown in the illustration below:
Figure 2: Palo Alto Networks Firewall - Single-Pass Architecture Traffic Flow
This processing of a packet in one go or single pass by Palo Alto Networks Next-Generation Firewall enormously reduces the processing overhead, other vendor firewalls using a different type of architecture produce a significantly higher overhead when processing packets traversing the firewall. It’s been observed that the Unified Threat Management (UTM), which processes the traffic using multi-pass architecture, results in process overhead, latency introduction and throughput degradation.
The diagram below illustrates the multi-pass architecture process used by other vendors’ firewalls, clearly showing differences to the Palo Alto Networks Firewall architecture and how the processing overhead is produced:
Figure 3: Traffic Flow for multi-pass architecture resulting in additional overhead processing
Palo Alto Networks Next-Generation Firewall Single Pass Software scans the contents based on the same stream and it uses uniform signature matching patterns to detect and block threats. By adopting this methodology Palo Alto Networks Next-Generation Firewall is negating the use of separate scan engines and signature sets, which results in low latency and high throughput.
Parallel Processing Hardware
Palo Alto Networks Parallel Processing hardware ensures function-specific processing is done in parallel at the hardware level which, in combination with the dedicated Data plane and Control plane, produces stunning performance results. By separating the Data plane and Control plane, Palo Alto Networks is ensuring heavy utilization of either plane will not impact the overall performance of the Platform. At the same time, this means there is no dependency on either plane as each has its own CPU and RAM as illustrated in the diagram below:
Figure 4: Palo Alto Networks Firewall Hardware Architecture – Separation of Data Plane and Control Plane
The Control Plane is responsible for tasks such as management, configuration of Palo Alto Networks Next-Generation Firewall and it takes care of logging and reporting functions.
Palo Alto Networks Next-Generation Firewall offers processors dedicated to specific functions that work in parallel. The Data Plane in the high-end models contains three types of processors (CPUs) connected by high-speed 1Gbps busses.
The three type of processors are:
- Security Matching Processor: Dedicated processor that performs vulnerability and virus detection.
- Security Processor: Dedicated processor that performs hardware acceleration and handles security tasks such as SSL decryption, IPsec decryption and similar tasks.
- Network Processor: Dedicated processor responsible for network functions such as routing, NAT, QOS, route lookup, MAC Lookup and network layer communications.
Conclusion
Palo Alto Networks unique architecture and design has played a significant role in helping place it apart from the rest of its competitors. Its Single Platform Parallel Processing architecture coupled with the single management system results in a fast and highly sophisticated Next-Generation Firewall that won’t be left behind anytime soon. For more technical information and articles covering configuration and technical features of the Palo Alto Networks Firewall, visit our Palo Alto Networks Firewall Section.
Import a Certificate and Private Key
If your enterprise has its own public key infrastructure (PKI), you can import a certificate and private key into the firewall from your enterprise certificate authority (CA). Enterprise CA certificates (unlike most certificates purchased from a trusted, third-party CA) can automatically issue CA certificates for applications such as SSL/TLS decryption or large-scale VPN.
https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/certificate-management/import-a-certificate-and-private-key
https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/certificate-management/import-a-certificate-and-private-key
Use Case: Configure Firewalls Using Panorama
https://www.paloaltonetworks.com/documentation/61/panorama/panorama_adminguide/manage-firewalls/use-case-configure-firewalls-using-panorama.htmlPanorama Commit Operations
When editing the configuration on Panorama, you are changing the candidate configuration file. The candidate configuration is a copy of the running configuration along with any changes you made since the last commit. The Panorama web interface displays all the configuration changes immediately. However, Panorama won’t implement the changes until you commit them. The commit process validates the changes in the candidate configuration file and saves it as the running configuration on Panorama.
 | After any system event or administrator action causes Panorama to reboot, all your changes since the last commit will be lost. To preserve changes without committing them, periodically click Save at the top right of the web interface to save a snapshot of the candidate configuration. If a reboot occurs, you can then revert to the snapshot. For details on backing up and restoring running and candidate configurations, see Manage Panorama Configuration Backups. |
When initiating a commit on Panorama, select one of the following types:
| Commit Options | Description |
|---|---|
| Panorama | Commits the changes on the current candidate configuration to the running configuration on Panorama. You must first commit your changes on Panorama, before committing any configuration updates (templates or device groups) to the managed firewalls or Collector Groups. |
| Template | Commits network and device configurations from a Panorama template to the selected firewalls. |
| Device Group | Commits policies and objects configured from Panorama to the selected firewalls/virtual systems. |
| Collector Group | Commits changes to the specified Collector Groups that Panorama manages. |
When you perform a commit, Panorama pushes the entire configuration to the managed firewalls. When the commit completes, a result displays: Commit succeeded or Commit succeeded with warnings.
Some other commit choices are:
Preview Changes —This option is available when the Commit Type is Panorama. It enables you to compare the candidate configuration with the running configuration in the same way as the Panorama > Config Audit feature (see Compare Changes in Panorama Configurations). After clicking Preview Changes, select the number of lines to include for context, and click OK. As a best practice, preview your configuration changes before committing them.
 | Because the preview results display in a new window, your browser must allow pop-up windows. If the preview window does not open, refer to your browser documentation for the steps to unblock pop-up windows. |
Include Device and Network Templates —This option is available when committing a device group from Panorama. It allows you to commit both device group and template changes, to the pertinent firewalls, in a single commit operation.
If you prefer to commit your changes as separate commit operations, do not select this check box.
Force Template Values —When performing a Template commit, the Force Template Values option overrides all local configuration and removes objects on the selected firewalls or virtual systems that do not exist in the template or have been overridden by the local configuration. This is an override that reverts all existing configuration on the managed firewall, and ensures that the firewall inherits the settings defined in the template only. Merge with Candidate Config —When enabled, this option allows you to merge and commit the Panorama configuration changes with any pending configuration changes that were implemented locally on the target firewall. If this option is not enabled, the candidate configuration on the firewall is not included in the commit operation. As a best practice, leave this option disabled if you allow firewall administrators to modify the configuration directly on a firewall and you don’t want to include their changes when committing changes from Panorama.
Keys and Certificates for Decryption Policies
Keys are strings of numbers that are typically generated using a mathematical operation involving random numbers and large primes. Keys are used to transform other strings—such as passwords and shared secrets—from plaintext to ciphertext (called encryption) and from ciphertext to plaintext (called decryption). Keys can be symmetric (the same key is used to encrypt and decrypt) or asymmetric (one key is used for encryption and a mathematically related key is used for decryption). Any system can generate a key.
X.509 certificates are used to establish trust between a client and a server in order to establish an SSL connection. A client attempting to authenticate a server (or a server authenticating a client) knows the structure of the X.509 certificate and therefore knows how to extract identifying information about the server from fields within the certificate, such as its FQDN or IP address (called a common name or CN within the certificate) or the name of the organization, department, or user to which the certificate was issued. All certificates must be issued by a certificate authority (CA). After the CA verifies a client or server, the CA issues the certificate and signs it using its private key.
With a decryption policy configured, an SSL/TLS session between the client and the server is established only if the firewall trusts the CA that signed the server’s certificate. In order to establish trust, the firewall must have the server’s root CA certificate in its certificate trust list (CTL) and use the public key contained in that root CA certificate to verify the signature. The firewall then presents a copy of the server certificate signed by the Forward Trust certificate for the client to authenticate. You can also configure the firewall to use an enterprise CA as a forward trust certificate for SSL Forward Proxy. If the firewall does not have the server’s root CA certificate in its CTL, the firewall will present a copy of the server certificate signed by the Forward Untrust certificate to the client. The Forward Untrust certificate ensures that clients are prompted with a certificate warning when attempting to access sites hosted by a server with untrusted certificates.
For detailed information on certificates, see Certificate Management.
| To control the trusted CAs that your device trusts, use the Device > Certificate Management > Certificates > Default Trusted Certificate Authorities tab on the firewall web interface. |
Table: Palo Alto Networks Device Keys and Certificates describes the different keys and certificates used by Palo Alto Networks devices for decryption. As a best practice, use different keys and certificates for each usage.
Table: Palo Alto Networks Device Keys and Certificates
| Key/Certificate Usage | Description |
|---|---|
| Forward Trust | The certificate the firewall presents to clients during decryption if the site the client is attempting to connect to has a certificate that is signed by a CA that the firewall trusts. To configure a Forward Trust certificate on the firewall, see Step 2 in the Configure SSL Forward Proxy task. By default, the firewall determines the key size to use for the client certificate based on the key size of the destination server. However, you can also set a specific key size for the firewall to use. See Configure the Key Size for SSL Forward Proxy Server Certificates. For added security, store the forward trust certificate on a Hardware Security Module (HSM), see Store Private Keys on an HSM. |
| Forward Untrust | The certificate the firewall presents to clients during decryption if the site the client is attempting to connect to has a certificate that is signed by a CA that the firewall does not trust. To configure a Forward Untrust certificate on the firewall, see Step 3 in the Configure SSL Forward Proxy task. |
| SSL Exclude Certificate | Certificates for servers that you want to exclude from SSL decryption. For example, if you have SSL decryption enabled, but have certain servers that you do not want included in SSL decryption, such as the web services for your HR systems, you would import the corresponding certificates onto the firewall and configure them as SSL Exclude Certificates. See Exclude a Server From Decryption. |
| SSL Inbound Inspection | The certificate used to decrypt inbound SSL traffic for inspection and policy enforcement. For this application, you would import the server certificate for the servers for which you are performing SSL inbound inspection, or store them on an HSM (see Store Private Keys on an HSM). |
Single Pass Parallel Processing (SP3) Architecture
Palo Alto Networks next-generation firewalls are based on a unique Single Pass Parallel Processing (SP3) Architecture – which enables high-throughput, low-latency network security, even while incorporating unprecedented features and technology.Palo Alto Networks solves the performance problems that plague today’s security infrastructure with the SP3 architecture, which combines two complementary components:
- Single Pass software
- Parallel Processing hardware
Single Pass Software
Palo Alto Networks Single Pass software is designed to accomplish two key functions within the Palo Alto Networks next-generation firewall. First, the single pass software performs operations once per packet. As a packet is processed, networking functions, policy lookup, application identification and decoding, and signature matching for any and all threats and content are all performed just once. This significantly reduces the amount of processing overhead required to perform multiple functions in one security device. Second, the content scanning step in Palo Alto Networks’ Single Pass software is stream-based, and uses uniform signature matching to detect and block threats. Instead of using separate engines and signature sets (requiring multi-pass scanning) and instead of using file proxies (requiring file download prior to scanning), the single pass software in our next-generation firewalls scans content once and in a stream-based fashion to avoid latency introduction.This Single Pass traffic processing enables very high throughput and low latency – with all security functions active. It also offers the additional benefit of a single, fully integrated policy, enabling simple, easier management of enterprise network security.
Parallel Processing Hardware
The other critical piece of Palo Alto Networks SP3 Architecture is hardware. Palo Alto Networks next-generation firewalls use Parallel Processing hardware to ensure that the Single Pass software runs fast. First, Palo Alto Networks engineers designed separate data and control planes. This separation means that heavy utilization of one won’t negatively impact the other – for example, an administrator could be running a very processor-intensive report, and yet the ability to process packets would be completely unhindered, due to the separation of data and control planes.The second important element of the Parallel Processing hardware is the use of discrete, specialized processing groups that work in harmony to perform several critical functions.
- Networking: routing, flow lookup, stats counting, NAT, and similar functions are performed on network-specific hardware
- User-ID, App-ID, and policy all occur on a multi-core security engine with hardware acceleration for encryption, decryption, and decompression.
- Content-ID content analysis uses dedicated, specialized content scanning engine
- On the controlplane, a dedicated management processor (with dedicated disk and RAM) drives the configuration management, logging, and reporting without touching data processing hardware.
0 Response to "Palo Alto Notes"
Post a Comment