Firewall - Automating Firewall Rule Cleanup Based on Usage

[HeikoAnkenbrand]

The following one-liner identifies all rules with a hit count of 0 entries. Depending on your environment, you may need to adjust the policy name to ensure the command runs against the correct configuration.

You can store all rules with a hit count of 0 in a file (e.g. delete_rules.txt). This file can then be processed by a script to automatically remove the listed rules.

mgmt_cli -r true show access-rulebase offset 0 limit 20 name "Network" details-level "standard" show-hits "true" use-object-dictionary true  --format json | jq '.rulebase[]| select(.hits.value==0) | {number:.["rule-number"], name:.name, uid:.uid}' > delete_rules.txt

You can use the file delete_rules.txt, which contains the list of rules with a hit count of 0, as input for an automated script. The script should read each line of the file (each line representing a rule), and then construct the appropriate delete command for that rule.

For security reasons,
I’m not sharing the one-liner for direct deletion, as it could easily cause serious damage to the policy.

This program writes the delete commands securely to an echo output; you can then remove the “echo” command in the one-liner and all rules will be deleted on the SMS 😉

jq -r '.uid' delete_rules.txt | while read uid; do
    echo mgmt_cli -r true delete access-rule uid "$uid" -s id.txt
done​

The id.txt file contains the status of the deletion action.

[HeikoAnkenbrand]

@Bob_Zimmerman, @the_rock, @_Val_ 

In the new version 1.2, I have added the layer, so it should now work with any layer.
Furthermore, the list of objects to be deleted is now automatically loaded when the page is opened.

[the_rock]

Great!

[Lars_Roerll]

Very interesting extension. 😀

[the_rock]

Its great!

[HeikoAnkenbrand]

THX

[the_rock]

I saw what Bob posted about layers...any way Heiko this can be referenced for ALL layers, including both inline and ordered ones?

Best,

Andy

[HeikoAnkenbrand]

@the_rock 

I have to agree with you on that. Inline layers are always a problem in the rulebase since they are not directly visible through the API. This is not only the case with the Management API but also on the gateways.

For example, if you analyze the rules on a gateway using
db_tool -p /opt/CPsuite-R81.20/fw1/state/local/FW1 get_rules,
the inline layers are also not displayed.

Unfortunately, I don't see any inline layers in the context.event.objects structure in the Smart Console either.

In principle, it is possible to work with them, but it requires a tremendous amount of scripting effort. Since in the community we usually try to solve this through reverse engineering, it becomes a difficult and complex task.

@Bob_Zimmerman 

The integration of the MDS is also somewhat more complex, since it can only be queried via a script on the MDS itself or in the "gateways" section. In the "policy" section, I have no option to use SmartConsole extensions to read the JSON parameters in context.event.objects. With these limited possibilities, implementation becomes difficult and very time-consuming.

- In the "gateway" area, I can read out the MDS parameters with context.event.objects.
- In the "policy" area, I can read out only the rules with context.event.objects.

The object structure does not allow both at the same time.

[HeikoAnkenbrand]

A brief overview of what it takes to create a Smart Console Extension:

• 1–2 days – Analyzing the context.event.objects structure under "policy" and/or "gateway"
                       + creating a reverse-engineering app + creating JSON parser for "0 hit counter rules"

• 2 days –      Creating and developing the SmartConsole application "delete.json" + "delete.htm"
                       + creating html code + creating JavaScript code + creating JSON parser + stylesheet html CSS
                       + check system calls with Management API version 1.8.1, 1.9, 1.9.1, 2.0

• 1 day –        Testing under R81.10, R81.20, and R82
                       + Approximately 9 different SmartConsole versions 
                       (81.10.9600.430, 81.20.9700.658, 81.20.9700.670, 82.0.9800.1027,  82.0.9800.1056, ...) 

• 1 day –        Debugging and improvements

• 1-2 days -   Explanation of why the smart console apps are not functioning + creating test app +
                       "test.json" + "test.htm" + creating html code + creating JavaScript code.
                       There are issues with newer SmartConsole versions R81.20/R82 where
                       SmartConsole Extensions no longer execute properly when calling the
                       following function "request-commit". 
                       

  SmartConsole Extension Issue in R81.20/R82

• 1 day -        Creating community articles and community communication
• 2 hours -    The most important thing!
                       Drinking coffee and tea 😀

---

PS: 
I would really appreciate more documentation from Check Point on these topics. With the current resources, implementation is highly complex, as only the following documentation is provided:

SmartConsole Extension Developer Guide
Management API Reference 

Maybe I should consider applying as a software developer at Check Point 😀.

[the_rock]

I like this challenge, will definitely look into it myself.

Andy

[Bob_Zimmerman]

Believe me, I get it. The management API has some really frustrating limitations and issues.

[HeikoAnkenbrand]

It usually develops into a research and tinkering project. Due to the bug "SmartConsole Extension Issue in R81.20/R82" in newer SmartConsole versions, it is currently not possible to automatically delete the objects.

[Jonatan_Frei]

👍