|
Authentication attempts for firewall administrators and REST API users are subject to lockouts according to the admin-lockout settings in 'config system global'.
For API users only, the duration of the administrative lockout is not static. The first time the IP is blocked, it is for the value configured in 'admin-lockout-duration'. Subsequent lockouts for the same IP address are double the previous lockout duration.
Relevant configuration settings:
API_TEST # config system global
API_TEST (global) # set admin-lockout?
admin-lockout-duration <----- Amount of time in seconds that an administrator account is locked out after reaching the admin-lockout-threshold for repeated failed login attempts.
admin-lockout-threshold <----- Number of failed login attempts before an administrator account is locked out for the admin-lockout-duration.
API_TEST (global) # set admin-lockout-duration ?
admin-lockout-duration <----- Enter an integer value from <1> to <2147483647> (default = <60>).
API_TEST (global) # set admin-lockout-threshold ?
admin-lockout-threshold <----- Enter an integer value from <1> to <10> (default = <3>).
Administrative lockouts prevent a blocked source IP from authenticating until the lockout-duration passes or the device is rebooted.
If a FortiGate with the default lockout-duration of 60 seconds continues to receive API calls improper credentials from a particular IP address, that IP will have API calls blocked for 60s, then 120s, then 240s, and so on. There is no practical upper bound for lockout duration. A monitoring tool with an outdated API credential that continues to make API calls will accumulate a significant lockout time even if the initial configured lockout duration is short.
A single successful authentication will reset the count completely, but during lockout, FortiGate rejects the API call without checking the API user's token. API calls during lockout do not contribute to successes or failures.
Example lockout diagnostics from SSH session:
diagnose debug application httpsd -1
diagnose debug console timestamp enable
diagnose debug enable
2024-12-06 12:45:47 [httpsd 516 - 1733445947 info] fweb_debug_init[531] -- New GET request for "/api/v2/monitor/system/current-admins" from "10.255.254.200:50578"
2024-12-06 12:45:47 [httpsd 516 - 1733445947 info] fweb_debug_init[533] -- User-Agent: "curl/8.0.1"
2024-12-06 12:45:47 [httpsd 516 - 1733445947 info] fweb_debug_init[535] -- Handler "api_monitor_v2-handler" assigned to request
2024-12-06 12:45:47 [httpsd 516 - 1733445947 info] api_access_check_for_api_key[638] -- No api-user found. <----- Token provided does not match any configured api-user.
2024-12-06 12:45:47 [httpsd 516 - 1733445947 warning] _lock_out_check_and_lock_out[416] -- Failed api-key login attempt from 10.255.254.200. (1/3 attempts within 60s).
2024-12-06 12:45:47 [httpsd 516 - 1733445947 info] fweb_debug_final[355] -- Completed GET request for "/api/v2/monitor/system/current-admins" (HTTP 401 Unauthorized)
...
2024-12-06 12:45:51 [httpsd 516 - 1733445951 warning] _lock_out_check_and_lock_out[416] -- Failed api-key login attempt from 10.255.254.200. (2/3 attempts within 60s).
...
2024-12-06 12:45:52 [httpsd 516 - 1733445952 warning] _lock_out_check_and_lock_out[411] -- Blocking api-key login attempts from 10.255.254.200 for 60s after 3 failures.
2024-12-06 12:45:52 [httpsd 516 - 1733445952 info] fweb_debug_final[355] -- Completed GET request for "/api/v2/monitor/system/current-admins" (HTTP 429 Too Many Requests)
Later, the lockout cleared and the administrator sent more test API calls, which also had the wrong Token.
2024-12-06 12:58:04 [httpsd 588 - 1733446684 warning] _lock_out_check_and_lock_out[416] -- Failed api-key login attempt from 10.255.254.200. (1/3 attempts within 60s).
...
2024-12-06 12:58:06 [httpsd 588 - 1733446686 warning] _lock_out_check_and_lock_out[416] -- Failed api-key login attempt from 10.255.254.200. (2/3 attempts within 60s).
...
2024-12-06 12:58:08 [httpsd 588 - 1733446688 warning] _lock_out_check_and_lock_out[411] -- Blocking api-key login attempts from 10.255.254.200 for 120s after 6 failures. <----- After 6 consecutive attempts with invalid tokens, lockout time doubles.
2024-12-06 12:58:08 [httpsd 588 - 1733446688 info] fweb_debug_final[355] -- Completed GET request for "/api/v2/monitor/system/current-admins" (HTTP 429 Too Many Requests)
2024-12-06 12:58:10 [httpsd 588 - 1733446690 info] fweb_debug_init[531] -- New GET request for "/api/v2/monitor/system/current-admins" from "10.255.254.200:58664"
2024-12-06 12:58:10 [httpsd 588 - 1733446690 info] fweb_debug_init[533] -- User-Agent: "curl/8.0.1"
2024-12-06 12:58:10 [httpsd 588 - 1733446690 info] fweb_debug_init[535] -- Handler "api_monitor_v2-handler" assigned to request
2024-12-06 12:58:10 [httpsd 588 - 1733446690 warning] _api_key_lock_out[495] -- Request from 10.255.254.200 will be ignored. Locked out for 118 more seconds.
2024-12-06 12:58:10 [httpsd 588 - 1733446690 info] fweb_debug_final[355] -- Completed GET request for "/api/v2/monitor/system/current-admins" (HTTP 429 Too Many Requests)
While the api-user is locked out, the FortiGate will return HTTP error 429 'Too many requests'.
Example output from a test API call while the user is locked out:
curl -k -v "https://10.255.255.100/api/v2/monitor/system/current-admins" --header "Authorization: Bearer 86zk**********************8s58" <--- key is entered in Request Header.
* Trying 10.255.255.100:443...
* Connected to 10.255.255.100 (10.255.255.100) port 443 (#0)
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: offers http/1.1
* ALPN: server accepted http/1.1
* using HTTP/1.1
> GET /api/v2/monitor/system/current-admins HTTP/1.1
> Host: 10.255.255.100
> User-Agent: curl/8.0.1
> Accept: */*
> Authorization: Bearer 86zk**********************8s58
>
< HTTP/1.1 429 Too Many Requests <----- FortiGate returns HTTP error 429 during lockout regardless of whether key is correct.
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< Strict-Transport-Security: max-age=63072000
< date: Thu, 05 Dec 2024 23:06:22 GMT
< content-length: 354
< content-type: text/html; charset=iso-8859-1
< Connection: keep-alive
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>429 Too Many Requests</title>
</head><body>
<h1>Too Many Requests</h1>
<p>The user has sent too many requests
in a given amount of time.</p>
<p>Additionally, a 429 Too Many Requests
error was encountered while trying to use an ErrorDocument to handle the request.</p>
</body></html>
* Connection #0 to host 10.255.255.100 left intact
The remaining lockout time of a failing API call can be verified from the FortiGate httpsd debug output. If it is not possible to wait for the remaining lockout time, a different source IP address should be used for the API call.
In some previous FortiOS versions, it was possible to work around a system administrator lockout by logging in from a different source IP and manipulating the configured lockout time. This was never possible for REST API users and has been removed for system administrators in current FortiOS versions, see this KB article: How to clear disabled admin lockout.
Note: It may sometimes be necessary to generate a new API key in order to resolve a 403 error code.
|
