topic If i'm not mistaken one in Network Security

Variable Set Failed Validation

Christopher Bell — Tue, 12 Mar 2019 12:54:33 GMT

Hello,

Last Friday I took the time to upgrade our FMC to 6.0 from 5.4.1.5. The SFRs are all still running 5.4.1.5 code. After the upgrade I found the policies had to be reapplied to each of the devices under the "Deploy" button at the top now (this took me a while to figure out). When I tried to apply the policies as they were in 5.4.1.5, I got warnings for each of my rule sets that said "Variable Set Failed Validation". On a 5506 we have in a test environment I was able to push past the warnings and apply the policies anyway. This resulted in all the policies being removed completely. For the production devices (5525, 5545, 5515) I'm not able to push past the warning - FMC wants the issues resolved before it will allow you to reapply the policies.

Any ideas on where to look or what may be causing this? We aren't using any custom variables. Filtered screenshot attached from FMC and two of the rules in one policy for one device.

Nobody has seen this?

Christopher Bell — Tue, 23 Feb 2016 16:19:44 GMT

Nobody has seen this?

I haven't seen it.

Marvin Rhoads — Wed, 24 Feb 2016 02:52:31 GMT

I haven't seen it.

I've done about four upgrades to 6.0 so far, both on-box (ASDM-based) and with FMC.

I'd open a TAC case - the TAC "Sourcefire" team is really quite good.

Issue seen on 6.0.0 , upgrade

Aastha Bhardwaj — Wed, 24 Feb 2016 19:04:29 GMT

Issue seen on 6.0.0 , upgrade to 6.0.0.1 resolved the issue.

Regards,

Aastha Bhardwaj

Thanks Astha, I can confirm

Christopher Bell — Wed, 24 Feb 2016 19:59:35 GMT

Thanks Astha, I can confirm that. Thanks for all your help. The problem now is that our IP to username mapping seem to be broken as well. I've restarted the SFUA and that didn't help. I'm wondering if that needs to be upgraded as well?

Hi,

Aastha Bhardwaj — Wed, 24 Feb 2016 20:03:26 GMT

Hi,

Most likely you are running into below mentioned bug :

https://tools.cisco.com/bugsearch/bug/CSCux39125/?reffering_site=dumpcr

Regards,

Aastha Bhardwaj

Rate if that helps!!!

That didn't help.

Christopher Bell — Wed, 24 Feb 2016 20:48:12 GMT

That didn't help.

Just to update this, I've

Christopher Bell — Fri, 26 Feb 2016 18:05:51 GMT

Just to update this, I've seen this now in 6.0.0.1 as well now when trying to apply policies.

Does it relate to this?https:

Dennis Perto — Wed, 09 Mar 2016 10:46:48 GMT

Does it relate to this?
https://popravak.wordpress.com/2015/11/23/fixing-error-fetching-groups-after-upgrade-sourcefire-to-6-0/

I had actually seen that

Christopher Bell — Wed, 09 Mar 2016 13:13:00 GMT

I had actually seen that particular article and that certainly was an issue, but not the issue. Thanks dennisperto. This ended up being a problem with the way the two of the default variable sets were configured after the upgrade. I'm assuming the upgrade process changed them somehow because I've never used custom variable sets.

If you go to Objects --> Object Management --> Variable Set and open the default set you will find EXTERNAL_NET and HOME_NET. These two variables were not correctly defined in my default-set.

Seems to be a known issue

cabell911 — Tue, 12 Apr 2016 17:51:17 GMT

Seems to be a known issue going from 6.0.0.1 to 6.0.1. I encountered the same error and found the following solution from another board just before calling TAC.

"PSA: don't upgrade to 6.0.1 if you're using custom object groups in your variables. You'll wind up with an error "variable set validation failed" in the policy view, and if you try to edit a variable with a custom object group you'll get "Can't use an undefined value as an ARRAY reference at /usr/local/sf/lib/perl/5.10.1/SF/EODataHandler/VariableSet.pm line 1276....".

The only workaround at this point is to use plain objects in the variables, or make faux object groups by creating a new variable and adding the objects to it, then referencing the faux variable in other variables (confused yet?).

Cisco's filing a bug on this one."

That's good info thanks

Christopher Bell — Wed, 13 Apr 2016 12:19:38 GMT

That's good info thanks cabell911. I was within 24-48 hours of moving from the bug riddled 6.0.0.1 to 6.0.1. Maybe I'll wait for a patch to hit 6.0.1.

I have a client pushing out 6

deyster94 — Wed, 13 Apr 2016 19:51:23 GMT

I have a client pushing out 6.0.1 because of this vulnerability in 6.0:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160330-fp

I noticed the mentioned issue and will do the workaround. Glad I could find a fix for it quickly.

Actually, how do you NOT have

Christopher Bell — Wed, 13 Apr 2016 20:03:13 GMT

Actually, how do you NOT have custom variable sets if you are using the IPS capabilities? You have to define a "HOME" and "EXTERNAL" net don't you? They are listed under customized variables. Are you talking about possibly other customized sets?

I'm under the assumption that

cabell911 — Thu, 14 Apr 2016 19:11:18 GMT

I'm under the assumption that if the IPS policy is applied with a source zone at a minimum that it would be fine. I could be wrong.

If i'm not mistaken one

evan.chadwick1 — Mon, 02 May 2016 23:58:35 GMT

If i'm not mistaken one should be really careful when editing variable sets as it could completely remove snort from inspecting certain traffic if you put the wrong information into a variable. Updating your Home_NET to include internal addresses and possibly company owned public ips (?) is what I have seen as recommended.

Evan,

Marvin Rhoads — Tue, 03 May 2016 00:05:13 GMT

Evan,

That's correct.

Most of the shared object rules and standard text rules that the FirePOWER system provides use predefined default variables to define networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network.

Thanks Marvin, Would you

evan.chadwick1 — Tue, 03 May 2016 03:22:43 GMT

Thanks Marvin, Would you recommend company owned public ips to be put into HOME_NET?

Evan,

Marvin Rhoads — Tue, 03 May 2016 13:54:32 GMT

Evan,

Re the company-owned public IPs it would be a case by case decision depending on where the IPS is architecturally. If they were "inside" the network (from the perspective of the IPS) then yes. If not, then no.

Thanks Marvin, gotcha

evan.chadwick1 — Wed, 04 May 2016 22:20:17 GMT

Thanks Marvin, gotcha