Set the API key lifetime to protect against compromise and to reduce the effects of an accidental exposure. To ensure that your keys are frequently rotated and each key is unique when regenerated, you must specify a validity period that ranges between 1—525600 minutes. Refer to the audit and compliance policies for your enterprise to determine how you should specify the lifetime for which your API keys are valid.

The Password profile sets a time period for the password to be active and expires after that period. This forces the password to change regularly, so saved or stolen credentials won't allow an attacker to compromise the firewall.

To prevent spyware activity on the network, clone the predefined strict Anti-Spyware profile and retain the default “reset-both” Action for critical, high, and medium severity levels. If business reasons prevent resetting both the server and the client, set the Action to “drop”, “reset-client”, “reset-server”, or “block-ip”, but “reset-both” is best. For critical, high, and medium severity levels, enable single packet capture for the same traffic that you log.

Different threat severities require different actions in Anti-Spyware profiles. Set the Action for informational and low Severity events to "default", which takes the default PAN-OS action for the threat. Don’t set the Severity to "any" because you have to set the Action to "reset-both" to handle critical, high, and medium severity signatures. Instead, assign specific actions to each Severity level.

If the firewall detects malware, the firewall should block the threat. To do that, set the FTP, HTTP, SMB, and SMTP decoders to “reset-both” in the Action column in every Antivirus profile. Resetting both ends of the connections is better than resetting only the client or only the server unless there are business reasons not to reset one end of the connection. You can tighten security even more by also setting the IMAP and POP3 decoder Action to “reset-both”. When you're using predefined profiles and if they’re failing BP checks you can clone them or create a custom profile and do the necessary changes to pass BP checks.

The WildFire Action setting in Antivirus profiles is based on WildFire content signature updates. If you have a WildFire subscription, your firewalls receive zero-day malware signatures from the WildFire cloud minutes after the threat was discovered. Set the FTP, HTTP, SMB, and SMTP decoders to “reset-both” (preferred for best security), “drop”, “reset-client”, or “reset-server” in the WildFire Action column in every Antivirus profile. You can tighten security even more by also setting the IMAP and POP3 decoder WildFire Action to “reset-both”. When you're using predefined profiles and if they’re failing BP checks you can clone them or create a custom profile and do the necessary changes to pass BP checks.

Configure WildFire Inline Machine Learning Action for decoders to block malicious threats detected in real time by the WildFire Inline ML models.

Use the WildFire Inline ML tab to enable and configure real-time WildFire analysis of files using a firewall-based machine learning model. Ensure action 'enable' is selected so the models can take the action as defined in the decoder section for the WildFire Inline ML Action column.

Downloading and installing Antivirus content updates hourly ensures that your firewalls applies the latest protection against known malware.

This check ensures that an App-ID (predefined or custom) is enabled on a Security policy rule. In the Best Practice Assessment report, you can filter the Security policy rules to find rules that don't have App-ID enabled (Application = "any"). You can leverage filters such as Device Group, Tags, and Service to narrow the filter search. Identifying the rules without App-ID enabled allows you to work on them to add the appropriate App-ID(s).

Sessions governed by application override policies prevent the firewall from using App-ID to identify applications, performing Layer 7 inspection, and scanning the traffic for threats. To support proprietary internal applications for which the firewall has no predefined App-ID (the firewall has App-IDs only for public applications), it’s better to create custom applications. Custom applications include the application service ports and application-layer pattern (signature) so the firewall performs Layer 7 inspection and scans the application traffic for threats when internal application traffic matches the security rule. If you see traffic for a commercial application that doesn’t have an App-ID, submit a request for a new App-ID. If a well-known application definition (ports or signature) changes so that the firewall no longer identifies the application correctly, create a support ticket for the issue, and Palo Alto Networks will update the definition. Until the application definition is updated, create a custom application so the firewall continues to perform Layer 7 inspection and threat scanning. If your rulebase has application override policies, you can work with your Palo Alto Networks account team to have App-IDs created for public applications or convert the application override policy to a custom application for internal applications.

Set the file size for APK files to 30 MB so all APK files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum APK file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

The 30-second default session timeout sets the maximum amount of time that a non-TCP/UDP, non-SCTP, or non-ICMP session can remain open without a response. The default value protects against leaving sessions open for protocols that aren't well known or well established. For internal software or application traffic that requires a longer timeout value, create a custom application and set a custom timeout value.

The best practice for content updates depends on whether your business values security first or availability first. If you value security first, set the update recurrence to "hourly", the action to "download-and-install", and the delay threshold to less than six hours. If you value availability first, set the update recurrence to "daily", the action to "download-and-install", and the delay threshold to between 24 and 48 hours.

When application availability is critical, validate new App-IDs in a test environment before you install the new App-IDs on production firewalls. This check ensures that you have enough time to update or modify Security policies for the new App-IDs before you install them in a production environment. Content updates with new App-IDs are released once a month. You can set a delay threshold to trigger installation at a time of your choice to give yourself enough time to validate the new App-IDs first.

Set the maximum file size for archive files to 10 MB so all archive files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size, increasing the maximum archive file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

If you use Authentication Portal services, "Enable Authentication Portal " settings (Device > User Identification > Authentication Portal Settings) to set timers, and specify profiles and authentication settings to authenticate users based on Authentication policy rules.

To provide the strongest security against SSL/TLS protocol vulnerabilities, for Authentication Portal, set the SSL/TLS Service Profile (Device > Certificate Management > SSL/TLS Service Profile) "Min Version" to "TLSv1.2" and the "Max Version" to "Max".

The default 30-second timeout sets the maximum amount of time for an Authentication Portal web form session. If a user doesn't complete the web form before the timeout, authentication fails and the connection attempt fails.

Enable automatically creating a commit lock as soon as an administrator makes configuration changes. The commit lock prevents other administrators from making configuration changes until the first administrator commits her/his changes on the firewall.

If the primary HA1 link fails, the secondary HA1 link exchanges control information such as heartbeat, configuration sync, HA state information, etc., between the HA peers. It’s recommended you configure both HA1 and HA1 secondary so that if the primary link fails, the secondary link takes effect immediately to keep the devices in sync and up to date.

