Create the Data Center Best Practice Decryption Profiles

Decryption Profiles define the SSL Protocol settings the firewall accepts so you can protect against vulnerable, weak protocols and algorithms.
Decryption profiles specify how the firewall checks decrypted traffic and also traffic that you either can’t or choose not to decrypt. The firewall checks protocols, server certificates, session characteristics, and ciphers (key exchange algorithms, encryption algorithms, and authentication algorithms). You apply Decryption profiles (
Objects
Decryption Profile
) to Decryption policy rules (
Policies
Decryption
). Decryption policy rules define the traffic to check using the source, destination, service category, and URL category as match criteria so that you have granular control over the traffic to which you apply a Decryption profile.
To decrypt outbound traffic, the firewall acts as an SSL forward proxy device between the internal client and the external server. To inspect inbound traffic, the firewall makes a copy of the incoming session traffic and decrypts and inspects the copy.
  1. Configure the firewall to perform CRL/OCSP checks to ensure that certificates presented during SSL decryption are valid.
  2. Configure the
    SSL Decryption
    SSL Protocol Settings
    to block vulnerable SSL/TLS versions such as TLS 1.0 and SSLv3, and to avoid weak encryption algorithms such as RC4 and 3DES, and weak authentication algorithms such as MD5 and SHA1.
    SSL Protocol Settings apply to all decrypted traffic.
    ssl-protocol-settings-forward-proxy-best-practice.png
    Set the
    Min Version
    to
    TLSv1.2
    to provide the strongest security—business sites that value security support TLSv1.2. If a site (or a category of sites) only supports weaker ciphers, review the site and determine if it really houses a legitimate business application. If it does, make an exception for only that site by configuring a Decryption profile with a
    Min Version
    that matches the strongest cipher the site supports and applying it to a Decryption policy rule that limits the weak cipher to only the site or sites in question. If the site doesn’t house a legitimate business application, don’t weaken your security posture to support the site—weak protocols (and ciphers) contain known vulnerabilities that attackers can exploit. If the site belongs to a category of sites that you don’t need for business purposes, use URL Filtering to block access to the entire category. Don’t support weak encryption or authentication algorithms unless you must do so to support important legacy sites.
    Set the
    Max Version
    to
    Max
    rather than to a particular version so that as the protocols improve, the firewall automatically supports the newest and best protocols. Whether you intend to attach a Decryption profile to a Decryption policy rule that governs inbound (SSL Inbound Inspection) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.
  3. Configure the
    SSL Decryption
    SSL Forward Proxy
    settings for outbound traffic to block exceptions during SSL negotiation and block sessions that can’t be decrypted.
    In some cases, the best practice settings depend on your company’s security compliance rules. Apply the SSL Forward Proxy Decryption profile to security policy rules that control outbound traffic.
    ssl-forward-proxy-best-practice-80.png
    Block exceptions during SSL negotiation and block sessions that can’t be decrypted.
    • Server Certificate Verification
      —Whether to check the
      Block sessions on certificate status check timeout
      box depends on your company’s security compliance stance because it’s a tradeoff between tighter security and a better user experience. Certificate status verification examines the Certificate Revocation List (CRL) on a revocation server or uses Online Certificate Status Protocol (OCSP) to find out if the issuing CA has revoked the certificate and the certificate should not be trusted. However, revocation servers can be slow to respond, which can cause the session to timeout and the firewall to block the session even though the certificate may be valid. If you
      Block sessions on certificate status check timeout
      and the revocation server is slow to respond, you can use
      Device
      Setup
      Session
      Decryption Settings
      and click
      Certificate Revocation Checking
      to change the default timeout value of five seconds to another value.
      certificate-revocation-checking.png
      Enable both CRL and OCSP certificate revocation checking because server certificates can contain the CRL URL in the CRL Distribution Point (CDP) extension or the OCSP URL in the Authority Information Access (AIA) certificate extension.
      Block all other server certificate verification exceptions.
    • Unsupported Mode Checks
      —If you don’t block sessions with unsupported versions and unsupported cipher suites, then users receive a warning message that they can click through to reach the risky website. The reason you configure tight SSL Protocol Settings is to block and protect you from servers that use these weak (risky) protocol versions and algorithms. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obfuscate their activities.
      Block sessions with client authentication
      enables you to choose whether to allow or block sessions that use client authentication. Although server authentication can be the only authentication used to establish a session, some sites use mutual authentication, where both the server and the client authenticate to establish a session. Client authentication using an X.509 Digital Certificate is similar to server authentication in that both methods use a digital certificate issued by a trusted Certificate Authority to authenticate a session. The client certificate acts as a digital identifier for the client, resides on the client device, and can’t be ported to other devices. However, client authentication prevents the firewall from decrypting the session because the firewall needs both the client and server certificates to perform bi-directional decryption, but the firewall only knows the server certificate. This breaks decryption for client authentication sessions.
      If you don’t check
      Block sessions with client authentication
      , when the firewall attempts to decrypt a session that uses client authentication, the firewall allows the session and adds an entry in its local decrypt exclude cache that contains the server URL/IP address, the application, and the Decryption profile. Entries remain in the cache for 12 hours and then age out. If the same user or a different user attempts to access the serer within 12 hours using client authentication, the firewall matches the session to the decrypt exclude cache entry, does not attempt to decrypt the traffic, and allows the encrypted session.
      If the exclude cache becomes full, the firewall purges the oldest entries as new entries arrive. If you change the Decryption policy or profile, the firewall flushes the exclude cache because changing the policy or profile can change the classification outcome of the session.
      If you check
      Block sessions with client authentication
      , the firewall blocks sessions that use client authentication, with the exception of sessions from sites on the SSL Decryption Exclusion list (
      Device
      Certificate Management
      SSL Decryption Exclusion
      ).
      You may need to allow traffic on your network from other sites that use client authentication in addition to the Predefined sites on the SSL Decryption Exclusion list. Create a Decryption profile that allows sessions with client authentication. Add it to a Decryption policy rule that applies only to the server(s) that house the application. To increase security even more, you can require Multi-Factor Authentication to complete the user login process.
      For all other traffic, apply the Decryption profile that blocks sessions with client authentication.
    • Failure Checks
      —If you don’t
      Block sessions if resources not available
      , the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. Whether to implement failure checks depends on your company’s security compliance stance and the importance to your business of the user experience, weighed against tighter security.
      If you use a Hardware Security Module (HSM) to store your private keys, whether you check
      Block sessions if HSM not available
      depends on your compliance rules about where the private key must come from and how you want to handle encrypted traffic if the HSM isn’t available. For example, if your company mandates the use of an HSM for private key signing, then block sessions if the HSM isn’t available. However, if your company is less strict about this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is down, the firewall can process decryption for sites for which it has cached the response from the HSM, but not for other sites.) The best practice in this case depends on your company’s policies. If the HSM is critical to your business, run the HSM in a high-availability (HA) pair (PAN-OS 8.0 supports two members in an HSM HA pair).
  4. Configure the
    SSL Decryption
    SSL Inbound Inspection
    settings to inspect traffic from an external client to your internal servers and block suspicious sessions.
    Apply the SSL Inbound Inspection Decryption profile to security policy rules that control inbound traffic.
    ssl-inbound-inspection-best-practice.png
    • Unsupported Mode Checks
      —The firewall can’t decrypt session versions and ciphers that the firewall doesn’t support. To prevent attackers from using unsupported versions and ciphers to sneak onto the network, block session versions and cipher suites that the firewall doesn’t support. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obscure their activities.
      On the server, enable only the ciphers that you support on the firewall. Ensuring this compatibility makes the negotiation between the client and the server smoother.
    • Failure Checks
      —If you don’t
      Block sessions if resources not available
      , the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. Whether to implement failure checks depends on your company’s security compliance stance and the importance to your business of the user experience, weighed against tighter security.
      If you use a Hardware Security Module (HSM) to store your private keys, whether you check
      Block sessions if HSM not available
      depends on your compliance rules about where the private key must come from and how you want to handle encrypted traffic if the HSM isn’t available. For example, if your company mandates the use of an HSM for private key signing, then block sessions if the HSM isn’t available. However, if your company is less strict about this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is down, the firewall can process decryption for sites for which it has cached the response from the HSM, but not for other sites.) The best practice in this case depends on your company’s policies. If the HSM is critical to your business, run the HSM in a high-availability (HA) pair (PAN-OS 8.0 supports two members in an HSM HA pair).
  5. For SSH traffic, configure SSH Proxy Decryption profile settings.
    SSH Decryption allows normally routed SSH traffic and denies SSH tunneling (SSH port forwarding) traffic, but doesn’t perform content or threat inspection on the SSH traffic. SSH tunneling sessions can tunnel X11 Windows packets and TCP packets. One SSH connection may contain multiple channels. When you apply an SSH Decryption profile to traffic, for each channel in the connection, the firewall examines the App-ID of the traffic and identifies the channel type. The channel type can be:
    • session
    • X11
    • forwarded-tcpip
    • direct-tcpip
    When the channel type is session, the firewall identifies the traffic as allowed SSH traffic such as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the firewall identifies the traffic as SSH tunneling traffic and blocks it.
    For most user groups, you probably won’t allow SSH traffic in the data center. SSH is usually used for remote access to servers, which is not a capability you want most users to have because it places your data center servers at greater risk, for access to Linux servers, and for file transfers. You can’t decrypt SSH traffic, so anyone who uses SSH to access data center resources must be trusted—and even so, all of the threat profiles should be attached to any rule that allows SSH access to scan for malware, viruses, spyware, etc.
    An example use case for SSH is IT personnel who manage and maintain data center servers and use SSH for remote access.
    ssh-proxy-best-practice-profile.png
    • Unsupported Mode Checks
      —The firewall can’t decrypt session versions and ciphers that the firewall doesn’t support and unsupported versions and ciphers may be vulnerable. To prevent attackers from using unsupported versions and ciphers to sneak onto the network, block session versions and cipher suites that the firewall doesn’t support. In addition, blocking sessions with unsupported mode checks protects you from malicious backdoors and other threats that use custom and non-standard encryption to obscure their activities.
    • Failure Checks
      —If you don’t
      Block sessions if resources not available
      , the risk is that a lack of processing resources may allow potentially dangerous connections. If you block sessions for which resources aren’t available, it may affect the user experience. Whether to implement failure checks depends on your company’s security compliance stance and the importance to your business of the user experience, weighed against tighter security.
  6. For traffic that you choose not to decrypt, configure the
    No Decryption
    settings to block encrypted sessions destined for sites with expired certificates or untrusted issuers.
    Apply the No Decryption profile only to traffic that you choose not to decrypt because of regulations or compliance rules, not to traffic that can’t be decrypted because of technical reasons, such as a pinned certificate. The best practice is to decrypt as much data center traffic as possible.
    no-decryption-forward-proxy-best-practice.png

Related Documentation