Security best practices

This chapter describes some techniques and best practices that you can use to improve FortiOS security.

Install the FortiGate unit in a physically secure location

A good place to start with is physical security. Install your FortiGate in a secure location, such as a locked room or one with restricted access. A restricted location prevents unauthorized users from getting physical access to the device.

If unauthorized users have physical access, they can disrupt your entire network by disconnecting your FortiGate (either by accident or on purpose). They could also connect a console cable and attempt to log into the CLI. Also, when a FortiGate unit reboots, a person with physical access can interrupt the boot process and install different firmware.

Register your product with Fortinet Support

You need to register your Fortinet product with Fortinet Support to receive customer services, such as firmware updates and customer support. You must also register your product for FortiGuard services, such as up-to-date antivirus and IPS signatures. To register your product the Fortinet Support website.

Keep your FortiOS firmware up to date

Always keep FortiOS up to date. The most recent version is the most stable and has the most bugs fixed and vulnerabilities removed. Fortinet periodically updates the FortiGate firmware to include new features and resolve important issues.

After you register your FortiGate, you can receive notifications on FortiGate GUI about firmware updates. You can update the firmware directly from the GUI or by downloading firmware updates from the Fortinet Support website.

Before you install any new firmware, be sure to follow these steps:

• Review the release notes for the latest firmware release.
• Review the Supported Upgrade Paths guide to determine the best path to take from your current version of FortiOS to the latest version.
• Back up the current configuration.

Only FortiGate administrators who have read and write privileges can upgrade the FortiOS firmware.

System administrator best practices

This section describes a collection of changes you can implement to make administrative access to the GUI and CLI more secure.

Disable administrative access to the external (Internet-facing) interface

When possible, don’t allow administration access on the external (Internet-facing) interface.

To disable administrative access, go to Network > Interfaces, edit the external interface and disable HTTPS, PING, HTTP, SSH, and TELNET under Administrative Access.

From the CLI:

config system interface edit <external-interface-name> unset allowaccess

end

Allow only HTTPS access to the GUI and SSH access to the CLI

For greater security never allow HTTP or Telnet administrative access to a FortiGate interface, only allow HTTPS and SSH access. You can change these settings for individual interfaces by going to Network > Interfaces and adjusting the administrative access to each interface.

From the CLI:

config system interface edit <interface-name> set allowaccess https ssh

end

Require TLS 1.2 for HTTPS administrator access

Use the following command to require TLS 1.2 for HTTPS administrator access to the GUI:

config system global set admin-https-ssl-versions tlsv1-2

end

TLS 1.2 is currently the most secure SSL/TLS supported version for SSL-encrypted administrator access.

Re-direct HTTP GUI logins to HTTPS

Go to System > Settings > Administrator Settings and enable Redirect to HTTPS to make sure that all attempted HTTP login connections are redirected to HTTPS.

From the CLI:

config system global set admin-https-redirect enable end

 

Change the HTTPS and SSH admin access ports to non-standard ports

Go to System > Settings > Administrator Settings and change the HTTPS and SSH ports.

You can change the default port configurations for HTTPS and SSH administrative access for added security. To connect to a non-standard port, the new port number must be included in the collection request. For example:

l If you change the HTTPS port to 7734, you would browse to https://<ip-address>:7734. l If you change the SSH port to 2345, you would connect to ssh admin@<ip-address>:2345 To change the HTTPS and SSH login ports from the CLI:

config system global set admin-sport 7734 set admin-ssh-port 2345

end

If you change to the HTTPS or SSH port numbers, make sure your changes do not conflict with ports used for other services.

Maintain short login timeouts

Set the idle timeout to a short time to avoid the possibility of an administrator walking away from their management computer and leaving it exposed to unauthorized personnel.

To set the administrator idle timeout, go to System > Settings and enter the amount of time for the Idle timeout. A best practice is to keep the default time of 5 minutes.

To set the administrator idle timeout from the CLI:

config system global set admintimeout 5

end

You can use the following command to adjust the grace time permitted between making an SSH connection and authenticating. The range can be between 10 and 3600 seconds, the default is 120 seconds (minutes). By shortening this time, you can decrease the chances of someone attempting a brute force attack a from being successful. For example, you could set the time to 30 seconds.

config system global set admin-ssh-grace-time 30

end

