- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Hi,
We make significant use of Dynamic Global Network Objects in our policies, specifically for install-on targets but also within global rules as source and destination fields. These were previously created via the following dbedit commands on R77.30
create dynamic_object DMZ_Firewalls_global
modify network_objects DMZ_Firewalls_global bogus_ip 0.0.0.1
modify network_objects DMZ_Firewalls_global color black
modify network_objects DMZ_Firewalls_global comments "All site DMZ virtual firewalls"
update network_objects DMZ_Firewalls_global
And these have been "converted" to an object of
Thanks for the information. Not having the ability to create these "new" variants of the object via the API seems like a bit of a miss as they were available to create via dbedit in the past (this now fails too); our existing tooling is now unable to take full advantage of the API.
And yes, by referencing the UID instead of the name I am able to use the objects in the source/destination field in the policy. I was just wondering if the ability to only reference by UID is either by design, a problem or that the inability to reference by name for that rule field is the problem (referencing by name for the install-on value/field works fine)
Hi Mike
Here is a one-liner to create a Global Dynamic Network object in the Global domain using the undocumented add-generic-object API endpoint.
Please Note:
These APIs provide direct access to different objects and fields in the database. As a result if an objects schema change, scripts that relied on specific schema fields may break.
As the generic-object(s) API calls have direct access to change different objects and fields in the database, they do not provide any data validation to ensure that the data added to the fields are following required format for this field. Therefore you have to ensure that the script or 3rd party system you are using to integrate with the management server is doing appropriate data validation before sending the API call.
mgmt_cli -r true -d Global -f json add-generic-object create "com.checkpoint.blades_common.objects.DynamicGlobalNetworkObject" name DMZ_Firewalls_global
Here is a small shell script that can be used:
https://github.com/jimoq/CHKP_api_examples/blob/master/mgmt_cli/generic_object_add_dynamic_global_ne...
You can get it to the management server by running
[Expert@mds10:0]# curl_cli -kLs https://raw.githubusercontent.com/jimoq/CHKP_api_examples/master/mgmt_cli/generic_object_add_dynamic_global_network_object.sh > generic_object_add_dynamic_global_network_object.sh
[Expert@mds10:0]# bash generic_object_add_dynamic_global_network_object.sh DMZ_Firewalls
Concerning the other issue with adding a Global dynamic object to to source and destination column in the access control rulebase . I tested it and get the same result, for me it looks like a issue that should be resolved by our support, I suggest that you open a ticket with support to get a fix for that
Not available as an API object (yet?) therefore not possible to create them that way.
By using the UID reference you can bypass the problem that there is no variable set for the object maybe?
Thanks for the information. Not having the ability to create these "new" variants of the object via the API seems like a bit of a miss as they were available to create via dbedit in the past (this now fails too); our existing tooling is now unable to take full advantage of the API.
And yes, by referencing the UID instead of the name I am able to use the objects in the source/destination field in the policy. I was just wondering if the ability to only reference by UID is either by design, a problem or that the inability to reference by name for that rule field is the problem (referencing by name for the install-on value/field works fine)
@Omer_Kleinstern can you chime in here?
There are still a handful of attributes/object types that don’t have official API support.
Entirely possible this is doable with the generic-object API.
There are a few examples in the community (not for this specifically).
thanks for the detail.
Hi Mike
Here is a one-liner to create a Global Dynamic Network object in the Global domain using the undocumented add-generic-object API endpoint.
Please Note:
These APIs provide direct access to different objects and fields in the database. As a result if an objects schema change, scripts that relied on specific schema fields may break.
As the generic-object(s) API calls have direct access to change different objects and fields in the database, they do not provide any data validation to ensure that the data added to the fields are following required format for this field. Therefore you have to ensure that the script or 3rd party system you are using to integrate with the management server is doing appropriate data validation before sending the API call.
mgmt_cli -r true -d Global -f json add-generic-object create "com.checkpoint.blades_common.objects.DynamicGlobalNetworkObject" name DMZ_Firewalls_global
Here is a small shell script that can be used:
https://github.com/jimoq/CHKP_api_examples/blob/master/mgmt_cli/generic_object_add_dynamic_global_ne...
You can get it to the management server by running
[Expert@mds10:0]# curl_cli -kLs https://raw.githubusercontent.com/jimoq/CHKP_api_examples/master/mgmt_cli/generic_object_add_dynamic_global_network_object.sh > generic_object_add_dynamic_global_network_object.sh
[Expert@mds10:0]# bash generic_object_add_dynamic_global_network_object.sh DMZ_Firewalls
Concerning the other issue with adding a Global dynamic object to to source and destination column in the access control rulebase . I tested it and get the same result, for me it looks like a issue that should be resolved by our support, I suggest that you open a ticket with support to get a fix for that
Jim,
Thanks a lot for the detail. Fully understand that there is a lack of validation - will use this with care.
Mike
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY