FortiGate Hardening Guide: Close the Attack Surface in Execution Order

FortiOS ships with a broad default configuration designed for fast deployment, not minimal exposure. Left unchanged, that configuration hands attackers a wide surface: management interfaces reachable from untrusted zones, weak cipher suites, permissive admin timeouts, and shadow policies that silently permit traffic your team never intended to allow.

This checklist walks through remediation in the order that minimises risk of breaking production. Each step includes what to verify and where operators typically go wrong. Work through it on a maintenance window the first time; subsequent runs can be automated via the FortiGate REST API or SCM policy checks.

Before You Start

Take a full configuration backup (execute backup config ftp ... or via the GUI under System > Backup). Confirm you have out-of-band console access or an alternative management path before touching interface or admin settings. Changes to admin access and TLS settings (steps 1-4) carry the highest production risk.

The Hardening Checklist

1. Restrict management interface access by source address. Under System > Administrator, set a trusted host list for every admin account. Limit to your jump-host CIDR or dedicated management VLAN. Do not leave 0.0.0.0/0 as a trusted host. Verify: Attempt an SSH login from an IP outside the trusted range. It should be silently dropped, not presented with a login prompt. Pitfall: If your management workstation changes IP (DHCP, VPN split-tunnel), you lock yourself out. Pin management workstations to static addresses or a stable VLAN before applying this step.

2. Disable management access on all production-facing interfaces. For each interface under Network > Interfaces, uncheck HTTPS, SSH, PING, and SNMP unless that interface is your designated management interface. FortiOS enables HTTPS and PING on new interfaces by default. Verify: Run get system interface in the CLI and confirm allowaccess lists only ping (or nothing) on WAN and DMZ interfaces. Pitfall: If you use SNMP polling from a monitoring system that reaches the firewall via a production interface, disabling SNMP there will break monitoring. Move polling to the management interface first.

3. Replace self-signed certificates on the management GUI. Upload a certificate signed by your internal CA (or a public CA for internet-reachable management) under System > Certificates. Assign it under System > Settings > HTTPS server certificate. Verify: Open the GUI in a browser with strict certificate validation. No untrusted-cert warning should appear. Pitfall: Browsers cache certificate errors aggressively. Test in a fresh private window or with curl -v against the management IP.

4. Enforce TLS 1.2 minimum and restrict cipher suites. In the CLI:

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

   Remove NULL, RC4, DES, and 3DES cipher suites from SSL inspection profiles under Security Profiles > SSL/SSH Inspection. Verify: Use nmap --script ssl-enum-ciphers -p 443 <mgmt-IP> from a test host. Confirm no TLS 1.0 or 1.1 entries appear. Pitfall: Older network monitoring tools and some SCADA clients only speak TLS 1.0. Inventory dependent clients before enforcing this.

5. Set admin session timeout to 5 minutes or less.

   config system global
     set admintimeout 5
   end
   

   Verify: Log in, leave the session idle, and confirm automatic logout at the configured interval. Pitfall: None significant. This change is low-risk and takes effect immediately.

6. Enable multi-factor authentication for all administrator accounts. FortiOS supports FortiToken (hardware or mobile) and RADIUS-based MFA. Assign a token under System > Administrator > Edit > Two-factor Authentication. Verify: Log out and attempt login with credentials only. The session should not complete without the second factor. Pitfall: If FortiToken Mobile is used and the mobile device is unavailable during an incident, you lose admin access. Maintain at least one break-glass account with a hardware token stored offline.

7. Audit and remove unused administrator accounts. Run get system admin in the CLI. Delete any account not tied to a named individual or documented service identity. Rename the default admin account if your FortiOS version supports it, or set a complex passphrase and restrict its trusted hosts to an offline break-glass workstation. Verify: Confirm the account list matches your identity register. No generic or vendor-default accounts should remain active. Pitfall: Some FortiManager integrations create a local admin account during initial setup. Removing it without updating FortiManager will break centralised management.

8. Review and tighten firewall policies: remove any-to-any rules. Under Policy & Objects > Firewall Policy, filter for rules with source all, destination all, or service ALL. Each should have a documented business justification. Policies with no hits in the last 90 days are candidates for removal. Verify: Enable policy hit counters (config system settings > set policy-auth-concurrent enable) and review the hit count column after 24 hours of production traffic. Pitfall: Hit count resets on reboot. Export counts before a maintenance window if you need historical data.

9. Disable unused services and features at the global level. If you do not use SSL VPN, disable it:

   config vpn ssl settings
     set status disable
   end
   

   Similarly disable WCCP, LLDP transmission, and FortiTelemetry on interfaces where they are not required. Verify: Scan the external interface with nmap -sV from a test host outside the perimeter. SSL VPN port (default 443 or 10443) should not respond. Pitfall: Disabling SSL VPN while remote workers are connected will drop their sessions immediately. Schedule this during a low-traffic window and communicate in advance.

10. Enable and centralise logging. Verify logs are reaching the SIEM. Configure log forwarding to your SIEM or syslog collector under Log & Report > Log Settings. Set log severity to information at minimum. Enable logging on all firewall policies, including implicit deny. Verify: Trigger a policy-denied connection and confirm the event appears in the SIEM within your acceptable latency window (target: under 60 seconds). Pitfall: FortiOS local disk logging fills quickly on busy firewalls. If disk logging is the only method, old events are overwritten silently. Always pair disk logging with remote forwarding.

11. Run a FortiGate hygiene check against your configuration baseline. Use Retrievy's FortiGate hygiene checks inside SCM to diff the running configuration against your approved baseline. Any deviation, such as a re-enabled management interface or a new any-to-any policy, surfaces as a drift alert before it becomes an incident. Verify: Confirm zero open findings after completing steps 1-10. Schedule the check to run on every configuration save event. Pitfall: Baseline drift accumulates fastest after emergency changes. Require a post-incident configuration review within 24 hours of any out-of-band change.

Measuring Success

A hardened FortiGate configuration should produce measurable outcomes:

• Management interface access attempts from untrusted IPs: 0 successful authentications.
• SSL/TLS scan of management port: no protocols below TLS 1.2.
• Firewall policy audit: 0 rules with source all and service ALL without documented exception.
• SIEM log latency: under 60 seconds from event to ingestion.
• SCM drift findings: 0 open after baseline commit.

Rerun this checklist after every FortiOS upgrade. Firmware updates can re-enable features or reset settings that were explicitly disabled. Treat each upgrade as a partial re-hardening event.