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
(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 details on 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.