top of page

Firepower Dynamic Objects

One of the most difficult tasks when learning a new system is figuring out what is possible. For the most part, you can find step-by-step instructions on how to implement anything, but you do need to know what you want to implement. Often, the process starts with a specific use case or a specific requirement. The customer says, “I want to be able to do X” and you have to figure out how to make that happen. The good news is customer requirements make you a tougher engineer.


Use Case

Now that we got that out of the way, we can start with a use case. A customer has Internet facing web servers and wants the ability to block public source IP Addresses in real-time at the Internet edge. This simple ability can increase security dramatically. It is a quick method of stopping brute force attacks, simple DoS attacks, and can also be used to stop reconnaissance attacks quickly.

Solutions

Of course, there are many ways to “nearly” accomplish the goal, but the key word in our Use-Case is “real-time”. That keyword throws a monkey wrench into our operation. For example:


Standard Object within an ACP Rule

We can create a simple object with a list of bad IPs and attach it to a Deny rule. This will not do. 😊 There are two main problems with this approach:

  1. The team or group that is responsible for Firepower changes is likely not the group that monitors the firewalls for potential security issues. Thus, step 1 would be creating a ticket for the group that makes actual firewalls changes. We already missed the “real-time” goal. The last thing a security engineer wants to do in the middle of an attack is create a ticket and wait.

  2. When you make a change to a standard object, you must deploy the change to your firewalls. This also hurts our real-time goal, but more importantly, most organizations have a policy prohibiting deployments during working hours. So now, the security engineer must create a ticket and wait for a change window. By the time that occurs, the attack either failed or succeeded, making the mitigation effort pointless.

Figure 1: Waiting for the IP Block


IP Blacklist

Option #2 is a simple IP Blacklist. This can be built into something like Secure-X, or you can also publish your own blacklist on an internal web server. As you likely already guessed, this won’t cut it either. The implementation of the blacklist is not trivial and is not real-time. For example, with Secure-X, you can quickly and easily add the IP to the blacklist, but it is very difficult to get Firepower to download it quickly. The default is every two hours or AKA not real-time.


Prefilter Rule

Another relatively quick way to accomplish the goal is a simple deny rule within the Prefilter policy. However, this has the same drawbacks as the standard object within the ACP. You still need someone to make the firewall change and the change still needs to be deployed. Not acceptable!

Figure 2: Can't wait any longer!

Firepower Dynamic Object

Bingo! The key advantage to Dynamic Objects is they do not have to be deployed. In addition, you do not even have to login to Firepower to add an IP. We solved the segregation of duties issue and the deployment issue. Nice!

Figure 3: It's done!!!

How to: Dynamic Objects

Firepower Dynamic Objects use the built-in REST API on the FMC. This article will not be a deep dive into how to use an API and some level of knowledge is assumed.


Once you setup the typical environment variables within your API app or script, the process is rather simple:


Return a list of existing dynamic objects:

  • https://{{fmc_ip}}//api/fmc_config/v1/domain/{{domain_uuid}}/object/dynamicobjects

Return a list of IPs within a specific object, where X is the dynamic object:

  • https://{{fmc_ip}}//api/fmc_config/v1/domain/{{domain_uuid}}/object/dynamicobjects/X/mappings

Add an IP to a specific dynamic object:

  • https://{{fmc_ip}}//api/fmc_config/v1/domain/{{domain_uuid}}/object/dynamicobjectmappings

{
    "add": [
        {
            "mappings":[
                "1.2.3.4"
            ],
            "dynamicObject": {
                "id": "X"
            }
        }
        ]
}

Remove an IP from a specific dynamic object:

  • https://{{fmc_ip}}//api/fmc_config/v1/domain/{{domain_uuid}}/object/dynamicobjectmappings

{
    "remove": [
        {
            "mappings":[
                "1.2.3.4"
            ],
            "dynamicObject": {
                "id": "X"
            }
        }
        ]
}

That’s it!!

We have met every goal in an easy-to-use format. Of course, we can go a step further and integrate our script into a ticketing system or automation platform.

So how can CDA help you improve your network security?

Members of our team are Cisco Certified Internetwork Expert (CCIE) certified and can help at any stage of the process: proof of concept, design, architecture, implementation, testing, & issue resolution. Want to learn more?


  • Twitter
  • LinkedIn
  • YouTube

©2024 by Critical Design Associates, Inc.

bottom of page