Threat Prevention policies after R77.30 to R80.10 migration. Is it correct?

[gianogli]

Hi to all,

I have a little question related to the new Unified Policy (Threat Prevention). We have just migrate all our environment from R77.30 to R80.10 (management server and gateways) and now we are trying to migrate all the policy to the new paradigm.

After the migration our Threat Prevention policies is based on 2 layers: "IPS" and "Threat Prevention". What we would to do is to create a Threat Prevention policies based on only 1 layer (by using an ad-hoc profile with all our active blades configured). Is it possible?

We tried to do that many times but we are not able to delete the layers:  in the "Threat Prevention" layer the option is disabled/grayed (we can only "edit" it!) while in the IPS layer all the options are disabled. This last layer is also shared and we would un-shared it but this is not possible.

I'm not sure if this is the behavior "by design" for a R80.10 environment also because we have seen some video here where the the Threat Prevention policies had no layers.

So... is it correct that we are unable to modify our Threat Prevention policies or we have some kind of problem? I've also tried to open a SR but CP told us that this is a "by design" behavior... I know that this is true in a R77.30 environment, but is it true also in a R80.10 environment?

Can someone help me?

Thanks...

[PhoneBoy]

This is by design as long as you have ANY gateways that are not R80.10 and above defined.

This is because IPS is not part of Threat Prevention layer in R77.30 and earlier.

[gianogli]

Thanks for your quick answer but all our environment is R80.10 now. If I open the "General Properties" window of all our CP objects I see that the "Platform" field is configured on version R80.10 as you can see in the following image:

Is it enough or have we to count also the "Externally Managed CP gw" used in site-to-site VPN?

Is there a way to check if we have any hidden R77.30 object or any corruption into our DB?

Thanks...

[Hugo_vd_Kooij]

Round up the usual suspects.

I would advise to open a TAC case here. If you have not applied HFA Take 42 yet you might want to do so first. and make sure you use the updated SmartConsole version.

[gianogli]

Thanks for your answer but I've already installed the Take 42 and the last SmartConsole (version 005).

[PhoneBoy]

It appears if the management EVER had a pre-R80.10 gateway with IPS enabled, the shared IPS policy will always show up and can't be disabled.

This is a limitation of R80.10.

In this case, you should disable all policy lines in the IPS shared policy and configure the desired rules in the Threat Prevention layer.

[gianogli]

Thanks again for your quick answer.

Yes, until 2 months ago our R80.10 management had a R77.30 cluster with the IPS blade enabled!

So, if I've understood well, in this case it's not possible to delete the "old" IPS shared layer due to a R80.10 limitation, is it correct?

To solve the problem I've to delete/disable all the policy lines in the IPS shared layer (it will be always active but without rules) and create a new "Threat Prevention" layer whit my new configuration for all the blades (IPS blade included).

Is this the only way?

I think that this is a big limitation for the R80.10... Do you know if this problem will be solved on R80.20?

Thanks...

[PhoneBoy]

As far as I know this is the only way.

I'm not sure in what release this limitation is targeted for removal.

Hopefully someone from R&D can chime in.

[Tomer_Sole · Accepted solution]

Hi, This is actually not a limitation. It is by design.

One of our principles is not to modify users' policies automatically. We leave that to the user to decide on his policy architecture.

So once you got rid of all of your Pre-R80 gateways that have IPS blade enabled, your policy will still remain as before. We definitely recommend on unifying your threat prevention rules into one policy, manually:

1. On the Threat Prevention layer, make sure that your gateway will be matched to the appropriate profile (either since the "install on" is "any" or if it's your specific gateway, as well as one explicit rule with "any" in the protected scope). If this is not the case, create such rule.

2. Go to your IPS layer and delete the gateway rule. 

3. Once you have removed all of your IPS layer rules, the IPS layer will disappear.

The reason why this process does not happen automatically, is because users might still be interested with a layer per threat prevention engine. Some users may also want to use the "protected scope" column to create specific threat prevention profiles to different scopes. So the decision stays in the hand of the user.

Please let us know what are your thoughts on this behavior.

[gianogli]

Great! It worked!!!

In the last days we migrated all of our threat prevention profiles and after I removed all of our IPS rules, the IPS layer disappeared automatically! WOW! Now we are fully R80.10 compliant. Thanks!!!

Regarding your questions: I'm agree with you when you wrote that one of your principles is not to modify users' policies automatically. Also the behavior of the IPS layer... it's the correct one for me.

However the problems I noticed during the Threat Prevention policies migration are two:

1) We opened a SR with the official support but no-one told us this procedure to delete IPS layer. They told us instead that was impossible to delete the IPS layer "by design".

2) We searched into the SKs and into the official R80.10 documentation but we didn't find any information regarding this procedure.

Could you add this IPS layer migration procedure into a SK or into the official documentation?

Thanks again for your support!

[Tomer_Sole]

Apologize for the partial answer from Support. We will add this to the docs. I encourage you to ask “why are things like this” type of questions here publicly to raise community discussions. 

[Eric_Beasley]

Hello Granluca,

Based on my own experience with earlier JHF levels and older SmartConsole builds, it was the case that you couldn't delete the rule entries in the Shared IPS layer or even remove the whole layer if you had upgraded to R80.10.  The issues blocking this were corrected in a later JHF and SmartConsole, so now it works as defined.

I expect part of the issue with it not being known that the situation has changed is that we are missing an entry in the R80.10 JHF SK sk116380 showing this should now work, and after what JHF it was fixed.  Based on your timeframe for success, that might have been R80.10 JHF Take 42.

Thank you for raising this issue and topic, which has led to some good information about the migration from IPS on R77.30 to R80.10.

[Chad_Hubich]

Hi Tomer,

Note: The IPS layer is shared among all policies per management server.  Is there any way to make this change on only one gateway without impacting the other policies/gateways?

[Eric_Beasley]

So the IPS shared layer will be in all policies as long as there are pre-R80.10 gateways with IPS which need it.  For R80.10 and later gateways, their respective entry can be deleted, or disabled, then that policy line is not active anywhere, but also does not affect other policies.

Since each policy line in the IPS shared layer is dedicated to a specific gateway and only created for pre-R80.10 gateways with IPS, deleting or disabling that specific line when the gateway is upgraded to R80.10 or later, only changes the impact for that specific gateway (or cluster). 

Once the last policy line is deleted from the IPS shared layer, the layer itself is removed from policy.

IMPORTANT NOTE :  should a new R77.30 or earlier gateway be added to management with IPS enabled, then the IPS shared layer will return with a policy line for that gateway.  That also will happen with SMB appliances running R77.20.XX firmware!

[Luis_Miguel_Mig]

I don't have any pre-r80.10 and I don't have IPS blade enabled and the IPS layer has 0 rules but I can't delete it and it doesn't disappear automatically

[PhoneBoy]

Did this environment ever have a pre-R80.10 gateway in it?
There might still be a reference there that needs to be removed...possibly with the help of TAC.

[Luis_Miguel_Mig]

Something like that. We never had an R77.20 but  we imported R77.20 configuration using migrate import into a r80.40 manager. 

[PhoneBoy]

There might be some stray reference to that gateway somewhere still.