Check Point R80 Manual Configuration File Retrieval

There are 8 main sections that will form your Check Point R80 configuration file following this guide.

  1. Retrieve login message

  2. Retrieve filtering rules

  3. Retrieve NAT rules

  4. Retrieve services

  5. Retrieve network objects

  6. Retrieve IPS settings

  7. Retrieve VPN

  8. Retrieve users

Throughout this guide you will be taken through the steps to generate a manual configuration Json file from your Check Point R80 device. As well as this guide, there is also a Python script and an executable available to automate this process. It is highly recommended that one of these options is used to avoid human error – for more information, contact support@titania.com.

The following pages provide an overview to running web requests and populating your configuration file with the response from your requests – to jump straight to the configuration retrieval steps, go here.

 

Running Requests

HTTP and HTTPS requests can be run in many ways – we recommend using Postman, a free tool for making requests to RESTAPI’s.

The following guide will take you through the steps for retrieving your Check Point R80 manual configuration using Postman by running various commands and populating our Json configuration schema.

All commands throughout this guide will use the address of your Check Point R80 device with /web_api appended to this to access certain parts of the Check Point Web API, e.g.

https://192.168.0.1:443/web_api

Where https:// is the connection method, 192.168.0.1 is the address of your Check Point R80 device and :443 is the port to connect to.

As well as specifying the address and API to connect to, you will also be required to specify headers and a body for the request.

 

Request Headers

Content-Type

The first header that needs to be specified will remain the same throughout all requests in this guide – this is the ‘Content-Type’ header, which should always be set to ‘application/json’. This tells the request that the response we want to receive should be in Json format.

X-chkp-sid

The second header that needs to be specified acts as a session authenticator to ensure you can continue to send successful requests to your Check Point R80 device – this is the “X-chkp-sid” header. Once the login request is sent, you will receive a response containing a “sid” key and value – copy this value. Any requests sent after this should add the header “X-chkp-sid” with the value previously copied.

Request Body

The request body will vary between requests being sent but will always be in Json format. If you are completing this guide using Postman, a request will only be successfully sent if the body contains valid Json.

Object request limit body

Several requests that will be made throughout this guide have to specify a limit of objects returned by the device, this cannot exceed 500. When this is the case, it is important that each object is retrieved for Nipper to report accurately on your device. Any request body that contains the key “limit” is considered an object request limit body.

Copy

Code Snippet 1: Object request limit body example

{
    "offset": 0,
    "limit": 500,
    "details-level": "standard"
}

 

When running a request with an object request limit body, the response will always contain information about how many objects have been returned, and how many there are in total.

 

In the following example, we have sent a request with a limit of 500 objects, but there are 650 objects that could have been returned, as denoted by “total”. In this case we need to copy the response from this request to a new file and run another request to retrieve the complete configuration.

 

Copy

Code Snippet 2: Example response

  ],
  "from": 1,
  "to": 500,
  "total": 650
}

Once the response from the original command has been saved to another file, go into Postman and edit the body.

This will involve changing the “offset” to the last object that was received – as the limit will always be set to 500, the offset should always be “500” when running a second command.

Copy

Code Snippet 3: Object request limit body second request

{
    "offset": 500,
    "limit": 500,
    "details-level": "standard"
}

 

Once the body has been updated, the request can be sent again. This will now retrieve all objects from the 500th. In our example, we would not need to send any more requests for this command.

Copy

Code Snippet 4: Example response second request

  ],
  "from": 500,
  "to": 650,
  "total": 650
}
We have now received all 650 possible objects from the device configuration section we have been sending requests to, so do not need to send any more requests for this.

If after sending the second request, all the objects have not been retrieved, repeat the previous steps to save the response to a new file and keep sending requests, editing the body each time until all objects are received.

Combining saved responses

Once all the objects have been received for a request, the files that have each response in need to be combined.

Any request that has an object request limit body will have an “objects” array in its response.

Copy

Code Snippet 5: Second objects array

{
  "objects": [
        {
        "object": "500"
    },
    {
        "object": "501"
    },
    {
        "object": "502"
    }
    
  ],
  "from": 500,
  "to": 503,
  "total": 503
}

 

For these arrays to be combined, all the objects need to be copied into one of the arrays from the relevant response. We recommend using the first response as this will usually contain the most objects already.

Copy the contents of the “objects” array into the first response saved, making sure there is a comma separating each new object added. The “from”, “to” and “total” keys do not need to be updated. For information on where to put this array in your configuration file, see here.

 

Copy

Code Snippet 6: Combined arrays

    {
        "object": "498"
    },
    {
        "object": "499"
    },
        {
        "object": "500"
    },
    {
        "object": "501"
    },
    {
        "object": "502"
    }
    
  ],
  "from": 1,
  "to": 500,
  "total": 503
}

 

 

Enabling Check Point Management API

In order to send API request to your Check Point R80 device, it is necessary to enable the management API – this can be done through SmartConsole following the instructions below.

 

 

Postman Example

Creating a new collection

In Postman, groups of requests are stored in collections. Create a new collection to store all your requests related to retrieving your configuration from your Check Point R80 device.

 

 

Once you have created your new collection, click the three dots, and go down to ‘Add Request’. This will prompt you with a menu allowing you to name the request – keep this name related to the request you are about to send.

Headers – the headers to attach to the request

Body – the body of the request

Type of request

Button to send the request once the URL, headers and body are populated

Address of Check Point R80 device to connect to

Highlighted are the key areas that will need to be used when following this guide.

 

As a default, all requests throughout this guide will be populated with these details. The request type is POST, the URL is the IP address and port of the Check Point R80 device to connect, with /web_api appended. The Content-Type header is added with the value application/json and the body is set to raw, Json.

 

Here is a look at what an example response from a request may look like once your request has received a response - in this case, this is the login request.

Each request instruction will detail steps to populate the provided Json schema with this Json repsponse

 

Populating your configuration file

Schema

In order to populate your configuration file with the response from each request you will need to copy data into the Json file schema provided.

Copy
Code Snippet 7: Schema with 2 objects
[
    {
        "request-response": [
            {
                "request": {
                    "command": ""
                },
                "response": {
                    "body": {
                        "key": ""
                    }
                }
            }
        ],
        "titania-command-id": ""
    },
    {
        "request-response": [
            {
                "request": {
                    "command": ""
                },
                "response": {
                    "body": {
                        "key": ""
                    }
                }
            }
        ],
        "titania-command-id": ""
    }
]

 

For most requests, a new Json object will need to be added to this array (ensuring there is a comma between each object). The example above shows two empty objects in the configuration file.

There are three areas that need to be populated each time a new object is added – the “command”, with the area of the API the request is being sent to (this will be explained in each request instruction). For instance, a POST request to https://192.168.0.1:443/web_api/example-command has a command of “example-command” and this is the value that will populate the “command”

The “body” object is populated from the return of the response. Responses will be returned in a Json object from Postman, e.g.

Copy
Code Snippet 8: Example Json body
{
    "key": "value",
    "key2": "value"
}

 

Only the actual content of the object should be copied into the “body” object of your configuration file, the leading and trailing curly braces should not be copied with this. With this example response, only the following should be copied –

Copy

Code Snippet 9: Example Json body once copied

"key": "value",
"key2": "value"

 

Each object has a unique “titania-command-id”. This is used internally in Nipper and is very important to populate correctly – instructions for this will be detailed with each request instruction.

Copy

Code Snippet 10: Completed example

[
    {
        "request-response": [
            {
                "request": {
                    "command": "example-command"
                },
                "response": {
                    "body": {
                        "key": "value",
                "key2": "value"
                    }
                }
            }
        ],
        "titania-command-id": "example command"
    }
]

 

