Fortinet black logo

Handbook

SSL/SSH inspection

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:314945
Download PDF

SSL/SSH inspection

While the profile configuration for SSL/SSH Inspection is found in the Security Profiles section it is enabled in the firewall policy by enabling any of the security profiles. Choosing which of the SSL/SSH Inspection profiles is all that can really be done in the policy.

The reason for having this inspection as part of the policy is the wide spread use of encryption by both legitimate and malicious actors. The legitimate users of the Internet use encryption to hide their information from snooping bad guy but the bad guys use encryption to hide their malicious content from being scanned for viruses and other malicious code by security devices.

By using the correct SSL certificates, the FortiGate can open up encrypted traffic and inspect it for malicious content that would otherwise make it past the other profiles because they couldn't read the encrypted traffic.

There are two basic types of inspection:

  • Certificate inspection, which only looks at the certificate that encrypted the packets to make sure that it is a recognized and valid certificate.
  • Full inspection, or deep inspection, that looks at all of the content of the packet. While more thorough, it also takes up more resources to perform.

HTTP Strict Transport Security (HSTS) Protocol

HSTS is a protocol used by Google and other web browsers to prevent man-in-the-middle attacks that use SSL stripping, where attackers try to force a client to only use HTTP in its communication. It also prevents users from circumventing security warnings related to an invalid certificate and proceeding to the website.

When performing deep inspection, the FortiGate serves as an intermediary to connect to the HTTPS server. It decrypts and inspects the traffic, then forwards it to the client if no threat is found. Before forwarding the traffic, the FortiGate re-encrypts the content with a certificate that is signed with its own CA certificate configured in the SSL/SSH profile. If the client trusts the CA used by the FortiGate to sign the certificate, then the connection succeeds. If the client does not trust the CA, the browser displays a warning with no option to circumvent the warning and proceed.

It is important for each endpoint to have a valid certificate chain back to the trusted root CA in its certificate store when deploying SSL deep inspection.

SSH MITM deep inspection

Due to an increase, in recent years of vulnerabilities discovered in the SSH protocol, protections have been incorporated into FortiOS's Intrusion Prevention System (IPS) engine that will aid in protecting against malicious activity coming through the FortiGate against SSH access points. In addition to the protections offered by IPS, additional settings and functionality have been added to protect against man-in-the-middle (MITM) attacks that use SSH as the attack vector.

These protections include support for comprehensive security controls on SSH MITM deep inspections:

  • SSH filter profile to control SSH tunnel types and filtering on SSH shell commands.
  • SSH proxy policy that can apply a proxy firewall policy or firewall policy using SSH inspection, with user authentication to SSH sessions.
  • Support for SSH tunnel policy access control for TCP/IP port forwarding traffic tunneled through SSH proxy. This allows IPS scanning to be applied to the tunneled traffic.
  • Support the use of SSH trust status to detect and prevent SSH-based MITM attacks.

Support SSH proxy policy for SSH sessions

Policy check

To enable SSH proxy-policy or SSH tunnel-policy, ssh-policy-check or ssh-tun-policy-check must be enabled under ssl-ssh-profile for the corresponding firewall policy.

config firewall ssl-ssh-profile

edit <name>

config ssh

set ssh-policy-check [disable|enable]

set ssh-tun-policy-check [disable|enable]

end

end

SSH proxy option

Set the proxy type to ssh in config firewall proxy-policy.

config firewall proxy-policy

edit <pol-id>

set proxy ssh

set action {accept|deny}

set utm-status enable

set ssh-filter-profile <profile_name>

end

Authentication for SSH

When user or user-group is set in SSH proxy policy, firewall authentication can be implemented for SSH proxy traffic.

config authentication rule

edit <name>

set protocol ssh

end

Basic authentication scheme:

config authentication scheme

edit "ssh-active"

set method basic

set user-database "local" #or LDAP server

end

note icon

Under authentication for SSH, with basic authentication scheme, the client is expected to input username/password in the format of:

  • <firewall username>:<server username>
  • <firewall password>:<server password>
SSH-publickey authentication scheme:

config authentication scheme

edit "ssh-pkey"

set method ssh-publickey

set user-database "local"

set ssh-ca "server-ca"

end

note icon

The user name is embedded in ssh-publickey. The user group information will be retrieved if the public key is validated by CA.

FortiOS currently only supports validation by using CA. The CA needs to be configured under config firewall ssh local-ca.

Private-key is not required for client public-key authentication. Once the client offers the public-key signed by the set CA will be authenticated.

Both basic and SSH-publickey authentication scheme:

config authentication scheme

edit "ssh-pkey"

set method basic ssh-publickey

set user-database "local"

set ssh-ca "server-ca"

end

Support SSH tunnel policy to do access control for TCP/IP port forwarding traffic.
Add a proxy type ssh-tunnel into config firewall proxy-policy

config firewall proxy-policy

edit <pol-id>

set proxy ssh-tunnel

set action {accept | deny}

set utm-status enable

end

The feature supports allowing or denying based on the IPS sensor/app-control applied to the traffic.

config firewall proxy-policy

edit <pol-id>

set ips-sensor <sensor_profile_name>

set application-list <application_control_list>

end

Support SSH trust to detect and prevent from SSH MITM attacks
Define trusted SSH host key for specific SSH server

config firewall ssh host-key

edit <name>

set status {trusted|revoked}

set type {RSA|DSS|ECDSA}

set nid <NID of ECDSA key>

set ip <ip>

set port <port>

set hostname <name>

set public-key <host key>

end

Define trusted/untrusted CAs for host key signing.

Any host key signed by trust CA is trusted unless the host key is revoked.

config firewall ssh local-ca

edit <name>

set password <passwd>

set public-key <public key>

set private-key <private key>

set source {built-in|user}

end

note icon
  • The system creates two built-in SSH CAs:
  • Fortinet_SSH_CA
  • Fortinet_SSH_CA_Untrusted.
  • The CAs are used to re-sign a server host key with local host-key using trusted/untrusted CA when the server host key is trusted or untrusted.
Define local hostkey templates for trusted re-signing.

By default, the local hostkey templates are generated automatically.

config firewall ssh local-key

edit <name>

set status [trusted|revoked]

set type [RSA|DSA|ECDSA|ED25519|RSA-CA|DSA-CA|ECDSA-CA|ED25519-CA]

set nid <NID of ECDSA key>

set ip <ip>

set port <port>

set hostname <name>

set password <passwd>

set public-key <public key>

set private-key <private key>

set source {build-in|user}

end

Per VDOM SSH settings

config firewall ssh setting

set caname <trusted-ca>

set untrusted-caname <untrusted-ca>

set hostkey-rsa <hostkey-rsa>

set hostkey-dss <hostkey-dss>

set hostkey-ecdsa256 <hostkey-ecdsa256>

set hostkey-ecdsa384 <hostkey-ecdsa384>

set ed25519-key <ed25519-key>

set host-trusted-check {enable|disble}

end

note icon
  • When a host key is trusted and signed by a CA, SSH proxy re-signs according to the type of hostkey using trusted CA.
  • When a host is trusted but not signed, SSH proxy sends back according type of hostkey.
  • When a host key is untrusted and signed by a CA, SSH proxy re-signs a temporary host key (1 hour) using untrusted CA.
  • When a host is trusted but not signed, SSH proxy sends back a temporary host key (1 hour).
Add SSH filter profile table
Support options to block/log "x11-filter/ssh-shell/exec/port-forward/sftp"

config ssh-filter profile

edit <name>

set block {x11|shell|exec|port-forward|tun-forward|sftp|unknown}+

set log {x11|shell|exec|port-forward|tun-forward|sftp|unknown}+

end

Add shell command filters

config ssh-filter profile

edit <name>

config shell-commands

edit <id>

set type {simple|regex}

set pattern <cmd-string>

set action {block|allow}

set log {block|allow}

set alert {block|allow}

set severity {low|medium|high|critical}

end

set default-command-log {block|allow}

end

SSL/SSH inspection

While the profile configuration for SSL/SSH Inspection is found in the Security Profiles section it is enabled in the firewall policy by enabling any of the security profiles. Choosing which of the SSL/SSH Inspection profiles is all that can really be done in the policy.

The reason for having this inspection as part of the policy is the wide spread use of encryption by both legitimate and malicious actors. The legitimate users of the Internet use encryption to hide their information from snooping bad guy but the bad guys use encryption to hide their malicious content from being scanned for viruses and other malicious code by security devices.

By using the correct SSL certificates, the FortiGate can open up encrypted traffic and inspect it for malicious content that would otherwise make it past the other profiles because they couldn't read the encrypted traffic.

There are two basic types of inspection:

  • Certificate inspection, which only looks at the certificate that encrypted the packets to make sure that it is a recognized and valid certificate.
  • Full inspection, or deep inspection, that looks at all of the content of the packet. While more thorough, it also takes up more resources to perform.

HTTP Strict Transport Security (HSTS) Protocol

HSTS is a protocol used by Google and other web browsers to prevent man-in-the-middle attacks that use SSL stripping, where attackers try to force a client to only use HTTP in its communication. It also prevents users from circumventing security warnings related to an invalid certificate and proceeding to the website.

When performing deep inspection, the FortiGate serves as an intermediary to connect to the HTTPS server. It decrypts and inspects the traffic, then forwards it to the client if no threat is found. Before forwarding the traffic, the FortiGate re-encrypts the content with a certificate that is signed with its own CA certificate configured in the SSL/SSH profile. If the client trusts the CA used by the FortiGate to sign the certificate, then the connection succeeds. If the client does not trust the CA, the browser displays a warning with no option to circumvent the warning and proceed.

It is important for each endpoint to have a valid certificate chain back to the trusted root CA in its certificate store when deploying SSL deep inspection.

SSH MITM deep inspection

Due to an increase, in recent years of vulnerabilities discovered in the SSH protocol, protections have been incorporated into FortiOS's Intrusion Prevention System (IPS) engine that will aid in protecting against malicious activity coming through the FortiGate against SSH access points. In addition to the protections offered by IPS, additional settings and functionality have been added to protect against man-in-the-middle (MITM) attacks that use SSH as the attack vector.

These protections include support for comprehensive security controls on SSH MITM deep inspections:

  • SSH filter profile to control SSH tunnel types and filtering on SSH shell commands.
  • SSH proxy policy that can apply a proxy firewall policy or firewall policy using SSH inspection, with user authentication to SSH sessions.
  • Support for SSH tunnel policy access control for TCP/IP port forwarding traffic tunneled through SSH proxy. This allows IPS scanning to be applied to the tunneled traffic.
  • Support the use of SSH trust status to detect and prevent SSH-based MITM attacks.

Support SSH proxy policy for SSH sessions

Policy check

To enable SSH proxy-policy or SSH tunnel-policy, ssh-policy-check or ssh-tun-policy-check must be enabled under ssl-ssh-profile for the corresponding firewall policy.

config firewall ssl-ssh-profile

edit <name>

config ssh

set ssh-policy-check [disable|enable]

set ssh-tun-policy-check [disable|enable]

end

end

SSH proxy option

Set the proxy type to ssh in config firewall proxy-policy.

config firewall proxy-policy

edit <pol-id>

set proxy ssh

set action {accept|deny}

set utm-status enable

set ssh-filter-profile <profile_name>

end

Authentication for SSH

When user or user-group is set in SSH proxy policy, firewall authentication can be implemented for SSH proxy traffic.

config authentication rule

edit <name>

set protocol ssh

end

Basic authentication scheme:

config authentication scheme

edit "ssh-active"

set method basic

set user-database "local" #or LDAP server

end

note icon

Under authentication for SSH, with basic authentication scheme, the client is expected to input username/password in the format of:

  • <firewall username>:<server username>
  • <firewall password>:<server password>
SSH-publickey authentication scheme:

