Best Practices

FortiOS 7.0.0
FORTINET DOCUMENT LIBRARY
[Link]

FORTINET VIDEO LIBRARY

[Link]

FORTINET BLOG
[Link]

CUSTOMER SERVICE & SUPPORT

[Link]

FORTINET TRAINING & CERTIFICATION PROGRAM

[Link]

FORTINET TRAINING INSTITUTE

[Link]

FORTIGUARD LABS
[Link]

END USER LICENSE AGREEMENT

[Link]

FEEDBACK
Email: techdoc@[Link]

February 21, 2025

FortiOS 7.0.0 Best Practices
01-700-688731-20250221
 TABLE OF CONTENTS
Change Log 5
Getting started 6
Registration 6
Basic configuration 6
Resources 7
Administrator access 9
Management network 9
User authentication for management network access 9
Who can access the FortiGate 10
What can administrators access 10
How can users access the FortiGate 10
Administrative settings 10
Day to day operations 12
Configuration changes 12
Policy configuration changes 13
Logging and reporting 14
Performance monitoring 14
Identity and access management 15
Certificates 17
Certificate usage 17
Security profiles 19
Opened ports for Authentication Override in Web Filter Replacement Messages 20
SSL/TLS deep inspection 21
Migration 23
Migrating a FortiGate configuration manually using configuration files 24
Remote access 26
SSL VPN 26
IPsec VPN 27
Non-VPN remote access 27
High availability and redundancy 28
High availability 28
Redundant and aggregate links 28
SD-WAN 29
Disaster recovery 30
Security rating 31
Network security 32
Policies 32
VPN 34

FortiOS 7.0.0 Best Practices 3

Fortinet Inc.
 Hardening 35
Physical security 35
Vulnerability - monitoring PSIRT 36
Firmware 36
Encrypted protocols 36
Strong ciphers 37
FortiGuard databases 37
Penetration testing 37
Denial of service 37
Secure password storage 38
Configuration backup 38
Firmware change management 40
Understanding the new version 40
Reasons to upgrade 40
Preparing an upgrade plan 41
Business aspects of the upgrade 41
Technical and operational aspects of the upgrade 41
Executing the upgrade plan 42
Learning more about change management 43

FortiOS 7.0.0 Best Practices 4

Fortinet Inc.
Change Log

Date Change Description

2021-09-24 Initial release.

2022-01-28 Updated Hardening on page 35.

2022-04-13 Updated Security rating on page 31.

2022-05-18 Updated Hardening on page 35.

2022-05-26 Added Firmware change management on page 40.

2022-07-15 Added Virtual IPs on page 33.

2022-10-13 Updated Security rating on page 31.

2022-10-14 Updated Security profiles on page 19.

2022-10-21 Updated Hardening on page 35.

2023-03-03 Updated Security profiles on page 19.

2023-06-13 Updated Identity and access management on page 15, Certificate usage on page 17, and
Encrypted protocols on page 36.

2023-08-25 Added Configuration backup on page 38.

2023-09-27 Updated Hardening on page 35.

2023-12-20 Updated Firmware change management on page 40.

2024-04-08 Added Migrating a FortiGate configuration manually using configuration files on page 24.

2024-05-06 Updated Hardening on page 35.

2024-09-09 Updated Identity and access management on page 15.

2025-02-21 New section Policy configuration changes on page 13.

2025-05-27 Updated Security rating on page 31.

FortiOS 7.0.0 Best Practices 5

Fortinet Inc.
Getting started
FortiGate is a complex security device with many configuration options. The following are the first steps to take when
preparing a new FortiGate for deployment:
l Registration on page 6
l Basic configuration on page 6
l Resources on page 7

Registration
The FortiGate, and then its service contract, must be registered to have full access to Fortinet Customer Service and
Support, and FortiGuard services. The FortiGate can be registered in either the FortiGate GUI or the FortiCloud support
portal. The service contract can be registered from the FortiCloud support portal.
To verify the license status on the FortiGate, go to System > FortiGuard and check the License Information table. There
can be a delay of a few hours between when you register your device and when the license information on the FortiGate
is updated.
The License Information table can be used to confirm that the FortiGate is receiving the latest updates. Expand a service
in the table and hover over a version to see the day it was last updated. Some services have daily updates, but others will
remain unchanged for a longer period of time. For example, the AV engine can stay unchanged for months, while the AV
signature database can receive multiple updates a day.
If you are not receiving updates, ensure that the FortiGate's communication with FortiGuard is uninterrupted (see the
FortiOS Ports guide), and check the FortiGuard troubleshooting section in the FortiOS Administration Guide.

Basic configuration
As the first step on a new deployment, review default settings such as administrator passwords, certificates for GUI and
SSL VPN access, SSH keys, open administrative ports on interfaces, and default firewall policies.
As soon as the FortiGate is connected to the internet it is exposed to external risks, such as unauthorized access, man-
in-the-middle attacks, spoofing, DoS attacks, and other malicious activities from malicious actors. Either use the start up
wizard or manually reconfigure the default settings to tighten your security from the beginning.
For instructions on connecting to your devices GUI and CLI, see the FortiOS Administration Guide and the FortiGate
QuickStart Guides.
l Operating mode:
NAT mode is preferred for security purposes. NAT mode policies translate addresses in a more secure zone from
users that are in a less secure zone using a NATed IP address or IP address pool. This layer of obfuscation

FortiOS 7.0.0 Best Practices 6

Fortinet Inc.
Getting started

prevents malicious actors on the internet from knowing the IP addresses of the resources in your LAN and DMZ.
Use transparent mode when a network is complex and does not allow for changes in the IP addressing scheme.
l Firmware:
If the shipped firmware is not the firmware that you will be running, either load the required firmware before doing
any configuration, or establish remote access for the additional firmware upload options (SFTP, FTP, SCP, HTTPS)
and then load the required firmware.
l Hostname:
Use a meaningful hostname. It is used in the CLI prompt, as the SNMP system name, as the FortiGate Cloud device
name, and as the device name in an HA configuration.
l System time:
Several FortiGate features rely on an accurate system time, such as logging and certificate related functions. It is
recommended that you use a Network Time Protocol (NTP) or Precision Time Protocol (PTP) server to set the
system time. If necessary, the system time can be set manually.
l Administrator password:
The admin administrator password must be set when you first log in to the FortiGate. Ensure that the password is
unique and has adequate complexity.
l Management interface:
Configure the IP address, subnet mask, and only the required administrative access services (such as HTTPS and
SSH) on the management interface.

Resources
Fortinet provides many resources to help you configure and use Fortinet devices, software, and services:

Fortinet Document Library Access Fortinet product documentation, including

[Link] administration guides, reference manuals, release
notes, hardware manuals, and QuickStart guides.

Fortinet Video Library Become proficient in Fortinet technology with free,

[Link] learn-as-you-go, videos.

Fortinet Community A central repository of technical notes, tips,

[Link] troubleshooting and debugging, and instructions
primarily provided by the technical support team.

FortiGuard Labs Information on the latest internet threats, security

[Link] advisories, hot bulletins, and malware through the
threat encyclopedia. This database has more than
four million records and provides access to the
signature database.
The FortiGuard network resources helps you keep up
to date with the security landscape through
Advisories & Reports, FortiGuard services, and a
Resource library.

FortiOS 7.0.0 Best Practices 7

Fortinet Inc.
Getting started

Fortinet Blog Read articles and essays about a variety of security

[Link] related topics.

Customer Service & Support (FortiCloud) Start a chat, open a ticket, or call in for immediate
[Link] service. Be aware of your support SLA with regards
to receiving assistance based on the issue severity
and Return Merchandise Authorization (RMA)
replacement times.

Forti-Companions The Forti-Companion to Technical Support and Forti-

[Link] Companion to RMA Services documents provide
information to help you make the best use of the
Technical Support and RMA services.

Professional Services Assistance with configuring your FortiGate, and other

[Link] Fortinet products.
services/professional-services

Fortinet Training Institute Sign up for computer based or instructor led training
[Link] and hands on labs.

