IPS exceptions and Profiles post Migration to r80.30

[Malik1]

Hi Team,

We migrated our mgmt server to R80.30 from R77.30 .Post migration we are not able to find certain network exception that were previously configured . The network exceptions were for ssl tunneling .We cant either locate these in the threat prevention layer exception nor in the Inspection setting exceptions .Are these exceptions deleted?

There are cloned/new profiles that have been created under inspection settings with an added suffix "parser_settings" so are these profiles any different then the migrated profiles.(The original R77.30 profiles) ?

We have identified that the  exception in the threat prevention layer are “inactive” post migration and change it to detect or prevent we are prompted with an warning “Exception 'E-5.2' will not be enforced, for IPS Gateways. 'Action' must be inactive for pre R80 IPS gateway.” 

These exceptions action is "inactive" so does this mean these are not enabled and the traffic for these exception will be inspected ?

Is there an option to resolve this so the traffic for these exceptions are not inspected . We have 14 clusters and will take time to upgrade  them to r80.30.

Regards,

Sijeel Malik

[Timothy_Hall]

All your questions are answered in my IPS Immersion class, including how to handle R77.30 and earlier gateways under R80+ management for IPS.  The following is all quoted directly from the class material and should get you going in the right direction:

Click to Expand

• The full list of IPS protections migrated to other blades in R80.10 is documented here: sk103766: List of IPS Protections removed in R80.x. There is also an informative discussion at CheckMates titled “Where did all my IPS Protections go?”  https://community.checkpoint.com/message/6315

• There are FOUR different types of exceptions related to IPS, make sure you add the right one to address your issue! The most
reliable way to add an Exception is directly from a log entry referencing the IPS Protection itself.

• The four types of Exceptions are below and presented roughly in the order that they are applied by the gateway:

◦ Geo Policy Exceptions
◦ Inspection Settings Exceptions
◦ ThreatCloud Exceptions
◦ Core Activations Exceptions

Exceptions Tips & Tricks

• There are two levels of Exceptions that can be defined in IPS: per–signature & global. If a particular signature is causing false–
positives with a certain system, always create an Exception for that specific signature first. If you are still having numerous
false–positive issues with many signatures for a single IP address or network, only then should you consider adding a global
Network Exception.

• In an IPS exception rule for R77.XX gateways, the Action is always Inactive. For other Threat Prevention blades you can select
the Action; normally the actions would be Detect or Inactive, but it can also be Prevent which is an interesting option.

• Although they were part of the IPS blade in R77.XX and earlier, Inspection Settings are now part of the Access Control policy
layers and no longer part of IPS/Threat Prevention in R80+ management. They perform protocol inspection that is inherent in
the gateway’s stateful inspection process, and have the following attributes:

◦ As shown above Inspection Settings are part of the Access Control policy layers, so if any changes are made to them, the
Access Policy needs to be installed to the gateway.
◦ Similarly to Core Activations, all Inspection Settings are included with a new software release, and are not updated via IPS
Updates from the Check Point ThreatCloud.
◦ Inspection Settings Exceptions are specified separately from Threat Prevention Exceptions, so the main Threat Prevention
Global exceptions DO NOT apply.
◦ One, some, or all Inspection Settings signatures can be specified in a single Inspection Setting Exception rule for an R80.10
gateway. For an R77.30 gateway, Inspection Settings Exceptions must be specified in the IPS layer under Threat Prevention.
◦ Each gateway has exactly one Inspection Settings Profile assigned to it.


• Note that creating an Exception simply changes the final decision (usually from Prevent to Detect or Inactive) but does not stop
the relevant blades from still expending CPU overhead to inspect the traffic.

• IPS Exceptions (whether for R77.XX gateways or R80.10+ gateways) will not exempt traffic from IPS inspection completely
and allow the traffic to take a more efficient path. An Exception only changes the decision made about whether to Prevent the
traffic or not; the traffic still must pass through the same processing path it would have even if there was no Exception at all.

• However for an R80.10+ gateway one can define a “null” IPS Profile like this:



• For traffic traveling to and from the system Behemoth, no IPS inspection (or any other Threat Prevention inspection in this
example) will occur at all, and the traffic may now be eligible to be handled in the fastpath (SXL path). However if some other
blade such as Application Control is also inspecting the traffic, it will still need to take the Medium Path (PXL). But even if that
is the case, significant CPU overhead will be saved by avoiding IPS inspection of this traffic completely in PXL. This “null”
profile’s positive effect on performance is significantly larger than that of an IPS Exception.

[Malik1]

Hi Tim, Thanks for the explanation. But I have a question you mentioned that "in an IPS exception rule for R77.XX gateways, the Action is always Inactive. For other Threat Prevention blades you can select the Action; normally the actions would be Detect or Inactive, but it can also be Prevent which is an interesting option" So if the action is always inactive in r77.30 wont that mean exception does not work.What my understanding is that the exception should be prevent so that it can work. You also mentioned that the action normally is detect or inactive . If its inactive the exception wont work and no log will be logged incase if detect exception wont work by log will be logged. Its confusing what should be the action to exceptions in r80 under TP layer ? Is there any clear documentation We are in the process of migration and I don't want that keeping the exception "inactive": under TP layer will not honour these exception and create an issue. Cause when I change the action on to detect or prevent with mgmt. on r80 and gateway on r77.30 I have presented with the below warning. “Exception 'E-5.2' will not be enforced, for IPS Gateways. 'Action' must be inactive for pre R80 IPS gateway. Regards, Sijeel Malik

[Timothy_Hall · Accepted solution]

When applying an IPS exception on an R77.30 gateway under R80+ management the action must be Inactive, you aren't allowed to set Detect or Prevent on the exception unless you have an R80.10+ gateway.  This is because there was no action setting available when creating an IPS exception under R77.30 management.  What setting "Inactive" on an R77.30 IPS exception under R80+ management actually means is that the R77.30 gateway is still looking for that particular signature, but if a "hit" is encountered it is just ignored due to the exception.  So there is no savings in processing overhead, as exceptions are not consulted until a "hit" on a signature occurs during regular processing.  So once again what "Inactive" means in the context of an exception is to just ignore any "hits" that match the exception, and there won't be any logging of it (like there would be for a Detect), nor will there be a Prevent action executed.

Admittedly managing the IPS feature on R77.30 or earlier gateways under R80+ management is confusing (including the separate IPS TP "layer" which isn't really a true layer), since you can see all the new IPS capabilities in the SmartConsole GUI for R80.10+ gateways, but you aren't allowed to use them with older gateways.  The configuration of the other four TP blades is much more straightforward under R80+ management for both R77.30 and R80.10+ gateways, with only a few extra restrictions for R77.30 vs. R80.10+ gateways.  Thankfully on an R80.10+ gateway IPS and the other four TP blades are fully integrated, and all the bizarre restrictions you are encountering involving IPS go away.

As far as documentation for this situation, this CheckMates post is about as authoritative as you will get:

https://community.checkpoint.com/t5/Policy-Management/What-is-the-roadmap-for-Threat-Prevention-Poli...

Beyond that, the points you raise are a major reason I created the IPS Immersion class and covered this topic so heavily.