FortiOS 7.2 Best - Practices

Best Practices
FortiOS 7.2
FORTINET DOCUMENT LIBRARY
https://docs.fortinet.com
FORTINET VIDEO GUIDE

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
NSE INSTITUTE
https://training.fortinet.com
FORTIGUARD CENTER
https://www.fortiguard.com
END USER LICENSE AGREEMENT

https://www.fortinet.com/doc/legal/EULA.pdf
FEEDBACK
Email: techdoc@fortinet.com
March 03, 2022

FortiOS 7.2 Best Practices
01-720-793982-20230303
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 9
What can administrators access 10
How can users access the FortiGate 10
Administrative settings 10
Day to day operations 12
Configuration changes 12
Logging and reporting 13
Performance monitoring 13
Identity and access management 14
Certificates 15
Certificate usage 15
Security profiles 17
Opened ports for Authentication Override in Web Filter Replacement Messages 18
SSL/TLS deep inspection 19
Migration 21
Remote access 22
SSL VPN 22
IPsec VPN 23
Non-VPN remote access 23
High availability and redundancy 24
High availability 24
Redundant and aggregate links 24
SD-WAN 25
Disaster recovery 26
Security rating 27
Network security 32
Policies 32
VPN 34
Hardening 35
Physical security 35
Vulnerability - monitoring PSIRT 36
Firmware 36
FortiOS 7.2 Best Practices 3

Fortinet Inc.
Encrypted protocols 36
Strong ciphers 36
FortiGuard databases 36
Penetration testing 37
Denial of service 37
Secure password storage 37
Firmware change management 39
Understanding the new version 39
Reasons to upgrade 39
Preparing an upgrade plan 40
Business aspects of the upgrade 40
Technical and operational aspects of the upgrade 40
Executing the upgrade plan 41
Learning more about change management 41

Fortinet Inc.
Change Log
Date Change Description
2022-03-31 Initial release.
2022-04-13 Updated Security rating on page 27.
2022-05-18 Updated Hardening on page 35.
2022-05-25 Added Firmware change management on page 39.
2022-07-15 Added Virtual IPs on page 33.
2022-08-22 Updated Security rating on page 27.
2022-10-14 Updated Security profiles on page 17.
2022-10-21 Updated Hardening on page 35.
2023-01-31 Updated Administrative settings on page 10 and Policies on page 32.
2023-03-03 Updated Security profiles on page 17.

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

Fortinet Inc.
Getting started
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

https://docs.fortinet.com administration guides, reference manuals, release
notes, hardware manuals, and QuickStart guides.
Fortinet Video Library Become proficient in Fortinet technology with free,

https://video.fortinet.com learn-as-you-go, videos.
Knowledge Base A central repository of technical notes, tips,

https://kb.fortinet.com troubleshooting and debugging, and instructions
primarily provided by the technical support team.
FortiGuard Labs Information on the latest internet threats, security

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

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

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

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

https://www.fortinet.com/support/support- Fortinet products.
services/professional-services
NSE Training Institute Sign up for computer based or instructor led training
https://training.fortinet.com and hands on labs.

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

Fortinet Inc.
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.
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.
The maintainer account has been removed in FortiOS 7.2.4 and later.

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

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 13
l Performance monitoring on page 13
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.

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.

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 LDAP, RADIUS, or TACACS+, that
the FortiGate queries.
l PKI/peer: Users that authenticate using a client certificate.
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.
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.

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

Fortinet Inc.
Certificates
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.

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

Fortinet Inc.
Security profiles
Security profile Inbound traffic Outbound traffic
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 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:
config webfilter fortiguard
set close-ports enable
end

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

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.

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.

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 22
l IPsec VPN on page 23
l Non-VPN remote access on page 23
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.

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

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
along with FortiGate HA could be used so that no single link, switch, or firewall is a point of failure that could disrupt the

Fortinet Inc.
High availability and redundancy
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.

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.

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 NIST, PCI DSS compliance, GDPR, and CIS.
Enabling the Security Fabric and rating service allows you to easily identify key deficiencies, take action based on
automated recommendations, secure your entire fabric, and passively monitor based on your Security Fabric scores.
The following table lists the security rating tests that are included with FortiOS and do not require a license. The table is
grouped by the Score Care category (for example, Security Posture, Fabric Coverage and Optimization) and sorted by
the FSBP ID.
Score Card FSBP ID Name Description Category

Category
Security Posture AL02.1 Centralized Logging and reporting Audit Logging &
Logging & should be done in a Monitoring
Reporting centralized place.
EM01.1 Endpoint Interfaces which are Endpoint

Registration classified as "LAN" and Management
are used by a policy
should have Security
Fabric Connection
enabled.
EM01.2 FortiClient All registered FortiClient Endpoint

Vulnerabilities devices should have no Management
critical vulnerabilities.
ND02.4 FortiAP UTM SSID (blank) Network Design &