FortiOS 7.0.0 Best Practices 8

Fortinet Inc.
Administrator access
Give special attention to management traffic that is accessing the FortiGate. When access to the FortiGate is insecure,
so is the traffic that it passes. The following information can help you prevent unwanted access to your FortiGate:
l Management network on page 9
l User authentication for management network access on page 9
l Administrative settings on page 10

Management network
There are many benefits to using a management network for administrative access to your network devices:
l Reliability:
When management traffic is independent from production or business traffic, it does not have to compete for
resources and management access can be maintained when reconfiguring the production network.
l Simpler policies:
Using a management interface allows for policy separation of the management and production traffic. Policies with
specific purposes are easier to understand and troubleshoot.
l Security:
It is more difficult to access network devices on the production network when their management access is on a
separate network.
A single interface or VLAN interface in the management network should be dedicated for all administrative access.
Administrative access should be disabled on all other interfaces.

Avoid using the WAN interface, or a publicly exposed interface, for management, as it will be
subject to constant attacks.

User authentication for management network

access
Controlling who can access the FortiGate, and what permission they have, is integral to the security of your network.

FortiOS 7.0.0 Best Practices 9

Fortinet Inc.
Administrator access

Who can access the FortiGate

Users can log in to the FortiGate by authenticating locally with the FortiGate, or with a remote access server that is
integrated with the FortiGate, such as LDAP or RADIUS servers.
For local accounts on the FortiGate, define a password policy to ensure a minimum complexity level.
Remote authentication servers enforce their own password policies. They also provide more configuration options. For
example, you can use pre-defined security groups to enable access to a group of users. If an administrator's access
needs to be removed, when their account is disabled in the remote access server, they are no longer able to log in to the
FortiGate.
Do not use shared accounts to access the FortiGate. Shared accounts are more likely to be compromised, are more
difficult to maintain as password updates must be disseminated to all users, and make it impossible to audit access to
the FortiGate.
In addition to accounts for GUI and CLI administration, the FortiGate can be managed with API calls by API users who
are required to generate authorization tokens for REST API messages. If the FortiGate is managed by running scripts
over SSH, authenticate users using certificates to avoid storing and maintaining passwords in the application that is
making the SSH connection.

What can administrators access

The features that an administrator can access should be limited to the scope of that administrator's work to reduce
possible attack vectors. The access profile tied to the user account defines the areas on the FortiGate that the
administrator can access, and what they can do in those areas. The list of users with access should be audited regularly
to ensure that it is current.

How can users access the FortiGate

Limit access to the FortiGate to a management interface on a management network. Trusted hosts can also be used to
specify the IP addresses or subnets that can log in to the FortiGate.
When authenticating to the FortiGate, implement multi-factor authentication (MFA). This makes it significantly more
difficult for an attacker to gain access to the FortiGate.

Administrative settings
The following general administrative settings are recommended:
l Set the idle timeout time for administrators to a low value, preferably less that ten minutes.
l Use non-standard HTTPS and SSH ports for administrative access.
l Disable weak encryption protocols.
l Disable the maintainer account if the FortiGate device's physical security cannot be guaranteed.

FortiOS 7.0.0 Best Practices 10

Fortinet Inc.
Administrator access

The built-in maintainer account is used to log in to the FortiGate if you have lost all administrator credentials.
Physical access to the FortiGate device is required. If maintainer account is disabled and you lose all of your
administrator credentials, then you will no longer be able to access to access the FortiGate and it will need to be
reset to factory default settings.
l Replace the certificate that is offered for HTTPS access with a trusted certificate that has the FQDN or IP address of
the FortiGate.
l Configure the Fortinet Security Fabric when multiple FortiGates and fabric devices are used. It provides a single-
pane-of-glass administration, allowing administrators access to each device in the fabric using SSO.
A Fortinet Security Fabric includes a root FortiGate, downstream FortiGates, and other Fortinet fabric devices. A
maximum of 35 downstream FortiGates is recommended.

FortiOS 7.0.0 Best Practices 11

Fortinet Inc.
Day to day operations
The two primary reasons to interact with the FortiGate are to make configuration changes, and to check the logs and
device performance information.
l Configuration changes on page 12
l Logging and reporting on page 14
l Performance monitoring on page 14

Configuration changes
Configuration changes on the FortiGate after its initial setup should follow a change procedure as part of your change
management plan.
For example, the following is a possible change procedure for changes to the FortiGate configuration:
l Make sure that all of the affected parties are aware of the upcoming change and have a platform to provide input.
l Define the required changes and the objective, to keep the task focused.
l If creating or changing policies, note the following:
l The purpose of the policy,
l The affected services, applications, users, and devices,
l The date that the policy is added and, if applicable, the date that it expires,
l The name of the person who added or edited the policy.
l Define the possible risks, and plans to mitigate them.
l Define a contingency, or back-out, plan.
l Create a backup of the working configuration before making any changes.
l Prepare a well defined workflow. This can be particularly important if multiple teams are involved.
l Schedule a maintenance window.
l Test the changes, and have them validated by any affected parties.
l Audit and document the completed work.
l Create a backup of the new configuration.

Always maintain a backup of the FortiGate's working configuration. Keeping multiple past
configurations is recommended. Backups can be created in the GUI, CLI, and API, and on
FortiManager and FortiCloud.

FortiOS 7.0.0 Best Practices 12

Fortinet Inc.
Day to day operations

Policy configuration changes

In environments with high traffic loads, firewall policy configuration changes or a routing change can significantly affect
established sessions and device’s CPU usage. On a heavy-loaded system, plan configuration changes during low usage
periods to minimize impact on CPU usage and established sessions.
When traffic flows through a firewall policy and sessions for that traffic are established and offloaded to hardware (i.e.
hardware-accelerated), and if any changes are made to configuration of firewall policy, FortiOS flags those sessions as
dirty. Similarly, any routing change also affects the corresponding sessions associated with the modified routes, are also
flagged dirty. A session flagged as dirty requires revalidation by FortiGate’s CPU. A session revalidation refers to the
process when FortiGate’s CPU verifies whether an established session’s attributes (i.e. src, dst, sport, dport,
dintf, policy etc.) conforms to the latest firewall policy or route change. If a large number of active sessions get
affected by a policy or route change, session revalidation can engage the CPU and thus result in CPU spikes.
During revalidation of sessions that flagged as dirty, if the session attributes conforms with the latest changes made to
firewall policy, the session remains unaffected. If the firewall policy configuration or routing changes do not align with
session attributes, such sessions are flagged as blocked and are removed from session table. Any traffic for such
sessions is dropped. For more information, see Using a session table.
You can use the the firewall-session-dirty option of the config system settings command to control how
FortiOS handles session revalidation during policy or routing changes. This option determines how the CPU revalidates
current and new sessions.
config system settings
set firewall-session-dirty {check-all | check-new | check-policy-option}
end

check-all the default option. The CPU flags current sessions that are affected by a firewall policy change or routing
change, as dirty. These sessions are revalidated to check whether they conform with the firewall policy and routing
configuration. If a sessions does not conform, it is flagged as blocked and removed from the session table and traffic
using this session is dropped.
check-new the CPU flags current sessions as persistent. Persistent sessions are not revalidated against new
firewall policy or routing changes. This reduces CPU load and packet loss. Firewall policy and routing changes only
apply to new sessions.
Only sessions created after setting firewall-session-dirty to check-new are flagged as persistent. Sessions
that existed before enabling check-new are not affected by this setting and are revalidated after a policy or routing
configuration change.
check-policy-option this option allows you to configure whether individual policies or routes are revalidated after a
policy or routing configuration change. For example:
config firewall policy
set firewall-session-dirty {check-all | check-new}
end

check-all enforces the latest firewall policy configuration and route updates for sessions,
optimizing security. check-new applies firewall policy and route change to new sessions only,
optimizing performance. You can use these options to balance security vs performance based
on your organization's priorities.

FortiOS 7.0.0 Best Practices 13

Fortinet Inc.
Day to day operations

Logging and reporting

Logging generates system event, traffic, user login, and many other types of records that can be used for alerts,
analysis, and troubleshooting. The records can be stored locally (data at rest) or remotely (data in motion). Due to the
sensitivity of the log data, it is important to encrypt data in motion through the logging transmission channel.
Communication with FortiAnalyzer and FortiCloud is encrypted by default. When logging to third party devices, make
sure that the channel is secure. If it is not secure, it is recommended that you form a VPN to the remote logging device
before transmitting logs to it.
Logging options include FortiAnalyzer, syslog, and a local disk. Logging with syslog only stores the log messages.
Logging to FortiAnalyzer stores the logs and provides log analysis . If a security fabric is established, you can create
rules to trigger actions based on the logs. For example, sending an email if the FortiGate configuration is changed, or
running a CLI script if a host is compromised. If you are using a standalone logging server, integrating an analyzer
application or server allows you to parse the raw logs into meaningful data.
FortiSIEM (security information and event management) and FortiSOAR (security orchestration, automation, and
response) both aggregate security data from various sources into alerts. The FortiSOAR can also automate responses
to different alerts.

Performance monitoring
FortiGate supports multiple protocols for monitoring resource utilization, such as SNMPv3, NetFlow, and sFlow. These
protocols are used to measure the performance of the FortiGate and provide insight into the traffic that it is passing.
SNMP polling and traps can be used to optimize monitoring, and the results should be collected and consolidated into
meaningful output. A variety of third party SNMP reporting applications can be used to analyze collected results.
Resource monitoring helps to establish resource utilization baselines that can be useful for:
l Configuring IPS signature rates.
l Recognizing abnormal activity, such as when an attack is occurring.
l Comparing the bandwidth utilization over specific time spans, such as month to month or year to year, to plan for
growth.
l Comparing the bandwidth utilization between different WANs, and applying SD-WAN and traffic shaping as needed.
l Tuning security profiles to optimize resource usage.

FortiOS 7.0.0 Best Practices 14

Fortinet Inc.
Identity and access management
Secure authentication is paramount in the implementation of an effective security policy. Many of the most damaging
security breaches are due to compromised user accounts. By identifying and authenticating users, a significantly more
granular control can be implemented to ensure that the right users are accessing the right network resources.
FortiGate supports identifying users in many different ways, including but not limited to:
l Local: The username and password are stored on the FortiGate.
l Remote: The username and password are stored on a remote server, such as LDAPS or TACACS+, that the
FortiGate queries.
l PKI/peer: Users that authenticate using a client certificate.

When configuring an LDAP connection to an Active Directory server, an administrator must

provide Active Directory user credentials.
l To secure this connection, use LDAPS on both the Active Directory server and FortiGate.

See Configuring an LDAP server.

l Apply the principle of least privilege. For the LDAP regular bind operation, do not use
credentials that provide full administrative access to the Windows server when using
credentials. See Configuring least privileges for LDAP admin account authentication in
Active Directory.
l When connecting to RADIUS over UDP, it is recommended to ensure the FortiGate and
RADIUS connection passes through a trusted network or the connection passes through
an encrypted tunnel over untrusted networks. If the traffic must pass through an untrusted
network without going through an encrypted tunnel, consider upgrading to FortiOS 7.4.0
or later, where RADSEC over TLS is supported as a transport protocol.

Authentication can be configured for:

l Administrative access
l Firewall authentication and SSO
l VPN
l Wireless security
l 802.1X port security
The most effective authentication includes more than one of the following:
l Something that the user knows: a username and password
l Something that the user has: a certificate, a one time password (OTP) in the form of a token or code either sent to
the user over email or SMS, or generated by a hardware token or authenticator app.
l Something specific to the user: biometric data, such as a fingerprint
Single sign-on (SSO) can be used to reduce user fatigue by allowing users to only authenticate one time to gain access
to all permitted resources.
FortiClient provides a solution to user and device identification, and can function as an SSO agent. It is also part of the
Zero Trust Network Access (ZTNA) solution, allowing security posture checks along with authentication.

FortiOS 7.0.0 Best Practices 15

Fortinet Inc.
Identity and access management

Note that, when implementing MFA on the FortiGate, a FortiToken can only be registered to one FortiGate at a time. If
you use a remote authentication server for MFA, then each FortiGate points to the server. FortiAuthenticator and
FortiToken Cloud are remote authentication servers that can manage the FortiTokens for multiple FortiGates at the
same time. This allows you to use one token per user across multiple FortiGates.

FortiOS 7.0.0 Best Practices 16

Fortinet Inc.
Certificates
Certificates serve three primary purposes:
1. Authentication
The Common Name (CN) and/or Subject Alternative Name (SAN) fields are used to identify the device that the
certificate is representing.
2. Encryption and decryption
Private and public key pairs are used to encrypt and decrypt traffic.
3. Integrity
Messages are hashed using a secret key known to both the sender and the receiver. The receiver uses the key to
check the hash value and confirm the message's data integrity and authenticity.
Certificate based authentication has several advantages over password based authentication. While password based
authentication relies on secrets that are defined and managed by a user, certificate based authentication uses secrets
that are issued and managed by the certificate authority. Certificates are more secure than passwords, because the
private key in the certificate has high cryptographic strength, which a user defined password does not usually have.
The CA vouches for the certificates that it signs. If the endpoint has the CA root certificate installed, then it trusts the CA
and anything that the CA signs. There are three types of CAs:
l Public CA
Public, or well-known, CAs charge a fee to sign your certificate. Many systems come with these CA root certificates
pre-installed.
l Let's Encrypt
Let's Encrypt is a free, automated, and open CA. FortiGate includes an Automated Certificate Management
Environment (ACME) to directly interact with Let's Encrypt. Some legacy systems might not have the Let's Encrypt
CA root certificate installed.
l Private CA
Private CAs are created by an organization that creates its own local CA instead of using an external CA. It
functions the same as a public CA, but the root certificate is not pre-installed on anything. FortiAuthenticator,
Microsoft Server, OpenSSL, and XCA can all function as CAs.
Regardless of what kind of CA is used, involved devices must have the CA root certificate installed in order to trust the
certificate that it signs.

Certificate usage
FortiOS leverages certificates in multiple areas, such as administrative access, ZTNA, SAML authentication, LDAPS,
VPNs, communication between Fortinet devices and services, deep packet inspection, and authenticating Security
Fabric devices.

FortiOS 7.0.0 Best Practices 17

Fortinet Inc.
Certificates

When configuring an LDAP connection to an Active Directory server, an administrator must

provide Active Directory user credentials.
l To secure this connection, use LDAPS on both the Active Directory server and FortiGate.

See Configuring an LDAP server.

l Apply the principle of least privilege. For the LDAP regular bind operation, do not use
credentials that provide full administrative access to the Windows server when using
credentials. See Configuring least privileges for LDAP admin account authentication in
Active Directory.

The default Fortinet factory self-signed certificates are provided to simplify initial installation and testing. Replace any
used certificates with certificates that are signed by a trusted CA and specific to that FortiGate
Certificates can be uploaded to the FortiGate in multiple ways:
l Automated Certificate Management Environment (ACME),
l Simple Certificate Enrollment Protocol (SCEP),
l Uploading a certificate in the GUI or CLI,
l Creating a Certificate Signing Request (CSR), having it signed by a CA, then uploading the certificate.

FortiOS 7.0.0 Best Practices 18

Fortinet Inc.
Security profiles
Security profiles define what to inspect in the traffic that the FortiGate is passing. When traffic matches the profile, it is
either allowed, blocked, or monitored (allowed and logged).
The protection that a profile provides, and the information that it monitors, can be configured to your requirements, but
increased inspection uses more of the FortiGate's resources. Assess your policies' traffic matching, and then apply the
necessary level of protection. You might consider implementing denial of service (DoS) security policies to detect and
drop illegitimate traffic before it reaches the more resource intensive security profiles (see Denial of service on page 37
for more information).
Security profiles can use flow or proxy mode inspection. Apply flow mode inspection to policies that prioritize traffic
throughput, and proxy mode when thoroughness is more important than performance. Under normal traffic conditions,
the throughput difference between the two modes is insignificant. For resource optimization, using one mode uniformly
across all of the policies is recommended.
Each security profile generates its own log type that contains some log fields that are not present in other logs. This can
be important when reviewing or analyzing the logs to assess or troubleshoot user traffic. For example, if no web filtering
is applied, then you will not have insight or control of users' browsing information.
The following table lists some basic examples of how a security profile could be used on an edge FortiGate, where
inbound traffic goes from the internet to an internal resource using a VIP, and outbound traffic goes from your network to
an internet resource:

