SSH Proxy decryption decrypts inbound and outbound SSH sessions and ensures that attackers can’t use SSH to tunnel potentially malicious applications and content.
In an SSH Proxy configuration, the firewall resides between a client and a server. SSH Proxy enables the firewall to decrypt inbound and outbound SSH connections and ensures that attackers don’t use SSH to tunnel unwanted applications and content. SSH decryption does not require certificates and the firewall automatically generates the key used for SSH decryption when the firewall boots up. During the boot up process, the firewall checks if there is an existing key. If not, the firewall generates a key. The firewall uses the key to decrypt SSH sessions for all virtual systems configured on the firewall and all SSH v2 sessions.
SSH allows tunneling, which can hide malicious traffic from decryption. The firewall can’t decrypt traffic inside an SSH tunnel. You can block all SSH tunnel traffic by configuring a Security policy rule for the application
Deny(along with a Security policy rule to allow traffic from the
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:
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.
Limit SSH use to administrators who need to manage network devices, log all SSH traffic, and consider configuring Multi-Factor Authentication to help ensure that only legitimate users can use SSH to access devices, which reduces the attack surface.
The following figure shows how SSH Proxy decryption works. See Configure SSH Proxy for how to enable SSH Proxy decryption.
When the client sends an SSH request to the server to initiate a session, the firewall intercepts the request and forwards it to the server. The firewall then intercepts the server response and forwards it to the client. This establishes two separate SSH tunnels, one between the firewall and the client and one between the firewall and the server, with firewall functioning as a proxy. As traffic flows between the client and the server, the firewall checks whether the SSH traffic is being routed normally or if it is using SSH tunneling (port forwarding). The firewall doesn’t perform content and threat inspection on SSH tunnels; however, if the firewall identifies SSH tunnels, it blocks the SSH tunneled traffic and restricts the traffic according to configured security policies.