Log4J IPS block clarification

[Dario1]

Good afternoon ladies/gents. I attended the Log4J CheckPoint online update last week which was really helpful however I am after some further advice.

In summary: As per CP PS direction few months ago we have rolled out IPS global policy across our firewall estate in "Detect" mode which is manually set on every FW cluster: Activation Mode - Detect only.
We are currently working to finetune the Threat Prevention Policy on R80.20 and R80.40 gateways before we switch to Activation Mode - According to the TP policy.

In our global IPS profile Activation mode - Medium confidence level is set to: Detect so this puts Log4J in Detect even if our gateways IPS was switched to IPS according to TP policy.

My question to you is even if we were to manually override Apache Log4J protection main action to "Prevent" for the global IPS profile, as all FW clusters have IPS set to "detect" I suspect this cluster level detect will supersede manual Log4J protection override to "Prevent"

If that is the case what is the best way to have Log4J only in prevent while having the main IPS global TP policy set to detect in cluster IPS?

The staging mode is disabled in the IPS global profile.

Hope the above makes sense, your help is much appreciated as always. Tx

[Timothy_Hall]

If you have Activation Mode set to "Detect Only" (formerly known as Troubleshooting Mode) and not "According to policy" on the gateway/cluster object, it doesn't matter whether your log4j protections are set to Prevent even with a user override, it will still act like Detect. 

You could simply create a new TP profile, manually set everything except the log4j signatures to Detect or Inactive, put this new profile in a rule at the top of your TP policy, and disable all other rules in your TP policy.  However this will not allow you to continue tuning on your existing TP profiles in anticipation of moving to full Prevent mode.

If you want to keep your existing profiles and continue tuning them in anticipation of going full Prevent eventually yet still have log4j in Prevent mode, there is not an easy way to do this but here is a workaround:

0) Take a backup of your SMS just in case.

1) Look at your Threat Prevention policy rules and determine all TP profiles in use by your gateway(s).  If for some reason your gateway's IPS functionality is still implemented in the legacy "IPS" layer, there can be only one TP profile assigned to the gateway for IPS functionality.  Let's assume for this example that two profiles are being used: Optimized and Strict.

2) In both the Optimized and Strict profile properties, check the IPS...Updates...Newly Updated Protections screen, and make sure that the Set Activation as Staging Mode checkbox is set for now.  This will ensure that any newly downloaded protections go into Staging/Detect mode while in this special period of only log4j being Prevent.  Obviously this box should be unchecked once you move from "Detect Only" to "According to Policy", make sure you don't forget about it!  Note that if the log4j protections get updated by Check Point they will automatically move back into Detect if this is set, so you'll need to weigh the risk of some other newly-downloaded Protection getting put in Prevent mode automatically vs. the log4j Protections going back into Detect if they get updated.

3) Go to the IPS Protections screen.  Sort the Optimized column until Prevent actions (blue shield) are at the top of the list.

4) Make a note of any protections that currently have an administrator override set by clicking User Modified under the Filter tab on the right.  Take a screenshot of any overrides already in place.  Clear the User Modified checkbox.

5) Now the painful part, bulk-select up to 200 Protections currently set for Prevent, then click Actions...Selected Protections...Detect Selected.  You should get a popup warning about being applied to all visible profiles (which should be both Optimized and Strict in our example which is fine), and click OK.  The bulk select is a bit clumsy here, see the screenshot from my IPS/AV/ABOT Immersion class below for tips.

6) The overridden protections will jump down to the bottom of the sorted list and not be visible on the screen any more, select the next 200 or so protections set for Prevent and repeat until there are no more protections under Optimized/Strict showing Prevent (blue shield).  Make sure you don't accidentally set any protections under Optimized/Strict currently set as Inactive to Detect with your override actions.

7) Now locate the two log4j protections and override them to Prevent.  Once again, double-check via sorts on the Optimized and Strict columns that only the log4j protections are showing a blue shield.

8 ) Change Activation Mode on the gateway to "According to policy", then publish and install the TP policy.  Using a blade:ips filter in the logs, immediately make sure that no IPS signatures other than log4j are being tripped in Prevent mode.

Now let's assume that some time has passed and you have achieved reasonable certainty in the rest of your IPS configuration with exceptions and such, and you are ready for full Prevent mode on the gateway:

1) Go to the IPS Protections screen, and under Actions select Cleanup options...Profile cleanup.  Click "Remove all user modified".  Under Select Profiles pick Optimized and Strict (or whatever profiles you are using), then click OK.

2) Manually re-implement any User Overrides noted in step #4 above.

3) Uncheck the Set Activation as Staging Mode checkbox in all utilized TP profiles.

4) Publish and reinstall the TP policy.

Here is the screenshot showing bulk-selection tips for IPS Protections from my IPS/AV/ABOT Immersion course, it was talking about bulk clearing of the Staging flag but the techniques apply here as well:

[Dario1]

