PAN-OS: Configuring SSH Proxy Decryption

What is SSH Proxy Decryption?

SSH Proxy is the Palo Alto Networks feature for decrypting and inspecting Secure Shell (SSH) traffic. While SSH provides essential confidentiality for remote administration and file transfers (like SCP and SFTP), its encrypted nature creates a blind spot for security inspection. Malicious actors can abuse SSH tunnels for:

• Command and Control (C2) communication.
• Data exfiltration.
• Tunneling other protocols or malware.
• Unauthorized access or lateral movement.

By enabling SSH Proxy decryption, the firewall can gain visibility into the SSH payload, allowing App-ID to potentially identify tunneled applications and enabling Threat Prevention (Anti-Spyware, Vulnerability Protection), File Blocking , and potentially Data Filtering profiles to inspect the content within SSH sessions.

This is distinct from SSL/TLS decryption, targeting port 22 (or other ports running SSH) specifically.

Similar to SSL Forward Proxy, SSH Proxy operates as a Man-in-the-Middle (MITM):

1. Client Initiates SSH Connection: An internal client initiates an SSH connection to an external (or internal) server.
2. Firewall Intercepts: A Decryption Policy rule configured for SSH Proxy matches the session (based on port, usually TCP/22).
3. Firewall Connects to Server: The firewall establishes its own separate SSH connection to the actual destination server. During this, it receives and typically validates the *real* server's public host key.
4. Firewall Presents its Key to Client: The firewall presents its *own* unique SSH public host key (typically generated on-the-fly or a pre-generated dedicated key) to the initiating client, essentially pretending to be the destination server.
5. Client Verification (CRITICAL STEP): The SSH client compares the public key presented by the firewall against its `known_hosts` file (or prompts the user if it's the first connection).
   • If Key is Accepted/Trusted: The user explicitly accepts the firewall's key (or strict host key checking is disabled), the SSH session is established between the client and the *firewall*.
   • If Key is Rejected: The client's strict host key checking detects a mismatch with a previously known key for that destination, or the user refuses to accept the new key. The connection fails, often with a "MAN-IN-THE-MIDDLE ATTACK" warning.
6. Decryption and Inspection: With two separate SSH sessions active (Client<->Firewall and Firewall<->Server), the firewall decrypts traffic from the client, inspects the payload using enabled Security Profiles, re-encrypts it using the session key from the connection to the real server, and forwards it (and vice-versa).

The firewall essentially acts as an SSH proxy server, terminating the client's connection and initiating a new one to the destination server.

• Firewall SSH Key Pair (Implicit): The firewall manages its own key pairs used for proxying SSH sessions. While you don't typically import external server keys like with SSL Inbound, the firewall needs its cryptographic components functioning.
• Client Trust Management Strategy: A plan for how clients will handle the firewall's presented host key (e.g., disabling strict host key checking on clients - less secure, pre-populating known_hosts, user training - often problematic).
• Supporting Network Configuration: Interfaces, Zones, Routing.
• Security Policy: Rule(s) allowing the underlying SSH traffic (App-ID `ssh` on `service-ssh` or custom port).

1. Configure SSH Proxy Settings in Decryption Profile:

   • GUI Path: Objects > Decryption > Decryption Profile
   • Click Add or edit an existing profile. Name it (e.g., `SSH-Proxy-Inspect-Profile`).
   • Navigate to the SSH Proxy tab.
   • Configure Failure Checks:
     • Check `Block sessions with unsupported versions` to prevent use of weak/legacy SSH versions.
     • Check `Block sessions with unsupported algorithms` to enforce strong key exchange, encryption, and MAC algorithms.
   • Click OK.

   These settings ensure only relatively secure SSH parameters are allowed through the decrypted session.

2. Create a Decryption Policy Rule:

   • GUI Path: Policies > Decryption
   • Click Add .
   • Name: e.g., `Decrypt-Outbound-SSH`.
   • Source Tab: Define Source Zone(s) (e.g., `Trust`), Address(es), User(s).
   • Destination Tab: Define Destination Zone(s) (e.g., `Untrust`), Address(es).
   • Service/URL Category Tab:
     • Service: Select service-ssh (for TCP/22) or a custom service object if SSH runs on a non-standard port.
     • URL Category: Not applicable to SSH Proxy.
   • Options Tab (Crucial):
     • Action: Select `Decrypt` .
     • Type: Select `SSH Proxy` .
     • Decryption Profile: Select the Decryption Profile configured in Step 1 (e.g., `SSH-Proxy-Inspect-Profile`).
   • Click OK.
   • Place this rule appropriately in the Decryption policy list (top-down processing applies). Consider placing "No Decrypt" rules above it for specific SSH destinations that must not be proxied.

3. Configure Supporting Security Policy & Profiles:

   • Ensure a Security Policy rule exists ( Policies > Security ) that allows the SSH traffic (e.g., Source `Trust`, Dest `Untrust`, Application `ssh` , Service `service-ssh` , Action `Allow`).
   • Crucially, attach relevant Security Profiles (Anti-Spyware, Vulnerability Protection, File Blocking) to this Security Policy rule. The inspection engines operate on the decrypted content based on the Security Policy context.

4. Address Client Host Key Checking: (External Step / Critical Consideration)

   • Decide how client machines will handle the firewall presenting its proxy key instead of the real server's key. Options include:
     • Disabling strict host key checking on clients (reduces security).
     • Pre-populating client `known_hosts` files with the firewall's proxy key associated with proxied destinations (complex to manage).
     • Training users to manually accept the new key (prone to error, teaches bad habits).
     • Using SSH Certificate Authentication (more advanced, bypasses traditional host key checks if configured correctly).
   • Failure to address this will likely result in connection failures and user complaints.

5. Commit Changes:

   Commit the configuration to the firewall.

• Threat Prevention within SSH: Allows Anti-Spyware (detecting C2 over SSH) and Vulnerability Protection (detecting exploits targeting SSH servers or clients via proxied connections) to inspect the decrypted payload.
• File Blocking within SSH: Enables File Blocking profiles to control file transfers using SCP or SFTP protocols tunneled over the decrypted SSH session.
• Limited Application Visibility: While it decrypts SSH, identifying specific applications *tunneled* within SSH is often still challenging for App-ID unless the application has very distinct patterns in the decrypted stream. The primary App-ID will remain `ssh`.
• Policy Enforcement: Enforce policies based on content within SSH, block malicious commands or file transfers.

Caveats, Gotchas, and Considerations

For the PCNSE exam, regarding SSH Proxy:

• Understand its purpose: Gaining visibility into encrypted SSH traffic for inspection.
• Know the MITM mechanism: Firewall acts as a proxy using its own host key.
• Recognize the critical client-side challenge: Handling host key checking (`known_hosts`, user acceptance).
• Differentiate it from SSL decryption.
• Identify the configuration location: Decryption Policy (Type: `SSH Proxy`) and the SSH Proxy tab in Decryption Profiles .
• Understand that inspection (Threat, File Blocking) relies on Security Profiles applied to the Security Policy rule allowing `ssh`.
• Be aware of performance considerations and potential compatibility issues.