Fortigate hardening (FortiOS 8.0): A step-by-step CLI guide

Introduction

The FortiOS 8.0.0 Best Practices guide treats hardening as the process of reducing the attack surface of your firewall. This post turns that guidance into a checklist you can follow in order, with CLI examples where they help.

How to read the commands:

(guide) The command appears in the Fortinet guide.
(supplemental) The command is NOT in the guide. It was written from general
FortiOS knowledge and must be validated against your
FortiOS version and hardware model.

Interface names, IP addresses, ports and object names are examples. Replace them with your own values.

Step 1 - Register the device and the contract

Without the device and its service contract registered in FortiCloud, you do not get full access to support or to FortiGuard services.

* In the GUI, check System > FortiGuard > License Information.
* It can take a few hours for the license status to refresh after registration.

STEP 2 - USE A DEDICATED MANAGEMENT NETWORK

* Dedicate a single interface or VLAN interface to all administrative access.
* Disable administrative access on every other interface.
* Avoid managing the firewall through the WAN or any publicly exposed interface, because it will be under constant attack.

config system interface
edit "mgmt"
set allowaccess https ssh ping (supplemental)
next
edit "wan1"
set allowaccess ping (supplemental)
next
end

On the WAN interface, keep only what you really need (for example ping), and never HTTPS, SSH or Telnet.

Step 3 - Time (NTP) and logging

Accurate time is required for logs and certificates. The guide also asks you to encrypt logs in transit. FortiAnalyzer and FortiCloud already use an encrypted channel. For third-party syslog servers, use a secure channel or a VPN to the collector.

config system ntp (supplemental)
set ntpsync enable
set type custom
config ntpserver
edit 1
set server "<NTP-1>"
next
end
end

config log syslogd setting (supplemental)
set status enable
set server "<SYSLOG-SERVER>"
set mode reliable
set enc-algorithm high
end

Step 4 - Administrator access

Who can access:
* Do not use shared accounts.
* Prefer remote authentication (LDAPS, RADSEC over TLS or TACACS+) and enable MFA.
* For scripts that connect over SSH, use certificates instead of stored passwords.

What they can access:
* Limit each administrator with an access profile (accprofile) and review the list of administrators regularly.

How they access:
* Use trusted hosts and block the login methods an administrator does not need.

config system admin
edit <administrator>
set disallowed-login-methods {console | gui | ssh | telnet} (guide)
set trusthost1 <MGMT-NETWORK> <MASK> (supplemental)
next
end

Step 5 - Global administrative settings

The guide recommends:
* an idle timeout preferably under 10 minutes;
* non-standard HTTPS and SSH ports;
* HTTP and Telnet disabled;
* HTTP-to-HTTPS redirection disabled; if it must stay on, pin the admin-host to the device hostname;
* a trusted certificate with the FQDN or IP of the FortiGate, instead of the factory self-signed one.

config system global
set admin-host <DEVICE-HOSTNAME> (guide)
set admintimeout 5 (supplemental, minutes)
set admin-sport <HTTPS-PORT> (supplemental)
set admin-ssh-port <SSH-PORT> (supplemental)
set admin-https-redirect disable (supplemental)
end

Step 6 - Admin passwords with PBKDF2

In FortiOS 8.0 and later, PBKDF2 is the default hashing algorithm for administrator passwords. After an upgrade, however, existing passwords stay hashed with SHA256 until they are updated. To convert them:

1. Make every administrator log in at least once after the upgrade.
2. For accounts that do not log in, a super_admin resets the password:

config system admin
edit <administrator>
set password <new_password>

3. Check the hash format. PBKDF2 hashes start with the prefix PB2, and the legacy SHA256 hashes start with SH2:

show system admin

FortiOS may keep the previous SHA256 hash in a hidden field (old-password). It does not affect authentication, but keep it in mind when you export or audit configuration files.

Step 7 - Local-in policies: Protect the management plane

Local-in policies control access to the FortiGate interfaces and are used to block access to management ports. Be careful: a wrong rule can break dynamic routing, HA and other features. If management must be allowed on a public interface, restrict it to trusted hosts and enable logging.

config firewall local-in-policy (supplemental)
edit 1
set intf "wan1"
set srcaddr "<TRUSTED-GROUP>"
set dstaddr "all"
set service "HTTPS" "SSH"
set action accept
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "all"
set dstaddr "all"
set service "HTTPS" "SSH"
set action deny
set schedule "always"
next
end

STEP 8 - PHYSICAL SECURITY

Install the FortiGate in a physically secure location. If that is not possible, make sure USB-based firmware and configuration installation is disabled (this is the default), and enable 802.1X port security to stop unauthorized devices from forwarding traffic.

config system auto-install
set auto-install-config disable (guide)
set auto-install-image disable
end

Step 9 - Firmware, vulnerabilities and patches

