About maurisy

Summary This document discusses the configuration steps for applying a vulnerability protection security profile to GlobalProtect interface, in order to protect the GlobalProtect services from attacks using published product security vulnerabilities.   Background In customer deployments that use GlobalProtect for remote access, customers often configure and apply security profiles such as vulnerability protection to network traffic between VPN clients and internal network zones.    There are also certain circumstances where a customer may want to apply a vulnerability protection profile to traffic hitting the GlobalProtect portal and gateway services, which are served by the firewall and not just traffic going through the firewall into the network. For example, there may be situations where a customer wants to block attempted attacks before they are able to upgrade PAN-OS to a patched version. This can be accomplished by applying a properly configured vulnerability protection profile to a firewall rule that is configured to apply to traffic hitting the GlobalProtect portal and gateway services hosted by the firewall.   Note: This document uses CVE-2019-1579 as an example in this how-to guide, where vulnerability protection signature #54582 was released in content version 8173*, released on 7/18/2019 to detect and prevent attempted attacks. The vulnerability affected GlobalProtect portal and gateway services. This document assumes that the firewall is already configured and used as a GlobalProtect portal and/or gateway service.   *Note: Additional protections for CVE-2019-1579 were released with Content version 8180   Configuration Steps:   Step 1: Ensure that you have the latest content update installed that includes the relevant threat protection Make sure the content version that you are running includes the threat signature(s) that need to be applied to the GlobalProtect interfaces in order to block the attack. In the example used in this document, the minimum content version required is 8173, which was released on 7/18/2019.   Step 2: Determine the correct zone for GP portal and GP gateway If a GP Portal is configured, go to Network > GlobalProtect > Portals and find the portal and associated interface. In the example below, you will see we are using GP-Auto-Portal1 as an example. The interface that the portal connects to is shown to be ethernet1/1.     Determine the associated zone for the GlobalProtect portal that includes the interface found in the previous step. Go to Network > Interfaces > Ethernet. In the example below, we can see that interface ethernet1/1 is in GP-untrust zone.     If a GlobalProtect gateway is configured, go to Network > GlobalProtect > Gateways and find the gateway and associated interface. In the example below, you will see we are using GP-GW1 as an example. The interface is loopback.1.     Determine the zone associated with the GlobalProtect gateway. Go to Network > Interfaces > Loopback. We can see that interface loopback.1 is also in GP-untrust zone. Now we know the zone for the portal and gateway, which we need to protect with a vulnerability protection profile.     Step 3: Modify or Create a New Vulnerability Protection Profile  Configure a new or existing vulnerability profile that is specifically configured to block the relevant threat impacting the GlobalProtect services. Go to Objects > Security Profiles > Vulnerability Protection. We recommend as a best practice to simply set the blocking action of “reset-server” for all critical severity signature triggers.     Alternatively, you can add an exception specifically for the relevant signature (#54582 in this case) to configure the reset-server action for this signature when it triggers (see below).       Step 4: Create a firewall security rule After modifying or creating a new vulnerability protection object, create a security rule to apply the vulnerability protection profile to. Go to Policies > Security. Create a new policy. In this example, we name it “block_gp_vulnerability.” The source zone should be “any” and the destination zone is the GlobalProtect gateway and/or GlobalProtect portal zones we found in step 1. Assign to this rule the Vulnerability Protection Profile you modified or created in step 2.       Step 5: Commit Commit the changes to apply the new Vulnerability Protection Profile to the Security Rule protecting the GP Portal and/or Gateway.  Any attempted attacks against the GlobalProtect services that attempt to use this specific vulnerability will be blocked and logged in the threat log. ... View more