Following through the above examples should produce a configuration file.

 

Multiple Requests

Some sections of the configuration file will require multiple commands to be run in order to gather all the data needed for a given section. When this is the case, a new object should be added to the “request-response” array like so.

Copy

Code Snippet 11: Multiple requests example

[
    {
        "request-response": [
            {
                "request": {
                    "command": "command-1"
                },
                "response": {
                    "body": {
                        "key": "value1"
                    }
                }
            },
        {
                "request": {
                    "command": "command-2"
                },
                "response": {
                    "body": {
                        "key": "value2"
                    }
                }
            },
        {
                "request": {
                    "command": "command-3"
                },
                "response": {
                    "body": {
                        "key": "value3"
                    }
                }
            }
       ],
       "titania-command-id": "multiple commands"
    }
]

Notice that each object has its own command, but the “request-response” array still only has one “titania-command-id” field after it.

 

Configuration Retrieval

 

1 - Login

  • Create a new POST request

  • Add ‘/login’ to the end of your address e.g. https://192.168.0.1:443/web_api/login

  • Add the Content-Type header

  • Add a Json body with the username and password to connect with, e.g.

Copy

Code Snippet 12: Json body example

{
    "user": "",
    "password": ""
}

  • Once populated with your credentials, send the command and wait for the response

  • Once the response comes back with status code 200 (success), see the headers section for details of how to authenticate the remaining requests

  • No data from this request needs to be added to your configuration file.

 

2 - Retrieve login message

Copy

Code Snippet 13: Empty Json body

{
}

  • Send the command and wait for the response

  • Once the response comes back with status code 200 (success)

    • Add a new Json object to your configuration file

    • Copy the contents of the response into the response “body” in your manual config

  • Place “show-login-message” into the request “command”

  • Place “login message” into the “titania-command-id”

Your configuration file should now contain the response from the request, e.g.

Copy

Code Snippet 14: Populated login message

[
    {
        "request-response": [
            {
                "request": {
                    "command": "show-login-message"
                },
                "response": {
                    "body": {
                        "domain": {
                            "domain-type": "domain",
                            "name": "SMC User",
                            "uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
                        },
                        "header": "ATTENTION",
                        "message": "This is the login message.",
                        "show-message": true,
                        "type": "login-message",
                        "warning": true
                    }
            }    
            }
        ],
        "titania-command-id": "login message"
    }
]

3 - Retrieve Filtering Rules

The filtering rules section requires multiple requests to be run in order to pull all the data required to generate a complete report in Nipper. Instructions for populating your configuration file with multiple requests and responses for the same command can be seen in the example.

Copy

Code Snippet 15: Object request limit body

{
    "offset": 0,
    "limit": 500,
    "details-level": "standard"
}

  • Send the request and wait for the response

  • Follow the steps in this section to ensure all access layers are received.

  • Once all the access layers have been retrieved, place “show-access-layers” in the request “command”. Your configuration file should now be populated with all configured access layers, e.g.

Copy

Code Snippet 16: Example multiple layers

"request-response": [
    {
        "request": {
            "command": "show-access-layers"
        },
        "response": {
            "body": {
                "access-layers": [
                    {
                        "domain": {
                            "domain-type": "domain",
                            "name": "SMC User",
                            "uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
                        },
                        "name": "Layer 1",
                        "type": "access-layer",
                        "uid": "b50d42a7-d1fe-4f8c-84a7-5d02f32c3010"
                    },
                    {
                        "domain": {
                            "domain-type": "domain",
                            "name": "SMC User",
                            "uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
                        },
                        "name": "Layer 2",
                        "type": "access-layer",
                        "uid": "e34d73a0-07fb-4152-9ed5-743d52aac93f"
                    },
                    {
                        "domain": {
                            "domain-type": "domain",
                            "name": "SMC User",
                            "uid": "41e821a0-3720-11e3-aa6e-0800200c9fde"
                        },
                        "name": "Layer 3",
                        "type": "access-layer",
                        "uid": "c0264a80-1832-4fce-8a90-d0849dc4ba33"
                    }
                ]
            }
        }
    }
]

 

Retrieving information for each access layer

Once we have a complete list of all the configured access layers, we need to run an extra command for each layer in the list to get extra information.

These extra commands should be added to the same “request-response” array that has the previous command data in – an example of this can be seen here.

  • Go through the “access-layers” array that was populated with the previous requests and for each one, write the “name” in a separate file (this is not the “name” in the “domain” object). In the above example, this would give the list as: Layer1, Layer2, Layer3

  • Create a new POST request

  • Add show-access-rulebase to the end of your address e.g. https://192.168.0.1:443/web_api/show-access-rulebase

  • Add the Content-Type header

  • Add a new header with the key “X-chkp-sid”

  • Add a new Json body – this will use the names of the access layers that were received from the previous command –

Copy

Code Snippet 17: Example body

{
    "offset": 0,
    "limit": 500,
    "name": "Layer 1",
    "details-level": "standard",
    "use-object-dictionary": true
}

 

Here is an example of what this request body should look like. “name” should be populated with a name from the list of access layer names generated earlier.

  • Send the request and wait for the response

  • The response from the request can be added as a new object in the configuration file in the same “request-response” array that is populated with the show-access-layers request. Further instructions are available here.

  • This process needs to be repeated for each access layer name that was found during the show-access-layers request and saved to a separate file. Each request and response for the individual access layer names should be a new object in the “request-response” array.

  • Once a request has been run for each access layer, “titania-command-id” can be set to “filter rules” below the “request-response” array.

 

3 – Retrieve NAT Rules

 

Copy

Code Snippet 18: Example body

{
    "offset": 0,
    "limit": 500,
    "details-level": "full",
    "use-object-dictionary": "true",
    "package": "standard"
}

  • Send the command and wait for the response

  • Once the response is received, ensure all NAT rules have been returned, by following these examples

  • Add the response to your configuration file

  • Place “show-nat-rulesbase” in the request command

  • Place “nat rules” in “titania-command-id”.

    •  

4 – Retrieve Services

This section requires running multiple commands that are very similar in order to retrieve all the services configured on your Check Point R80 device, these commands are –

  • show-services-tcp

  • show-services-udp

  • show-services-icmp

  • show-services-icmp6

  • show-services-sctp

  • show-services-dce-rpc

  • show-services-rpc

 

Copy

Code Snippet 19: Example body

{
    "offset": 0,
    "limit": 500,
    "details-level": "full"
}

  • Send the request and wait for the response

As this is an object request limit body, ensure all objects have been received with this example

  • Add a new object to the “request-response”. Populate the request command with the command just run, e.g. “show-services-tcp” and populate the response body with the response to the request.

  • Repeat this process for each command listed above.

 

Retrieving service groups

  • Add a new POST request

  • Add “show-service-groups” to the address, e.g. https://192.168.0.1:443/web_api/show-service-groups

  • Add the Content-Type header

  • Add the “X-chkp-sid” header

  • Add an object request limit body, e.g.

Copy

Code Snippet 20: Example body

{
    "offset": 0,
    "limit": 500,
    "details-level": "standard"
}

  • Send the request and wait for the response.

As this is an object request limit body, follow these examples to ensure all service groups are received

For this request, nothing needs to be added to the configuration file – save the response from this to a new file.

 

Retrieving information for each service group

For each of the service groups retrieved with the previous request, a request needs to be made to obtain more information on the service group. Each object in the “object” array of the previous command has a “uid” key – this will need to be used in the request body to get information for that group.

 

Copy

Code Snippet 21: Example body

