Saturday, March 23, 2019

Too Many Rules

 on  with No comments 
In ,  
There is definitely a number of local rules in Firepower that makes the system unhappy, and that number is somewhere in the neighborhood of 50,000. At some point when you pass by 50,000, your scheduled SRU fails each day, with the following text to be found at System > Updates > Rule Updates.  Cisco Bug CSCv81754 talks about this, though it only mentions version 6.2.3.

This failure, which will happen every time your system attempts a SRU, causes other issues as well, such as you'll be unable to upgrade the system.  I discovered this because we had a change window last weekend to upgrade the system, and the Readiness Check fails because of this.

So I opened a case with TAC to see what our options are. Naturally, they want us to delete all local rules and be done with it. However, we're currently paying for the Emerging Threats rules, so that option is a non-starter.

But the email from TAC (which told me to use to do it) got me thinking. I could delete the oldest rules (2500 open and 2500 pro for example). But there's also a file in the bundle, deleted.rules, which are all of the obsolete rules which are safe to delete. We appear to have been disabling these, but not deleting them. There's also well over 5000 of them, so that will get me back on the right side of 50,000.

I extracted the SIDs out of the file, generated a list titled sidlist.txt on the FMC, and then run this command

cat sidlist.txt | while read line ; do -n $line --prune <<< PRUNE ; done

and restart the FMC.  The documentation and everything I read online said that using pmtool to restart services would do the trick, but that hasn't ever worked for me.

So what's going on here?  cat sidlist.txt outputs the list of deleted sids, which is then piped into a while loop that feeds one line at a time into The output of this command's help is as follows:

So with each sid, it runs -n ##sidnumber##  --pruneThe n switch specifies an individual SID, and --prune is required to actually remove it from the database. Finally the end, <<< PRUNE enters the text PRUNE where asks for it to confirm.

Not much documentation for exists on the web, and probably for good reason, direct manipulation of the database is always a dangerous task. The best I could find is this bug report which will give you an idea of how sparse it is.

Other ideas

This is obviously a stop gap meant to lower the rule count one time. However, there's a few other things ET subscribers can do. First, there is a rule set called et-compromised (or compromised.rules) that block traffic from known compromised hosts on the internet. These IPs are also available as an IP list, so you could install these as a feed under Object Managment > Security Intelligence Network Lists and Feeds in Firepower, or in the appropriate spot of your firewall, which would make the rules redundant and therefore able to be removed.

Next, there is a rule base called et-botcc (or botcc.rules), that has an equivalent feed.  This feed collects various feeds from, Spamhaus and Dshield, so if you have this feed or it's source feeds, the same applies.

Finally, when all else fails, you're going to have to just delete old rules. Until Firepower stops choking at 50k, here's a way to delete a number of old Open rules:

for i in {2000000..2005000}; do -n $i  --prune <<< PRUNE; done

This will delete the first 5000 rules from the Open Set, change the leading 20 to 28 to do the same for Pro rules.  You can find the SID allocation here.