Create a Post
Showing results for 
Search instead for 
Did you mean: 

IPS protection set to detect from prevent after update


This is probably logical but may sometimes surprise you or lead to unwanted action for a IPS protection. Here is the case for "Apache Struts2 Content-Type Remote Code Execution" protection.

This attack protection was released in 07/03/2017 and updated 03/06/2018. The protection action was set to Prevent before the update date. Now since a new update on that protection happened on 03/06/2018 it was set to Detect because of the stage mode. Since you could have installed both "Access control" and "Threat Prevention" for a policy without clearing the stage mode, or a colleague of your IT-team the action is now set to Detect even if it was previously set to Prevent.

Proof of this: Notice the date after 02/06/2018 that it's set to Detect

I wish that an update of a protection that was set to Prevent remains like that even if there is a new update of that same protection. What do you guys think about this? 

Check Point software does not use the Apache Struts 2.X, therefore Check Point software is not vulnerable to any Apache Struts 2 vulnerability. But it could have been something that could affect your system. 

0 Kudos
3 Replies

Hi. see IPS Protections in Detect (Staging)  (3rd bullet and then how you can automate that)


Thank you Tomer. Somehow my brain thinks on newly downloaded protections to be completely new, not impacting already existing protections who got a new update for that same protection. 

The staging exclusion is good by using severity/performance impact and/or using categories. What about a third option that keeps an existing protection to remain in same action even if gets an update for that same protection. What do you think about that and is there any problems with an approach like that?

The motivation behind it is that if a protection gets updated, that's new code. So there is the possibility of a new false-positive that wasn't there before.