Troubleshooting Tip: High CPU usage due to httpsd daemon on FortiGate
| Description | This article describes how to troubleshoot scenarios where the FortiGate runs into high CPU utilization due to multiple httpsd daemons seen in a user environment. |
| Scope | FortiGate. |
| Solution |
diagnose sys process pidof httpsd
diagnose sys top 10 50 | grep httpsd
httpsd 1106 R 96.0 0.7 0 . .
If all of these symptoms occur, check the number of active admin sessions to the FortiGate:
get system info admin status
If there are multiple admin sessions, disconnect them from the GUI and only let one admin via SSH if the high CPU continues.
It will be prudent to check the httpsd real-time debug. The following is a real example that reports the same high CPU symptoms from httpsd daemons. In the output below, there are multiple HTTP POST requests targeting the login page coming from different IPs.
diagnose debug app httpsd -1 diagnose debug enable [httpsd 1168 - 1764537551 info] fweb_debug_init[451] -- New POST request for "/logincheck" from "X.X.X.233:56302"
During HTTPS daemon debugging on a FortiGate, log entries such as '[httpsd ... info] logincheck_handler[565] -- login attempt completed with code -100' indicate repeated failed or incomplete administrative login attempts.
The code '-100' reflects unsuccessful authentication, which may result from automated scripts, multiple browser sessions, or unauthorised probing. These repeated attempts increase the workload on existing httpsd worker processes. This activity elevates httpsd CPU usage and can cause it to appear at the top of 'diagnose sys top' output.
The source of such attempts can be restricted by configuring a local-in-policy to block access to the administrative HTTPS service from untrusted addresses.
To disable debugging:
diagnose debug reset diagnose debug disable
Go to Log & Report -> System Events, and analyze the event logs for multiple HTTPS login attempts and note the interface that is receiving these login attempts.
Alternatively, the sniffer command can also be executed to check incoming requests via CLI:
diagnose sniffer packet <wan-interface> 'host <wan-interface-ip> and port <admin-port>' 4 0 l
Workaround:
In the CLI:
config system interface edit "wan" set allowaccess ping # (remove https, ssh unless required) next end
The httpsd processes can be restarted by executing the command 'fnsysctl killall httpsd' or 'diagnose system kill 11 [pid_of_httpsd]'.
If GUI Administrative Access needs to be enabled on the internet-facing ports, consider using a Local‑In Policy to restrict GUI access from only specific Public IP Addresses.
config firewall local-in-policy set schedule "always" set service "HTTPS" set schedule "always"
As best practice, a 'local-in policy' can be configured with a GEO address object as follows:
First: Create an address object with 'geography' type:
config firewall address
Second: Use it as 'srcaddr' in the 'local-in policy':
config firewall local-in-policy set schedule "always" edit 2 set schedule "always"
Note: If the GUI access service does not use port 443, ensure the service is created with the correct port and then added to the 'local-in policy'. To review the administrative port, input this command:
In FortiOS v7.6.4 and above, a new daemon, the http_authd daemon, is introduced to enhance administrator authentication and session handling for connections to the FortiGate GUI. Refer Technical Tip: In FortiOS 7.6.4 and later, administrator web authentication is handled by the http_authd process
Related articles:
|