This Panorama setting (Panorama > Setup > Management > Logging and Reporting Settings) ensures that the logs are buffered on the firewall if Panorama loses the connection to the firewall. When the connection comes back up, the firewall forwards the buffered logs to Panorama. The firewall log buffer capacity depends on the log quota and the volume of logs to buffer.

A Certificate Profile validates the certificates of every party involved in establishing a secure session. It matches the client certificate from user endpoints to the certificate profile, in this case to ensure that the Administrator's host machine has the right certificates to authenticate with the Root CA certificate defined in the Certificate Profile .

This option ensures that the configuration is synchronized between the HA pair devices, so that if the active device goes down, the secondary or passive device has the same configuration to process traffic the same way as the active device.

Configuration logs (Device > Log Settings > Configuration) provide insight about configuration changes, which admin made the changes, the change time, etc. Configuration logs help troubleshoot performance, device management, and device health issues.

Phishing sites are sites that attackers disguise as legitimate websites with the aim to steal user information, especially the user credentials that provide access to your network. You can now identify and prevent in-progress phishing attacks by controlling sites to which users can submit corporate credentials based on the site’s URL category. This allows you to block users from submitting credentials to untrusted sites while allowing users to continue to submit credentials to corporate and sanctioned sites. In the User Credential Detection column, for the User Credential Detection field select the Domain Credential mode so that setting checks for a valid corporate username and the associated password if it’s being stolen. In the other two modes that is, IP User mapping and Group mapping, it checks for valid corporate username only. So, for precise phishing prevention, Domain credential mode is the best.

Phishing sites are sites that attackers disguise as legitimate websites with the aim to steal user information, especially the user credentials that provide access to your network. You can now identify and prevent in-progress phishing attacks by controlling sites to which users can submit corporate credentials based on the site’s URL category. This allows you to block users from submitting credentials to untrusted sites while allowing users to continue to submit credentials to corporate and sanctioned sites. In the URL Filtering profile's User Credential Submission column (Categories tab), don't set the value to "allow" for any categories because the firewall doesn't log the allowed traffic, so you have no visibility into that traffic. For URL categories you don't block, set the Site Access action to "alert" to log the traffic. On the User Credential Detection tab, select the User Credential Detection method and set the Log Severity to medium or higher. If you block all the URL categories in a URL Filtering profile for User Credential Submission, you don't need to check credentials because submission is blocked for all categories.

For improved coverage against threats using DNS, the DNS Security subscription enables users to access real-time protections using advanced predictive analytics. Using techniques such as DGA/DNS tunneling detection and machine learning, threats hidden within DNS traffic can be proactively identified and shared through an infinitely scalable cloud service. Because the DNS signatures and protections are stored in a cloud-based architecture, you can access the full database of ever-expanding signatures that have been generated using a multitude of data sources. This allows you to defend against an array of threats using DNS in real time against newly generated malicious domains. Ensure in each Anti-spyware profile in DNS Signatures tab, DNS Cloud security source is selected and action is set to sinkhole with packet capture enabled for single-packet. This check applies when DNS service license is active.

DNS Sinkhole features enable the ability to identify the compromised or infected host machines that are accessing malicious domains. When a host machine accesses a malicious domain, the DNS Sinkhole feature in the Antispyware profile will direct this traffic request to sinkhole IP address or an address that isn’t routable externally so that an administrator can identify all the traffic that was sinkholed to identify the compromised source machine. The action should be set to ‘sinkhole’ to pass the check. Packet capture should be set at 'single pcap' to collect raw data that may be necessary on the suspicious domain that may not be collected through the threat log. If you’re using predefined profiles and if they’re failing BP checks you can clone them or create a custom profile and do the necessary changes to pass BP checks.

Decryption profiles for traffic you decrypt specify SSL protocol settings such as the SSL/TLS protocol versions, key exchange algorithms, encryption algorithms, and authentication algorithms that you allow on your network. The best practice is to use the most recent version of TLS you can, and to avoid outdated algorithms. For outbound SSL sessions, Decryption profiles can block sessions with certificate issues and unsupported modes, and perform failure checks. For inbound SSL sessions, Decryption profiles can block unsupported modes and perform failure checks. For traffic you don’t decrypt, even though the firewall can’t see and inspect the content, Decryption profiles can block sessions with expired certificates and untrusted certificate issuers. Apply a Decryption profile to each Decryption policy rule, for both traffic you do decrypt and traffic you don’t decrypt.

Delete disabled Security policy rules created for temporary purposes, testing, or that have become obsolete to keep the rulebase uncluttered.

Don’t forward packets that exceed the TCP App-ID content inspection queue. If you forward packets when the TCP App-ID content inspection queue is full, the firewall forwards packets without completing App-ID inspection and identifies the packets as unknown-tcp, so the firewall doesn’t identify the application correctly and therefore can’t apply the correct Security policy rule. The best practice is to safely enable applications is to stop forwarding packets when the TCP App-ID content inspection queue is full so the firewall can accurately identify applications and match them to the correct rules (Device > Setup > Content-ID > Content-ID Settings). The tradeoff is that you may experience increased latency when more than 64 segments are in the App-ID processing queue.

Don’t forward packets that exceed the TCP content inspection queue. If you forward packets when the TCP content inspection queue is full, the firewall can’t inspect the content at the TCP layer, so it may not be able to identify and process malicious traffic. The best practice to safely enable applications is to drop segments when the TCP content inspection queue is full (Device > Setup > Content-ID > Content-ID Settings). The tradeoff is that high-volume traffic conditions could lead to performance degradation and some applications not functioning smoothly because of TCP retransmissions for dropped traffic.

Don’t forward UDP datagrams that exceed the UDP content inspection queue. If you forward packets when the UDP content inspection queue is full, the firewall can’t inspect the content at the UDP layer, so it may not be able to identify and process malicious traffic. The best practice to safely enable applications is to drop segments when the UDP content inspection queue is full (Device > Setup > Content-ID > Content-ID Settings). The tradeoff is that high-volume traffic conditions could lead to performance degradation and some applications not functioning smoothly due to dropped packets.

When 'HTTP Partial response' is enabled, it allows a client to fetch only part of a file. When a next-generation firewall in the path of a transfer identifies and drops a malicious file, it terminates the TCP session with an RST packet. If the web browser implements the HTTP Range option, it can start a new session to fetch only the remaining part of the file. This prevents the firewall from triggering the same signature again due to the lack of context into the initial session, while at the same time allowing the web browser to reassemble the file and deliver the malicious content. To prevent this, make sure this option is disabled. Note: By default, the Allow HTTP partial response is enabled. However, Palo Alto Networks recommends you disable this option for maximum security. Disabling this option shouldn’t impact device performance; however, HTTP file transfer interruption recovery may be impaired. In addition, disabling this option may also impact streaming media services, such as Netflix, Microsoft Updates, and Palo Alto Networks content updates.

Until the firewall receives all of the packets in order, it can’t send them from the TCP layer to the Application layer, so forwarding segments that exceed the TCP out-of-order queue limit (Device > Setup > Session > TCP Settings) and cause extra delay can degrade firewall performance.

Accelerated Aging ages out idle sessions if the session table reaches a configured threshold. You can also set an "accelerated aging scaling factor", which accelerates aging using the factor as a multiplier of the configured idle time to age out idle sessions faster when the session table reaches the "Accelerated Aging Threshold" value. This frees up session table space for new sessions.

A DoS flood attack can occur through any protocol, so enable all of the flood thresholds (SYN Flood, UDP Flood, ICMP Flood, ICMPv6 Flood, and Other IP Flood).

Enable sending unknown files in decrypted traffic to WildFire for analysis (Device > Setup > Content-ID > Content-ID Settings) to protect against new threats in encrypted traffic.

Enabling Rematch Sessions applies newly configured and committed Security policy rules to existing active sessions. If the action on the new rule is "deny", the session closes immediately. If you have configured Tunnel Content Inspection, ensure the firewall doesn't drop existing sessions when you create or revise a tunnel inspection policy by disabling Reject Non-SYN TCP on the Zone Protection Profile's Packet-Based Attack Protection tab for the zones that control your tunnel Security policy rules.

Set the "User Identification Timeout" (Device > User Identification > User Mapping > Palo Alto Networks User-ID Agent Setup > Cache) to ensure that the firewall has the most current user-to-IP-address-mapping information. When the timeout value is reached, the firewall clears the mappings from its cache, and the user must authenticate again.

Packet Buffer Protection defends your firewall from single session denial-of-service (DoS) attacks that can overwhelm the firewall's packet buffer and cause legitimate traffic to drop. Packet buffer protection settings are configured globally and then applied per ingress zone.

“Log container page only” is the default URL Filtering setting and logs only the landing or homepage or the specific URL link accessed with the web browser. This setting doesn’t log the rest of the related web links directed or connected to during the session, such as advertisements and content links, which reduces the logging and memory load while logging the relevant URLs. If you use proxies that mask the original IP address of the source, enable the HTTP Header Logging “X-Forwarded-For” option to preserve the original IP address of the user who initiated the webpage request.

For troubleshooting sessions, upgrade processes, or one-time events, you may configure a Security policy rule with a nonrecurring schedule so that the rule takes effect only during the scheduled time period. At the end of the scheduled time period, the rule no longer affects traffic. If you want the rule to continue to be in effect, apply a different schedule to the rule or remove the schedule from the rule. If you don’t need the rule, delete the rule to prevent the rulebase from becoming cluttered.

Configure an external Authentication profile such as LDAP, Kerberos, RADIUS, etc., for Admin login accounts to verify authentication externally using well-known protocols that include events and logs for troubleshooting and historical reference. External authentication enables monitoring all events on one authentication server, which makes management easier. Enable no more than two admin accounts for local database authentication as a standby in case external authentication fails. Configure management Authentication profiles using RADIUS or SAML (Device > Setup > Management > Authentication Settings). If you define administrators (Device > Administrators), use Multi-Factor Authentication. If you use RADIUS or SAML as the first factor, enable two-factor authentication directly or enable Okta, PingID, Duo v2, or RSA as the second factor using APIs. If you use LDAP, Kerberos, TACACS+, or local authentication as the first factor, use Okta, PingID, Duo v2, or RSA, as the second factor.

Setting a low number of Failed Attempts (Device > Setup > Management > Authentication Settings) allows users who make typing errors to retry the login a reasonable number of times while preventing malicious systems from trying to access the firewall with repeated login attempts (brute-force) until they gain access.

Setting a low number of Failed Attempts (Device > Setup > Management > Authentication Settings) allows users who make typing errors to retry the login a reasonable number of times while preventing malicious systems from trying to access the firewall with repeated login attempts (brute-force) until they gain access.

The predefined strict File Blocking profile identifies file transfer activity between different network segments (zones). The predefined strict File Blocking profile blocks files commonly seen in malware attack campaigns and for which no real upload/download use case exists, such as batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), BitTorrent files, .rar files, .tar files, encrypted-rar and encrypted-zip files, multilevel encoded files (files encoded or compressed up to four times), .hta files, and Windows Portable Executable (PE) files, which include .exe, .cpl, .dll, .ocx, .sys, .scr, .drv, .efi, .fon, and .pif files. The predefined strict profile alerts on all other file types for visibility into other file transfers so that you can determine if you need to make policy changes. In addition, log every file transfer for analytics and monitoring.

Set the file size for "flash" files to 5 MB so all flash files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum flash file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

Enable and set appropriate Flood Protection thresholds for each zone to prevent connection floods using any protocol (SYN, UDP, ICMP, ICMPv6, and Other IP). Don’t use the predefined threshold values because every network has different segmentation, bandwidth usage, traffic types, etc. Instead, base the Alarm, Activate, and Maximum thresholds for each zone on normal and peak connections-per-second (CPS) measurements for the zone and its interfaces. Take the measurements over the course of at least one normal business week. Set CPS thresholds based on the average and peak rates, and add some extra room to the thresholds to account for normal CPS fluctuations (margin of error). You can use many methods to take baseline measurements, such as logs, tools such as NetFlow or Wireshark, scripts, etc.

Forward critical system logs related to dynamic content updates to external storage, email, and/or analytics systems so that you can review and analyze the logs and take action as needed. This checks that the filter match for System logs is “(severity eq critical) and ( (description contains Content) or (description contains content) )” to ensure that all critical-severity system logs are forwarded.

The "Allow User to Disable GlobalProtect" option permits users to disable the GlobalProtect app. You can set the "Disable Timeout" value to restrict the amount of time for which users can disable the app. Ensures the GlobalProtect resumes and establishes the VPN once the timeout is complete and securing the user while accessing resources through GlobalProtect.