config authentication scheme

edit "ssh-pkey"

set method ssh-publickey

set user-database "local"

set ssh-ca "server-ca"

end

note icon

The user name is embedded in ssh-publickey. The user group information will be retrieved if the public key is validated by CA.

FortiOS currently only supports validation by using CA. The CA needs to be configured under config firewall ssh local-ca.

Private-key is not required for client public-key authentication. Once the client offers the public-key signed by the set CA will be authenticated.

Both basic and SSH-publickey authentication scheme:

config authentication scheme

edit "ssh-pkey"

set method basic ssh-publickey

set user-database "local"

set ssh-ca "server-ca"

end

Support SSH tunnel policy to do access control for TCP/IP port forwarding traffic.
Add a proxy type ssh-tunnel into config firewall proxy-policy

config firewall proxy-policy

edit <pol-id>

set proxy ssh-tunnel

set action {accept | deny}

set utm-status enable

end

The feature supports allowing or denying based on the IPS sensor/app-control applied to the traffic.

config firewall proxy-policy

edit <pol-id>

set ips-sensor <sensor_profile_name>

set application-list <application_control_list>

end

Support SSH trust to detect and prevent from SSH MITM attacks
Define trusted SSH host key for specific SSH server

config firewall ssh host-key

edit <name>

set status {trusted|revoked}

set type {RSA|DSS|ECDSA}

set nid <NID of ECDSA key>

set ip <ip>

set port <port>

set hostname <name>

set public-key <host key>

end

Define trusted/untrusted CAs for host key signing.

Any host key signed by trust CA is trusted unless the host key is revoked.

config firewall ssh local-ca

edit <name>

set password <passwd>

set public-key <public key>

set private-key <private key>

set source {built-in|user}

end

note icon
  • The system creates two built-in SSH CAs:
  • Fortinet_SSH_CA
  • Fortinet_SSH_CA_Untrusted.
  • The CAs are used to re-sign a server host key with local host-key using trusted/untrusted CA when the server host key is trusted or untrusted.
Define local hostkey templates for trusted re-signing.

By default, the local hostkey templates are generated automatically.

config firewall ssh local-key

edit <name>

set status [trusted|revoked]

set type [RSA|DSA|ECDSA|ED25519|RSA-CA|DSA-CA|ECDSA-CA|ED25519-CA]

set nid <NID of ECDSA key>

set ip <ip>

set port <port>

set hostname <name>

set password <passwd>

set public-key <public key>

set private-key <private key>

set source {build-in|user}

end

Per VDOM SSH settings

config firewall ssh setting

set caname <trusted-ca>

set untrusted-caname <untrusted-ca>

set hostkey-rsa <hostkey-rsa>

set hostkey-dss <hostkey-dss>

set hostkey-ecdsa256 <hostkey-ecdsa256>

set hostkey-ecdsa384 <hostkey-ecdsa384>

set ed25519-key <ed25519-key>

set host-trusted-check {enable|disble}

end

note icon
  • When a host key is trusted and signed by a CA, SSH proxy re-signs according to the type of hostkey using trusted CA.
  • When a host is trusted but not signed, SSH proxy sends back according type of hostkey.
  • When a host key is untrusted and signed by a CA, SSH proxy re-signs a temporary host key (1 hour) using untrusted CA.
  • When a host is trusted but not signed, SSH proxy sends back a temporary host key (1 hour).
Add SSH filter profile table
Support options to block/log "x11-filter/ssh-shell/exec/port-forward/sftp"

config ssh-filter profile

edit <name>

set block {x11|shell|exec|port-forward|tun-forward|sftp|unknown}+

set log {x11|shell|exec|port-forward|tun-forward|sftp|unknown}+

end

Add shell command filters

config ssh-filter profile

edit <name>

config shell-commands

edit <id>

set type {simple|regex}

set pattern <cmd-string>

set action {block|allow}

set log {block|allow}

set alert {block|allow}

set severity {low|medium|high|critical}

end

set default-command-log {block|allow}

end