Best Practices

FortiOS 7.4
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com

FORTINET VIDEO LIBRARY

https://video.fortinet.com

FORTINET BLOG
https://blog.fortinet.com

CUSTOMER SERVICE & SUPPORT

https://support.fortinet.com

FORTINET TRAINING & CERTIFICATION PROGRAM

https://www.fortinet.com/training-certification

FORTINET TRAINING INSTITUTE

https://training.fortinet.com

FORTIGUARD LABS
https://www.fortiguard.com

END USER LICENSE AGREEMENT

https://www.fortinet.com/doc/legal/EULA.pdf

FEEDBACK
Email: [email protected]

July 30, 2025

FortiOS 7.4 Best Practices
01-740-920442-20250730
 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 22
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
Hardening 35
Physical security 35

FortiOS 7.4 Best Practices 3

Fortinet Inc.
 Vulnerability - monitoring PSIRT 36
Firmware 36
Encrypted protocols 36
Strong ciphers 37
FortiGuard databases 37
Penetration testing 37
Denial of service 38
Secure password storage 38
Configuration backup 39
RMA considerations 39
Non-standard admin ports and administrator usernames 40
Blocking external access to administrative ports 40
Firmware change management 41
Understanding the new version 41
Reasons to upgrade 41
Preparing an upgrade plan 42
Business aspects of the upgrade 42
Technical and operational aspects of the upgrade 42
Executing the upgrade plan 43
Learning more about change management 44
Auto-Patching 44

FortiOS 7.4 Best Practices 4

Fortinet Inc.
Change Log

Date Change Description

2023-06-05 Initial release.

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 39.

2023-09-18 Updated Hardening on page 35.

2023-09-27 Updated Hardening on page 35 and Administrative settings on page 10.

2023-10-10 Updated Administrative settings on page 10.

2023-12-20 Updated Administrative settings on page 10.

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

2024-05-06 Updated Hardening on page 35.

2024-10-09 Updated Firmware change management on page 41.

2025-02-04 Updated Auto-Patching on page 44.

2025-02-21 Added Policy configuration changes on page 13.

2025-05-12 Updated Administrative settings on page 10.

2025-05-22 Updated Hardening on page 35.

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

2025-06-18 Updated Hardening on page 35.

2025-07-30 Updated Hardening on page 35.

FortiOS 7.4 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.

FortiOS 7.4 Best Practices 6

Fortinet Inc.
Getting started

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 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,

https://docs.fortinet.com including administration guides, reference
manuals, release notes, hardware manuals,
and QuickStart guides.

Fortinet Video Library Become proficient in Fortinet technology

https://video.fortinet.com with free, learn-as-you-go, videos.

Fortinet Community A central repository of technical notes, tips,

https://community.fortinet.com troubleshooting and debugging, and
instructions primarily provided by the
technical support team.

FortiOS 7.4 Best Practices 7

Fortinet Inc.
Getting started

FortiGuard Labs Information on the latest internet threats,

https://www.fortiguard.com security 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.

Fortinet Blog Read articles and essays about a variety of

https://blog.fortinet.com security related topics.

Customer Service & Support (FortiCloud) Start a chat, open a ticket, or call in for
https://support.fortinet.com immediate 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

https://support.fortinet.com/Information/DocumentList.aspx and Forti-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,

https://www.fortinet.com/support/support- and other Fortinet products.
services/professional-services

Fortinet Training Institute Sign up for computer based or instructor led

https://training.fortinet.com training and hands on labs.

FortiOS 7.4 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.4 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 Replace the certificate that is offered for HTTPS access with a trusted certificate that has the FQDN or
IP address of the FortiGate.

FortiOS 7.4 Best Practices 10

Fortinet Inc.
Administrator access

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.

In FortiOS 7.4.1, as part of improvements to reducing memory usage, FortiGate

models with 2 GB RAM cannot be the root of the Security Fabric topology or any
mid-tier part of the topology. They can only be configured as downstream devices
in a Security Fabric or standalone devices.
To use FortiGate models with 2 GB RAM as a Fabric root, upgrade to FortiOS 7.4.2 or
later, which supports up to five downstream devices.
The affected models are the FortiGate 40F, 60E, 60F, 80E and 90E series devices
and their variants.

l Disable the use of insecure protocols, such as HTTP and Telnet.