Hi Tim, thank you for taking time to reply to my post much appreciated. I didnt think of the cleanup options for the manual protections, that is really handy.

With what you said in mind now that I had a day to digest what you said, I thought of a different way to apply that to the environment I look after. Wonder what you think or am I completely off?
In summary, I sold IPS solution to the business as the best thing since sliced bread as all IPS can be managed via a single MDS/Global policy.
The old legacy IPS had been migrated to Threat Prevention that gives us the option of multi profile policy.

I was trying to come up with a way to change the global policy (now production in detect only at the gateway level) to "according to the policy" activation but in the safest possible way without enabling too many protections in Prevent.
I now know as per your advice on the gateway we got to activate IPS "According to the TP policy" if I then set the global IPS profile to Severity: High & Critical, Confidence: High, Performance Impact: Very Low
Effectively thats puts all but 4 protections in Detect via the global policy profile. Assuming we can trust the 4 protections in Prevent wont break anything we then set Log4J in manual Prevent, without having to use another profile
and we can still then keep on tuning/assessing protections until we work our way to protections equivalent of Optimised profile. What do you think could this be a viable option or have I missed a point?
It is paramount whatever we change on the global IPS profile is super safe option otherwise that goes out to all our firewalls and potentially causes issues.

The other thing is if i am not mistaken CP now advise to disable the "staging mode" so the new protections are activated as per profile activation categories i guess best to leave update "mark with follow up flag" on.
Is this because CP now have more confidence in the new protections, and the protections get activated straight away, getting a dodgy protection could bring down my whole environment.
Would it not be safer to leave the staging mode detect on until someone can look into the new protections, what you you think?

Thanks again for your time.
D

[Timothy_Hall]

You could come in over the top with a global TP rule that references your profile with the highly restrictive settings and the log4j protections set to Prevent, but keep in mind that only one TP rule can be matched at a time.  So depending on how the Protected Scope is defined in this global rule all TP inspection will happen against this global rule, and nothing will hit the lower rules utilizing the Optimized profile which you are trying to tune with the goal of going full prevent eventually.  So yes your approach would work but it would delay your tuning efforts of the Optimized profile further down since nothing would be hitting it anymore.  I assume in this case your profile tuning efforts would then be for the new restricted profile you are using in the global rule.

Yes Check Point changed the default behavior for newly downloaded/updated protections in R80.20 such that they are not placed in staging mode anymore.  In general Check Point has done a good job and it is relatively rare in today's world that an IPS Update with new protections not going into staging mode automatically will suddenly break stuff.  But this is your call of course.

[Dario1]

Thanks Tim,

When you say only one TP rule can be matched at the time, is it not the case of top to bottom rulebase match?

Or is it the case once the lets say TP local profile is matched under policy section 1 TP policy mechanism would not continue to TP policy section 2 global profile?  If we have local and global profiles for the same blade (IPS) do we know what mechanism is used to work out which profile protection has the precedence?

E.g. Rule number one "Parent rule on the domain policy" local rule. I would have local sub sections for different local profiles 1.1 for Anti-Bot, 1.2 Threat Emulation then section 2 would be the global profile rule that goes over the top. My understanding is all section 1 subsections with their different local profiles supersede the global profile, so maybe I could add another local profile under new sub section 1.3 for manually enabled protection like Log4J etc.. Then use tailored safe tool to tune that global profile to eventually match optimised profile. My idea is to try to have that global profile across all firewalls but then again some have different blades enabled depending on the function, so under the section 1 public facing firewall will have local profiles for Anti-Bot, URL filter, TE etc..

Its fun and games getting all these security blade profiles configured in the correct way for user friendly management.

Thanks again.

Dario

[Timothy_Hall]

Threat Prevention policies do a top-down, first-fit rule match just like Access Control policies.  Therefore the first TP rule matched has precedence regardless of whether it is global or local.

So if you have global rule 1 and based on Protected Scope/Source/Destination it matches the connection attributes, only that rule will be applied along with any per-rule exceptions tied to that rule if any.  The approach you mentioned where you have multiple profiles in multiple rules, one for each TP blade won't work.  So if global rule 1 is matched and only IPS is enabled in the matching profile, only IPS will be applied to that traffic and the other TP blades will not.  So if the Protected Scope/Source/Destination matching criteria is the same for two rules (even if one is local and one is global), only the first rule will be matched and the second ignored.  Hopefully I understood your question properly and answered it, if not please provide some screenshots of what you are trying to do.

Note that if you have more than one Threat Prevention policy layer (not common) both are checked simultaneously, at most one matching rule is found in each, and the most stringent action applied unless there is an exception which can possibly change the outcome.

[Dario1]

Hi Tim, thanks again i was overthinking it, like you said "first-fit rule match just like Access Control policies" That makes perfect sense now. Thanks for going into so much detail that really helped. I feel like I now got a way forward along with few different options in managing our security blade policies. Much appreciated. Dario