When you "Enforce GlobalProtect Connection for Network Access", GlobalProtect blocks all network traffic to and from the endpoint until the app connects to an internal gateway inside the enterprise network or an external gateway outside the enterprise network. After the app establishes a connection, all network traffic is sent to the firewall for inspection and policy enforcement.

Access routes specify the destination subnets or address objects that you want to include in the VPN tunnel and/or exclude from the VPN tunnel when the GlobalProtect app establishes a tunnel with the gateway. An access route of "0.0.0.0/0" or "::/0" indicates that you’re including all destination subnet or address object.

To strengthen GlobalProtect Gateway client authentication, enable two-factor authentication. Ensure the Client Authentication profile defined for the Globalprotect Gateway has Radius or SAML with two-factor authentication. If Client Authentication profile for the Globalprotect Gateway is other than Radius or SAML, then Certificate profile should be configured in addition to Authentication profile.

"Replay attack detection" protects GlobalProtect satellites against replay attacks, in which unauthorized users maliciously retransmit valid data (such as user credentials) to GlobalProtect gateways in order to gain access to network resources.

Tunnel Monitoring enables GlobalProtect satellites to monitor gateway tunnel connections. If a satellite is unable to connect to a GlobalProtect gateway, you can enable the satellite to failover to another gateway or wait for the tunnel to recover using the "Tunnel Monitor Profile".

To provide the strongest security against SSL/TLS protocol vulnerabilities, set the "Min Version" of your SSL/TLS Service Profile to "TLSv1.2" and the "Max Version" to "Max".

If you enable GlobalProtect to "Collect HIP Data", the GlobalProtect app collects and sends Host Information Profile (HIP) data from the endpoint to the firewall for HIP-based policy enforcement. HIP data is matched against the HIP objects and/or HIP Profiles that you define for policy enforcement. Depending on which HIP object and/or HIP Profile the HIP data matches, corresponding Security policies are enforced to grant or deny endpoints network access.

Internal host detection enables the GlobalProtect app to determine whether an endpoint is inside the enterprise (internal) network. If the GlobalProtect app detects an internal host on the endpoint, the endpoint is inside the enterprise network and can connect to an internal gateway. If the GlobalProtect app can’t detect an internal host on the endpoint, the endpoint is outside the enterprise network and must connect to an external gateway to access the network.

To strengthen the protection of sensitive resources or to comply with regulatory requirements, configure the GlobalProtect portal to use two-factor authentication. You can configure two-factor authentication using certificate and authentication profiles, one-time passwords (OTPs)/tokens, or smart cards.

OCSP responders help identify the revocation status of the certificates that endpoints present to GlobalProtect portals and gateways during certificate authentication. Endpoints use certificates to establish trust with portals and gateways. If a certificate has been revoked for any reason, you must be notified so you can take appropriate action to establish a secure connection to the portal and gateways. To use this feature, you must also enable "CRL" and "OCSP" in the "Certificate Revocation Checking" settings (Device > Setup > Session > Certificate Revocation Checking).

Specifying Trusted Root CA certificates and intermediate certificates in the portal satellite configuration (Network > GlobalProtect > Portals > <portal-config> > Satellite) enables GlobalProtect satellites to verify gateway server certificates and establish secure VPN tunnel connections to GlobalProtect gateways. Satellite Trusted Root CA certificates are pushed to endpoints at the same time as the portal agent configuration.

To provide the strongest security against SSL/TLS protocol vulnerabilities, set the "Min Version" of your SSL/TLS Service Profile to "TLSv1.2" and the "Max Version" to "Max".

Enable "Report Grayware Files" (Device > Setup > WildFire > General Settings) to log details such as session information, behavioral summary, network activity, host activity, and more to help with analytics. If you don't enable this setting, only malware files are logged

When you configure Group Mapping, populate the "Included Groups" list (Device > User Identification > Group Mapping Settings > Group Include List) with only the groups you need to include so the firewall retrieves user group mappings for only the necessary groups and not for the whole tree from the LDAP directory.

HA Timer settings define the intervals at which the HA peers exchange Hello and Heartbeat packets, and also set various timers before the HA peers take an action, such as remaining active after a link monitor or path monitor failure. Recommended settings are preset for most general failovers. The other options are 'Aggressive', which allows faster failover, and 'Advanced' where you can customize settings. Unless you’re sure what settings you need, the best practice is to select "Recommended".

You can now safely enable applications running over HTTP/2. Ensure 'Strip ALPN' setting in your decryption profile is disabled to inspect HTTP/2 protocol. Ensure ECDHE exchange algorithm is enabled in the decryption profile. For HTTP/2 protocol to function we should have Decryption rules configured to decrypt with the configured decryption profile.

As we know HA1 is used for control communication between the HA pair devices to make sure they are in sync, and the HA state information is exchanged frequently to operate as High Availability and make sure its availability. HA1 encryption isn’t necessary for HA firewalls that are connected directly. HA1 encryption is needed if the firewalls are physically apart or the connections for HA1 are going through network devices that can inspect/process/capture traffic.

If HA1 and HA1-backup are configured with dataplane ports, Heartbeat Backup is needed. If Management port is used as HA1 backup, Heartbeat Backup isn’t needed.

HA3 is packet forwarding link between the HA pair devices only used and necessary in Active-Active High availability deployment. This link is used by the firewalls to pass the packets related to session setup and asymmetric packet flows.

When HA2 Keep-alive is enabled, the firewall monitors the connection stability between itself and the HA peer on HA2 connection. A threshold can be set (in milliseconds) so that if the keep-alive packets don’t reach the connected peer by that time, the HA2 connection is considered down. The firewall generates a log about the event (severity is Critical).

When the HA2 connection between the HA pair fails, the firewall generates a system log of Critical severity, indicating an HA2 connection drop.

When you enable Link Monitoring, define and enable a Link Group and assign interfaces to the group. The interfaces are those links that are monitored to see if they’re up; if any or all of them (based on the Failure Condition) go down, link monitoring triggers a failover.