Restrict logins from trusted hosts

Setting up trusted hosts for an administrator limits the addresses from where they can log into FortiOS. The trusted hosts configuration applies to most forms of administrative access including HTTPS, SSH, and SNMP. When you identify a trusted host for an administrator account, FortiOS accepts that administrator’s login only from one of the trusted hosts. A login, even with proper credentials, from a non-trusted host is dropped.

System administrator best practices

To identify trusted hosts, go to System > Administrators, edit the administrator account, enable Restrict login to trusted hosts, and add up to ten trusted host IP addresses.

To add two trusted hosts from the CLI:

config system admin edit <administrator-name> set trustedhost1 172.25.176.23 255.255.255.255 set trustedhost2 172.25.177.0 255.255.255.0

end

Trusted host IP addresses can identify individual hosts or subnets. Just like firewall policies, FortiOS searches through the list of trusted hosts in order and acts on the first match it finds. When you configure trusted hosts, start by adding specific addresses at the top of the list. Follow with more general IP addresses. You don’t have to add addresses to all of the trusted hosts as long as all specific addresses are above all of the 0.0.0.0 0.0.0.0 addresses.

Set up two-factor authentication for administrators

FortiOS supports FortiToken and FortiToken Mobile 2-factor authentication. FortiToken Mobile is available for iOS and Android devices from their respective application stores.

Every registered FortiGate unit includes two trial tokens for free. You can purchase additional tokens from your reseller or from Fortinet.

To assign a token to an administrator, go to System > Administrators and select Enable Two-factor Authentication for each administrator.

Create multiple administrator accounts

Rather than allowing all administrators to access ForiOS with the same administrator account, you can create accounts for each person or each role that requires administrative access. This configuration allows you to track the activities of each administrator or administrative role.

If you want administrators to have different functions you can add different administrator profiles. Go to System > Admin Profiles and select Create New.

Modify administrator account lockout duration and threshold values

By default, the FortiGate sets the number of password retries at three, allowing the administrator a maximum of three attempts to log into their account before locking the account for a set amount of time.

Both the number of attempts (admin-lockout-threshold) and the wait time before the administrator can try to enter a password again (admin-lockout-duration) can be configured within the CLI.

To configure the lockout options:

config system global set admin-lockout-threshold <failed_attempts> set admin-lockout-duration <seconds>

end

The default value of admin-lockout-threshold is 3 and the range of values is between 1 and 10. The admin-lockout-duration is set to 60 seconds by default and the range of values is between 1 and 4294967295 seconds.

Global commands for stronger and more secure encryption

Keep in mind that the higher the lockout threshold, the higher the risk that someone may be able to break into the FortiGate.

Example:

To set the admin-lockout-threshold to one attempt and the admin-lockout-duration to a five minute duration before the administrator can try to log in again, enter the commands:

config system global set admin-lockout-threshold 1 set admin-lockout-duration 300 end

If the time span between the first failed login attempt and the admin-lockoutthreshold failed login attempt is less than admin-lockout-duration, the lockout will be triggered.

Rename the admin administrator account

You can improve security by renaming the admin account. To do this, create a new administrator account with the super_admin admin profile and log in as that administrator. Then go to System > Administrators and edit the admin administrator and change the User Name. Renaming the admin account makes it more difficult for an attacker to log into FortiOS.

Add administrator disclaimers

FortiOS can display a disclaimer before or after logging into the GUI or CLI (or both). In either case the administrator must read and accept the disclaimer before they can proceed.

Use the following command to display a disclaimer before logging in:

config system global set pre-login-banner enable

end

Use the following command to display a disclaimer after logging in:

config system global set post-login-banner enable

end

You can customize the replacement messages for these disclaimers by going to System > Replacement Messages. Select Extended View to view and edit the Administrator replacement messages.

From the CLI:

config system replacemsg admin pre_admin-disclaimer-text config system replacemsg admin post_admin-disclaimer-text

Global commands for stronger and more secure encryption

This section describes some best practices for employing stronger and more secure encryption.

Disable sending malware statistics to FortiGuard

Turn on global strong encryption

Enter the following command to configure FortiOS to use only strong encryption and allow only strong ciphers (AES, 3DES) and digest (SHA1) for HTTPS, SSH, TLS, and SSL functions.

config sys global set strong-crypto enable

