Saturday, February 16, 2019

Default User Role in Firepower

 on  with No comments 
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.

Saturday, February 9, 2019

Database Integrity Check Failed

 on  with No comments 
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, 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 -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 -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.