topic Understanding API output using show-logs command in API / CLI Discussion

Understanding API output using show-logs command

iamnzri — Fri, 20 Jan 2023 21:44:45 GMT

Hello everyone,

Glad to be a part of the community. I only started using Checkpoint's Smart Console recently and am still learning a lot about it.
I am trying to write a python script that processes the correlation between rules and log entries (not audit logs) and have since been delving deeper into the capabilities of the API.

However, I found out that the keys structure from the show logs output are not very predictable. I keep getting KeyErrors because the key-value pair that I expect does not appear in the dictionary from the API. It seems that there is a certain logic behind it. For example, connections that are dropped does not necessarily have a matched rule number attached to the log. This wasn't documented in the API reference.

I've also found out that ip addresses that are not internal doesn't have the key-value src_attr. I think there are a lot more pitfalls that I have yet to discover. But since there's about 10-20 key-pairs in the results, I do not want to theorize what every single one means and work based on guesses.

I wished the docs have some more info on what type of log entries that might appear and how to reliably parse the data given. Does anyone maybe have some experience with this?

Edit: I am using SmartConsole R81.10. Screenshots coming soon

Re: Understanding API output using show-logs command

PhoneBoy — Fri, 20 Jan 2023 19:25:18 GMT

Let's start with version/JHF of the management.
Some precise examples with sensitive data redacted might be helpful for discussion purposes.
This includes both API output and screenshots of the relevant log cards.

Re: Understanding API output using show-logs command

iamnzri — Mon, 23 Jan 2023 18:13:15 GMT

Thank you for your response.

As mentioned in the edited original post, I am using the version R81.10 with JHF B410 (whatever that means 😅).

I am expecting this output from the show-logs command.

"__interface": "bond80.3562", "action": "Accept", "conn_direction": "Incoming", "db_tag": "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXB398}", "domain": "DE", "dst": "000.232.30.1", "dst_attr": [ { "isCHKPObject": "true", "resolved": "DE-DNS.de.top.com" } ], "first": "true", "fservice": "domain-udp", "i_f_dir": "inbound", "i_f_name": "bond80.3562", "id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX00fe", "id_generated_by_indexer": "false", "layer_name": "SomeLayer Network", "log_delay": "1674022657", "logid": "0", "marker": "@A@@B@1674022009@C@6619901", "match_table": [ { "layer_name": "SomeLayer Network", "layer_uuid": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXf4e7", "match_id": "36", "parent_rule": "0", "rule": "31.6", "rule_action": "Accept", "rule_uid": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXd8e7" } ], "orig": "de-aah-ant-dc-f020_de-datac", "orig_log_server": "000.178.157.42", "orig_log_server_attr": [ { "isCHKPObject": "true", "resolved": "mdlog-de1", "uuid": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX64b4" } ], "policy_date": "2023-01-16T11:44:05Z", "policy_mgmt": "fwm1-de1", "policy_name": "de_datac", "product": "Firewall", "product_family": "Access", "proto": "17", "proto_attr": [ { "isCHKPObject": "false", "resolved": "UDP (17)" } ], "rule": "31.6", "rule_uid": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXd8e7", "s_port": "50135", "sequencenum": "4229", "service": "53", "service_id": "domain-udp", "src": "000.232.194.154", "src_attr": [ { "isCHKPObject": "true", "resolved": "appliance-de-ops-worker-002-p3-cg1.de.redacted.XXX" } ], "time": "2023-01-18T06:17:37Z", "type": "Connection"

As you can see, I can rely upon the fact that there is a matched rule, service id, and src_attr.

Note that there is a corresponding rule to this network traffic. A connection with a matched rule would be a type of this kind of log entry.
There is also a connection with no matched rule, because for example the participants don't execute the TCP protocol correctly. Then there wouldn't be any matched rule in the response

Then, I also notice the key outzone/inzone. This key-pair also do not appear regularly. From what I understand, it tells whether the connection destination is within the network or outside of the network. If so, Checkpoint could've just provide some regularity by giving the same key-pair in each log entry, couldn't they?

{ "__interface": "bond80.3562", "action": "Accept", "db_tag": "{XXXXXXXX-XXXX-XXXX-XXXX-980BBAA7B398}", "domain": "DE", "dst": "000.232.30.124", "dst_attr": [ { "isCHKPObject": "true", "resolved": "wtsfug.de.redacted.xxx" } ], "first": "true", "fservice": "https", "i_f_dir": "inbound", "i_f_name": "bond80.3562", "id": "XXXXXXXX-XXXX-XXXX-XXXX-8f01000000ec", "id_generated_by_indexer": "false", "inzone": "External", "layer_name": "SomeLayer Network", "logid": "0", "marker": "@A@@B@1674022009@C@6619900", "match_table": [ { "layer_name": "SomeLayer Network", "layer_uuid": "XXXXXXXX-XXXX-XXXX-XXXX-d8d2070bf4e7", "match_id": "1837", "parent_rule": "0", "rule": "31.1807", "rule_action": "Accept", "rule_name": "Ersatzregel", "rule_uid": "XXXXXXXX-XXXX-XXXX-XXXX-0116356bd3f8" } ], "orig": "de-aah-ant-dc-f020_de-datac", "orig_log_server": "000.178.157.42", "orig_log_server_attr": [ { "isCHKPObject": "true", "resolved": "mdlog-de1", "uuid": "XXXXXXXX-XXXX-XXXX-XXXX-b895029f64b4" } ], "outzone": "Internal", "policy_date": "2023-01-16T11:44:05Z", "policy_mgmt": "fwm1-de1", "policy_name": "de_datac", "product": "Firewall", "product_family": "Access", "proto": "6", "proto_attr": [ { "isCHKPObject": "false", "resolved": "TCP (6)" } ], "rule": "31.1807", "rule_name": "Ersatzregel", "rule_uid": "XXXXXXXX-XXXX-XXXX-XXXX-0116356bd3f8", "s_port": "51151", "sequencenum": "4228", "service": "443", "service_id": "https", "src": "000.252.165.0", "time": "2023-01-18T06:17:37Z", "type": "Connection" },

Any help or comment will be appreciated.

Regards

Re: Understanding API output using show-logs command

PhoneBoy — Tue, 24 Jan 2023 03:49:06 GMT

Did you compare the API results with that of the log cards for the same data?
I suspect you will find them identical.
The issue isn't with the API, the issue is with the specific logs.

Without seeing the exact logs in question, it's going to be difficult to comment much further on this.
Recommend engaging with the TAC.