end

Disable MD5 and CBC for SSH

In some cases, you may not be able to enable strong encryption. For example, your FortiGate may be communicating with a system that does not support strong encryption. With strong-crypto disabled you can use the following options to prevent SSH sessions with the FortiGate from using less secure MD5 and CBC algorithms:

config sys global set ssh-hmac-md5 disable set ssh-cbc-cipher disable

end

Disable static keys for TLS

You can use the following command to prevent TLS sessions from using static keys (AES128-SHA, AES256-SHA, AES128-SHA256, AES256-SHA256):

config sys global set ssl-static-key-ciphers disable

end

Require larger values for Diffie-Hellman exchanges

Larger Diffie-Hellman values result in stronger encryption. Use the following command to force Diffie-Hellman exchanges to use 8192 bit values (the highest configurable DH value).

config sys global set dh-params 8192

end

Disable sending malware statistics to FortiGuard

By default FortiOS periodically sends encrypted malware statistics to FortiGuard. The malware statistics record Antivirus, IPS, or Application Control events. This data is used to improved FortiGuard services. The malware statistics that FortiOS sends do not include any personal or sensitive customer data. The information is not shared with any external parties and is used in accordance with Fortinet’s Privacy Policy.

To disable sending malware statistics to FortiGuard, enter the following command: config system global set fds-statistics disable

end

Disable sending Security Rating statistics to FortiGuard

Security Rating is a Fortinet Security Fabric feature that allows customers to audit their Security Fabric and find and fix security problems. As part of the feature, FortiOS sends your security rating to FortiGuard every time a security rating test runs.

You can opt out of submitting Security Rating scores to FortiGuard. If you opt out you won’t be able to see how your organization’s scores compare with the scores of other organizations. Instead, an absolute score is shown. Use the following command to disable FortiGuard Security Rating result submission:

config system global set fortiguard-audit-result-submission disable

end

Disable auto USB installation

If USB installation is enabled, an attacker with physical access to a FortiGate could load a new configuration or firmware on the FortiGate using the USB port. You can disable USB installation by entering the following from the CLI:

config system auto-install set auto-install-config disable set auto-install-image disable

end

Set system time by synchronizing with an NTP server

For accurate time, use an NTP server to set system time. Synchronized time facilitates auditing and consistency between expiry dates used in expiration of certificates and security protocols.

From the GUI go to System > Settings > System Time and select Synchronize with NTP Server. By default, this causes FortiOS to synchronize with Fortinet’s FortiGuard secure NTP server.

From the CLI you can use one or more different NTP servers:

config system ntp set type custom set ntpsync enable config ntpserver edit 1 set server <ntp-server-ip>

next edit 2 set server <other-ntp-server-ip> end

Disable the maintainer admin account

Administrators with physical access to a FortiGate appliance can use a console cable and a special administrator account called maintainer to log into the CLI without a password. This feature allows you to log into a FortiGate if you have lost all administrator passwords. See Resetting a lost Admin password on the Fortinet Cookbook for details.

The maintainer account can be disabled using the following command:

config system global set admin-maintainer disable

end

Enable password policies

Go to System > Settings > Password Policy, to create a password policy that all administrators must follow. Using the available options you can define the required length of the password, what it must contain (numbers, upper and lower case, and so on) and an expiry time.

Use the password policy feature to make sure all administrators use secure passwords that meet your organization’s requirements.

Configure auditing and logging

For optimum security go to Log & Report > Log Settings enable Event Logging. For best results send log messages to FortiAnalyzer or FortiCloud.

From FortiAnalyzer or FortiCloud, you can view reports or system event log messages to look for system events that may indicate potential problems. You can also view system events by going to FortiView > System Events.

Establish an auditing schedule to routinely inspect logs for signs of intrusion and probing.

Encrypt logs sent to FortiAnalyzer/FortiManager

To keep information in log messages sent to FortiAnalyzer private, go to Log & Report > Log Settings and when you configure Remote Logging to FortiAnalyzer/FortiManager select Encrypt log transmission.

From the CLI.

config log {fortianalyzer | fortianalyzer2 | fortianalyzer3} setting set enc-algorithm high end

Disable unused interfaces

To disable an interface from the GUI, go to Network > Interfaces. Edit the interface to be disabled and set Interface State to Disabled.

