Default User Role in Firepower

When I took over the Firepower system at work, we had a long standing issue relating to a couple of users. Everyone in Security Operations is an admin in the FMC, however, one of our SecOps guy could not see all the events in the FMC. He can see everything in the SIEM, just not in the FMC, verifying that this is indeed a FMC issue.  2 separate TAC cases had been raised before, neither of which got to the bottom of the matter.

One of the first tasks I had in Firepower was adding in the remaining IR guys who did not have accounts yet. One if the IR guy immediately noticed the same behavior as the previous mentioned SecOps guys. He could see some events, just not all of them.

Here's what happened. In the FMC, we had a default user role defined for RADIUS users under External Authentications. This user role had Restrictive Search enabled everywhere possible in the user role. User role permissions are cumulative, however it appears that Restrictive Search overrides everything.

Because this is the default role, it gets applied to all RADIUS authenticated users upon login. Even if you uncheck the role from their user profile later, it will get rechecked the next time they login. You can see that this is the case when you look at the user profile and see that the role is marked Externally Set.

We were hesitant to change the default user role to Security Analyst (Read Only) which is what the IR guys were getting because the more restrictive role was set up for users outside of the SOC to view events related to their devices and it was feared that a new non-SOC user in the future would accidentally get more access than they required.

So the answer was to create a new user role with zero access, set that as the default, and then add another role on top of that be it Administrator, Security Analyst (Read Only), or the previous mentioned custom role with the Restricted Search filters.

Database Integrity Check Failed

A quick tip for Firepower when you have a database error.  This seems to come up a lot especially if you're manually importing snort rules from an outside source such as Emerging Threats.

Every once in a while you'll get a database error that will cause an operation to fail. In my case, it's the scheduled backup. The web page doesn't give you a lot go to on at first glance, but under your schedule, it should tell you more at the bottom of the calendar.

If you ssh in and run DBCheck.pl, you'll see something like this:

[Tue Feb  5 13:15:50 2019][FATAL]  [missing eo reference]    database [sybase],table [rule_header] column [uuid], uuid [fcd5fc7a-2889-11e9-ab40-b1c5df20061d],rev_uuid [NULL]

indicating a bad database entry for a snort rule.

This is easily fixed by typing 

OmniQuery.pl -db sdb -e "delete from rule_header where uuid ='fcd5fc7a-2889-11e9-ab40-b1c5df20061d';"

Pay close attention to the table (rule_header in this case). I've also seen EOPermissions, EORevisionStore, and EOContainerStore (or all 4). 

Again, this seems to only be a problem here for the Emerging Threats rules that I import, I've never seen it happen for the default rule set downloaded and installed automatically by Firepower.

TAC also likes to suggest the "slow repair,"

for i in `ls -1|egrep -v "\.BAK$"|sed 's/\....$//'|sort|uniq`; do repair_table.pl -frames $i;done 

but I've never had that actually fix anything. Note here that you have to actually be in /var/lib/mysql/sfsnort for this to actually do anything despite TAC's insistence that it can be run from anywhere in the file system.

Chicken Chicken

Chicken Chicken Chicken Chicken.

https://isotropic.org/papers/chicken.pdf

My New Favorite ISE Setting

And by favorite, of course I mean least favorite ever.

This one has been a thorn in my side for a while now. In the User Password Policy (Administration > Identity Management > Settings > User Password Policy), under Password Lifetime, there's a setting called "Disable user account after ____ days if password not changed." This setting is enabled by default, with a value of 60 days.

What happened is that I set up a pretty weak password policy for convenience including passwords that do not expire (it's a lab environment, and I only have the one local user account in ISE) but seemingly out of the blue, the account would become disabled. At one point, I even deleted the account and created a new one. Who notices it's been exactly 60 days? I'd reenable the account, and the next day it would be disabled again. The only thing I use this ISE local account for is the automated testing feature on my 802.1x enabled switches. This account becoming disabled leads to a long list of nasty red failed authentications in the Live Log.

For reference, here is the setting: