A new feature in the version 7.0 release of Cisco FMC/FTD (aka Cisco Secure Firewall) is Dynamic Objects. A Dynamic Object is a list of IP addresses/subnets, unlike a regular network object changes to the Dynamic Objects group takes place immediately without the need to deploy a policy to the FTD. Management of the IP addresses within the Dynamic Object group is using API. This post covers the configuration of a Dynamic Object group and demonstrates how to add IP addresses to the group using the API tool Postman.
Configuration
The configuration within the FMC is actually very little, a Dynamic Object is created and then referenced in the Access Control rule.
- Login to the FMC
- Navigate to Objects > Object Management > External Attributes > Dynamic Object
- Click Add Dynamic Objects
- Click Save
From the screenshot below, note the number of mappings IPs at this point is 0.
- Navigate to Policies > Access Control
- Modify the existing Access Control Policy
- Create a new rule, click the tab called Dynamic Attributes
- From the Available Attributes drop-down list, select Dynamic Objects
- Add the newly created Dynamic Object to the destination
- Click Save
For testing purposes in this lab environment, icmp pings will be permitted only to destinations defined in the Dynamic Object. All other ping requests will be denied by the default rule “Block all traffic”, as represented in the screenshot below.
- Deploy the Access Control Policy to the FTD
Configuration within the FMC is now complete, RestAPI is used for the remaining steps to add the IP addresses to the Dynamic Object group.
RestAPI
The application called Postman will be used when communicating with the FMC using RestAPI. Refer to this Cisco guide on how to enable RestAPI and request an authentication token to communicate with the FMC.
The FMC API explorer on the FMC provides information on the API abilities and can be accessed https://<FMC IP Address>/api/api-explorer/
A POST request is sent to https://<FMC IP Address>/api/fmc_platform/v1/auth/generatetoken when requesting an access token only username/password credentials with the relevant permissions is required. In the output response will be X-auth-access-token and DOMAIN_UUID values, these will be used in API requests to the FMC.
Once an access token and the DOMAIN_UUID values have been determined a GET request can be sent to the FMC to determine the ID of the Dynamic Object previously created. A GET request is sent to https://<FMC IP Address>/api/fmc_config/v1/domain/<DOMAIN UUID>/object/dynamicobjects.
The API request Auth uses the admin credentials to login to the FMC (or create a specified account for API requests), the Headers include the access token previously determined above using the value X-auth-access-token and the Content-Type of application/json.
The screenshot below demonstrates the usage of the KEY values (X-auth-access-token and Content-Type) and in the body of response at the bottom, we can determine the id of the Dynamic Object called DynObject we previously created. This ID will be used in feature API requests to add IP addresses to the group.
To add IP addresses to the group we need to create a POST request to the FMC using the URL https://<FMC IP Address>/api/fmc_config/v1/domain/<DOMAIN_UUID>/object/dynamicobjectmappings
The POST request will require Auth credentials, the headers including the X-auth-access-token and Content-Type of application/json. The body of the POST request must be formatted correctly and include the IP address and the ID of the Dynamic Object. Specify raw and JSON.
The screenshot below represents a POST request to add the IP address 8.8.8.8 to the Dynamic Object group called DynObject, the ID value is the same value determined in the previous step.
Click Send to POST the request
From the screenshot below we can determine from the output that the response code is 201, which means the request has been fulfilled and the resource has been created.
Testing/Verification
Running a ping from a local computer will confirm that the ping will now be permitted.
For confirmation we will run a ping to another IP address not defined in the Dynamic Object group, in the example below 8.8.4.4.
From the FTD CLI running the command system support firewall-engine-debug and filtering on the source or destination IP address, we can determine the ping was dropped by the default action.
Run a constant ping on the client computer to the destination IP address.
POST another request on Postman to add the other IP address to the Dynamic Object group, confirming the resource has been added by checking the response code is 201.
Back on the client computer we can confirm the ping responded once the IP address had been POST via API to the FMC. No policy was required to be deployed to the FTD in order for access to be granted.
From the output of the system support firewall-engine-debug filter we can confirm the traffic initially does not match the Dynamic Object Rule and is denied. Once the IP address is added to the Dynamic Object group via the API request, we now see the traffic matches the correct rule and is permitted.
On the FMC under Objects > Object Management > External Attributes > Dynamic Objects we can see the number of Mappings IPs for the DynObject is now 2.
We can click the Download Mappings button and open the text file to confirm the IP addresses.
Summary
As demonstrated in this post, the new Dynamic Objects feature as part of FMC/FTD version 7.0 is powerful and how quickly the FTD policy can be updated. With automation we can speed up deployment of IP address/subnet mappings and deploy in bulk, for example importing from csv file.
integrating IT 