{
    "uid": "cd7c1a5f-6268-40b6-a8c7-2727b8036cb1"
}

  • Send the request and wait for the response

  • The response to this request can be added to the same “request-response” array that contains the information for each service, with the request command of “show-service-group”.

  • Repeat these steps until a request has been run for each service groups UID.

  • Once information for each service group has been received and written to your configuration file, add the “titania-command-id” of “services”

 

5 – Retrieve Network Objects

Various commands needed to be run in order to obtain all network objects configured on your Check Point R80 device. Each of these has an object request limit body, meaning it is possible that not every object is returned on the first request, see here for how to handle this.

List of commands –

  • show-hosts

  • show-networks

  • show-address-ranges

  • show-multicast-address-ranges

  • show-gateways-and-servers

  • show-security-zones

  • show-dynamic-objects

  • show-groups

Each of these commands specify a level of detail that should be returned in the response – this is set to “standard” for all commands, other than show-gateways-and-servers, which requires the details level to be set to “full”.

Copy

Code Snippet 22: Example body

{
    "offset": 0,
    "limit": 500,
    "details-level": "standard"
}

As previously mentioned, all the commands bar one use “standard” details level. The “show-gateways-and-servers” command should exchange “standard” for “full”.

  • Send the request and wait for the response.

  • Once the response comes back, it can be written to your configuration file as a new object in a “request-response” array. Each of these commands should be written to the same array with the request command as the command run, e.g. “show-hosts”.

This process should be repeated for each command as listed above.

 

Groups information

In the previous requests, the “show-groups” command was run. For us to get all the information we need for these network groups; an extra command needs to be run for each group retrieved.

 

  • Add a new POST request

  • Add “show-group” to the address, e.g. https://192.168.0.1:443/web_api/show-group

  • Add the Content-Type header

  • Add the “X-chkp-sid” header

  • Add a Json body, specifying the name of one of the groups returned in the previous “show-groups” request, e.g.

Copy

Code Snippet 23: Example body

{
    "name": "Network Group 1",
    "details-level": "standard"
}
 

 

Each of these requests should use “standard” details level.

  • Send the request and wait for the response

  • Once the response is received, write this to a new object in the same “request-response” array that contains all previous commands in in the network objects section. Set the request “command” to “show-group

  • This process should be repeated until a request has been run for every group returned in the “show-groups” request, at which point the “titania-command-id” can be added with the value “network objects”.

 

 

6 – Retrieve IPS Settings

Retrieve Gateways

Copy

Code Snippet 24: Example body

{
    "details-level": "full"
}

 

  • Send the request and wait for the response

  • This response does not need to be written to the configuration file – instead look for the gateway that relates to the device you are connecting to (this will be the gateway that is configured with the same IP address that you are connecting to). We will need the “name” key of this gateway.

 

Retrieve Gateway Information

Copy

Code Snippet 25: Example body

{
    "name": "gw-gateway1"
}

  • Send the request and wait for the response

  • Add this response as a new object. Set the request command to “show-simple-gateway” and the “titania-command-id” to “show simple gateway”

  • The response body should be set to the response of the show-simple-gateway request

7 – Retrieve VPN Settings

In order to retrieve all VPN settings needed from your device, multiple commands are required. For examples on how to populate your configuration file with multiple commands, see here.

 

VPN Communities

Copy

Code Snippet 26: Example body

{
    "offset": 0,
    "limit": 500,
    "details-level": "uid"
}

  • Send the request and wait for the response

  • As this is an object request limit body, there is a chance that not all objects are retrieved in the first request, see this example for how to ensure all objects are retrieved.

  • Once all of the objects are retrieved for this request, save the response to a new file and run the same request will need to be run, replacing “show-vpn-communities-meshed” with “show-vpn-communities-star”

  • Once both the show-vpn-communitites-meshed and show-vpn-communities-star combine the “objects” array of each request into one.

