How to monitor Check Point API?

[IdentityUnknown]

Hi folks,

one question. Do I have any chances to monitor the status of the REST API without a login?

On the CLI I am able to check the "api status".

If everything is fine I will get the message

"API readiness test SUCCESSFUL. The server is up and ready to receive connections"

Now I want to monitor the API status with a simple curl statement. But without the need of a session id and authorization.

 Any ideas?

Best regards!

[HeikoAnkenbrand]

Use this CLI command and you get the mgmt version:

# mgmt_cli -r  true show version


product-version: "Check Point Gaia R80.30"
os-build: "200"
os-kernel-version: "3.10.0-693cpx86_64"
os-edition: "64-bit"

[IdentityUnknown]

Yes, but I need the status from an external monitoring device and via https.
I need an URL which I am able to access without login credentials and which will response with http status 200 if the API is up and running.

https://1.1.1.1:443/web_api responses with 200 but it doesn't matter if the API is up or down. 

[Nüüül]

Hi

you can either for mgmt api use the SDK from Checkpoint ( https://github.com/CheckPointSW/cp_mgmt_api_python_sdk ) for logging in and checking if logging in was successful. like:

if login_res.success is False:
  print("Login failed: {}".format(login_res.error_message))
  raise SystemExit("UNKNOWN")
do-something = client.api_call("show-something")

if login_res.success just checks if the respons´s JSON field "success" has value false

I assume you have some kind of Monitoring in place that looks for Responses like "OK", "WARNING, "CRITICAL" or "UNKNOWN"? i.e. Nagios based. With the SystemExit you can raise these towards the application.

(remember to logoff the session afterwards, otherwise you´ll end up with lots of orphaned sessions)

Maybe this helps:

https://github.com/leinadred/CP_IPS-Update-Monitoring4Nagios

(just take out the IPS stuff 🙂 )

For gateway API there is no SDK AFAIK, so you might have to "login manually" via sending http requests in json and so... it´s possible with some time

Daniel

[PhoneBoy · Accepted solution]

Every API call other than login requires an active session ID. There is no "status" API call that I am aware of. Might be a decent RFE. @Omer_Kleinstern 

[796570686578]

Do you know if this has ever been implemented or if there is a different solution to actively monitor the management API? I went through the current API docs but wasn't able to find anything

[PhoneBoy]

There aren't any endpoints you can query that monitor the health of the API itself, except for possibly something via run-script.
However run-script requires admin privileges, which is probably not a good idea for "monitoring" purposes.
Even so, if you can log in with a read-only user, the API is "active."

An RFE is probably necessary.

[Nüüül]

If you tell something about how you are monitoring the system and what the expected outcome is there might be ideas.

like:

SNMP, expected Outcome "I want to know, if the service in general is running":

in Check Point MIBs i didn´t find something out of the box, that indicates mgmt API health (might be an idea for future releases?)  Maybe custom OIDs might work?

CURLing onto management API LogIn endpoint with just an empty POST will end up in:

curl https://<mgmtip>/web_api/login --insecure -X POST

{
"code" : "generic_err_invalid_syntax",
"message" : "Login request message processing failed"
}

which at least indicates, that API is running and expecting LogIn informations. 

Another one would be to monitor by ssh (most monitoring solutions have this aboard) and let them issue something like:

api status | grep "API readiness\|Overall API Status" | sed -e 's/API readiness test/API State:/g'

[Expert@labfwm:0]# api status | grep "API readiness\|Overall API Status" | sed  -e 's/API readiness test/API State:/g'
Overall API Status: Started
API State: SUCCESSFUL. The server is up and ready to receive connections
[Expert@labfwm:0]# api stop
2024-May-24 07:10:28 - Stopping API ...
2024-May-24 07:10:30 - API stopped successfully.
[Expert@labfwm:0]# api status | grep "API readiness\|Overall API Status" | sed  -e 's/API readiness test/API State:/g'
Overall API Status: The API Server Is Not Running!
API State: FAILED. The server is down and unable to receive connections!
[Expert@labfwm:0]# api start
2024-May-24 07:10:41 - Starting API ...
2024-May-24 07:10:43 - API started successfully.
[Expert@labfwm:0]# api status | grep "API readiness\|Overall API Status" | sed  -e 's/API readiness test/API State:/g'
Overall API Status: Started
API State: SUCCESSFUL. The server is up and ready to receive connections
[Expert@labfwm:0]#

Only some ideas, without knowing what your thoughts / goal is. Perhaps this commands can be issued via custom OID, but did not find further documentation on this, right now. (and was too lazy to look longer than i did 🙂 )

[Bob_Zimmerman]

The 'api' command requires root access to run, which I know I would rather not give to a monitoring tool. The cURL call definitely works, though. You get a 503 when the API is down, and a 400 when the API is up. Zero authentication needed:

[Expert@TestSC]# api stop
2024-May-24 13:36:05 - Stopping API ...
2024-May-24 13:36:07 - API stopped successfully.
[Expert@TestSC]# curl_cli -vkX POST https://127.0.0.1/web_api/login 
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering http/1.1
* *** Current date is: Fri May 24 13:36:21 2024
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* err is -1, detail is 2
* *** Current date is: Fri May 24 13:36:21 2024
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* servercert: Activated
* servercert: CRL validation was disabled
* Server certificate:
*  subject: L=Locality Name (eg, city); CN=169.254.0.1; emailAddress=Email Address; unstructuredName=An optional company name
*  start date: May 19 16:16:45 2024 GMT
*  expire date: May 19 16:16:45 2034 GMT
*  issuer: L=Locality Name (eg, city); CN=169.254.0.1; emailAddress=Email Address; unstructuredName=An optional company name
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* servercert: Finished
< HTTP/1.1 503 Service Unavailable
< Date: Fri, 24 May 2024 13:36:21 GMT
< Server: CPWS
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Frame-Options: SAMEORIGIN
< Content-Length: 299
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Unavailable</title>
</head><body>
<h1>Service Unavailable</h1>
<p>The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.</p>
</body></html>
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
[Expert@TestSC]# api start
2024-May-24 13:36:29 - Starting API ...
2024-May-24 13:36:31 - API started successfully.
[Expert@TestSC]# curl_cli -vkX POST https://127.0.0.1/web_api/login 
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering http/1.1
* *** Current date is: Fri May 24 13:37:51 2024
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* err is -1, detail is 2
* *** Current date is: Fri May 24 13:37:51 2024
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* servercert: Activated
* servercert: CRL validation was disabled
* Server certificate:
*  subject: L=Locality Name (eg, city); CN=169.254.0.1; emailAddress=Email Address; unstructuredName=An optional company name
*  start date: May 19 16:16:45 2024 GMT
*  expire date: May 19 16:16:45 2034 GMT
*  issuer: L=Locality Name (eg, city); CN=169.254.0.1; emailAddress=Email Address; unstructuredName=An optional company name
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* servercert: Finished
< HTTP/1.1 400 Bad Request
< Date: Fri, 24 May 2024 13:37:51 GMT
< Server: Jetty(9.2.9.v20150224)
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json
< X-UA-Compatible: IE=EmulateIE8
< X-Forwarded-Host-Port: 443
< Connection: close
< Transfer-Encoding: chunked
< 
{
  "code" : "generic_err_invalid_syntax",
  "message" : "Login request message processing failed"
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
}[Expert@TestSC]#