* Follow PSIRT advisories at fortiguard.com/psirt.
* Read the release notes before you upgrade.
* Do not run out-of-support firmware. Plan the upgrade before the End of Support date.
* For standalone FortiGates, enable automatic firmware updates. They only install the latest patch of the current minor version.
* If you cannot patch right away, the guide mentions virtual patching in the local-in policies as a temporary measure.
* Since versions 7.4.8 and 7.6.4, an upgrade to the latest patch is mandatory when the Firmware & General Updates (FMWR) license is invalid or the version reached end of engineering support. Once scheduled, it can only be postponed for seven days.

STEP 10 - ENCRYPTED PROTOCOLS AND STRONG CIPHERS

Prefer the secure protocol whenever possible:

* LDAPS instead of LDAP
* RADSEC over TLS instead of RADIUS
* SNMPv3 instead of SNMP
* SSH instead of Telnet
* SCP instead of FTP or TFTP
* OSPF and NTP authentication
* encrypted logging

Strong crypto is enabled by default:

config system global
set strong-crypto enable (guide)
set ssl-static-key-ciphers disable
set dh-params 8192
end

Step 11 - FortiGuard databases

Keep the AS, IPS and AV databases up to date, and optionally alert when they are out of date. For the Generative AI application database, the guide gives this check:

diagnose autoupdate versions | grep -A 6 GenAI (guide)

A version of 0.00000 means the database has not been updated.

Step 12 - Denial of service protection

DoS policies are evaluated BEFORE security policies. The guide suggests starting in monitor mode with logging, to learn what normal traffic looks like, and then tuning the thresholds. Enable these anomalies:

tcp_syn_flood, tcp_port_scan, tcp_src_session, tcp_dst_session,
ip_src_session, ip_dst_session

config firewall DoS-policy (supplemental)
edit 1
set interface "wan1"
set srcaddr "all"
set dstaddr "all"
set service "ALL"
config anomaly
edit "tcp_syn_flood"
set status enable
set log enable
set action pass
set threshold <THRESHOLD>
next
end
next
end

Repeat the anomaly block for the other anomalies. Where supported, enable ASIC DoS offloading.

Step 13 - Secure storage of passwords and keys

Passwords and private keys are stored encrypted in the configuration. To use your own private data encryption key:

config system global
set private-data-encryption enable (guide)
end

From 7.6.1, the FortiGate generates a random password and no longer asks for the key. Two cautions:

* A backup made with private-data-encryption enabled can only be restored on a unit with the same key.
* In case of RMA, the guide says to disable private-data-encryption and back up the configuration before restoring it on the replacement unit. Depending on the hardware failure this may not be possible, so weigh the risk before you enable it.

STEP 14 - CONFIGURATION BACKUP

The configuration file holds network details, users, credentials and keys. Protect it:

* Enable Encryption when backing up.
* Store the file in a secure location and delete old files.
* When sharing with a third party, send only the section needed, or use an encrypted backup with a password shared only with that party, enable password masking, and ask for the file to be deleted afterwards.
* From 8.0.0, saving a revision on logout is enabled by default (on models with a hard disk):

config system global
set revision-backup-on-logout enable (guide)
end

Step 15 - Non-standard ports and admin username

The default admin ports and the default administrator name are well known and are the first things attackers try. The guide strongly recommends changing both to non-standard, non-guessable values. Use the commands from Step 5 for the ports, create a named administrator account with a different name, and disable the default admin according to your policy.

Step 16 - Test your work

Try to gain unauthorized access to your own FortiGate, or hire a penetration testing company to verify your work.

Notes about the guide

* The guide mentions PBKDF2, Password-Based Key Derivation Function 2, in two places with different versions: as the default from 8.0.0 (the PBKDF2 section) and from 7.6.1 (the password storage section). Check your own device with "show system admin" and look for the PB2 prefix.
* The hardening chapter refers back to items that are described in earlier chapters, such as administrator access, system time and logging.

Quick checklist

[ ] Device and contract registered
[ ] Management on a dedicated interface and disabled elsewhere
[ ] MFA, trusted hosts and least-privilege access profiles
[ ] Short timeout, non-standard ports, HTTP and Telnet disabled
[ ] Passwords converted to PBKDF2 (PB2 prefix)
[ ] Local-in and DoS policies in place
[ ] Firmware current, PSIRT followed, FortiGuard databases up to date
[ ] Strong ciphers, encrypted protocols and encrypted logs
[ ] Encrypted backups and a tested RMA plan

Conclusion

Hardening a FortiGate is mostly a matter of discipline: shrink the management surface, authenticate strongly, keep firmware and signatures current, protect secrets and backups, and test the result. Follow the steps in order, validate every supplemental command in your own environment, and keep a rollback plan for each change.

Reference

https://docs.fortinet.com/document/fortigate/8.0.0/best-practices/555436/hardening

techcyber.blog

All rights reserved.