SSH MITM 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. l 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

SSH-publickey authentication scheme:

config authentication scheme edit “ssh-pkey” set method ssh-publickey set user-database “local” set ssh-ca “server-ca” end

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

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

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

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

  • 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

Mirroring SSL inspected traffic

It is possible to “mirror” or send a copy of traffic decrypted by SSL inspection to one or more FortiGate interfaces so that the traffic can be collected by a raw packet capture tool for archiving or analysis. The mirroring occurs after being processed by the SSL decoder and in the same point in the work flow as the decryption of application data. The decrypted application data is wrapped inside a TCP packet (with IP and Ethernet headers), and then sent to the mirror port.

This feature works when the inspection mode is set to flow-based or proxy-based, but not for explicit proxy.

Decryption, storage, inspection, and use decrypted content is subject to local privacy rules. Use of these features could enable malicious users with administrative access to your FortiGate to harvest sensitive information submitted using an encrypted channel.

In this example, the setting enables the policy to send all traffic decrypted by the policy to the FortiGate port1 and port2 interfaces.

config firewall policy edit 0 set ssl-mirror enable set ssl-mirror-intf port1 port2 end


Having trouble configuring your Fortinet hardware or have some questions you need answered? Ask your questions in the comments below!!! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Don't Forget To Buy Your Fortinet Hardware From The Fortinet GURU