SSL VPN security best practices

SSL VPN settings

• Define your minimum supported TLS version and cipher suites

• Limit log in attempts and block duration

• Limit users to one SSL VPN session at a time

• Use a custom listening port for SSL VPN

• Disable SSL VPN

Authentication

• Integrate with authentication servers

• Use a non-factory SSL certificate for the SSL VPN portal

• Use multi-factor authentication

• Use multi-factor authentication with authentication servers

• Disable case sensitivity for remote users using authentication servers and MFA

• Deploy user certificates for remote SSL VPN users

Authorization

• Properly administer firewall policies and profiles against only the access level required for the remote user

• Set the default portal to a custom SSL VPN with all modes disabled

• Limit incoming access to specific hosts or geography based addresses

• Limit incoming access using local-in policies with specific hosts, geography based addresses, or schedules

• Limit incoming access using a virtual IP, loopback interface, and firewall policy with Internet Services or a threat feed or schedule

SSL VPN settings

Define your minimum supported TLS version and cipher suites

Minimum and maximum supported TLS version can be configured in the FortiGate CLI. The cipher algorithm can also be customized.

See How to control the SSL version and cipher suite for SSL VPN for more information.

Limit log in attempts and block duration

To prevent brute force attacks, limit log in attempts and configure the block duration:

config vpn ssl settings
   set login-attempt-limit 2    
   set login-block-time 60          
end

These values are the default values. The FortiGate will block attempts to connect to SSL VPN for 60 seconds after two unsuccessful log in attempts. These values can be configured as needed.

See How to limit SSL VPN login attempts and block duration for more information.

Limit users to one SSL VPN session at a time

To prevent attacks from a compromised user, you can limit a user to one SSL VPN session at a time by going to VPN > SSL-VPN Portals, editing a portal, and enabling Limit Users to One SSL-VPN Connection at a Time. This option can also be configured in the CLI:

config vpn ssl web portal
    edit < portal name >
        set limit-user-logins enable
    end
end

See Multiple sessions of SSL VPN users for more information.

Use a custom listening port for SSL VPN

To prevent external attacks targeting the default SSL VPN port 10443, use a custom listening port for SSL VPN other than port 10443.

The SSL VPN listening port can be configured from the GUI on the VPN > SSL-VPN Settings page by changing the Listen on Port field from the default 10443 to any other port. To change the listening port in the CLI:

config vpn ssl settings
    set port <port number>
end

After the SSL VPN listening port has been changed, the custom port must be communicated to end users that must use it for SSL VPN tunnel mode access using FortiClient, or for SSL VPN web portal access using a web browser, replacing 10443 in the web portal URL.

Disable SSL VPN

After the SSL VPN settings have been configured, SSL VPN can be disabled when not in use.

To disable SSL VPN in the GUI:

1. Go to VPN > SSL-VPN Settings.

2. Disable Enable SSL-VPN.

3. Click Apply.

If the FortiGate has VDOMs configured, then you can select the appropriate VDOM and repeat the steps to disable SSL VPN for that specific VDOM.

See How to disable SSL VPN functionality on FortiGate for more information.

Authentication

Integrate with authentication servers

For networks with many users, integrate your user configuration with existing authentication servers through LDAP, RADIUS, or FortiAuthenticator. When integrating with existing authentication servers, these users are referred to as remote users.

By integrating with existing authentication servers, such as Windows AD, there is a lower chance of making mistakes when configuring remote users and remote user groups, reducing your administration effort. Also, credentials for remote users are kept on the authentication servers themselves and are not stored on the FortiGate, unlike credentials for local users.

See SSL VPN with LDAP user authentication and SSL VPN with RADIUS on Windows NPS for more information.

It is best practice to integrate with encrypted protocols on authentication servers such as LDAPS instead of LDAP. See Configuring client certificate authentication on the LDAP server for more information.

Use a non-factory SSL certificate for the SSL VPN portal

Your certificate should identify your domain so that a remote user can recognize the identity of the server or portal that they are accessing through a trusted CA.

The default Fortinet factory self-signed certificates are provided to simplify initial installation and testing. If you use these certificates you are vulnerable to man‑in‑the‑middle attacks, where an attacker spoofs your certificate, compromises your connection, and steals your personal information. It is highly recommended that you purchase a server certificate from a trusted CA to allow remote users to connect to SSL VPN with confidence. See Procuring and importing a signed SSL certificate for more information.

Enabling the Do not Warn Invalid Server Certificate option on the client disables the certificate warning message, potentially allowing users to accidentally connect to untrusted servers. Disabling invalid server certificate warnings is not recommended.

Use multi-factor authentication

Multi-factor authentication (MFA) ensures that the end-user is who they claim to be by requiring at least two factors - a piece of information that the user knows (password), and an asset that the user has (OTP). A third factor, something a user is (fingerprint or face), may be enabled as well. FortiToken Mobile is typically used for MFA.

FortiGate comes with two free FortiTokens, and more can be purchased from the FortiToken Mobile iOS app or through Fortinet partners.

See SSL VPN with FortiToken mobile push authentication for more information.

2FA, a subset of MFA, can also be set up with email tokens. See Email Two-Factor Authentication on FortiGate for information.

Use multi-factor authentication with authentication servers

Users configured with MFA, such as FortiToken Mobile tokens and email tokens on the FortiGate, are still essentially local users with user credentials stored on the FortiGate.

You should therefore consider using a combination of MFA and authentication servers for optimal security. See SSL VPN with LDAP-integrated certificate authentication and SSL VPN with RADIUS and FortiToken mobile push on FortiAuthenticator for more information.

Disable case sensitivity for remote users using authentication servers and MFA

When using remote users with authentication servers and MFA, it is possible for MFA to be bypassed if the case of the entered username is not an exact match. To prevent this, ensure case sensitivity is disabled for each remote user that has been configured on the FortiGate with authentication server and MFA settings. See SSL VPN for remote users with MFA and user sensitivity for more information.

Deploy user certificates for remote SSL VPN users

This method of 2FA uses a user certificate as the second authentication factor. This is more secure, as it identifies the end user using a certificate. The configuration and administration of this solution is significantly more complicated, and requires administrators with advanced knowledge of the FortiGate and certificate deployment.

See SSL VPN with certificate authentication for more information.

Authorization

Properly administer firewall policies and profiles against only the access level required for the remote user

Users do not all require the same access. Access should only be granted after careful considerations. Typically, users are placed in groups, and each group is allowed access to limited resources.

Using SSL VPN realms simplifies defining the control structure for mapping users and groups to the appropriate resources.

See SSL VPN multi-realm for more information.

Set the default portal to a custom SSL VPN with all modes disabled

In the SSL VPN settings, it is mandatory in the Authentication/Portal Mapping section to configure a portal for All Other Users/Groups or what can be considered a default portal for other users who are not specifically mapped to access SSL VPN portals.

When the Authentication/Portal Mapping does not match users or groups that you have specifically mapped to access SSL VPN portals, you can create a custom SSL VPN portal with both tunnel and web modes disabled, and then set the default portal to that custom portal. This configuration is analogous to the implicit deny policy in firewall policies, in that this custom portal can deny all other users and groups.

Even with a default portal with all modes disabled, users deemed to be part of All Other Users/Groups will still be able to access the web portal. Once these users try to log into the web portal, access will be denied. Users deemed to be part of All Other Users/Groups should not be able to successfully establish tunnel mode connections in this case.

See How to disable SSL VPN Web Mode or Tunnel Mode in SSL VPN portal for more information.

Limit incoming access to specific hosts or geography based addresses

The simplest method for limiting incoming access is specifying source addresses in the SSL VPN settings.

• If you require schedules and geography based addresses, and are comfortable using the CLI, then consider configuring local-in policies as described in To limit incoming access to specific hosts based on their source IP addresses in the CLI.
• If you require Internet Services using ISDB or threat feeds, or schedules and geography based addresses, and are more comfortable using the GUI, then consider configuring a VIP, loopback, and firewall policy as described in To limit incoming access to specific hosts based on their source IP addresses in the GUI.

In SSL VPN, IPv6 geography based addresses are not supported.

To limit incoming access to specific hosts based on their source IP addresses in the GUI:

1. Create address objects or groups with the source IP addresses you need to allow access to SSL VPN modes.

2. In VPN > SSL-VPN Settings under Restrict Access, select Limit access to specific hosts and in the Hosts field select address objects or groups corresponding to specific source IP addresses for hosts that you need to allow.

You can block incoming access for specific hosts by following the same configuration steps with the address objects or groups being of hosts to block and instead selecting Negate Source. See How to block SSL VPN connection from a certain source IP Address for more information.

To limit incoming access to specific hosts based on their source IP addresses in the CLI:

config vpn ssl settings
    set source-address <source address 1> ... <source address n>
    set source-address-negate {disable | enable}
end

With this CLI, you can limit incoming access to hosts from specific countries by specifying geography based addresses as the source addresses. See Geography based addresses and Restricting SSL VPN connectivity from certain countries using firewall geography address for more information.

Limit incoming access using local-in policies with specific hosts, geography based addresses, or schedules

As an alternative to configuring source addresses in the SSL VPN settings, you can configure local-in policies to allow and deny specific source addresses. Local-in policies must be defined in the CLI, so this approach requires familiarity with CLI commands.

The configuration workflow is:

1. Create a new custom service corresponding to the SSL VPN listening TCP port.

2. (Optional) Create new geography based addresses that can be specified as the source addresses for the allow and deny local-in policies that are created.

3. (Optional) Configure new schedules that can be specified as the schedule for the allow and deny local-in policies that are created.

4. Create a local-in policy using the SSL VPN custom service to allow specific source addresses.

5. Create a local-in policy using the SSL VPN custom service to deny specific source addresses. This is required since there is no implicit deny local-in policy defined by default.

Note that extra care should be taken when configuring a local-in policy, as an incorrect configuration could inadvertently deny traffic for IPsec VPN, dynamic routing protocols, HA, and other FortiGate features.

The source IP address objects that are used can be address objects or groups, or geography based address objects. New schedules can be created and applied to the local-in policies to impose schedule-based access restrictions.

You can also deny all access to SSL VPN by creating a deny local-in policy using source address all and SSL VPN custom service without creating a corresponding local-in policy to allow the SSL VPN custom service.

See Local-in policy, Restricting/Allowing access to the FortiGate SSL-VPN from specific countries or IP addresses with local-in-policy, and Scheduled SSL-VPN connectivity via Local-in-Policy for more information.

Limit incoming access using a virtual IP, loopback interface, and firewall policy with Internet Services or a threat feed or schedule

SSL VPN access can be moved to a secondary IP address or any other WAN IP address defined on a FortiGate interface by using a virtual IP (VIP), loopback interface, and WAN-to-loopback firewall policy. This method can be configured entirely in the GUI and is much easier to configure than local-in policies.

The configuration workflow is as follows:

1. Configure the SSL VPN firewall policy from the ssl.<VDOM> interface to the internal interface or interfaces, ensuring that you specify the users and groups (required), and addresses or address groups (optional) in the policy's Source field. See SSL VPN split tunnel for remote user.

2. Create a new loopback interface and specify an IP address that is not being used by any other interface on the FortiGate. This IP address can be a private IP address within the RFC 1918 range.

3. Create a new VIP with the following settings:

   • External IP address/range configured as the secondary WAN IP address, or any other WAN IP address that is available for the WAN interface.

   • IPv4 address/range configured as the IP address assigned to the loopback interface.

   • Port forwarding enabled with External service port and Map to IPv4 port with the SSL VPN listening port.

4. Create a new WAN interface to loopback interface firewall policy with the VIP as the destination address.

5. In the SSL VPN settings set Listen on Interface(s) to the newly created loopback interface.

6. (Optional) Create a new deny firewall policy, configure Internet Services as source addresses in the new policy, and place it above the WAN-to-loopback firewall policy.

7. (Optional) Create a new deny firewall policy, configure an IP address threat feed, configure the threat feed as a source address in the new policy, and place it above the WAN-to-loopback firewall policy.

8. (Optional) Configure a new schedule and apply it to the WAN-to-loopback firewall policy.

This configuration gives you the option to deny access to SSL VPN from specified hosts. You can create a new deny firewall policy, apply Internet Services using the ISDB or threat feed objects as source addresses and place the deny policy above the WAN-to-loopback firewall policy.

You also have the option of creating a new schedule and applying it to the WAN-to-loopback firewall policy to allow SSL VPN access during a specified time or days of the week.

Finally, you can disable all SSL VPN access by disabling the WAN-to-loopback firewall policy.

See Access SSL VPN from Secondary IP only, Using Internet Service in a policy, IP address threat feed, and Firewall policy for more information.

See Prevent TOR IP addresses from accessing SSL-VPN with brute-force attacks on FortiGate and How to use a Threat Feed with SSL VPN for specific examples.