VPN Objects

     

    • Add a new POST request

    • Add show-generic-object to the address, e.g. https://192.168.0.1:443/web_api/show-generic-object

    • Add the Content-Type header

    • Add the “X-chkp-sid” header

    • Add a Json body, specifying the UID of the first object in the combined “objects” array retrieved in the previous request, e.g.

Copy

Code Snippet 27: Example body

{
        "uid": "cbfed2ed-04d7-49b7-950c-a182d872fca8",
        "details-level": "full"
}

  • Send the request and wait for the response

  • Write the response to a new file and continue running these requests until one has been run for each object UID in the “objects” list generated in the VPN Communities section.

  • Once all the VPN objects have been retrieved, they should each be placed in your configuration file as a new object in the “request-response” array with the request command of “show-generic-object”. For examples of how to do this, see here.

       

Retrieve Remote Access VPN Settings

Due to limitations with Check Points management API, the previous commands to not give us any information on the RemoteAccess VPN – we must run a further command to get this.

Copy
{
    "name": "RemoteAccess",
    "details-level": "full"
}

  • Send the request and wait for the response

  • Once the response is received, this can be added as a new object to the “request-response” array that was populated as part of retrieving VPN objects with the request command of “show-generic-objects”.

Retrieve Diffie-Hellman group

In order to retrieve information on the Diffie-Hellman group that each VPN has configured, traverse through the responses received as part of VPN Objects and Remote Access VPN subsection and look for the “ikeP1” and “ikeP2” objects. In the ikeP1 object, there will be a “ikeP1DhGrp” key – the value of this (which should be a UID) should be written to a new file and saved. In the ikeP2 object, there will be a “ikeP2PfsDhGrp” key – the value of this (which should also be a UID) should be written to the same file and saved.

Once these values have been retrieved for each object, go through the list and remove any duplicates – this will prevent us adding unnecessary extra information to the configuration file.

  • Add a post request

  • Add show-generic-object to the address, e.g. https://192.168.0.1:443/web_api/show-generic-object

  • Add the Content-Type header

  • Add the “X-chkp-sid” header

  • Add a Json body specifying the uid of the object to retrieve (this is from the list generated earlier in this subsection) and the details level required – this is full.

Copy
{
    "uid": "cfbbb4d3-3ab1-4aff-844c-e31044490eec",
    "details-level": "full"
}

  • Send the request and wait for the response

  • Each response to this request can be added as a new object to the “request-response” array with the request command of “show-generic-object”. This request should be repeated for every UID in the file written at the start of this subsection.

 

Retrieve Gateway Information

Instructions for retrieving configured gateways can be seen at the beginning of the IPS settings section. This request can be run the same, other than the Json body, which can be changed to have standard details.

Copy

Code Snippet 28: Body example

{
    "details-level": "standard"
}

Once this request has run, it can be added to the same “request-response” array populated in this section with the command “show-simple-gateways”.

This section is now complete and a titania-command-id with value “VPN” can be added to your configuration file below the “request-response” array.

 

8 – Retrieve Users

The command to retrieve user information requires logging in to the system data domain of your device. As part of this process, it is necessary to logout of the current session as to not leave a hanging connection on the device.

 

Logout

Copy

Code Snippet 29: Example empty body

{
}

  • Send the request and wait for the response

  • If this request is successful, the “X-chkp-sid” value will no longer be valid.

System Data Login

  • Add a new POST request

  • Add “login” to the address

  • Add the Content-Type header

  • Add a Json body specifying the credentials and domain to log into, e.g.

Copy

Code Snippet 30: Example body

{    
    "user": "",
    "password": "",
    "domain": "System Data"
}

  • Send the request and wait for the response

  • The response to this request will look very similar to the original login request. Copy the “sid” value – this is once again the new “X-chkp-header”, see here for details.

Retrieving Users

Copy

Code Snippet 31: Example empty body

{
}

 

  • Send the request and wait for the response

  • Add the response from this request to a new object. Set the request command to “show-administrators”, the response body to the response of this request and add a titania-command-id of “show administrators”