Link monitoring helps the firewall to fail over if a physical link (or group of links) fails. If the link(s) fail, the firewall can’t process and forward traffic, so it fails over to the peer to receive traffic. Similarly, in Path monitoring, the firewall monitors whether a specified destination IP address is reachable through pings, indicating the connection is up for HA to function. If the pings fail, the path to the destination IP address is considered down, so the firewall fails over to ensure the path is connected for HA to function at optimal levels. It’s recommended you enable Link Monitoring or Path Monitoring to maintain traffic continuity through the firewalls.

When you enable Path Monitoring, define and enable a Path Group(s) with Virtual Wire Path, VLAN Path or Virtual Router Path. The path(s) are those that are monitored to see if they’re up; if any or all of the destination IP addresses (based on the Failure Condition) are unreachable, path monitoring triggers a failover.

If "Session Owner Selection" is set to "First Packet," the firewall that receives the first packet of a session becomes the session owner. This setting helps reduce traffic across the HA3 link and helps distribute the dataplane load across the peers.

Session information will be synchronized with the passive device. This is necessary because if a failover occurs and traffic starts to flow from primary unit to secondary unit (which is active after a failover), the secondary unit should have the session in the dataplane so that packets can match the synced session and quickly get processed and forwarded. Otherwise, the secondary firewall will create the session again, which introduces latency and connection drops.

MD5 and SHA1 aren’t secure. Use SHA256 for short-lived transactions and use SHA384 or higher for traffic that requires the most secure authentication, such as financial transactions.

DES and 3DES are weak, vulnerable encryption algorithms. Use the more secure AES algorithm.

Encapsulating Security Payload (ESP) provides better security than Authentication Header (AH) because ESP provides connection confidentiality and authentication but AH provides only authentication.

An idle administrator session with the firewall may allow an unauthorized user to access the firewall. Administrator firewall sessions should be open and active only when an administrator is actively working on the firewall. Set the timeout (Device > Setup > Management > Authentication Settings) to the industry standard 10 minutes to prevent unauthorized access.

Before you allow and block traffic by application, it’s advisable to block traffic from IP addresses that Palo Alto Networks and trusted third-party sources have proven to be High risk in nature. The security rule will ensure that your network is always protected against the IP addresses from the Palo Alto Networks malicious IP address feeds and other feeds, which are compiled and dynamically updated based on the latest threat intelligence. Ensure the security rule is logging at session end and Log Forwarding profile is applied to track activity.

Before you allow and block traffic by application, it’s advisable to block traffic from IP addresses that Palo Alto Networks and trusted third-party sources have proven to be malicious. The rule will ensure that your network is always protected against the IP addresses from the Palo Alto Networks malicious IP address feeds and other feeds, which are compiled and dynamically updated based on the latest threat intelligence.

To map users on subnets, make sure to include the subnet in Device > User Identification > User Mapping > Include/Exclude Networks.

The firewall has a default Security policy rule at the bottom of the rulebase (“interzone-default”) that denies all traffic between zones. Create specific rules to allow traffic between zones. Override the rule and enable Log at Session End to gain visibility into the traffic that the interzone-default rule denies so you can evaluate whether legitimate traffic is inadvertently being denied or if recent changes deny traffic you want to allow.

Set the file size for "jar" files to 5 MB so all jar files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum jar file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

The best practice URL Filtering profile sets all known dangerous URL categories to block. These include command-and-control, copyright-infringement, dynamic DNS, extremism, malware, phishing, proxy-avoidance-and-anonymizers, unknown, and parked. Failure to block these dangerous categories puts you at risk for exploit infiltration, malware download, command-and-control activity, and data exfiltration.

Use the more secure SSL/TLS protocol to communicate with the LDAP server (this is the default setting).

This option verifies the LDAP server before SSL/TLS communication begins.

Configure at least two LDAP servers in the LDAP server profile (Device > Server Profiles > LDAP) to provide redundancy in case a connection goes down.

Set the maximum file size for Linux files to 2 MB so all Linux files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size, increasing the maximum Linux file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

The Lockout Time (Device > Setup > Management > Authentication Settings) sets the amount of time to wait between login attempts after the Failed Attempts counter is exceeded to prevent continuous login attempts from a malicious actor. If you can't use 30 minutes as a value, the value can range from 30-45 minutes. If necessary, use the CLI command "request authentication unlock-admin user <username>" to unlock the administrative user.

The Lockout Time (Device > Setup > Management > Authentication Settings) sets the amount of time to wait between login attempts after the Failed Attempts counter is exceeded to prevent continuous login attempts from a malicious actor. If you can't use 30 minutes as a value, the value can range from 30-45 minutes. If necessary, use the CLI command "request authentication unlock-admin user <username>" to unlock the administrative user.

The firewall has limited log storage space and when the space fills up, the firewall purges the oldest logs. Configure Log Forwarding for the traffic that matches each Security policy rule. You can create profiles that send logs to a dedicated storage device such as Panorama in Log Collector mode, a syslog or SNMP server, or to an email profile, to provide redundant storage for the logs on the firewall and a long-term repository for older logs. You can create profiles to forward logs to one or more external storage devices to remain in compliance, run analytics, and review abnormal activity, threat behaviors, and long-term patterns.

When you create Log Forwarding profiles, forward all Threat Logs (from low to critical) to Panorama and to at least one other logging space, such as a syslog, SNMP, email, or HTTP server so that you can analyze potential threats, helps in log recovery.

Log Forwarding profiles export logs to external storage for reasons such as compliance, running analytics, monitoring, and reviewing abnormal activity, threat behaviors, and long-term patterns. You can forward logs to multiple storage areas simultaneously, such as Panorama, syslog servers, SNMP servers, email servers, and HTTP servers for redundant log record storage. Enable Log Forwarding on Security, Authentication, and DoS policy rules, and on zones.

Forwarding WildFire logs ensure that malware and phishing verdict logs go to Panorama and other logging systems such as email, syslog, and SNMP. For malware verdict logs, enable email log forwarding if possible so that an administrator can receive the log details and take action quickly.

Firewall and Panorama system logs provide important information about system health, features, performance, and more. Forward the logs for all severities to an external device for historical reference and running analytics.

Firewall and Panorama system logs provide important information about system health, features, performance, and more. Forward the logs for all severities to an external device for historical reference and running analytics.

Firewall and Panorama system logs provide important information about system health, features, performance, and more. Forward the logs for all severities to an external device for historical reference and running analytics.

