Technical Tip: Securing the FortiGate administrative interface against brute-force attacks
| Description | This article describes methods to reduce brute-force attempts against the FortiGate administrative interface. A brute-force attempt against an administrator account is commonly identified by repetitive administrator login failure events in the event logs, assuming that Event Log and Administrator Events are enabled.
In many environments, these login attempts are generated by automated tools running from compromised hosts on the Internet. These tools scan for reachable HTTPS and SSH services, then attempt known credentials, weak passwords, or known attack patterns. |
| Scope | FortiGate, FortiOS v7.2.x, v7.4.x, v7.6.x. |
| Solution | The most effective protection is to restrict administrative access so that only known source IP addresses can reach the administrative services.
One method is to configure trusted hosts on each administrator account. Go to System -> Administrators, edit the required administrator account, then configure the trusted hosts that are allowed to connect to the FortiGate. A single host or an entire subnet can be defined.
If one administrator account does not have trusted hosts configured, FortiGate still allows administrative access on the enabled management services from any source IP address. In that case, the trusted host restriction applies only to the administrator accounts that have trusted hosts configured. Another method is to use a local-in policy to restrict administrative access from the WAN interface without fully disabling HTTPS or SSH administrative access. This approach is useful when administrative access must remain enabled on a WAN-facing interface, but access must be limited to a defined list of source addresses.
In FortiOS v7.2.x and v7.4.x, local-in policies must be configured from the CLI. Create address objects for the approved management IP addresses or subnets, then place them in an address group. Create a custom service object if a custom HTTPS port or a custom SSH port is used. After that, apply the local-in policy.
config firewall local-in-policy 
This example denies access from all source addresses that are not part of the allowed address object or address group referenced by 'Admin-In', while still keeping administrative access enabled on the interface. A further hardening measure is to use the Internet Service Database in a local-in policy to block traffic from known malicious sources, such as botnet infrastructure, phishing hosts, anonymous VPN providers, proxy services, Tor nodes, and bulletproof hosting providers. config firewall local-in-policy 
This method does not replace trusted hosts or explicit local-in restrictions for administrative access. It adds another layer of protection by reducing exposure to known hostile networks.
For additional hardening, limit administrative access only to the required protocols, use non-default administrative ports where operationally appropriate, and ensure that strong administrator passwords and multi-factor authentication are enabled where supported. The command 'diagnose alertconsole list' is helpful in identifying login failures; the command also displays the source IP where the attempt originated. Technical Tip: How to delete or rename the default 'admin' user Technical Tip: System administrator best practices Technical Tip: Recommendations and common scenarios for Administrator access on FortiGate |
