Hello Checkmates!
I wrote those two tools for one of my projects. I wanted to have an easy way of rulebases migration from Managment to management IE: Lab to prod, prod to lab... To do so, I leverage some useful and quick API calls:
As an example, the call:“show access-rulebase name "RulebaseName" details-level full” will return the whole rulebase. The json output will contain all objects(objects-dictionary[]) and rules(rulebase[]).
Once we have the JSON in hand, we can then execute query on it using "jq". This means fewer API calls are sent to the management server. Less API calls mean more speed.
Here some "jq" queries examples:
This is the command to list all available layers name inside current management.
First we get the JSON file by sending this one API call:
mgmt_cli show access-rulebases --session-id "$session_id" –format json > access-layers.json
Here the JQ query to get all layers name:
cat access-layers.json | jq '."access-layers"[]|.name'
This is the command To get the rulebase JSON:
mgmt_cli show access-rulebase name “$LayerName” --session-id "$session_id" –format json
JQ query examples to work on that rulebase:
This will show all information for the access-layer Network:
cat Network.json | jq ‘.”rulebase”[]’
This will show information on rule number 12:
cat Network.json | jq ‘.”rulebase”[12]’
This will show the Sources of rule number 12:
cat Network,json | jq ‘.”rulebase”[12]|.source’
This will show all objects by this rulebase:
cat network.json | jq ‘.”objects-dictionary”[]’
You can then search for object name, UID, type like this:
This show information of object name R80GW:
cat network.json | jq ‘.”objects-dictionary”[]|select (.name== “’R80GW’”)’
This show information of object UID aedb0f7c-c5f4-4f07-bad0-9e29200041dc:
cat network.json | jq ‘.”objects-dictionary”[]|select (.uid== “’aedb0f7c-c5f4-4f07-bad0-9e29200041dc’”)’
This will show all host in dictionary:
cat network.json | jq ‘.”objects-dictionary”[]|select (.type== “’host”)’
The advantage of using JSON and JQ: the export is fast. Don’t need to query the management for every single object. Just one API call gets the full rulebase and objects. All other processing is done locally using “jq” and the received json file. Objects that are not used by the rulebase won’t be exported.
Base on this principle, I created those two scripts. RulebaseExporter.sh and RulebaseImporter.sh.
Usage:
Run the exporter script in an empty folder on your Source management server. It will extract all layers from that management server and create a "tar" file.
Copy the TAR archive in an empty folder on the destination Management server. Untar and run RulebaseImporter. It will process all available layers and create the required objects on this management server.
If you are in a domain, provide the CMA name you want to export on the source Managment. On the target management, create an empty CMA then run the Importer and login to that empty CMA.
Supported Objects Types:
My scripts currently support those objects types:
- Access-Rulebase
- Access-Layers
- Inline layers
- Section Titles
- Network Objects:
- Host
- Network
- Address-Range
- Group
- Service-Group
- service tcp
- service utp
- Application Categories (system created)
- Application object (system created)
- Login MDM CMA
- Login to standard Management server
- Action
- Enable/Disable rule
- Rule name
TODO: NAT policies.
Notepad ++ required 😉
Happy scripting!
For the full list of White Papers, go here.