Security profile Inbound traffic Outbound traffic

Antivirus1 Protect external resources from malware, Scan requested user traffic for malware.
such as HTTP PUT requests or FTP uploads.

Web filter Not usually applied to inbound traffic. Monitor and block user web traffic based on
categories and domains.

Video filter Not usually applied to inbound traffic. Monitor and restrict YouTube videos based
on categories or channels.

DNS filter Not usually applied to inbound traffic. Monitor and filter DNS lookups based on
domain ratings.
Block requests for known compromised
domains.

Application control Make sure that specific protocols are used to Monitor and filter applications on any port.
access specific ports.
For example, only allow SSH traffic to be sent
and received over port 22.

Intrusion prevention Protect external services from known exploits Block connections to botnet sites.
and protocol anomalies.

FortiOS 7.0.0 Best Practices 19

Fortinet Inc.
Security profiles

Security profile Inbound traffic Outbound traffic

File filter Prevent uploading files based on the file type Prevent downloading files based on the file
and the protocol that is used. type and the protocol that is used.

Email filter Perform spam detection and filtering. Prevent specific IP address or subnets from
sending and receiving email messages.
Block messages that contain specific words.

Data leak prevention Prevent sensitive data from entering your Prevent sensitive data, such as credit card
network. numbers or SSNs, from leaving your network.

VoIP Allow SIP and SCCP traffic, and protect your Secure clients that are connecting to external
network from SIP and SCCP based attacks. SIP servers.

ICAP Offload tasks to separate, specialized Offload tasks to separate, specialized

servers. servers.

Web application Detect and block known web application Not usually applied to outbound traffic.
firewall attacks, such as SQL injection, XSS, and
known exploits.

1
Antivirus profiles can submit files to FortiSandbox for further inspection. This enables the detection of zero-day
malware, and threat intelligence that is learned from submitted malicious and suspicious files supplements the
FortiGate’s antivirus database and protection.

Opened ports for Authentication Override in Web

Filter Replacement Messages
When a firewall policy is configured with a web filter, AV or application control, or other UTM security profiles, the policy
may open up one or more of ports 8008, 8010, 8015 or 8020 for authentication override and data retrieval for
replacement messages, depending on the inspection mode.
When a port is open and you try to access the port on HTTP, this may result in the following behavior:
l FortiGate replies and then redirects to the port with a block message.
l FortiGate sends a TCP RST to close the connection.
l FortiGate doesn’t respond.
l FortiGate does a TCP 3-way handshake, then sends a FIN to close the connection.
Traffic does not leak through the policy. However, in some scenarios such as testing the FortiGate for open ports against
PCI compliance, this may result in failure of the test case.
To work around the issue, you can close the above ports by doing the following:
config webfilter fortiguard
set close-ports enable
end

FortiOS 7.0.0 Best Practices 20

Fortinet Inc.
Security profiles

When close-ports is enabled:

l FortiGuard web filter actions Warning and Authenticate in proxy and flow inspection
mode will not work.
l Allow users to override blocked categories will not work.
l The replacement message will not display the Fortinet logo.
FortiGuard and Local URL Filter blocking will not be affected.

When VDOM is enabled, edit the settings in global:

config global
config webfilter fortiguard
set close-ports enable
end
end

In the case of Application Control, use the following to disable the use of replacement messages and port 8008:
config application list
edit <list>
set app-replacemsg disable
next
end

If it is acceptable to simply change the ports to a high ephemeral port, the override ports can be changed from here:
l Default:
config webfilter fortiguard
set ovrd-auth-port-http 8008
set ovrd-auth-port-https 8010
set ovrd-auth-port-https-flow 8015
set ovrd-auth-port-warning 8020
end

l Update:
config webfilter fortiguard
set ovrd-auth-port-http <high port>
set ovrd-auth-port-https <high port>
set ovrd-auth-port-https-flow <high port>
set ovrd-auth-port-warning <high port>
end

SSL/TLS deep inspection

TLS encryption is used to secure traffic, but the encrypted traffic can be used to get around your network's normal
defenses. SSL/TLS deep inspection allows firewalls to inspect traffic even when they are encrypted. When you use deep
inspection, the FortiGate serves as the intermediary to connect to the SSL server, then decrypts and inspects the
content to find threats and block them. It then re-encrypts the content with a certificate that is signed by the FortiGate,
and sends it to the real recipient. The FortiGate acts as a subordinate CA to sign the certificate on the fly, as it re-
encrypts traffic. The FortiGate usually uses a subordinate CA certificate that is signed by the company's private CA, such

FortiOS 7.0.0 Best Practices 21

Fortinet Inc.
Security profiles

as a FortiAuthenticator or a Windows server with certificate services. For information about uploading a CA certificate
and private key for deep inspection, see Certificates in the FortiOS Administration Guide.
To implement seamless deep inspection, users must trust the certificate that is signed by the FortiGate, and there must
be certificate chain back to the trusted root CA that is installed on the user's endpoint. If the root certificate is not
installed, the user receives a certificate warning every time they access a website that is scanned by the FortiGate using
deep inspection. Administrators should provide the CA certificate to the end users if deep inspection will be used.
Users should be made aware that their communication is subject to these security measures, and that their privacy while
protected by a FortiGate that is performing deep inspection cannot be guaranteed. Performing deep inspection might be
undesirable when users are accessing certain web categories, such banking or personal health related sites. When
creating SSL/SSH inspection profiles that use full SSL inspection, the Finance and Banking, Health and Wellness, and
Personal Privacy categories are exempt from inspection by default. Administrators can customize these categories,
enable Reputable websites, and add individual addresses to the SSL exemptions as required.

FortiOS 7.0.0 Best Practices 22

Fortinet Inc.
Migration
There are two primary reasons to migrate a FortiGate:
l A FortiGate is been replaced with a different model.
l A different firewall is being replaced with a FortiGate.
The following steps can be used to help with you migration:
1. Audit the current configuration:
l Remove any unused objects or policies.
l Analyze the existing policies by assessing traffic flow through the FortiGate and defining what the traffic should
look like to determine if any of the policies can be combined.
2. Create diagrams mapping the existing firewall to the new FortiGate.
For example, port1 on the old firewall could be port2 on the new FortiGate.
3. Configure the general settings first:
l Interface settings: IP addresses, alias, management access, VLANs
l Routing: static and dynamic routes
l HA, if applicable
l Administrative settings: user account, remove authentication server integration, SNMP, logging, and others
l Certificates
4. Create the used objects on the FortiGate.
5. Create policies
l Separate them into sections applicable to your use case and configure them one at a time, for example: by
business group (HR, accounting), or by application or service (email, CRM).
6. Create an acceptance test plan:
l This must be executed as part of the cut-over maintenance window.
l Have an employee from each affected section verify functionality after the cut-over.
l If applicable, test HA failover.
7. Verify that the migration worked as planned as far as is possible. A lab that can simulate your normal traffic makes
this much easier.
8. Install the new FortiGate during the maintenance window.
l If possible, install the new FortiGate alongside the existing firewall and only cut-over a small, select group of
users.
l Have a back-up plan in the event that the cut-over does not go as planned.
9. Run user acceptance testing:
l Have all affected parties ensure that their requirements are unaffected by the change.
Fortinet offers FortiConverter as a one time, paid service that helps migrate configurations to a new FortiGate. It reduces
migration complexity, and eliminates common migration configuration errors. For details on purchasing the
FortiConverter service, contact you Fortinet sales partner or reseller. After the configuration generated by FortiConverter
has been loaded onto the target device, Fortinet technical support or Technical Assistance Center (TAC) can assist with
any issues.