l Disable HTTP redirection to HTTPS from System > Settings.
l If HTTP redirection must be enabled, set the admin-host property to the device hostname. This setting
prevents HTTP redirect to use the client-provided host property in the HTTP header. Instead, it will use the
device hostname configured on the FortiGate.

config system global

set admin-host <redirect host name>
end

The maintainer account has been removed in FortiOS 7.2.4 and later.

FortiOS 7.4 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.4 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.4 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.4 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, RADSEC over TLS, 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 and Configuring client certificate

authentication on the 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.
To secure RADIUS connections, consider using RADSEC over TLS instead. See
Configuring a RADSEC client.

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.4 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.4 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, RADSEC over TLS, VPNs, communication between Fortinet devices and services, deep packet
inspection, and authenticating Security Fabric devices.

FortiOS 7.4 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 and Configuring client certificate

authentication on the 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.
To secure RADIUS connections, consider using RADSEC over TLS instead. See
Configuring a RADSEC client.

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.4 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 38 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 Monitor and filter applications on any port.
to access specific ports.
For example, only allow SSH traffic to be
sent and received over port 22.

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

FortiOS 7.4 Best Practices 19

Fortinet Inc.
Security profiles

Security profile Inbound traffic Outbound traffic

File filter Prevent uploading files based on the file Prevent downloading files based on the
type and the protocol that is used. file 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 Prevent sensitive data from entering your Prevent sensitive data, such as credit card
prevention network. numbers or SSNs, from leaving your
network.

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

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 with the Inline Block feature (see Understanding Inline Block
feature).

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:

FortiOS 7.4 Best Practices 20

Fortinet Inc.
Security profiles

config webfilter fortiguard

set close-ports enable
end

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

FortiOS 7.4 Best Practices 21

Fortinet Inc.
Security profiles

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 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.4 Best Practices 22

Fortinet Inc.
Migration

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.4 Best Practices 23

Fortinet Inc.
Migration

A configuration can be migrated from an older FortiGate device to a new FortiGate

device directly from the FortiGate GUI, without having to access the FortiConverter
portal. See Migrating a configuration with FortiConverter in the FortiOS Administration
Guide for more information.

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

FortiOS 7.4 Best Practices 24

Fortinet Inc.
Migration

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.

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.4 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.

FortiOS 7.4 Best Practices 26

Fortinet Inc.
Remote access

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.

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 port).
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 Zero Trust Network Access Solution Hub
l Zero Trust Network Access 4-D Resources
l FortiSASE
l FortiSASE Product Documentation
l FortiSASE 4-D Resources

FortiOS 7.4 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.

FortiOS 7.4 Best Practices 28

Fortinet Inc.
High availability and redundancy

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 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 and the Secure SD-WAN 4-D Resources.

FortiOS 7.4 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.4 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.4 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, https://www.fortinet.com/solutions, provides information about products and
solutions for different business sizes and industries.
Refer to the Next Generation Firewall 4-D Resources to understand more about NGFW and its best practices in-
depth.

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

FortiOS 7.4 Best Practices 32

Fortinet Inc.
Network security

your business traffic rates (see Performance monitoring on page 14).

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:

FortiOS 7.4 Best Practices 33

Fortinet Inc.
Network security

Policy 1 Policy 2

Source 10.3.3.3 all

Destination all WEB_SERVER

Action deny accept

Match VIP disable n/a

Traffic from 10.3.3.3 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 10.3.3.3 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.
In FortiOS 7.2.4 and later, match-vip is enabled by default in new deny 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.

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.4 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 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 38
l Secure password storage on page 38
l Configuration backup on page 39
l Non-standard admin ports and administrator usernames on page 40

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 Ensure USB firmware and configuration installation are disabled. They are disabled by default:

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.

FortiOS 7.4 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 https://www.fortiguard.com/psirt.

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 Life Cycle > Software page and plan to upgrade
before the FortiOS End of Support (EOS) date, which is when Fortinet Support services for the firmware
version expire.
l Use a federated update to upgrade the firmware of all devices. This process follows the upgrade path to
ensure a smooth transition. See Upgrading all device firmware by following the upgrade path (federated
update) for more information.
l For standalone FortiGates, enable automatic firmware updates to automatically update firmware based on
the FortiGuard upgrade path. Only upgrades to the latest patch of the current minor version are performed,
for example from 7.4.1 to 7.4.2. See Enabling automatic firmware updates for more information.
l In the event a the user is unable to immediately apply a patch to their device, they have the option to
temporarily activate virtual patching within their local-in policies. See Virtual patching on the local-in
management interface for more information.

Encrypted protocols
Use encrypted protocols whenever possible, for example:
l LDAPS instead of LDAP
l RADSEC over TLS instead of RADIUS
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

FortiOS 7.4 Best Practices 36

Fortinet Inc.
Hardening

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 and Configuring client certificate

authentication on the 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.
To secure RADIUS connections, consider using RADSEC over TLS instead. See
Configuring a RADSEC client.

Strong ciphers
Force higher levels of encryption and strong ciphers. Strong crypto is enabled by default:

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.

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.

FortiOS 7.4 Best Practices 37

Fortinet Inc.
Hardening

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.
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 policy 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 NP 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. In FortiOS 7.4.8 and later, admin passwords are
hashed with PBKDF2. See Enhanced administrator password security for more information.
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.

FortiOS 7.4 Best Practices 38

Fortinet Inc.
Hardening

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 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, or enable Password Masking when
backing up the configuration.
l Request that the configuration file be deleted after the intended purpose has been satisfied.
If FortiGate has private-data-encryption enabled, you can only restore the configuration file on a FortiGate
with the same encryption key configured.
Keep this in mind for FortiOS 7.6.1 and later where the encryption key is automatically generated. As such, a
configuration that is backed up while private-data-encryption is enabled cannot be restored when private-
data-encryption is disabled or when private-data-encryption is re-enabled because it generates a different
random key.

RMA considerations
When a device has private-data-encryption enabled in FortiOS 7.6.1 and later, and the hardware
malfunctions, you must disable private-data-encryption and back up the configuration. Then you can restore
the configuration backup on a replacement unit with private-data-encryption disabled. After restoring the
configuration backup, you can enable the private-data-encryption setting on the replacement unit.

FortiOS 7.4 Best Practices 39

Fortinet Inc.
Hardening

Depending on the reason the hardware malfunctioned, you may be unable to complete this operation.
Therefore, consider this risk when you enable private-data-encryption.

Non-standard admin ports and administrator

usernames
FortiGate is configured with default administrative access ports under System > Settings. These ports are well
known and likely to be targeted by malicious actors in the first pass. Similarly, the FortiGate has a default system
administrator that is also well known. It is highly recommended to change the default ports and username to
non-standard and non-guessable ports and names for an added layer of protection.

Blocking external access to administrative ports

It is generally not recommended to allow external (WAN) access to administrative ports on the FortiGate. A
better solution is to configure administrative access on a trusted management interface where the management
computer must be in the physical location, or accessible only through a trusted connection like a VPN for remote
access. Ideally, this connection is out-of-band, meaning that it does not rely on the connection passing through
the FortiGate. For information about configuring administrative access on interfaces, see Interface Settings >
Configure administrative access to interfaces.
If access must be granted on an external and public interface, ensure that a local-in policy is defined to allow
only trusted hosts to connect, or restrict administrator accounts logins to trusted hosts only. See Restricting
logins to trusted hosts.
Local-in policies offer granularity in defining the hosts, or groups of hosts that are allowed or blocked. For
example, using the ISDB or Geo-IP database, administrators can restrict a specific geo-location from accessing
the administrative port and interface, or open up specific regions. By enabling logs on the local-in policy, you
can also perform detailed forensic analysis on intrusion attempts.
For more information on Local-in policies, see Local-in policy.

FortiOS 7.4 Best Practices 40

Fortinet Inc.
Firmware change management

Firmware change management

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?
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?

FortiOS 7.4 Best Practices 41

Fortinet Inc.
Firmware change management

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.
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

FortiOS 7.4 Best Practices 42

Fortinet Inc.
Firmware change management

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.4 Best Practices 43

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 & Registration section of the
FortiOS Administration Guide.

Auto-Patching
Starting in version 7.4.5, FortiGates have their auto-patch option enabled by default. You can adjust when the
patching takes place locally on the FortiGate. See Automatic Firmware Upgrades.
For FortiGates managed by FortiGate Cloud, automatic firmware patch may be enabled depending on the
FortiGate Cloud version and portal in use. See the Administration Guide for the applicable FortiGate Cloud
version and portal:
l Standard Portal Administration Guide
l 25.1.a Portal (Beta) Administration Guide
l Premium Portal Administration Guide

FortiOS 7.4 Best Practices 44

Fortinet Inc.
 www.fortinet.com

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.