Compatibility Policies
ND04.1 LAN Segment Servers should be placed Network Design &

Fortinet Inc.
Security rating

Category
Servers behind interfaces Policies

classified as "DMZ".
ND05.2 VLAN Non-FortiLink interfaces Network Design &

Management should not have multiple Policies
VLANs configured on
them.
ND07.1 Device Discovery Interfaces which are Network Design &

classified as "LAN" or Policies
"DMZ" and are used by a
policy should have device
detection enabled.
ND08.1 Interface All interfaces used by a Network Design &

Classification policy should be classified Policies
as either 'LAN', 'WAN', or
'DMZ'.
ND09.1 Detect Botnet Policies should block or Network Design &

Connections monitor outgoing Policies
connections to botnet
sites.
ND10.1 Explicit Interface Polices that allow traffic Network Design &
Policies should not be using the Policies
"any" interface.
SH01.1 Unsecure Protocol Interfaces currently in use Fabric Security

- Telnet should not allow TELNET Hardening
administrative access.
SH01.11 Unsecure Protocol (blank) Fabric Security

- TFTP Hardening
SH01.2 Unsecure Protocol Interfaces currently in use Fabric Security

- HTTP should not allow HTTP Hardening
administrative access.
SH03.1 Valid HTTPS The administrative GUI Fabric Security

Certificate - should be using a valid Hardening
Administrative GUI and secure certificate.
SH04.1 Valid HTTPS SSL-VPN should be using Fabric Security

Certificate - SSL- a valid and secure Hardening
VPN certificate.
SH05.1 Admin Password A password policy should Fabric Security

Policy be set up for system Hardening
administrators.

Fortinet Inc.
Security rating

Category
SH09.7 LDAP Server Verify that server-identity- Fabric Security

Identity Check check is enabled for LDAP Hardening
Servers to ensure
certificate validation takes
place. While this is the
default option in a clean
install, it may not be set if
upgrading from older
releases.
SH09.8 Disable Username Verify that username case Fabric Security

Sensitivity Check sensitivity is disabled for Hardening
remote LDAP users. This
option is provided only for
legacy compatibility
reasons. If enabled, it can
lead to the bypass of two-
factor authentication.
SH20.1 DNS Helper (blank) Fabric Security

Hardening
Fabric Coverage AL02.2 FortiAnalyzer All FortiGates in the Audit Logging &
Security Fabric can Monitoring
connect to and
authenticate with their
configured FortiAnalyzer.
FS01.1 Compatible All devices in the Security Firmware &

Firmware Fabric should have Subscriptions
compatible firmware
versions.
FS01.2 FortiAP Firmware All FortiAPs should be Firmware &

Versions running the latest Subscriptions
firmware.
FS01.3 FortiSwitch All FortiSwitches should Firmware &

Firmware Versions be running the latest Subscriptions
firmware.
FS02.1 FortiCare Support Appropriate devices Firmware &

should be registered with Subscriptions
FortiCare and have valid
support coverage.
FS02.10 Firmware & Firmware & General Firmware &

General Updates Updates subscription Subscriptions
should be valid.

Fortinet Inc.
Security rating

Category
FS02.11 Indicators of For compromised hosts Firmware &

Compromise support the IoC Subscriptions
subscription should be
valid.
FS02.2 IPS IPS subscription should be Firmware &

valid. Subscriptions
FS02.3 AntiVirus AntiVirus subscription Firmware &

should be valid. Subscriptions
FS02.5 Web Filtering Web Filtering subscription Firmware &

FS02.6 Anti-Spam Anti-Spam subscription Firmware &

FS02.8 Industrial DB Industrial DB subscription Firmware &

FS02.9 Outbreak Outbreak Prevention Firmware &

Prevention subscription should be Subscriptions
valid.
FS03.1 Security Rating Security Rating Firmware &

subscription should be Subscriptions
valid.
FS05.1 Activate FortiCloud (blank) Firmware &

Services Subscriptions
ND01.1 Unauthorized All discovered Network Design &

FortiSwitches FortiSwitches should be Policies
authorized or disabled.
ND01.2 Unauthorized All discovered FortiAPs Network Design &

FortiAPs should be authorized or Policies
disabled.
ND06.1 Third Party Router No third party router or Network Design &
& NAT Devices NAT devices should be Policies
detected in the network.
TV01.1 Advanced Threat Suspicious files should be Threat &

Protection submitted to FortiSandbox Vulnerability
Appliance/FortiSandbox Management
Cloud for inspection.
TV01.2 FortiSandbox All FortiGates in the Threat &

Security Fabric can Vulnerability
connect to their configured Management
FortiSandbox.

Fortinet Inc.
Security rating

Category
Optimization ND03.1 Unused Policies All policies should be Network Design &
used. Policies
PO01.10 Policy Inspection Policies should not Performance

Mode combine proxy and flow Optimization
inspection modes.
PO04.1 Managed Switch Number of managed Performance