Firewall and Panorama system logs provide important information about system health, features, performance, and more. Forward the logs for all severities to an external device for historical reference and running analytics.

Firewall and Panorama system logs provide important information about system health, features, performance, and more. Forward the logs for all severities to an external device for historical reference and running analytics.

By default, the firewall creates logs at the end of the session for all sessions that match a Security policy rule because the application identification is likely to change as the firewall identifies the specific application and because logging at the session end consumes fewer resources than logging the session start. For example, at the start of a session, the firewall identifies Facebook traffic as web-browsing traffic, but after examining a few packets, the firewall refines the application to Facebook-base. Use “Log at Session Start” only to troubleshoot packet flow and related issues, or for tunnel session logs (only logging at session start shows active GRE tunnels in the Application Command Center).

The firewall generates a system log when the packet processing load reaches 100 percent CPU usage. When the CPU is experiencing maximum load, it may not be favorable for currently running processes to run at their optimum levels and may cause issues in starting new processes. Enabling "Log on High DP Load" (Device > Setup > Management > Logging and Reporting Settings) allows administrators to investigate and identify the cause of the high CPU utilization and take action to remediate the issue.

Login Banner text enables you to post login messages to provide necessary information to administrators when accessing the firewall over a web interface. For example, a banner could state that only authorized network or security team personnel are allowed access, and if the user isn’t part of that group, the user shouldn’t proceed and should close the browser tab.

Minimum Password Complexity (Device > Setup > Minimum Password Complexity) sets format and functionality requirements for passwords. The settings help you make it difficult for brute-force attacks to succeed in accessing the firewall or Panorama. Format requirements include minimum length, lowercase, uppercase letters and numerical values to include in the password, while functionality requirements include blocking username inclusion in password or having reversed username in password, how often to change the password, etc.

An NTP server keeps the firewall's clock synchronized with the NTP server clock. If all network firewalls and Panorama use NTP, then all of them have synchronized clocks, so scheduled jobs run as expected and timestamps can help identify the root cause of various issues involving multiple devices. Configure both a primary and a secondary NTP server in case the primary NTP server becomes unreachable.

NTP Server Authentication ensures that the NTP server approves the client and provides synchronized updates.

Before you allow and block traffic by application, it’s advisable to block traffic from IP addresses that Palo Alto Networks and trusted third-party sources have proven to be High risk in nature. The security rule will ensure that your network is always protected against the IP addresses from the Palo Alto Networks malicious IP address feeds and other feeds, which are compiled and dynamically updated based on the latest threat intelligence. Ensure the security rule is logging at session end and Log Forwarding profile is applied to track activity.

Before you allow and block traffic by application, it’s advisable to block traffic from IP addresses that Palo Alto Networks and trusted third-party sources have proven to be malicious. The security rule will ensure that your network is always protected against the IP addresses from the Palo Alto Networks malicious IP address feeds and other feeds, which are compiled and dynamically updated based on the latest threat intelligence. Ensure the security rule is logging at session end and log forwarding profile is applied to track activity.

To enhance security for a zone, Packet-Based Attack Protection allows you to specify whether the firewall drops IP, IPv6, TCP, ICMP, or ICMPv6 packets that have certain characteristics or strips certain options from the packets.

Packet Buffer Protection defends your firewall from single session denial-of-service (DoS) attacks that can overwhelm the firewall's packet buffer and cause legitimate traffic to drop. Packet buffer protection settings are configured globally and then applied per ingress zone.

On the passive firewall, when the Passive Link State is set to Auto, the links that have physical connectivity remain physically up, but in a disabled state. This setting helps reduce convergence times during a failover because no time is spent to bring up the links. To avoid network loops, don’t select Auto if the firewall has any Layer 2 interfaces configured.

Enabling and specifying the Permitted IP Addresses (Device > Setup > Interfaces > Management) ensures that only the IP addresses and subnets in the list can access the firewall management interface. This reduces the attack surface by denying access to addresses that aren't on the list. If the Management IP address is a public address, configure a permitted IP address list, and allow only access to those as needed.

Tracks how often traffic matches the policy rules you configured on the firewall. Identifies the inactive rules. When enabled, you can view the total Hit Count for total traffic matches against each rule along with First Hit and Last Hit.

Set the file size for PDF files to 1,000 KB so all PDF files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum PDF file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

Set the file size for PE files to 10 MB so all PE files that pass through the firewall are sent to WildFire for inspection. Because each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum PE file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at the same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

Chrome and some other browsers establish sessions using QUIC instead of TLS/SSL, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Blocking QUIC forces the browser to fall back to TLS/SSL which can be decrypted by the firewall and take the necessary action on the security rule-based on Application and Security Profiles. Configure a security rule with application=quic and set to action=deny. Set this rule before any permit rules so it covers all traffic. On a Panorama configure this security rule in pre-rules for full effect.

Reconnaissance Protection identifies host sweeps and TCP and UDP port scans, and takes the configured action (allow, alert, block, block IP) when time interval and event threshold criteria are matched. Enable Reconnaissance Protection on less trusted and internet-facing zones.

HTTP and Telnet use plain text and aren’t as secure as other services. For management interface access, require SSH or HTTPS.

HTTP and Telnet use plain text and aren’t as secure as other services. For management access through data port, require SSH or HTTPS only.

As the Security policy rulebase grows and becomes more granular, the Description helps to differentiate and provide context for each rule.

New App-IDs can cause a change in policy enforcement for traffic that is newly identified as belonging to a certain application. To mitigate any impact to security policy enforcement, you can use the New App-ID characteristic within Application filter in a security policy rule so that the rule always enforces the most recently introduced App-IDs without requiring you to make configuration changes when new App-IDs are installed. New App-IDs are released monthly, so a policy rule that allows the latest App-IDs gives you a month’s time (or, if the firewall isn’t installing content updates on a schedule, until the next time you manually install content) to assess how newly-categorized applications might impact security policy enforcement and make any necessary adjustments. Apply a security rule permitting traffic for new App-IDs only. Create an Application filter with check enabled on New App-IDs only or necessary new App-IDs by filtering in Application filter. Apply this Application filter on a security policy with action set to Allow. Ensure in Apps and Threats content Dynamic update the check for 'Disable new apps in content update' is disabled.