From the CLI, to disable the port21 interface:

config system interface edit port21 set status down

end

Disable unused protocols on interfaces

You can use the config system interface command to disable unused protocols that attackers may attempt to use to gather information about a FortiGate unit. Many of these protocols are disabled by default. Using the config system interface command you can see the current configuration of each of these options for the selected interface and then choose to disable them if required.

config system interface edit <interface-name> set dhcp-relay-service disable set pptp-client disable set arpforward disable set broadcast-forward disable set l2forward disable set icmp-redirect disable set vlanforward disable set stpforward disable set ident-accept disable set ipmac disable set netbios-forward disable set security-mode none set device-identification disable set lldp-transmission disable end

Option	Description
dhcp-relay-service	Disable the DHCP relay service.
pptp-client	Disable operating the interface as a PPTP client.
arpforward	Disable ARP forwarding.
broadcast-forward	Disable forwarding broadcast packets.
l2forward	Disable layer 2 forwarding.
icmp-redirect	Disable ICMP redirect.

 

Option	Description
vlanforward	Disable VLAN forwarding.
stpforward	Disable STP forwarding.
ident-accept	Disable authentication for this interface. The interface will not respond to a connection with an authentication prompt.
ipmac	Disable IP/MAC binding.
netbios-forward	Disable NETBIOS forwarding.
security-mode	Set to none to disable captive portal authentication. The interface will not respond to a connection with a captive portal.
device-identification	Disable device identification.
lldp-transmission	Disable link layer discovery (LLDP).

Use local-in policies to close open ports or restrict access

You can also use local-in policies to close open ports or otherwise restrict access to FortiOS.

Close ICMP ports

Use the following command to close all ICMP ports on the WAN1 interface. The following example blocks traffic that matches the ICMP_ANY firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all set action deny set service ICMP_ANY set schedule always

end

Close the BGP port

Use the following command to close the BGP port on the wan1 interface. The following example blocks traffic that matches the BGP firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all

Use local-in policies to close open ports or restrict access

set action deny set service BGP set schedule always end

IP, TCP, and UDP load balancing

You can load balance all IP, TCP or UDP sessions accepted by the security policy that includes a load balancing virtual server with the type set to IP, TCP, or UDP. Traffic with destination IP and port that matches the virtual server IP and port is load balanced. For these protocol-level load balancing virtual servers you can select a load balance method and add real servers and health checking. However, you can’t configure persistence, HTTP multiplexing and SSL offloading.

Example HTTP load balancing to three real web servers

In this example, a virtual web server with IP address 192.168.37.4 on the Internet, is mapped to three real web servers connected to the FortiGate unit dmz1 interface. The real servers have IP addresses 10.10.123.42, 10.10.123.43, and 10.10.123.44. The virtual server uses the First Alive load balancing method. The configuration also includes an HTTP health check monitor that includes a URL used by the FortiGate unit for get requests to monitor the health of the real servers.

Connections to the virtual web server at IP address 192.168.37.4 from the Internet are translated and load balanced to the real servers by the FortiGate unit. First alive load balancing directs all sessions to the first real server. The computers on the Internet are unaware of this translation and load balancing and see a single virtual server at IP address 192.168.37.4 rather than the three real servers behind the FortiGate unit.

Virtual server configuration example

GUI configuration

Use the following procedures to configure this load balancing setup from the GUI.

To add an HTTP health check monitor

In this example, the HTTP health check monitor includes the URL “/index.html” and the Matched Phrase “Fortinet products”.

1. Go to Policy & Objects > Health Check.
2. Select Create New.
3. Add an HTTP health check monitor that sends get requests to http://<real_server_IP_address>/index.html and searches the returned web page for the phrase “Fortinet products”.

Name	HTTP_health_chk_1
Type	HTTP
Port	80
URL	/index.html
Matched Content	Fortinet products
Interval	10 seconds
Timeout	2 seconds
Retry	3

4. Select OK.

To add the HTTP virtual server and the real servers

1. Go to Policy & Objects > Virtual Servers.
2. Select Create New.
3. Add an HTTP virtual server that allows users on the Internet to connect to the real servers on the internal network.

In this example, the FortiGate wan1 interface is connected to the Internet.