Capacity FortiSwitch should not Optimization
Exceeded on exceed 80% of the
FortiGate FortiGate's maximum
capacity (table size). We
suggest upgrading (or
adding more FortiGate if
the model already has
maximum table size) when
the threshold is reached.
PO04.2 Redundant Should have redundant Performance

FortiLinks FortiLink between Optimization
FortiGate and FortiSwitch.
We suggest adding
FortiLink if there is only 1
FortiLink. Switches not
directly connected to FGT
are exempt.
PO04.3 Enable MC-LAG Detect switch peer Performance

candidates that can form a Optimization
tier-1 MC-LAG.
PO04.4 Redundant ISL Should have redundant Performance

inter-switch links between Optimization
FortiSwitches.
PO04.5 Enable STP Once the network topology Performance

is stable, enable STP on Optimization
the FortiSwitch ports to
avoid a switching loop.
PO04.6 Lockdown LLDP Edge ports should have Performance

Profile LLDP profile locked down Optimization
to avoid accidental growth
in network topology.
For more information about security ratings, and details about each of the checks that are performed, go to Security Best
Practices & Security Rating Feature.

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

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.
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 10.3.3.3 all
Destination all WEB_SERVER
Action deny accept
Match VIP disable n/a

Fortinet Inc.
Network security
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 22 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.

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 36
l FortiGuard databases on page 36
l Penetration testing on page 37
l Denial of service on page 37
l Secure password storage on page 37
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.

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 lifecycle and plan to upgrade before the firmware expires.
l Optionally, subscribe to the Fortinet firmware RSS feed: https://pub.kb.fortinet.com/rss/firmware.xml.
Encrypted protocols
Use encrypted protocols whenever possible, for example, SNMPv3 instead of SNMP, SSH instead of telnet, OSPF MD5
authentication, SCP instead of FTP or TFTP, NTP authentication, and encrypted logging instead of TCP.
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.
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.

Fortinet Inc.
Hardening
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 Ensure the FortiGate is receiving regular IPS signature updates from the FortiGuard network through a valid
subscription.
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 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.
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.

Fortinet Inc.
Hardening
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.

Fortinet Inc.
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?
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.

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

Fortinet Inc.
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:
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.

Fortinet Inc.
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 Fabric Management section of the FortiOS
Administration Guide.

Fortinet Inc.
www.fortinet.com
Copyright© 2023 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 General Counsel, 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.

FortiOS 7.2 Best - Practices

Uploaded by

Copyright:

Available Formats

FortiOS 7.2 Best - Practices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FortiOS 7.2 Best - Practices

Uploaded by

Copyright:

Available Formats

What are the main sections covered in the document?

What are the main sections covered in the document?

What are some best practices for upgrading firmware?

What are some best practices for upgrading firmware?

Best Practices

FORTINET VIDEO GUIDE

CUSTOMER SERVICE & SUPPORT

FORTINET TRAINING & CERTIFICATION PROGRAM

END USER LICENSE AGREEMENT

March 03, 2022

FortiOS 7.2 Best Practices 3

FortiOS 7.2 Best Practices 4

Date Change Description

2022-03-31 Initial release.

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

2022-05-18 Updated Hardening on page 35.

2022-05-25 Added Firmware change management on page 39.

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

2022-08-22 Updated Security rating on page 27.

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

2022-10-21 Updated Hardening on page 35.

2023-01-31 Updated Administrative settings on page 10 and Policies on page 32.

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

FortiOS 7.2 Best Practices 5

FortiOS 7.2 Best Practices 6

Fortinet Document Library Access Fortinet product documentation, including

Fortinet Video Library Become proficient in Fortinet technology with free,

Knowledge Base A central repository of technical notes, tips,

FortiGuard Labs Information on the latest internet threats, security

Fortinet Blog Read articles and essays about a variety of security

FortiOS 7.2 Best Practices 7

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

Professional Services Assistance with configuring your FortiGate, and other

FortiOS 7.2 Best Practices 8

User authentication for management network access

Who can access the FortiGate

FortiOS 7.2 Best Practices 9

What can administrators access

How can users access the FortiGate

The following general administrative settings are recommended:

FortiOS 7.2 Best Practices 10

FortiOS 7.2 Best Practices 11

FortiOS 7.2 Best Practices 12

Logging and reporting

FortiOS 7.2 Best Practices 13

FortiOS 7.2 Best Practices 14

Certificates serve three primary purposes:

FortiOS 7.2 Best Practices 15

Certificates can be uploaded to the FortiGate in multiple ways:

FortiOS 7.2 Best Practices 16

Security profile Inbound traffic Outbound traffic

FortiOS 7.2 Best Practices 17

Security profile Inbound traffic Outbound traffic

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

Opened ports for Authentication Override in Web Filter

FortiOS 7.2 Best Practices 18

When close-ports is enabled:

will not work.

When VDOM is enabled, edit the settings in global: