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? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!