Name	Load_Bal_VS1
Type	HTTP
Interface	wan1
Virtual Server IP	192.168.37.4 The public IP address of the web server. The virtual server IP address is usually a static IP address obtained from your ISP for your web server. This address must be a unique IP address that is not used by another host and cannot be the same as the IP address of the external interface the virtual IP will be using. However, the external IP address must be routed to the selected interface. The virtual IP address and the external IP address can be on different subnets. When you add the virtual IP, the external interface responds to ARP requests for the external IP address.
Virtual Server Port	80

 

Load Balance Method	First Alive
Persistence	HTTP cookie
Health Check	HTTP_health_chk_1
HTTP Multiplexing	Turn on. The FortiGate unit multiplexes multiple client into a few connections between the FortiGate unit and each real HTTP server. This can improve performance by reducing server overhead associated with establishing multiple connections.
Preserve Client IP	Turn on. The FortiGate unit preserves the IP address of the client in the XForwarded-For HTTP header.

4. Add three real servers to the virtual server. Each real server must include the IP address of a real server on the internal network.

Configuration for the first real server.

IP Address	10.10.10.42
Port	80
Max Connections	0 Setting Max Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of connections to each real server to limit the traffic received by each server. In this example, the Max Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.
Mode	Active

Configuration for the second real server.

IP Address	10.10.10.43
Port	80
Max Connections	0
Mode	Active

Configuration for the third real server.

IP Address		10.10.10.44
Port		80

 

HTTP load balancing to three real web servers

Max Connections	0
Mode	Active

To add the virtual server to a security policy

Add a wan1 to dmz1 security policy that uses the virtual server so that when users on the Internet attempt to connect to the web server’s IP address, packets pass through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses.

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New.
3. Configure the security policy:

Name	Add a name for the policy.
Incoming Interface	wan1
Outgoing Interface	dmz1
Source	all (or a more specific address)
Destination	Load_Bal_VS1
Schedule	always
Service	HTTP
Action	ACCEPT
NAT	Select this option and select Use Destination Interface Address.
Log Allowed Traffic	Select to log virtual server traffic

4. Select other security policy options as required.
5. Select OK.

SSL/TLS load balancing

In a firewall load balancing virtual server configuration, you can select SSL to load balance only SSL and TLS sessions. The virtual server will load balance SSL and TLS sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. Change this port to match the destination port of the sessions to be load balanced.

For SSL load balancing you can also set persistence to SSL session ID. Persistence is achieved by the FortiGate unit sending all sessions with the same SSL session ID to the same real server. When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an SSL session ID, the FortiGate unit sends all subsequent sessions with the same SSL session ID to the same real server.

SSL/TLS offloading

Use SSL offloading to accelerate clients’ SSL or HTTPS connections to real servers by using the FortiGate unit to perform SSL/TLS operations (offloading them from the real servers using the FortiGate unit’s SSL acceleration hardware). FortiGate units can offload most versions of SSL/TLS, including SSL 3.0, TLS 1.0 and TLS 1.2. SSL/TLS offloading is available on FortiGate units that support SSL acceleration.

To configure SSL offloading from the GUI go to Policy & Objects > Virtual Servers. Add a virtual server and set the type to HTTPS or SSL and select the SSL offloading type (Client <-> FortiGate or Full).

Select Client <-> FortiGate to apply hardware accelerated SSL/TLS processing only to the part of the connection between the client and the FortiGate unit. This mode is called half mode SSL offloading. The segment between the FortiGate unit and the server will use clear text communications. This results in best performance, but cannot be used in failover configurations where the failover path does not have an SSL accelerator.

Select Full to apply hardware accelerated SSL processing to both parts of the connection: the segment between client and the FortiGate unit, and the segment between the FortiGate unit and the server. The segment between the FortiGate unit and the server uses encrypted communications, but the handshakes are abbreviated. This is not as efficient as half mode SSL offloading, but still improves performance. As well, full-mode SSL offloading can be used in failover configurations where the failover path does not have an SSL accelerator. If the server is already configured to use SSL, this also enables SSL acceleration without requiring changes to the server’s configuration.

 

SSL Offloading modes (Half Mode and Full Mode)

Configuring SSL offloading also requires selecting a certificate to use for the SSL offloading sessions. SSL offloading supports key sizes up to 4096. FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive

The following CLI command shows an example half mode HTTPS SSL offloading configuration. In the example the ssl-mode option sets the SSL offload mode to half (which is the default mode).

config firewall vip edit Vserver-ssl-offload set type server-load-balance set server-type https set ldb-method round-robin set extip 172.20.120.30 set extintf wan1 set extport 443

Separate virtual-server client and server TLS version and cipher configuration

set persistence ssl-session-id set ssl-mode half set ssl-certificate my-cert set monitor tcp-mon-1 config realservers edit 1 set ip 10.31.101.30 set port 443

next edit 2 set ip 10.31.101.40 set port 443

end

end

Separate virtual-server client and server TLS version and cipher configuration

In some cases, you may want the to use different versions of SSL or TLS on the client to FortiGate connection than on the FortiGate to server connection. For example, you may want to use the FortiGate to protect a legacy SSL 3.0 or TLS 1.0 server while making sure that client to FortiGate connections must always use the higher level of protection offered by TLS 1.1 or greater. Also, in some cases you might want to protect a server that only has weak ciphers (for example, DES or RC4) while making sure that all connections between the FortiGate and the client use a strong cipher for better protection.

The following options are available when configuring server load balancing for HTTPS sessions configured with the following command:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full …

Setting the SSL/TLS versions to use for server and client connections

The ssl-server-min-version, ssl-server-max-version, ssl-min-version and ssl-maxversion configuration options allow the minimum and maximum SSL/TLS versions for the client to FortiGate connection to be independent of the FortiGate to server configuration. By default these options are both set to client and the configured ssl-min-version and ssl-max-version settings are applied to both the client and the server connection.

You can change the ssl-server-min-version and ssl-server-max-version to apply different options to the server connection. The ssl-min-version and ssl-max-version settings are still applied to the client connection. If you set the ssl-server-min-version and ssl-server-max-version to an explicit version then both must be set to an explicit version.

The ssl-server-min-version and ssl-server-max-version options allow you to specify the minimum and maximum SSL/TLS versions the FortiGate will offer to the server (in the record header of the ClientHello) when performing full mode SSL offloading and thus the minimum and maximum SSL/TLS versions the FortiGate accepts from the server (in a ServerHello). If the server responds with a version in its ServerHello Setting the SSL/TLS cipher choices for server and client connections

that is lower than ssl-server-min-version or higher than the ssl-server-max-version then the FortiGate terminates the connection.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full set ssl-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-server-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client} set ssl-server-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client}

Setting the SSL/TLS cipher choices for server and client connections

The ssl-algorithm and ssl-server-algorithm configuration options allow the cipher choice for the FortiGate to server connection to be independent of the client to FortiGate connection. By default, sslserver-algorithm is set to client and the configured ssl-algorithm setting is applied to both the client and the server connection.

You can change the ssl-server-algorithm to apply different options to the server connection. The sslalgorithm setting is still applied to the client connection. The following ssl-server-algorithm options are available:

• high, offer AES or 3DES cypher suites in the ServerHello l medium, use AES, 3DES, or RC4 cypher suites in the ServerHello l low, use AES, 3DES, RC4, or DES cypher suites in the ServerHello l custom, specifiy custom cypher suites using the config ssl-server-cipher-suites and offer these custom cypher suites in the ServerHello.
• client, offer the cypher suites in the ServerHello that are offered in the ClientHello.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full

set ssl-algorithm {high | medium | low | custom}

set ssl-server-algorithm {high | medium | low | custom | client}

If you set ssl-server-algorithm to custom, the syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full

set ssl-server-algorithm custom config ssl-server-cipher-suites edit 10 set cipher <cipher-suite>

set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2}

Protection from TLS protocol downgrade attacks

next edit 20 set cipher <cipher-suite>

set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} end

Protection from TLS protocol downgrade attacks

The ssl-client-fallback option, when enabled (the default configuration), performs downgrade attack prevention (RFC 7507).

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-client-fallback {disable | enable}

Setting 3072- and 4096-bit Diffie-Hellman values

The ssl-dh-bits option allows you to specify the number of bits of the prime number used in the DiffieHellman exchange for RSA encryption of the SSL connection. Larger prime numbers are associated with greater cryptographic strength. You can set DH values from 768 to 4096 bits.

Command syntax is:

