Inspection Settings

[s_milidrag]

Hi Check Mate

I am pretty confused about the difference between core protections and protections listed in Inspection settings.

What is the difference between them ?

In Inspection Settings there are two profiles "Recommended Inspection" and "Default Inspection"

By default "Default Inspection" profile is applied. Why not "Recommended Inspection" profile ?

What is a best practice & recommendation by Check Point ? Do we need to change this settings in a production enthronement ? 

[Jerry]

Inspection Settings

You can configure inspection settings for the Firewall:
◦Deep packet inspection settings
◦Protocol parsing inspection settings
◦VoIP packet inspection settings

The Security Management Server comes with two preconfigured inspection profiles for the Firewall:
◦Default Inspection
◦Recommended Inspection

When you configure a Security Gateway, the Default Inspection profile is enabled for it. You can also assign the Recommended Inspection profile to the Security Gateway, or to create a custom profile and assign it to the Security Gateway.

To activate the Inspection Settings, install the Access Control Policy.

Note - In a pre-R80 SmartConsole, Inspection Settings are configured as IPS Protections.


--

more @ https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_SecurityManagement_AdminGuid...

[HeikoAnkenbrand]

Recommended Inspection profile is high pervormance intense.

[Jerry]

Agree with Heiko, however I do believe that that's the profile we all shoudl be using as it is sort of "bunch" of recommendations all-in-one and we all should be protected by at least a CLONE of that one Profile.
Default one is the one you got when SG is installed (depoyed) whilst the Recommended one is simply the MINIMUM version which afterwards should be customized and used per Gateway configuration.

just my 5 cents. the call is yours of course.

[s_milidrag]

Thanks,

So it is not recommended to user Recommended Profile 

Also I am confused about TCP Invalid Retransmission protection.

In Recommended Inspection profile action is Drop and in Default Inspection profile, action is Inactive. 

Maybe I am wrong, but if something is Inactive, that means it is Accepted.

TCP Invalid Retransmission protection is declared as a high Important...

[Oliver_Fink]

I have been looking for an answer to the same question and found an answer from @Lari_Luoma here:

The other reason why I think it's better (and safer) to create a new profile than clone the existing one is that some of the settings can be quite dangerous and you really should understand your environment well before changing any of the settings.

This is why I really would recommend using the default-profile unless you know exactly what you want to change and why. You might have some non-RFC compliant DNS for example in your network and enabling that protection would cause your DNS to stop working.

This is my personal opinion based on what I've seen on the field. Feel free to disagree.

Seems, that you are right: The Recommended Profile for Inspection Settings is not recommended – maybe "dangerous".

What I really cannot understand, is the fact that naming and documentation are as maximal bad as they could be. Is there any quality assurance at work before a product goes into the wild?

[Lari_Luoma]

Hi Olivier,

Can you be more specific on what naming and documentation you are referring to?

[biskit]

I'm still a bit confused with these settings. 

Why are so many by default "Inactive"?  What does this mean?  Is this traffic accepted?

Why are so many  "N/A"?  

In my case I see I have lots and lots of "IPS" logs showing traffic accepted, with reason "HTTP parsing error detected. Bypassing the request as defined in the Inspection Settings.". 

I can't change the action on the HTTP Protocol - General.  So any bad traffic picked up by this inspection setting is just bypassed (accepted).  Why?  How do I prevent this bad traffic from just being accepted?  What if I want to stop/block/drop it?  Once it's accepted by this inspection, does anything else in the firewall check to make sure it's OK before simply allowing it through?  

[Timothy_Hall]

Inspection Settings enforce compliance at the protocol level and are inherent to the basic stateful inspection process; these signatures used to be part of the IPS blade prior to R80 and to some degree are still influenced by IPS settings.  Inspection Settings are not looking for known attacks but protocols being used in a weak way (i.e. no POP3/IMAP password) or protocols being used in a fashion that violates that protocol's standard or an RFC.  Many of them are set to Inactive as some vendors do not strictly adhere to the protocol standards or come up with their own proprietary extensions, thus resulting in false positives.  Once again Inspection settings are not looking for known exploits/attacks, just nonstandard or weak behavior.  Just because traffic matches an Inspection Setting that is Inactive does not automatically mean it is accepted; it can still be dropped by a policy layer rule or some other blade such as APCL/URLF or Threat Prevention.

My interpretation of Inspection Settings protections that are N/A is that these are just placeholders for protections whose behavior is controlled elsewhere from Threat Prevention, or the settings under Global Properties...Advanced...Advanced Configuration...Configure.

In the case of your HTTP traffic matching the HTTP Protocol General protection and being accepted, that just means that the HTTP protocol inspection could not be performed and that traffic bypassed inspection by that Inspection settings signature.  Some other element of the firewall's configuration can still block it later.  This situation qualifies as an inspection engine failure, and by default it is set to fail-open.  If you want it to fail closed change the Fail Mode setting located on Manage & Settings...Blades...Threat Prevention...Advanced Settings to fail-closed.  But be warned that the traffic that formerly bypassed HTTP Protocol Inspection will be immediately denied because the inspection failed, and this may break stuff in your network.

[PhoneBoy]

I believe you can make this stricter with the following SK: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

[Jerry]

you may also find interesting comparing all this with following:

https://community.checkpoint.com/t5/IPS-Anti-Virus-and-Anti-Bot/Optimize-vs-Recommended-Protection/t...

[Timothy_Hall]

Here is some content from my IPS Immersion class taking a shot an explaining the difference between Core Protections/Activations and Inspection Settings.

Click to Expand

• There are actually four different “classes” of what might be considered IPS Protections under R80.10+ management. (Note that Geo Policy/Protection is the fourth, and will be covered later in Module 4) The subtle differences in how you work with each of these four classes is the source of a LOT of confusion. They are:

  1. ThreatCloud Protections (~9,300+, shield icon)
  2. Core Activations (~39, shield w/ firewall icon)
  3. Inspection Settings (~150, wrench icon)
  4. Geo Policy (Covered in Module 4)

• 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.

• For technical reasons, 39 Core Activations exist in a kind of “no–man’s land” between ThreatCloud Protections and Inspection Settings. They typically enforce protocol standards via a protocol parser, and have the following attributes:

  ◦ Instead of the typical Inactive/Prevent/Detect settings, “See Details...” appears instead
  ◦ Exceptions can only be added for a single Core Activation signature at a time, and the main Threat Prevention Global & Custom Exceptions DO NOT apply
  ◦ Core Activations ship with the product and are not modified or augmented by IPS Updates from the Check Point ThreatCloud
  ◦ Under R80+ management, if configuration changes are made to existing Core Activations, they can be made active on the gateway by:
     ▪ R77.XX gateway: Install the Access Control Policy
     ▪ R80.10+ gateway: Install the Access Control Policy (NOT Threat Prevention)

◦ Core Activations have a special “shield with firewall” icon and will typically have an “Advanced” screen where the Activation can be further tuned or adjusted.

[GigaYang]

If I change action setting from prevent to accecpt. All hit log will show detect. Is it right?

[Timothy_Hall]

Yes, Accept is the equivalent of Detect for Inspection Settings.  As long as Track is set to Log for that protection you should see a log for it.