- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Delete rules without traffic R81.10
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Delete rules without traffic R81.10
Hello, everyone.
Is there any accurate way to identify which rules are currently "no longer used" in GW?
I have a R81.10 console, but I have quite a few rules, in which I don't see HITS, but there are so many rules, and besides that, I'm not sure if the fact that a rule has no HITS, should make me assume that this rule can be removed.
Is there any way to validate which rules are the only ones currently "in use"?
Greetings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would say if rules show 0 hits, they are safe to remove. I found that in R81.10 and R81.20, those numbers are very accurate. From my extensive lab testing, I can confidently say that.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
By default the column 'Hits', how long is it that 'filters' that option? 1, 2, 3 months?
Is there a way to set this 'hits' value?
Greetings
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See attached bro.
Andy
From global properties, 2 years is the highest value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @the_rock ,
I highly disagree on this part 🙂 We have some 80.000 firewall rules across our install base,
and have started a massive project cleaning up some +40.000 that is suspected unused.
We have found it neccessary to query our log system for logs with uid for each unused rule found in Smart Console.
We see around 1.000 rules that actually show logs in our log system (or smartlog) but hitcounter is 0.
I am just warning you to not bulk delete rules. In critical environments, whis will quickly lead to incidents.
I have spent many hours in the postgres db analyzing the design of the hit counter. (it's really bad) when we built all the logic behind the firewall cleaning
edit: we run r81.10 take NEW'ish - But I found this issue to be true on all versions. Not on r81.20 yet, but I see the db design is the same.
/Henrik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
K, thats fair. Im just speaking from my extensive testing in the lab and production as well, it was accurate 100% of the time.
But, everyone's experience is different, I suppose.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can retrieve the hit counts from API.
You can even make a decision to disable rules based on this information, similar to what this script does:
https://community.checkpoint.com/t5/API-CLI-Discussion/Disable-Delete-Rules-with-a-Zero-Hit-Count-MD...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Whats the command to show rules with 0 hits? I cant seem to find it in the API guide
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The API will only tell you how many hits a given Access Rule has gotten.
You can write a script (similar to what I pointed to) that pulls out the rules have zero hits.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thats what I was trying to find in api guide, but could not. I searched for command that gives just the actual hits, but unable to locate one.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
export RANGE_AGO="6 months"
export RANGE=$(echo ${RANGE_AGO}|sed 's/ //g')
export FROM_DATE=$(date -d "${RANGE_AGO} ago" +"%Y-%m-%d")
export TO_DATE=$(date +"%Y-%m-%d")
export MGMT_CLI_FORMAT=json
* MGMT_CLI locally on management server:
mgmt_cli show-access-rulebase name Network package Standard show-hits true hits-settings.from-date ${FROM_DATE} hits-settings.to-date ${TO_DATE} use-object-dictionary false limit 350 > access_rules.last_${RANGE}.json
* REST API: send this JSON body via 'curl' or whatever:
{ "name" : "Network",
"show-hits" : true,
"hits-settings" : { "from-date" : "'${FROM_DATE}'", "to-date" : "'${TO_DATE}'" },
"limit" : 350,
"details-level" : "uid" }
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can buy 3rd party firewall policy management tools that tell you 'last date hit' as well as how many hits.
We found a rule for TACACS access that has not been used for 2 years. Doesn't mean we don't need it, just that nobody logged into a particular set of switches in the last 2 years, which is probably good news.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good to know...any specific tool you use/like?
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tufin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Never used it, but heard good things about it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Algosec, too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Just a note, while in my experience the Hits counter is correct, also think about when the rule was last modified. For example, if a rule was created yesterday, it's likely to not have any hits today.
So i usually take that into account when looking through the rulebase (manually) in order to disable unused rules. My rule of thumb is that a rule has not been used for a year and not been modified in this time either.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That makes sense, for sure. I can also say, again, from myown extensive testing, that in R81.20, hit count seems to be better than before, meaning, gets updated faster and I find is totally accurate.
But again, as I said previously, everyone's experience varies.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I find that using the zero hits does not always paint a clear picture. What if the rule with zero hits is actually required, but there is another rule higher in the policy that is overly permissive? When I look at zero hit rules, I often will look for the source, destination, and service within the logs to determine if the traffic is allowed - or dropped - on a different rule. I then would review this other rule to determine if it is defined accurately, or if there is a need to modify it. If the other rule is defined correctly, but I need the zero hit rule for tracking purposes, then I will move the zero hit rule accordingly. Likewise, if the other rule is defined correctly, then I would delete the rule with zero hits.
If I don't find the traffic in logs, now I can be a bit more assured the rule may not be needed. I still feel there needs to be some additional thought put into it though. Do you have an asset database? I would look up the owner of the asset and ask the question why is there a rule? Maybe it is something that only gets used in the event of an emergency - document that! Maybe it is an asset that has been decommissioned - what wasn't the firewall team notified? Is there a business process that is broken, or maybe needs to be defined?
I think you can probably get the idea from here. Just because there are zero hits does not always mean the rule can be deleted. Most of the time it probably does, but always do your due diligence when you find these rules.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Those are all valid points, for sure.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Is there a way to "export" in a report, all the rules that appear with "0 Hits" in our rule base?
In such a way, that a manual analysis can be done, in order to make a better decision on whether or not these rules should be deleted.
Greetings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have a look at attached file bro, rules in my lab, its all there.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is what I personally do... Every trimester I disable 0 hit rules(3 month counters), If after a month o so there are no complaints or no issues arise, I proceed to delete them.
So yes, if no hits after 3 months, it becomes a candidate for deletion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there any experience regarding NAT Hit Count? It was introduced in R81.10, but for me it looks like only rules leading to an actual address translation get hit counts.
No-NAT-Rules above them (Source+Destination set, but both translated source and destination set to original) dont get any hits even though they match.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just checked cloud instance on R81.20 and I can see that all the NAT rules supposed to be hit do show proper hit count and are updated.
Kind regards,
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am on R81.10 T110 and my No NATs are showing hit count.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found it with R81.20 it was very inconsistent, while with R81.20, consistent 100% of the time. Just my own experience : - )
Kind regards,
Andy