FortiOS 7.0.0 Best Practices 23

Fortinet Inc.
Migration

Migrating a FortiGate configuration manually using

configuration files

It is recommended to use FortiConverter to migrate a configuration between FortiGates. For

details, see Migrating a configuration with FortiConverter. Only use this procedure if you do not
have a FortiConverter license. Keep in mind that migrating a configuration manually might
result in errors that require correction.

This procedure describes how to replace existing FortiGate equipment by manually migrating the existing configuration
using the configuration files. This can be done if a FortiGate is being replaced with the same model or if a FortiGate
model is upgraded to a newer model.
Before starting, ensure that you have:
l Access to a plain text editor, such as Notepad++
l An admin administrator account with the super_admin security profile

To manually migrate a FortiGate configuration:

1. Create a backup file of the existing configuration for the old FortiGate device. For details, see Configuration backups
and reset.
2. Upgrade the new FortiGate device to the same firmware version as the old FortiGate device. For details, see
Upgrading individual devices.
3. Create a backup file of the new FortiGate device.
4. Open the backup configuration files for both the old and new FortiGate device models, and replace the config-
version section of the first line of the old FortiGate configuration file with the config-version section of the new
FortiGate configuration file.

If the new and old FortiGate devices have the same model number, for example swapping
a FG-80 device with another FG-80 device, the first line in both configuration files should
be the same. If the new FortiGate device is a different model number from the old
FortiGate device, for example swapping a FG-80 device for a FG-100 device, update the
configuration version in the first line of the configuration file. For example:
#config-version=FGT80F-7.0.6-FW-build0366-
220606:opmode=0:vdom=0:user=admin
#config-version=FGT100F-7.0.6-FW-build0366-
220606:opmode=0:vdom=0:user=admin

5. Review the configuration file on the old FortiGate device, and edit the configuration file to ensure the rest of file
matches the interface layout for the new FortiGate device setup.

This step is only required when swapping a FortiGate device with a different model number
than the old FortiGate device, for example swapping a FG-80 device with a FG-100
device. If the FortiGate replacement device has the same model number, for example
swapping a FG-80 device with another FG-80 device, skip this step.

FortiOS 7.0.0 Best Practices 24

Fortinet Inc.
Migration

6. Restore the modified configuration file from the old FortiGate device into the new FortiGate device. Once the
configuration file is restored in the new FortiGate device, reboot the device.
7. Once the reboot is complete, review the error log for any import errors. If any errors are present, compare the two
configuration files from both the modified old FortiGate device and the new FortiGate device and correct the errors.
Use this command in the CLI to check for errors:
#diag debug config-error-log read
Once all errors are corrected, restore the modified configuration file into the new FortiGate device again and reboot
the device. Repeat this step until all errors are gone.
8. Once the device reboots with no errors, swap the cables from the old FortiGate device to the new FortiGate device.
Any FortiSwitch devices connected to the FortiGate should keep their previous configuration.

FortiOS 7.0.0 Best Practices 25

Fortinet Inc.
Remote access
The number of remote workers is increasing, and networks are expanding into thin branch networks and the cloud.
Secure remote access is advancing to meet the requirements of increasingly distributed environments. Assess your
requirements and review the available options to determine the solution that best meets your requirements.
Fortinet has IPsec and SSL VPN options. SSL VPN has two modes: tunnel and web.
l SSL VPN on page 26
l IPsec VPN on page 27
l Non-VPN remote access on page 27
Regardless of the chosen remote access method, there are several options to enhance the security of the connection:
l Remote authentication servers
Integrating a remote server for user accounts avoids duplicating accounts on the FortiGate, enabling scalability and
reducing human caused errors.
l Certificates
As a VPN gateway, the FortiGate that you are connecting to can utilize server certificates to prove its identity to the
connecting device without requiring confirmation from the end user.
User certificates can be used in place of passwords. Administrators should assign a unique certificate to each user.
l Multi-factor authentication
MFA increases the difficulty for an attacker that is trying to establish a connection using a compromised account.
l TLS version and cipher suites
Setting a minimum TLS version and using high strength cipher suites can enhance security.

SSL VPN
Choosing a mode of operation and applying the proper levels of security depends on your specific environment and
requirements.
In tunnel mode, the SSL VPN client encrypts all traffic from the remote client computer and sends it to the FortiGate
through an SSL VPN tunnel over the HTTPS link between the user and the FortiGate. It supports a wide range of
applications, and provides a transparent user experience when properly configured. FortiClient might enable a DTLS
tunnel that allows the SSL VPN to encrypt traffic using TLS, and uses UDP as the transport layer instead of TCP. This
avoids retransmission issues that can occur with TCP-inTCP that result in lower throughput. For information on
troubleshooting slow SSL VPN throughput, see Troubleshooting common issues in the FortiOS Administration Guide.
Web mode provides clientless network access using a web browser with built-in SSL encryption. It is easier to set up
than tunnel mode and does not require that an application be installed on the endpoint, but it has limited application
support and requires more resources on the FortiGate.
For more information, see SSL VPN best practices in the FortiOS Administration Guide.

FortiOS 7.0.0 Best Practices 26

Fortinet Inc.
Remote access

IPsec VPN
IPsec VPN is a standard protocol that allows a variety of solutions for endpoint connectivity, including FortiClient.
It is a well defined protocol that uses specific ports, and it is not uncommon for ISPs to block these ports. On the
FortiGate, administrators can configure the ports used for IKE (UDP 500 and 4500) (see Configurable IKE ports). IPsec
also has the option to accept a peer ID to specify a tunnel if several tunnels exist on the same interface.
For more information, see IPsec VPNs in the FortiOS Administration Guide.

Non-VPN remote access

In addition to SSL and IPsec VPN, Fortinet offers more advanced solutions for distributed environments:
l Zero Trust Network Access
l FortiSASE SIA

FortiOS 7.0.0 Best Practices 27

Fortinet Inc.
High availability and redundancy
Downtime due to an unexpected network failure negatively impacts business operations. For some companies, some
downtime is acceptable; for others, any downtime is unacceptable. Determine your uptime requirements, and ensure
that your network has the resilience to meet those requirements.
Building a resilient network costs more initially, as it can include HA, cold standby spares, multiple internet circuits,
premium supports contracts, and more.

High availability
HA provides resilience not only in the event of a cluster member failing, but also allows for firmware updates without any
downtime. Several HA options are supported by FortiGate: FortiGate Clustering Protocol (FGCP), FortiGate Session
Life Support Protocol (FGSP), Virtual Router Redundancy Protocol (VRRP), and auto scaling in cloud environments.
FGCP is the most commonly used HA solution. It allows two or more FortiGates of the same type and model to be put
into a cluster in Active-Passive (A-P) or Active-Active (A-A) mode. A-P mode provides redundancy by having one or
more FortiGates in hot standby in case the primary device experiences a detectable failure. If a failure occurs, traffic
quickly fails over to a secondary device, preventing any significant downtime. A-A mode allows traffic to be balanced
across the units in the cluster for scanning purposes, and also performs failover. For FortiGates on the network edge, at
least a two unit cluster is recommended.
FGSP is used in more advanced setups that include external load balancers that distribute traffic across the firewall
nodes. FGSP members do not need to have the same network configuration, so they do not need to be in the same
physical location. Each FGSP member usually has identical firewall policies to enforce the same access rules. Sessions
can be failed over from one FGSP member to another if a device failure occurs.
HA is supported on cloud and virtual platforms. In the cloud, HA can be configured in A-P, A-A load balancing, auto-
scaling, and others. See the FortiGate Public Cloud documentation for more information.
FortiGates also support VRRP. This can be an appropriate choice when interoperating with third party routers and
firewalls. Consult public documentation for further details.
Assess your environment and budget to determine what options are most appropriate for your use case.

Redundant and aggregate links