Ensure the community string doesn't use default strings. Instead, use unique community strings, which also avoid conflicts if you use multiple SNMP services.

If you use SNMP, use version 3 (instead of version 2c) because version 3 includes authentication and other features to keep network connections secure.

Decryption profiles enable you to block and control specific aspects of SSL Forward Proxy (outbound) traffic. Enable appropriate server verification checks to ensure that internal users don’t establish a connection to servers with expired certificates, untrusted issues, unknown certificate status, and restrict certificate extensions. Enable unsupported mode checks to block sessions with unsupported versions and unsupported cipher suites.

Decryption profiles enable you to block and control specific aspects of SSL Inbound Inspection traffic. Enable unsupported mode checks to block sessions with unsupported versions and unsupported cipher suites. The ciphers and certificates required for SSL Inbound Inspection (configured on the SSL Protocol Settings tab) depend on what the internal server that you’re protecting with profile supports.

Due to SSL/TLS vulnerabilities, the latest version of TLS protocol is the most secure, so select TLSv1.2 as the Min Version and “Max” as the Max Version to ensure that the firewall uses the newest available version of TLS. Configure strict algorithms to prevent an attacker or man-in-the-middle from compromising SSL sessions. Don’t enable the weak 3DES or RC4 encryption algorithms, and don’t enable the MD5 or SHA1 authentication algorithms.

Set the file size for script files to 20 KB so all script files that pass through the firewall are sent to WildFire for inspection. As each firewall model has a different disk buffer size for forwarding to sandbox, increasing the maximum script file size limit may affect forwarding capacity in terms of the number of files the firewall can forward, so it's possible that not all files would be forwarded to WildFire if multiple big zero-day files are processed at same time. You can tune the maximum size setting and observe whether there's enough buffer space to handle a higher limit.

Configure the secondary and tertiary authentication methods (Device > Authentication Sequence) in case the primary authentication method fails. The firewall tries the primary authentication method first, and if it fails, falls back to the secondary method, and if that fails, falls back to the tertiary method, and so on (if you configure more than three methods).

Using the WinRM protocol greatly improves the speed, efficiency, and security when monitoring server events to map usernames to IP addresses. Leverage one of the Windows Remote Management (WinRM) protocol to monitor Active Directory Windows Servers 2008 or Microsoft Exchange Servers 2008 or later

The firewall acts as a User-ID agent and retrieves the user-to-IP-address mapping from monitored servers. Configure at least two servers for redundancy (Device > User Identification > User Mapping > Server Monitoring), so if a server goes down, the firewall can still learn the user-to-IP-address mapping from the other server.

Disabling server response inspection disables packet inspection on traffic from the server to the client, which means the firewall wouldn’t inspect server-to-client flows, so it can’t protect your network against threats in those flows. Reduce the attack surface by inspecting both directions of session flows.

In Security policy rules that allow traffic, never set the service port to “any”. Always specify the application and service port to prevent malware from accessing the network through open ports. The best service choice for most applications is “application-default”. When you set the service to application-default, the firewall opens only the ports defined as default ports for the specified application. The firewall also dynamically updates the rule if the default port definition for an application changes, so the firewall always opens only the default ports for the specified application’s traffic. If an application must use a nonstandard port, manually define the port in the rule, and update the rule if you need to change or add ports. Only open the service ports required for each application to reduce the attack surface.

This check lists Security policy rules and identifies rules that have App-ID enabled with the Service set to application-default or to a particular port or set of ports with a green check mark, and identifies rules that have App-ID enabled but don’t have the Service defined (Service is “any”) with a red cross mark and those rules that don’t have App-ID with a hyphen (“-”). Rules with the Service set to “any” allow the application to run on any port, which exposes your network to evasive traffic that uses nonstandard application ports to bypass security. The check returns the percentage of good rules (where the Service is defined as application-default, a specific port, or a specific set of ports) so you know how much progress you have made in transitioning from port-based to application-based rules.

Authentication Portal identifies user information for web traffic (HTTP or HTTPS) that matches an Authentication policy rule so you can identify users whose information isn’t available to the firewall. Setting service as 'any' in Authentication rules for Authentication Portal functionality ensures web traffic on all ports can be monitored to learn user information. So, not just HTTP and HTTPS but all ports need to be enabled as web traffic can originate on non-standard ports too.

Enable all options in the Session Information Settings (Device > Setup > WildFire > Session Information Settings) to view all session details in the WildFire Analysis report. Session information contains details on the source and destination addresses to track and remediate the system, time of system events, identification of firewalls that discovered a threat, and the application on which the threat was identified. These details provide statistics and other metrics that allow you to take actions to prevent future threat events.

The default 30-second timeout sets the maximum amount of time for a Authentication Portal web form session. If a user doesn't complete the web form before the timeout, authentication fails and the connection attempt fails.

The 30-second default session timeout sets the maximum amount of time that a non-TCP/UDP, non-SCTP, or non-ICMP session can remain open without a response. The default value protects against leaving sessions open for protocols that aren't well known or well established. For internal software or application traffic that requires a longer timeout value, create a custom application and set a custom timeout value.

The default 60-second Discard Default timeout takes effect on non-TCP/UDP/SCTP traffic when the Security policy denies the session.

The default 90-second Discard TCP timeout is the maximum time a TCP session can remain open after the firewall denies the session based on Security policy.

The default 60-second Discard UDP timeout is the maximum time a UDP session can remain open after the firewall denies the session based on Security policy.

The default 6-second ICMP timeout sets the maximum amount of time an ICMP session can remain open without an ICMP response.

The default 10-second Scan timeout sets the maximum amount of time any session remains open after the firewall considers it inactive.

The default 3600-second TCP timeout sets the maximum amount of time any TCP session remains open and idle after the handshake is complete.

The default 120-second timeout sets the maximum amount of time between receiving the first FIN and second FIN or an RST.

The default 10-second timeout sets the maximum amount of time between receiving the SYN-ACK and the subsequent ACK that fully establishes the session.

The default 5-second timeout sets the maximum amount of time between receiving the SYN and subsequent SYN-ACK before starting the TCP handshake timer.

The default 15-second timeout sets the maximum amount of time after receiving the second FIN or an RST.

The default 30-second timeout sets the maximum amount of time after receiving a UDP session remains open and listening without a UDP response.