config firewall vip edit server-name set type server-load-balance set server-type https set ssl-dh-bits {768 | 1024 | 1536 | 2048 | 3072 | 4096}

Setting the DH bits to 2048 only provides the equivalent of a symmetric cipher in the range of 112 – 128 bits. This means that if AES 256 is used then the weakest point is the DH of 2048 and a value of at least 3072 should be use if the goal is to have 256 bits of security.

FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive.

Additional SSL load balancing and SSL offloading options

The following SSL load balancing and SSL offloading options are only available from the CLI:

ssl-client-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the client and the FortiGate unit.

ssl-client-session-state-timeout <timeout_int>

Additional SSL load balancing and SSL offloading options

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the client and the FortiGate unit.

ssl-client-session-state-type {both | client | disable | time}

Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the client and the FortiGate unit.

• both: Select to expire SSL session states when either ssl-client-session-state-max or ssl-clientsession-state-timeout is exceeded, regardless of which occurs first. l count: Select to expire SSL session states when ssl-client-session-state-max is exceeded.
• disable: Select to keep no SSL session states.
• time: Select to expire SSL session states when ssl-client-session-state-timeout is exceeded.

ssl-http-location-conversion {enable | disable}

Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply,

Location: http://example.com/ would be converted to Location: https://example.com/ ssl-http-match-host {enable | disable}

Enable (the default) to apply Location conversion to the reply’s HTTP header only if the host name portion of Location matches the request’s Host field, or, if the Host field does not exist, the host name portion of the request’s URI.

If disabled, conversion occurs regardless of whether the host names in the request and the reply match.

For example, if host matching is enabled, and a request contains Host: example.com and the reply contains Location: http://example.cc/, the Location field does not match the host of the original request and the reply’s Location field remains unchanged. If the reply contains Location: http://example.com/, however, then the FortiGate unit detects the matching host name and converts the reply field to Location: https://example.com/.

This option appears only if ssl-http-location-conversion is enable.

ssl-send-empty-frags {enable | disable}

Select to precede the record with empty fragments to protect from attacks on CBC IV. You might disable this option if SSL acceleration will be used with an old or buggy SSL implementation which cannot properly handle empty fragments.

ssl-server-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the server and the FortiGate unit.

ssl-server-session-state-timeout <timeout_int>

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.

ssl-server-session-state-type {both | count | disable | time}

Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.

• both: Select to expire SSL session states when either ssl-server-session-state-max or ssl-serversession-state-timeout is exceeded, regardless of which occurs first. l count: Select to expire SSL session states when ssl-server-session-state-max is exceeded.
• disable: Select to keep no SSL session states. l time: Select to expire SSL session states when ssl-server-session-state-timeout is exceeded.

 

SSL offloading support for Internet Explorer 6

In some cases the Internet Explorer 6 web browser may be able to access real servers. To resolve this issue, disable the ssl-send-empty-frags option:

config firewall vip edit vip_name set type server-load-balance set server-type https set ssl-send-empty-frags disable

end

You can disable this option if SSL acceleration will be used with an old or buggy SSL implementation that cannot properly handle empty fragments.

Selecting the cipher suites available for SSL load balancing

You can use the following command to view the complete list of cipher suites available for SSL offloading:

config firewall vip edit <vip-name> set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 0 set cipher ?

In most configurations the matching cipher suite is automatically selected but you can limit the set of cipher suites that are available for a given SSL offloading configuration. For example, use the following command to limit an SSL load balancing configuration to use the three cipher suites that support ChaCha20 and Poly1305:

config firewall vip edit <vip-name> set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 1

set cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 next edit 2

set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 next edit 3

set cipher TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 end end

 

Disabling SSL/TLS re-negotiation

The vulnerability CVE-2009-3555 affects all SSL/TLS servers that support re-negotiation. FortiOS when configured for SSL/TLS offloading is operating as a SSL/TLS server. The IETF is working on a TLS protocol change that will fix the problem identified by CVE-2009-3555 while still supporting re-negotiation. Until that protocol change is available, you can use the ssl-client-renegotiation option to disable support for SSL/TLS re-negotiation. The default value of this option is allow, which allows an SSL client to renegotiate. You can change the setting to deny to abort any attempts by an SSL client to renegotiate. If you select deny as soon as a ClientHello message indicating a re-negotiation is received from the client FortiOS terminates the TCP connection.

Since SSL offloading does not support requesting client certificates the only circumstance in which a renegotiation is required is when more than 2^32 bytes of data are exchanged over a single handshake. If you are sure that this volume of traffic will not occur then you can disable re-negotiation and avoid any possibility of the attack described in CVE-2009-3555.

The re-negotiation behavior can be tested using OpenSSL. The OpenSSL s_client application has the feature that the user can request that it do renegotiation by typing “R”. For example, the following shows a successful renegotiation against a FortiGate unit configured with a VIP for 192.168.2.100:443:

$ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003)

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0

—

Certificate chain

0

s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com

i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com

—

Server certificate

—–BEGIN CERTIFICATE—–

—certificate not shown—

—–END CERTIFICATE—–

subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em ailAddress=support@fortinet.com

issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

—

No client certificate CA names sent

—

SSL handshake has read 2370 bytes and written 316 bytes —

Disabling SSL/TLS re-negotiation

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

Compression: NONE Expansion: NONE SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA Session-ID:

02781E1E368DCCE97A95396FAA82E8F740F5BBA96CF022F6FEC3597B0CC88095

Session-ID-ctx: Master-Key:

A6BBBD8477A2422D56E57C1792A4EA9C86F37D731E67D0A66E5CDB2B5C76650780C0E7F01CFF851EC44661

86F4C48397

Key-Arg : None

Start Time: 1264453027

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)

—

GET /main.c HTTP/1.0

R

RENEGOTIATING

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0 HTTP/1.0 200 ok

Content-type: text/plain

/*

* Copyright (C) 2004-2007 Fortinet */

#include <stdio.h> #include “vsd_ui.h”

int main(int argc, char **argv)

{

return vsd_ui_main(argc, argv);

} closed $

The following is the same test, but this time with the VIP configuration changed to ssl-clientrenegotation deny:

$ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003)

depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0

—

Certificate chain

0

s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com

i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com

—

Server certificate

—–BEGIN CERTIFICATE—–

—certificate not shown—

—–END CERTIFICATE—–

subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em ailAddress=support@fortinet.com

issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate

Authority/CN=support/emailAddress=support@fortinet.com

—

No client certificate CA names sent

—

SSL handshake has read 2370 bytes and written 316 bytes

—

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

Compression: NONE Expansion: NONE SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA Session-ID:

8253331D266DDE38E4D8A04AFCA9CBDED5B1134932CE1718EED6469C1FBC7474

Session-ID-ctx: Master-Key:

ED05A3EF168AF2D06A486362FE91F1D6CAA55CEFC38A3C36FB8BD74236BF2657D4701B6C1456CEB5BB5EFA

A7619EF12D

Key-Arg : None

Start Time: 1264452957

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)

—

GET /main.c HTTP/1.0

R

RENEGOTIATING

19916:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: Use the following command to check the SSL stats to see that the renegotiations blocked counter is now 1:

diagnose firewall vip virtual-server stats ssl ssl client connections total 0 active 0 max 0

handshakes total 4 active 0 max 0 completed 4 abbreviated 0 session states total 4 active 4 max 4

cipher-suite failures 0

embryonics total 0 active 0 max 0 terminated 0

Disabling SSL/TLS re-negotiation

renegotiations blocked 1

server connections total 0 active 0 max 0

handshakes total 3 active 0 max 0 completed 2 abbreviated 1 session states total 1 active 1 max 1

cipher-suite failures 0

internal error 0 bad handshake length 0 bad change cipher spec length 0 pubkey too big 0 persistence

find 0 found 0 clash 0 addr 0 error 0

If the virtual server debug log is examined (diagnose debug appl vs -1) then at the point the re-negotiation is blocked there is a log:

vs ssl 12 handshake recv ClientHello vs ssl 12 handshake recv 1

(0100005403014b5e056c7f573a563bebe0258c3254bbaff7046a461164f34f94f4f3d019c418000026

00390038003500160013000a00330032002f00050004001500120009001400110008000600030201000

00400230000) vs ssl 12 client renegotiation attempted rejected, abort

vs ssl 12 closing 0 up vs src 12 close 0 in vs src 12 error closing vs dst 14 error closing vs dst 14 closed vs ssl 14 close vs sock 14 free vs src 12 closed vs ssl 12 close vs sock 12 free