Using multiple interfaces and links adds resiliency if one link fails, and increases throughput at a lower cost than using a
single link with a larger throughput. For example, a 10 GB interface can be less than half the cost of a 20 GB interface.
When using multiple links to connect your FortiGate to the LAN, asses your network for single points of failure. For
example, if both links connect to a single switch, and that switch fails, then you could experience an outage. If a single
FortiGate is used in the network path, a failure on that FortiGate would also disrupt traffic. A full mesh switching solution

FortiOS 7.0.0 Best Practices 28

Fortinet Inc.
High availability and redundancy

along with FortiGate HA could be used so that no single link, switch, or firewall is a point of failure that could disrupt the
entire network. For information on FortiSwitch architectures that can deploy such redundancy, see the FortiSwitch
documentation.

SD-WAN
Traffic bottlenecks and disruptions often occur on the WAN links and ISP networks that are outside of your network
These can be due to bandwidth limitations, link quality, and other outside factors that are affecting your ISP. Using
multiple WAN connections from different vendors can ensure connectivity in the event of an ISP outage and increase
performance and throughput. SD-WAN SLA performance health checks can ensure that your WAN connection is always
available by selecting the next redundant WAN if the quality of the WAN link is degraded.
SD-WAN can also provide application and service based steering. For example, critical traffic can be steered to a more
expensive but more reliable transport link, while less important traffic is steered to a cheaper, higher bandwidth link. After
the rules have been defined, traffic steering happens automatically, with failover occurring as needed based on the link
health monitors. This can save administrative effort, and the panic caused be network outages, while providing a stable
experience for the end users.
For more information about SD-WAN solutions and configurations, see SD-WAN in the FortiOS Administration Guide.

FortiOS 7.0.0 Best Practices 29

Fortinet Inc.
Disaster recovery
It is important to plan what to do in the event that a disaster occurs. Disaster recovery starts with a business continuity
plan. This plan should be all-encompassing, and include your FortiGate.
FortiGate disaster recovery should include:
l A tested plan:
l Without testing the plan, you cannot be sure that it will work.
l Testing helps to uncover oversights and refine the process.
l Configuration backups:
l Backups should be made on a schedule, and after any changes have been made to the configuration.
l It is good practice to evaluate if any unexpected changes occur between backups.
l Remote site assistance:
l Who will load the configuration backup to the FortiGate?
l In the event of an RMA, who will install the replacement FortiGate?
l Do all of the people who will require it have access to the FortiGate?
l Replacement hardware:
l If the device is covered under warranty, what level of support has been purchased?
l What is the agreed expectation for a replacement?
l How will the backup configuration be loaded onto the new device?
After a disaster, review the recovery to asses what worked, what did not work, and what can be improved. Unfortunately,
sometimes a disaster helps get approval for a more robust solution, such as HA or a premium support contract with
better SLAs.

FortiOS 7.0.0 Best Practices 30

Fortinet Inc.
Security rating
Security audit checks are updated to match evolving vulnerability exploits and attacks. The Security Fabric rating service
helps the security and network teams keep up with changing compliance and regulatory standards by identifying
opportunities to improve the system configuration and automate processes. The security rating applies to all devices in
your Security Fabric, and uses real-time monitoring to analyze your Security Fabric deployment, identify potential
vulnerabilities, highlight best practices that can be used to improve the security and performance of your network, and
calculate Security Fabric scores.
The security rating gives grades in the following sections:
l Fabric Security Hardening
l Audit Logging & Monitoring
l Threat & Vulnerability Management
l Network Design & Policies
l Endpoint Management
l Firmware & Subscriptions
l Performance Optimization
The rating also adds consideration for industry standards, such as CIS and PCI. FortiAnalyzer Report feature with the
Attack Surface & Compliance subscription uses Security Rating to provide support for additional compliance reports.
Enabling the Security Rating service allows you to easily identify key deficiencies, take action based on automated
recommendations, secure your entire fabric, and monitor your Security Fabric scores.
Full details about Security Rating including the free and licensed checks available can be found in the Security Rating
Reference Guide.

FortiOS 7.0.0 Best Practices 31

Fortinet Inc.
Network security
Many factors affect how you design your network, the topology that you use, and the placement of your FortiGate in the
network, such as:
l The size of your business and the number of users that you are protecting.
l Your business type and industry - service provider, education, healthcare, retail, hospitality, operational
technologies, and so on.
l The function or functions that the FortiGate is providing, such as network security, fabric management, multi-cloud
security, VPN connectivity, SD-WAN, and so on.
l Who is being protected - employees, customers, students, remote workers, healthcare workers, and so on.
l What is being protected - web servers, office computers, cloud devices, industrial devices, POS terminals, and so
on.
For example, a mid-sized retail company might have a corporate headquarters, multiple branches, and physical and
cloud-based datacenters, with one or more FortiGates and other Fortinet products deployed at each location.
When designing the network, consider the functionality that you are providing at each location, what you are protecting,
and who is allowed access to protected resources. The branches likely have similar or identical setups, and
headquarters and the datacenters have setups specific to those locations' requirements. Considering the network design
factors helps you define the FortiGate's role (edge firewall, branch firewall, internal segmentation firewall, cloud firewall,
and so on), where it is placed in the network, and how to incorporated it and other network solutions into your
environment.
The Fortinet solutions page, [Link] provides information about products and solutions for
different business sizes and industries.

Policies
The FortiGate's primary role is to secure your network and data from external threats. It accomplishes this using policies
and security profiles. Policies control what kind of traffic is allowed where, and security profiles define what to look for in
the traffic.
FortiGate also has an NGFW mode in which you can allow applications and URL categories directly in the policies, and
do not need to define security profiles.
Use the different policy types to secure the different types of traffic that the FortiGate processes.

DoS policies

DoS policies are checked before security policies to prevent attacks from overwhelming your network and FortiGate by
triggering more resource intensive security protection. These policies should be adjusted based on your business traffic
rates (see Performance monitoring on page 14).

FortiOS 7.0.0 Best Practices 32

Fortinet Inc.
Network security

Local-in policies

Local-in policies control access to the FortiGate interfaces. They are often used to block unauthorized access to
management ports or other well known ports, and to limit access from specific sources. They should be used to further
enable or restrict access to the FortiGate based on your security requirements.
Note that extra care should be taken when configuring a local-in policy, as an incorrect configuration could inadvertently
deny traffic for SSL VPN, dynamic routing protocols, HA, and other FortiGate features.

Security policies

l Security policies control the flow of traffic and the security features that are applied to the traffic flow. They are the
most commonly used policy type.
l Each policy should have a unique name and there should not be any unused policies.
l Policies that allow traffic should apply to a specific interface, and not the any interface.
l Only the security profiles that are necessary for the traffic matching policy should be enabled.
l Security policies are evaluated in order. When traffic matches a policy, further policies are not processed. Put the
most specific policies at the top of the list, and follow the least privilege access principle.
l Interface aliases
l It might not be possible to use the same interface on each FortiGate for the same function. Add aliases to the
interfaces so that policies are easier to understand. For example, a policy that controls traffic between you
network and your phones switch is clearer if it shows LAN to Phones, instead of port4 to port2.
l Zones
l Zones are used to group multiple interfaces or subinterfaces into a single interface object that can be used in
policies.
l Grouping interfaces and VLAN subinterfaces into zones simplifies security policy creation by allowing multiple
network segments to use the same policy settings and protection profiles.
l Interfaces in a zone can also still be used individually and still route normally.
l Policies
l Put the most specific, or narrow, policies at the top of the policy list.
l Do not use the all or any objects in a policy, except when routing to the internet.
l Do not override the implicit deny policy.
l Use users in policies. This makes the policy more specific and reduces the chances of unintended traffic
matching.
l To update or modify a policy that is actively passing traffic in a production environment, see Policy
configuration changes on page 13.

Virtual IPs

Policies that include VIPs, or that have match-vip enabled, have priority over other policies.
For example, with the following policies, where Policy 1 comes first in the list, and Policy 2 has a VIP for its destination:

Policy 1 Policy 2

Source [Link] all

Destination all WEB_SERVER

Action deny accept

FortiOS 7.0.0 Best Practices 33

Fortinet Inc.
Network security

Traffic from [Link] to the WEB_SERVER VIP is not blocked, because policy 2 takes priority because it uses a VIP.
If Policy 1 is edited to enable match-vip, then it will have a higher priority and traffic from [Link] to the WEB_
SERVER VIP will be blocked.
config firewall policy
edit 1
set match-vip enable
next
end

Conversely, a VIP could be used in Policy 1 to give it higher priority.

The match-vip command can only be enabled in DENY policies. it is not available in
ACCEPT policies.

VPN
The following VPNs are for connecting disparate sites to your LAN. See Remote access on page 26 for information
about remote user access. There are several was to establish VPN connections between FortiGates, and some that can
be applied to other VPN appliances.

OCVPN

OCVPN is a cloud-based solution to simplify IPsec VPN setup. It automatically generates the IPsec configuration,
including static routes and policies, on all of the FortiGates in the FortiCare account. It includes self-learning for updates
on a FortiGate, such as changing the public IP address in DHCP.

ADVPN

ADVPN is used in hub and spoke topologies. The hub tells two spokes how they can establish a tunnel between each
other, instead of routing traffic through the hub.

Site to site

Site to site VPNs are used for a single, secure connection between two sites, or between a site and a cloud service. The
connection can be to an external party, such as a contractor or MSSP, or within the same business, such as to connect a
remote site to the headquarters.

FortiOS 7.0.0 Best Practices 34

Fortinet Inc.
Hardening
System hardening reduces security risk by eliminating potential attack vectors and shrinking the system's attack surface.
Some of the best practices described previously in this document contribute to the hardening of the FortiGate with
additional hardening steps listed here.
l Register your product with Fortinet Inc. Support
l Administrator access on page 9
l System time
l Configure logging
l Use local-in policies
l Physical security on page 35
l Vulnerability - monitoring PSIRT on page 36
l Firmware on page 36
l Encrypted protocols on page 36
l Strong ciphers on page 37
l FortiGuard databases on page 37
l Penetration testing on page 37
l Denial of service on page 37
l Secure password storage on page 38
l Configuration backup on page 38

Physical security
Install the FortiGate in a physically secure location. Physical access to the FortiGate can allow it to be bypassed, or other
firmware could be loaded after a manual reboot.
If the FortiGate cannot be physical secured:
l Disable USB firmware and configuration installation:
config system auto-install
set auto-install-config disable
set auto-install-image disable
end

l Enable port security (802.1x) to prevent unauthorized devices from forwarding traffic.
l Optionally, disable the maintainer account. Note that doing this will make you unable to recover administrator
access using a console connection is all of the administrator credentials are lost.

FortiOS 7.0.0 Best Practices 35

Fortinet Inc.
Hardening

Vulnerability - monitoring PSIRT

Product Security Incident Response Team (PSIRT) continually tests and gathers information about Fortinet hardware
and software products, looking for vulnerabilities and weaknesses. The findings are sent to the Fortinet development
teams, and serious issues are described, along with protective solutions, in advisories listed at
[Link]

Firmware
Keep the FortiOS firmware up to date. The latest patch release has the most fixed bugs and vulnerabilities, and should
be the most stable. Firmware is periodically updated to add new features and resolve important issues.
l Read the release notes. The known issues may include issues that affect your business.
l Do not use out of support firmware. Review the product lifecycle and plan to upgrade before the firmware expires.

Encrypted protocols
Use encrypted protocols whenever possible, for example:
l LDAPS instead of LDAP
l SNMPv3 instead of SNMP
l SSH instead of telnet
l OSPF MD5 authentication
l SCP instead of FTP or TFTP
l NTP authentication
l Encrypted logging instead of TCP

When configuring an LDAP connection to an Active Directory server, an administrator must

provide Active Directory user credentials.
l To secure this connection, use LDAPS on both the Active Directory server and FortiGate.

See Configuring an LDAP server.

l Apply the principle of least privilege. For the LDAP regular bind operation, do not use
credentials that provide full administrative access to the Windows server when using
credentials. See Configuring least privileges for LDAP admin account authentication in
Active Directory.

FortiOS 7.0.0 Best Practices 36

Fortinet Inc.
Hardening

Strong ciphers
Force higher levels of encryption and strong ciphers:
config system global
set strong-crypto enable
set ssl-static-key-ciphers disable
set dh-params 8192
end

See FortiGate encryption algorithm cipher suites for more information.

The ssh-hmac-md5 and ssh-cbc-cipher commands are removed in FortiOS 7.0.2 and
later. See Enabling individual ciphers in the SSH administrative access protocol for details.

FortiGuard databases
Ensure that FortiGuard databases, such as AS, IPS, and AV, are updated punctually. Optionally, send an alert if they are
out of date.

Penetration testing
Test your FortiGate to try to gain unauthorized access, or hire a penetration testing company to verify your work.

Denial of service
Denial of service (DoS) is a type of attack meant to disable a machine or network causing inaccessibility to the resource
or users. Most often this is accomplished by overwhelming the target with more information than it can handle, resulting
in a crash. DoS policies, which look for anomalous traffic patterns, are checked before the more resource intensive
security policies to help prevent this.
The following guidelines can be used to get started with DoS policies. These policies can be applied to incoming traffic
from your local network or internet, depending on your particular network.
l Enable anomaly logging and keep the action as monitor for some time. This is to observe and understand what
expected traffic looks like so that you may tune thresholds to have small margins, and therefore more protection.
Keep note of false alarms. If they are too frequent, you should adjust your policy accordingly.

FortiOS 7.0.0 Best Practices 37

Fortinet Inc.
Hardening

l Enable the following DoS policy anomalies to help prevent targeted attacks:
l tcp_syn_flood

l tcp_port_scan

l tcp_src_session

l tcp_dst_session

l ip_src_session

l ip_dst_session

If you have an idea of your traffic rates for the preceding traffic patterns, you may adjust the threshold. Otherwise,
begin with the default and adjust after a period of observing normal traffic. For more information, see DoS protection
in the FortiOS Administration Guide.
l Where possible, enable ASIC DoS for offloading using network processor ASICs. The FortiOS Hardware
Acceleration Guide contains more information about DoS-related NP6 ASIC features, such as configuring NP6
anomaly protection and using the host protection engine (HPE) to protect the FortiGate from DoS attacks.

Secure password storage

The passwords, and private keys used in certificates, that are stored on the FortiGate are encrypted using a predefined
private key, and encoded when displayed in the CLI and configuration file. System admin passwords are hashed with
SHA256 and encoded before being displayed.
Passwords cannot be decrypted without the private key and are not shown anywhere in clear text. The private key is
required on other FortiGates to restore the system from a configuration file. In an HA cluster, the same key should be
used on all of the units.
To enhance password security, specify a custom private key for the encryption process. This ensures that the key is only
known by you.
FortiGate models with a Trusted Platform Module (TPM) can store the master encryption password, which is used to
generate the master encryption key, on the TPM. For more information, see Trusted platform module support.

To configure your own private encryption key:

config system global

set private-data-encryption enable
end
Please type your private data encryption key (32 hexadecimal numbers):
********************************
Please re-enter your private data encryption key (32 hexadecimal numbers) again:
********************************
Your private data encryption key is accepted.

Configuration backup
The FortiGate configuration file has important information that should always be kept secured, including details about
your network, users, credentials, passwords, and keys. There are many reasons to back up your configuration, such as

FortiOS 7.0.0 Best Practices 38

Fortinet Inc.
Hardening

disaster recovery, preparing for migrating to another device, and troubleshooting. Evaluate the risk involved if your
configurations were exposed, and manage your risk accordingly.
When backing up your configuration, consider the following steps to safeguard the file:
l Enable Encryption when backing up the configuration.
l Store the configuration file in a secure location.
l Delete old configuration files that are no longer needed.
If a configuration file must be shared with a third party for auditing, troubleshooting, or any other reasons, consider only
providing a section of the file and not the entire file. Otherwise, consider the following steps:
l Enable Encryption when backing up the configuration and only share the password with the intended party.
l Manually replace the passwords in the backed up configuration file.
l Request that the configuration file be deleted after the intended purpose has been satisfied.