The default 30-second timeout sets the maximum amount of time after receiving an RST packet that can’t be verified.

Set a limit on how fast the firewall refreshes FQDNs that it receives from a DNS. This check ensures the FQDN isn’t outdated by setting refresh interval at default 30 sec.

The Server Log Monitor Frequency value defines how often the firewall queries the Windows server security logs for user mapping information. If the value is too high, the frequent monitoring can impact the domain controller, memory, CPU, and User-ID policy enforcement. If the value is too low, the latest IP-address-to-user mapping may not be available. Initially, try a value in Device > User Identification > User Mapping > Server Monitor > Server Log Monitor Frequency in the range of two to thirty seconds, then revise this value based on performance impact or how often user mappings are updated.

The "User Identification Timeout" ensures that the firewall has the most current user-to-IP-address-mapping information. Crossing the timeout threshold clears mappings from the firewall cache and the user has to authenticate again. Set the "User Identification Timeout" value (Device > User Identification > User Mapping > Palo Alto Networks User-ID Agent Setup > Cache) to the half-life of DHCP or to the Kerberos ticket lifetime.

Use Security policy settings to create rules that exactly define the traffic to which the rules apply (zones, IP addresses, users, applications). Policy rules that are too general may match traffic you don’t want the policy to match and either permit undesirable traffic or deny legitimate traffic. Defining the source, destination, or both zones prevent potentially malicious traffic that uses evasive or deceptive techniques to avoid detection or appear benign from traversing the entire network, which reduces the attack surface and the threat scope. The exception to this best practice is when the Security policy needs to protect the entire network. For example, a rule that blocks traffic to malware or phishing URL categories can apply to all zones (and all traffic) because the URL Category clearly defines the traffic to block. Another example is blocking all unknown traffic with a block rule that applies to all traffic in all zones and defining the blocked applications as “unknown-tcp”, “unknown-udp”, and “unknown-p2p”.

Use SSL (instead of UDP or TCP) to encrypt and secure the data sent to a syslog server so data isn't sent as clear text and therefore isn't readable in transit.

Applications can be tagged as ‘sanctioned’ to help differentiate sanctioned SaaS applications from Unsanctioned SaaS applications traffic. The SaaS Application Usage Report helps you understand both the sanctioned and unsanctioned SaaS application traffic on your network, including bandwidth consumption, application sub-category classification, user traffic classification, WildFire analysis, and if any malware was identified.

If you "allow" traffic from a URL category, the firewall doesn't log that traffic, so you have no visibility into traffic to websites in that URL category. For URL categories you don't block, set the Site Access action to "alert" to log traffic to all websites.

Protect SSL/TLS connections for traffic you don’t decrypt by enabling server verification checks to block sessions with expired certificates and untrusted issuers. You can’t see traffic you don’t decrypt, but you can prevent questionable connections.

Configuring a unique hostname for each networking device such as firewalls in the environment helps you understand which device you’re managing or working on.

The update server is the Palo Alto Networks server from which the firewall and Panorama fetch content, software, and other updates. Check the Verify Update Server Identity option to validate that the server has an SSL certificate signed by a trusted authority.

Using a user identification Include List in each zone includes only the IP addresses or subnets that are relevant to the particular zone. The Include List allow lists users whose IP addresses or subnets are defined in the list, which reduces the zone’s attack surface by restricting who can access the zone. You can specify an IP address or subnet, or select it from the defined Addresses and Address Groups (Objects > Addresses, Objects > Address Groups).

Ensure secure communication between firewall and User-ID or Terminal Server agents. The certificate profile is configured making sure both the ends trust each other to establish secure communication.

Client probing on high-security networks can generate a large amount of traffic, and, if misconfigured, can pose a security threat. Because probing trusts the data from the endpoint, it isn’t recommended for obtaining User-ID information. If you use the XML API to map users or the User-ID agent to parse security event logs or syslog messages, Palo Alto Networks recommends that you don’t enable probing. If you enable probing, don’t enable it on external untrusted interfaces. If you enable User-ID and WMI probing on an external untrusted zone (such as the internet), an attacker could send a probe outside of your protected network. This could result in a disclosure of the User-ID agent service account name, domain name, and encrypted password hash, which could allow an attacker to gain unauthorized access to protected resources.

Different threat severities require different actions in Vulnerability Protection profiles. Set the Action for informational and low Severity events to "default". Default takes the default PAN-OS action for the threat. Don’t set the Severity to "any" because you have to set the Action to "reset-both" to handle critical, high, and medium severity signatures. Instead, assign specific actions to each Severity level.

The WildFire cloud (and the on-premises WildFire private cloud) analyzes new files that the firewall hasn’t seen before. The default WildFire Analysis profile sends all new files for all applications to WildFire for analysis and inspection. WildFire then reaches a verdict and classifies the file as malicious, grayware, phishing, or benign. The Applications and File Types settings must be “any” to be sent to WildFire. Run the CLI command “show WildFire statistics” to identify error codes or logs for files forwarded to the cloud for inspection.

Download and install WildFire content updates every minute to provide protection against new threats before they become widespread (WildFire subscription required). The firewall only downloads content when new content is available.

Traffic sourced from a proxy server (client requests come from behind the proxy server) usually gives the proxy server IP as the source IP address instead of the client IP address, so users can't be identified using User-ID. Enabling this option pulls the original client IP address from the X-Forwarded-For field in the header so User-ID can match it to the username and apply the correct Security policy to the traffic, and so the original client IP address appears in the logs.

For each zone, Zone Protection profiles provide extended protection against IP floods, reconnaissance, packet-based attacks, and non-IP protocols. Set appropriate Flood Protection thresholds for each zone, based on normal and peak connections-per-second (CPS) measurements for the zone and its interfaces, to alarm and activate network and firewall resource protection against SYN, UDP, ICMP, ICMPv6, and Other IP flood attacks. Enable Reconnaissance Protection to prevent port scans and host sweeps probing for open ports. Enable Packet Based Attack Protection to check packet headers and inspect for abnormal characteristics and options. Enable Protocol Protection to defend against non-IP protocols in Layer 2 and Vwire zones based on including (allowlisting) protocols or excluding (blacklisting) protocols. It’s best to allow (allow list) only the protocols in use on your network.