Summary of Sweet32    Security researchers at INRIA recently published a paper that describes how an attacker could levy an attack against information encrypted using older 64-bit block ciphers, such as 3DES and Blowfish to successfully recover plaintext. To be successful, the attacker would need to monitor a long-lived HTTPS session (the researcher’s proof of concept required a single 3DES HTTPS session be continuously monitored over two days) and be able to exploit a separate cross-site scripting vulnerability (XSS).   These attacks are not effective against modern encryption ciphers like AES and Elliptic Curve Digital Signature Algorithm (ECDSA).   We are not aware of any active attacks against this issue at this time.   Palo Alto Networks customers are only at risk in limited circumstances in the event of a “downgrade attack” which would force Palo Alto Networks systems to use 3DES as an encryption cipher of last resort. Customers who are concerned can prevent these “downgrade attacks” by implementing the workarounds outlined below.     Impact on PAN-OS   Impact on SSL/TLS services on the firewall PAN-OS system software supports 3DES block cipher as part of the cipher suite list negotiated over SSL/TLS connections terminating on the firewall. These sessions are IP layer 3 SSL services offered by the firewall, such as administrative web access for device management, GlobalProtect portals/gateways and captive portal. Similar to other web servers, PAN-OS maintains an internal cipher preference list. The 3DES cipher is not included in the top priority ciphers in the list since we consider it a weak cipher that will generally not be negotiated by the server. However, a malicious client can offer only the affected block ciphers as part of the client hello message forcing the server to negotiate 3DES.   Another aspect is the duration of the encrypted session that allows for a successful attack. The underlying assumption is that the same set of keys are used for the entirety of the connection.   How to secure SSL access   Palo Alto Networks customers can mitigate the Sweet32 attack by deploying ECDSA certificates and locking down the protocol version to TLSv1.2 for the various SSL/TLS services on the firewall. This ensures that an ECDSA-based cipher suite is negotiated by the server. The 3DES encryption algorithm are supported with RSA authentication. Setting an ECDSA certificate  eliminates the possibility of negotiating the 3DES cipher.   Moreover, elliptic curve ciphers have a built in rekeying mechanism that would kick in sooner than the lifetime of the encrypted session, unlike RSA where rekeying can vary with specific SSL stack implementation. This ensures that a long-lived EC-based SSL session is not susceptible to the Sweet32 issue.   Steps for securing the SSL access:   Generate/import an ECDSA server certificate on the firewall Create an SSL/TLS service profile with Min and Max versions set to TLSv1.2 Reference the ECDSA certificate in the service profile Apply the profile(s) to the various L3 SSL/TLS services   Below is a screen capture for securing the web interface admin access of the firewall:     Impact on decrypted SSL traffic through the firewall   Palo Alto Networks customers who have deployed SSL decryption on the internet perimeter (Outbound) or in front of a data center server farm can secure their user population and/or corporate assets against a potential Sweet32 attack.   PAN-OS allows for cipher control on decrypted data traffic flowing through the firewall. The following steps can be used to prevent a potential Sweet32 attack on decrypted data traffic:   Unselect the 3DES cipher in the Objects->Decryption Profile->SSL Protocol Settings->Encryption Algorithms Apply the decryption profile to your decryption policies Below is a screen capture of the decryption profile that can be applied to Outbound and Inbound decryption policies:     Impact on SSH administrative CLI access   SSH tunnels are generally used for management access that carry less data at very low data rates. If an SSH connection would have a life size of 32GB or greater of data. An administrator can periodically reset the SSH keys for the management access via a simple expect or tcl script.   The following debug command can be used to reset the SSH keys: fwadmin@PA-200> debug system ssh-key-reset management   Impact on decrypted SSH access through the firewall   PAN-OS does not support DES/3DES ciphers while performing SSH proxy on management SSH sessions to secured assets behind the firewall. Such a traffic will not be affected by a potential Sweet32 attack.   Impact on IPSec and IKE   Palo Alto Networks next-generation firewalls are deployed in varied environments with a mix of devices supporting older and current IPSec crypto algorithms. PAN-OS supports DES and 3DES ciphers to maintain backward compatibility with such legacy systems and also support them as an IPSec peer.   PAN-OS provides a flexible way to configure each aspect of IKE and IPSec crypto. An administrator has to explicitly select encryption ciphers that need to be negotiated with the peer IKE gateway and IPSec tunnel end point.   This can be achieved by deselecting DES or 3DES algorithms in the IKE and IPSec crypto profile   Below is a snapshot of the crypto profiles that can be used to prevent a Sweet32 attack:     Note: For customers who do not want to remove DES and 3DES as part of phase 1 and phase 2 negotiation, PAN-OS reduces the chances of a potential Sweet32 attack as it rekeys the connection based on the data transferred.   An administrator can set the life size of an IPSec connection by setting the life size as 30GB (or by using a value below 32GB). Here is CLI command that can be used to achieve this:   fwadmin@PA-200# set network ike crypto-profiles ipsec-crypto-profiles corp-ike lifesize > gb       specify lifesize in gigabytes(GB) > kb       specify lifesize in kilobytes(KB) > mb       specify lifesize in megabytes(MB) > tb       specify lifesize in terabytes(TB)   <Enter> Finish input   Should you have any questions or need assistance with implementing the steps outlined above, please don’t hesitate to contact our support team at https://support.paloaltonetworks.com.   The Palo Alto Networks Support Team ... View more

Application and Threat Content version 571 was removed from the Palo Alto Networks support site at approximately 0230 PM PST on 24-MAR-2016, after discovering an issue with this content update and Panorama stability related to the Correlation Objects feature. In the interim, customers who have installed content version 571 and use Panorama for device management are advised to roll back to content 570 or disable the "Beacon Detection - Dynamic DNS” (ID-6007) and “Beacon Detection - Heuristics” (ID-6005) correlation objects on the Monitor—>Correlations objects page. Correlation Objects work specifically on the PA-3000, PA-5000, PA-7000 series and PAN-OS 7.0+ and VM or M-Series Panorama 7.0+.   Palo Alto Networks is working to resolve this, and will issue a notification when a remediated version of Application and Threat Content is made available. Please subscribe to this document to receive updates.     ... View more