FortiOS 7.0.0 Best Practices 39

Fortinet Inc.
Firmware change management

Firmware change management

For general FortiOS software recommendations in stability-focused deployments, please refer

to Technical Tip: Recommended Release for FortiOS.
For deployments that are leveraging the latest features, refer to the 4-D Best Practices and
Deployment Guides.

Consider the following points when performing firmware upgrades, not only in FortiOS but as general rules for any
change you have to make in a production environment.

Understanding the new version

Before attempting any changes in production, first make sure you set up a laboratory where you can freely play with the
new features and understand them without pressure and time constraints. Read the release notes, manuals, and other
documentation, such as presentations, videos, or podcasts about the new version.
You are ready to explain the need for an upgrade once you understand:
l The differences and enhancements between the new version and the previous versions.
l The impact of the upgrade on customers and the users of the operating platform.
l The known limitations that might affect your environment.
l The potential risks when performing the upgrade.
l The licensing changes that may apply.

Never attempt to upgrade to a version that you do not fully understand, in terms of both
features and known limitations, and on which you have no operational experience.

Reasons to upgrade
You should have a valid reason for upgrading the firmware. The reason cannot be only because you want the latest
version. The reason has to be explained in terms of business, technical, or operational improvement.
Affirmative answers to the following questions are valid reasons to upgrade:
l Does the new version have a feature that helps to ensure compliance?
l Does the new version have an enhancement that allows a 40% decrease on the time it takes to perform a certain
operation?

FortiOS 7.0.0 Best Practices 40

Fortinet Inc.
Firmware change management

l Does a new feature correct a known defect or bug found on a previous version that affects the company business or
operations?
l Will the new version allow your organization to deploy new services that will help to gain new customers or increase
loyalty of existing customers?
l Is the vendor cutting support for the version your organization is currently using?
If the best reason to upgrade is because the new features seem to be cool or because you want the latest version, some
more understanding and planning may be necessary.

Preparing an upgrade plan

If you choose to upgrade for a valid reason, make sure you create a plan that covers business, technical, and operational
aspects of the upgrade.

Business aspects of the upgrade

Proper planning and justification for an upgrade should be proportional to how critical the system is to the business.
l Make sure you can clearly articulate the benefits of the upgrade in business terms, such as time, money, and
efficiency.
l Understand the business processes that will be affected by the change.
l Make sure the upgrade maintenance window is not close to a business-critical process, such as quarterly or
monthly business closure.
l Obtain executive and operational approval for the maintenance window. The approval must come from the owners
of all the system and information affected by the upgrade, not only from those that own the system being upgraded.
The approval must be done formally through written statement or e-mail.

Technical and operational aspects of the upgrade

A plan must be created to account for technical and operational inputs.
l Re-read the release notes for the technology that you are upgrading. Supported hardware models, upgrade paths,
and known limitations should be clearly understood.
l Make sure your upgrade maintenance window does not overlap with any other maintenance window on your
infrastructure.
l If you have any premium support offer, such as TAM Premium Support, do a capacity planning exercise to ensure
the new firmware or software version does not take more hardware resources than you currently have.
l Create a backup, whether or not you already have scheduled backups.
l Obtain offline copies of both the currently installed firmware and the new version.
l Create a list of systems with inter-dependencies to the system you are upgrading. For example, if you are upgrading
a FortiGate, understand the impact on any FortiAP, FortiAuthenticator, FortiToken, FortiManager, or FortiAnalyzer
you have on your environment.

FortiOS 7.0.0 Best Practices 41

Fortinet Inc.
Firmware change management

l If your FortiGate is part of a security fabric, understand any firmware dependencies between fabric devices and plan
to upgrade fabric devices as necessary.
l Ensure you have a list of adjacent devices to the upgrading platform and have administrative access to them, in
case you need to do some troubleshooting. For example, if you are upgrading FortiWeb, make sure you can
administratively access the web applications. Likewise, if you are upgrading FortiGate, make sure you can
administratively access the surrounding switches and routers.
l Have a step-by-step plan on how to perform and test the upgrade. You want to make sure you think of the worst
situation before it happens, and have predefined courses of action, instead of thinking under pressure when
something has already gone wrong.
l Define a set of tests (that include critical business applications that should be working) to make sure the upgrade
was successful. If any test does not go well, define which ones mandate a rollback and which ones can be tolerated
for further troubleshooting. This set of tests should be run before and after the upgrade to compare results. The
tests performed before and after the upgrade should be the same.
l Define a clear rollback plan. If something goes wrong with the upgrade or the tests, the rollback plan will help you
get your environment back to a known and operational status. The plan must clearly state the conditions under
which the rollback will be started.
l Declare configuration freezes shortly before and after the upgrade. This reduces the amount of variables to take into
consideration if something goes wrong.
l Perform a quality assurance upgrade. Load a copy of the production configuration on a non-production box and
execute the upgrade to see if there are any issues on the process. Adjust your plan according to the results you
obtain.
l Have a list of information elements to be gathered if something goes wrong. This ensures that, even if the upgrade
fails, you will collect enough information to troubleshoot the issue without needing to repeat the problem. Get help
from Fortinet Support if you need to confirm what could be missing from your list.
l Define a test monitoring period after the change was completed. Even if the upgrade went smoothly, something
could still go wrong. Make sure that you monitor the upgraded system for at least one business cycle. Business
cycles may be a week, month, or quarter depending on your organization's business priorities.

Executing the upgrade plan

Execution of an upgrade is just as key as planning. Once you are performing the upgrade, the pressure will rise and
stress might peak. This is why you should stick to the plan you created with a cool head.
Resist the temptation to make decisions while performing the upgrade, as your judgment will be clouded by the stress of
the moment, even if a new decision seems to be an obvious improvement in the moment. If your plan says you should
rollback, then execute the rollback despite the potential quick fix mentality.
While performing the upgrade, make sure all the involved components are permanently monitored before, during, and
after the upgrade, either through monitoring systems, SNMP alerts, or with a ping. Critical resources like CPU, memory,
network, and disk utilization must also be constantly monitored.
To avoid misunderstandings, when performing the tests for each critical application defined in the planning, make sure
there are formal notifications on the results for each user area, service, system, and application tested.
Regardless if you have to rollback or not, if a problem occurs, make sure you gather as much information about the
problem as possible, so you can later place a support ticket to find a solution.
Finally, document the upgrade:

FortiOS 7.0.0 Best Practices 42

Fortinet Inc.
Firmware change management

l Enable your terminal emulation program to leave trace of all the commands executed and all the output generated.
If you are performing steps through the GUI, consider using a video capture tool to document it.
l Document any command or change performed over the adjacent and interdependent systems. Make sure they are
acknowledged by the relevant administrators.
l Document any deviations performed over the upgrade plan. This is the planned-versus-actual.

Learning more about change management

Change management and change control are huge knowledge areas in the fields of Information Systems, and Computer
and Network Security.
This document is by no means a comprehensive list on what you should do when performing an upgrade, with either
Fortinet or any other technology. It is merely a list of important things you should take into consideration when performing
upgrades. It is the result of years of experience dealing with changes on critical environments, as it is common that
security devices are protecting critical applications and processes.
There are vast resources on the topic of change management and change control, including books, public whitepapers,
blog entries, and so on. If you search the internet for the "Change Control Best Practices" or "Change Management Best
Practices," you will find many helpful results.

Changes on production IT infrastructure are critical to the business. Make sure they play in
your favor and not against you.

For details on upgrading and downgrading your device firmware, see the Firmware section and the Fabric Management
page of the FortiOS Administration Guide.

FortiOS 7.0.0 Best Practices 43

Fortinet Inc.
 [Link]

Copyright© 2025 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein
may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were
attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance
results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract,
signed by Fortinet’s Chief Legal Officer, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only
the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal
conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change,
modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.