Hi there,
i want to reboot my FortiGate 60E via the REST-API. Im using this endpoint:
doing this Request(obviously already authenticated):
curl -k -i -H "Accept: application/json" -X POST "https://ip:port/api/v2/monitor/system/os/reboot" --cookie cookie.txt
But I receive a Forbidden:
{
"http_method":"POST",
"status":"error",
"http_status":403,
"vdom":"root",
"path":"system",
"name":"os",
"action":"reboot",
"serial":"serial",
"version":"v6.0.5",
"build":268
}
How do I reboot the FortiGate via REST API?
PS: Im trying this with a user who has RW permission on all Categorys
Thank you!
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Btw just tested and it works for me using the CSRFTOKEN also ;)
supports-MacBook-Pro:Downloads ken$ cat fgtcookies # Netscape HTTP Cookie File# https://curl.haxx.se/docs/http-cookies.html# This file was generated by libcurl! Edit at your own risk. #HttpOnly_192.168.1.99 FALSE / TRUE 0 APSCOOKIE_79100365 "Era%3D0%26Payload%3DBqjjbe7htCOsFsYzarB2IEMxijyyM0neq8nLlRqdPhTTvad7eL0LZpsb161uxmQC%0AsYzlEA9fitnCbWPkYrtdAXttq3v+u7JbmALCfl5T+ALAE1e1dgquZbFA7iWbn%2FRX%0AjMI7Pvc0zLzCbKRaSWynEw4C2gQXazjG9tdCsTkjydzANRRwh6uulPiNj%2F83T8bg%0Al3DihIFtCw8WjHnA%2F+xK2Q%3D%3D%0A%26AuthHash%3DCA4eiUKEM0zcXjGIij0hoUdQwG4A%0A"192.168.1.99 FALSE / TRUE 0 ccsrftoken_79100365 "FB4B8AD9C51C5E5CBEBECD63EE2457A9"192.168.1.99 FALSE / TRUE 0 ccsrftoken "FB4B8AD9C51C5E5CBEBECD63EE2457A9" supports-MacBook-Pro:Downloads ken$ curl -X POST -s -b fgtcookies -k -H "Content-Type: application/json" -H "X-CSRFTOKEN: FB4B8AD9C51C5E5CBEBECD63EE2457A9" https://192.168.1.99/api/..onitor/system/os/rebootsupports-MacBook-Pro:Downloads ken$ ping 8.8.8.8PING 8.8.8.8 (8.8.8.8): 56 data bytesRequest timeout for icmp_seq 0Request timeout for icmp_seq 1Request timeout for icmp_seq 2 I use my admin account so that profile show be able to reboot the appliance. Cookies were grabbed on the logincheck by using this approach http://socpuppet.blogspot.com/2018/07/howto-use-fortios-api-to-add-delete.html YMMV but I didn't have any issues once I had the right URI in either case e.g /api/v2/monitor/system/os/reboot vrs /api/v2/monitor/system/dashboard/reboot I still think your profile is not correct for sysgrp and the action:reboot, just my hunch and this might lead into the 4xx status codes that are coming back. Ken Felix
PCNSE
NSE
StrongSwan
Try a prof_admin profile. RW probably does work for that cmd level.
Ken Felix
PCNSE
NSE
StrongSwan
Im using a super_admin profile, still not working. Also prof_admin getting the same response.
FWIW . I tried the following with an api_user based on some older API_REFERENCE
Socket1 $curl -X POST -k -H "Authorization: Bearer jx67dQm6r8nd4qQQhptr3rnjhbHdzx" "https://192.168.1.99/api/v2/monitor/system/dashboard/reboot?access_token=jx67dQm6r8nd4qQQhptr3rnjhbHdzx"{ "path":"system", "name":"dashboard", "action":"reboot", "serial":"FWF50xxxxxxxxx", "version":"v6.0.0", "build":76, "status":"error", "http_status":404}Socket1 $ It failed also. I haven't seen a working example on API reboot. The 404 tells me this entry point is not valid. In your status.code 403 seems to be authentication-related. Do you have a api_user ? Do other calls work? e.g API_USER using a authorization header ( the token ) curl -k -H "Authorization: Bearer jx67dQm6r8nd4qQQhptr3rnjhbHdzx" "https://192.168.1.99/api/v2/monitor/system/dhcp?"{ "http_method":"GET", "results":[ { "ip":"192.168.1.113", "mac":"bc:98:df:d3:eb:15", "vci":"android-dhcp-9", "expire_time":1570263781, "status":"leased", "interface":"internal", "type":"ipv4", "reserved":false, "server_mkey":1 }, { "ip":"192.168.1.112", "mac":"78:31:c1:d5:52:d0", "hostname":"supports-MBP", "expire_time":1570263602, "status":"leased", "interface":"internal", "type":"ipv4", "reserved":false, "server_mkey":1 },{output snipped} Socket1 $curl -k -H "Authorization: Bearer jx67dQm6r8nd4qQQhptr3rnjhbHdzx" "https://192.168.1.99/api/v2/monitor/firewall/policy"{ "http_method":"GET", "results":[ { "policyid":0, "active_sessions":0, "bytes":0, "packets":0 }, { "policyid":1, "uuid":"4642baea-885e-51e9-6881-43df12c629e1", "active_sessions":26, "bytes":121036518, "packets":156639, "last_used":1569665902, "first_used":1569607211, "hit_count":3847, "session_last_used":1569665899, "session_first_used":1569607211, "session_count":25 }, { "policyid":2, "uuid":"47cd84ec-ce3d-51e9-2d18-6ba8026ba89f", "active_sessions":23, "bytes":3673664328, "packets":4089520, "last_used":1569665899, "first_used":1569607211, "hit_count":9610, "session_last_used":1569665899, "session_first_used":1569607211, "session_count":23 },{output snipped} Socket1 $curl -k -H "Authorization: Bearer jx67dQm6r8nd4qQQhptr3rnjhbHdzx" "https://192.168.1.99/api/v2/monitor/router/statistics"{ "http_method":"GET", "results":{ "total_lines":8, "total_lines_ipv4":8, "total_lines_ipv6":0 }, "vdom":"root", "path":"router", "name":"statistics", "status":"success", "serial":"xxxxxxxxx", "version":"v6.0.0", "build":76 Do you have any API reference pdf ?
PCNSE
NSE
StrongSwan
I just tried it an got the same error. API profile has read/write for everything.
It's weird, I swear I tested this a while back and it worked, I think it was on 5.6 build. I'm curious as to why it's not working now.
Ok, so I did a debug and can see that it fails because there's no CSRF token sent with the API call:
[size="2"]FortiGate # [httpsd 221 - 1569684993 info] ap_invoke_handler[569] -- new request (handler='api_monitor_v2-handler', uri='/api/v2/monitor/system/os/reboot/', method='POST')[/size] [size="2"][httpsd 221 - 1569684993 info] ap_invoke_handler[573] -- User-Agent: insomnia/6.6.2[/size] [size="2"][httpsd 221 - 1569684993 info] ap_invoke_handler[576] -- Source: 192.168.160.254:59741 Destination: 192.168.160.102:443[/size] [size="2"][httpsd 221 - 1569684993 info] endpoint_handle_req[898] -- received api_monitor_v2_request from '192.168.160.254'[/size] [size="2"][httpsd 221 - 1569684993 info] aps_init_process_vdom[1258] -- initialized process vdom to 'root' (cookie='(null)')[/size] [size="2"][httpsd 221 - 1569684993 info] api_store_parameter[238] -- add API parameter 'access_token' (type=string)[/size] [size="2"][httpsd 221 - 1569684993 info] endpoint_process_req_vdom[709] -- new API request (action='reboot',path='system',name='os',vdom='root',user='admin')[/size] [size="2"][httpsd 221 - 1569684993 error] is_valid_csrf_token[2419] -- no CSRF token found[/size] [size="2"][httpsd 221 - 1569684993 error] api_endpoint_execute_handler[574] -- no valid CSRF token found[/size] [size="2"][httpsd 221 - 1569684993 error] api_return_http_result[690] -- API error 403 raised[/size]
I was under the impression when you send the API admin token in the URL that you don't need to add the CSRF header, maybe I'm missing something.
In any case, I reverted back to using the old way of using the REST API by logging in, copying the CSRF token and using it part of the API call and can confirm the reboot call is now working.
[size="2"][httpsd 221 - 1569685240 info] ap_invoke_handler[569] -- new request (handler='logincheck-handler', uri='/logincheck', method='POST')[/size] [size="2"][httpsd 221 - 1569685240 info] ap_invoke_handler[573] -- User-Agent: insomnia/6.6.2[/size] [size="2"][httpsd 221 - 1569685240 info] ap_invoke_handler[576] -- Source: 192.168.160.254:60085 Destination: 192.168.160.102:443[/size] [size="2"][httpsd 221 - 1569685240 info] logincheck_handler[347] -- entering vdom for login_attempt (vdom='root')[/size] [size="2"][httpsd 221 - 1569685240 info] logincheck_handler[440] -- login attempt OK, VDOM updated to 'root'[/size] [size="2"][httpsd 221 - 1569685240 info] logincheck_handler[448] -- login_attempt (method=5, vdom='root', name='admin',admin_name='admin', auth_svr='')[/size] [size="2"][httpsd 221 - 1569685240 info] ap_invoke_handler[592] -- request completed (handler='logincheck-handler' result==0)[/size] [size="2"][httpsd 214 - 1569685304 info] ap_invoke_handler[569] -- new request (handler='api_monitor_v2-handler', uri='/api/v2/monitor/system/os/reboot', method='POST')[/size] [size="2"][httpsd 214 - 1569685304 info] ap_invoke_handler[573] -- User-Agent: insomnia/6.6.2[/size] [size="2"][httpsd 214 - 1569685304 info] ap_invoke_handler[576] -- Source: 192.168.160.254:60184 Destination: 192.168.160.102:443[/size] [size="2"][httpsd 214 - 1569685304 info] endpoint_handle_req[898] -- received api_monitor_v2_request from '192.168.160.254'[/size] [size="2"][httpsd 214 - 1569685304 info] aps_init_process_vdom[1258] -- initialized process vdom to 'root' (cookie='(null)')[/size] [size="2"][httpsd 214 - 1569685304 info] endpoint_process_req_vdom[709] -- new API request (action='reboot',path='system',name='os',vdom='root',user='admin')[/size] [size="2"][httpsd 214 - 1569685304 info] ap_invoke_handler[592] -- request completed (handler='api_monitor_v2-handler' result==0)[/size] [size="2"][httpsd 151 - 1569685310 error] log_error_core[439] -- [Sat Sep 28 15:41:50 2019] [notice] caught SIGTERM, shutting down[/size]
Other request do work like I do it (im not using an API User, its just a normal super_admin which I login via /logincheck and then grab the CSRF-token) So I'm curious why its not working the way I do it.
Could you please post your curl call?
So the dashboard/reboot does not work, your URI is not found in my documentation even tho my API reference doc is quite old. Do you have a link to a newier version?
To answer your question, I'm using super_admin and post to the same URI as yours. I did a type of "do" vrs "os" to ensure and status.code 404
curl -X POST -k -H "Authorization: Bearer jx67dQm6r8nd4qQQhptr3rnjhbHdzx" "https://192.168.1.99/api/v2/monitor/system/os/reboot?access_token=jx67dQm6r8nd4qQQhptr3rnjhbHdzx"curl: (52) Empty reply from server
{ debug output }
[httpsd 1362 - 1569780248 info] ap_invoke_handler[593] -- new request (handler='api_monitor_v2-handler', uri='/api/v2/monitor/system/do/reboot?access_token=******************************', method='POST')[httpsd 1362 - 1569780248 info] ap_invoke_handler[597] -- User-Agent: curl/7.54.0[httpsd 1362 - 1569780248 info] ap_invoke_handler[600] -- Source: 192.168.1.112:60747 Destination: 192.168.1.99:443[httpsd 1362 - 1569780248 info] endpoint_handle_req[585] -- received api_monitor_v2_request from '192.168.1.112'[httpsd 1362 - 1569780248 warning] api_access_check_for_api_key[954] -- API Key request authorized for soc2 from 192.168.1.112.[httpsd 1362 - 1569780248 warning] endpoint_process_req[476] -- no matching method found[httpsd 1362 - 1569780248 error] api_return_http_result[516] -- API error 404 raised[httpsd 1362 - 1569780248 info] ap_invoke_handler[616] -- request completed (handler='api_monitor_v2-handler' result==0)[httpsd 190 - 1569780258 info] ap_invoke_handler[593] -- new request (handler='api_monitor_v2-handler', uri='/api/v2/monitor/system/os/reboot?access_token=******************************', method='POST')[httpsd 190 - 1569780258 info] ap_invoke_handler[597] -- User-Agent: curl/7.54.0[httpsd 190 - 1569780258 info] ap_invoke_handler[600] -- Source: 192.168.1.112:60750 Destination: 192.168.1.99:443[httpsd 190 - 1569780258 info] endpoint_handle_req[585] -- received api_monitor_v2_request from '192.168.1.112'[httpsd 190 - 1569780258 warning] api_access_check_for_api_key[954] -- API Key request authorized for soc2 from 192.168.1.112.[httpsd 190 - 1569780258 info] api_store_parameter[226] -- add API parameter 'access_token': '********' (type=string)[httpsd 190 - 1569780258 info] endpoint_process_req_vdom[440] -- new API request (action='reboot',path='system',name='os',vdom='root',user='soc2')[httpsd 123 - 1569780262 error] log_error_core[439] -- [Sun Sep 29 18:04:22 2019] [notice] caught SIGTERM, shutting downConnection to 192.168.1.99 closed by remote host.Connection to 192.168.1.99 closed. NOTE" soc2 is my api_user name. Thanks for the correct URI. "/api/v2/monitor/system/dashboard/reboot" is not working So your issues were 100% authentication issues. Ken Felix
PCNSE
NSE
StrongSwan
I honestly have no idea why, but rebooting is not working for me. If I try it the way you showed it (with an API user with Read/Write priv. on everything) it gives me a 401 - Error on every Request. If I authenticate with a super_admin via /logincheck and then do API calls with the CSRF-Token, I can make every API call, but rebooting is still giving me 403.
How do I enable this debugging thing you posted or how can I view these logs? Maybe this could help me.
Thank you!
Your httpsd debug should confirm, but let me test the other way ( CSRF ) and see what happens. I have no API reference that should that URI that you're using, but call it up does work at least for me. So to that's the entry poin
Your 401 and 403 are disturbing, so I would investigate those items. BTW I'm stuck on fortiOS 6.0.0 in this FWF50 so I can test another model at this time. Have recently upload or download the appliance and what happens if you craft a new token?
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1641 | |
1069 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.