Difference between "Protected Scope" and "Destination"

[Ruben_Starkovsk]

Whats the difference between "Destination" and "Protected Scope" in the Threat Prevention policy and Global Exception rules and when would you use either?

[Daniel_Taney · Accepted solution]

I believe "Protected Scope" is used in the Threat Prevention policy to designate an entity that you want protected (i.e. a single host, group of hosts, network, etc...). It is my understanding that this applies the protections in the policy to those nodes whether the malicious traffic is inbound or outbound. 

Whereas "Destination" would only apply the rule to traffic headed outbound. 

[cosmos]

I would like to know what the official answer is from Check Point.... anyone?

[Timothy_Hall · Accepted solution]

Protected Scope means match/scan all traffic going to/from this object regardless of which way the connection was originally initiated, as generally we don't care about "directionality" for the process of Threat Prevention.  We most certainly do care about that in Access Control policies.

If however the hidden Threat Prevention Source/Destination policy fields are exposed then populated (they both default to Any), you are implying directionality for what you want to scan.  So if in your TP policy Source is "net1", Destination is Any, and Protected Scope is Any, only connections initiated from net1 and the replies will match that rule and be scanned via the associated profile.  Connections initiated from outside net1 into it will not match that TP rule at all for traffic in both directions.

I got this question a lot in various classes so here is the coverage of this topic from my 2021 IPS/AV/ABOT Video Series class:

[Thomas_Eichelbu]

Hello Team!

iam not sure if it best practice to open follow up question to very old posts, anyway.

Protected Scope vs SRC and DST in the TP Rulebase.
Does it have any Peformance implications?

currently iam working on a performace issue, CIFS traffic over 100Mbit line.
mostly we achieve 100Mbits throughout, sometimes not.


we have enabled all blades.

enabled_blades
fw vpn cvpn urlf av appi ips SSL_INSPECT anti_bot content_awareness mon zero_phishing

ISP redundancy is enabled
-> kills SXL

Zones are enabled on all interfaces
-> Kills SXL Templating

TP Profile with AV Deep and and even Archive Scan.
This are all settings which negatively affects SXL
ISP Redundancy sets all my traffic in slow path, but i think VPN is not affected by ISP Redundacy, at least i dont see any  VPN connections is slow path (checked with fw tab -t connections -z) 

we need to test more, but i think settings a policy with Protected Scope does alot harm for performance instead of using SRC & DST. Of Course when using SRC and DST and can narrow down on true use case.

so what is your performance related experiance Protected Scope VS SRC & DST policies?
second:
Protected Scope in the profile:
(Yes we enabled all blades and all functions, because We Secure The Internet and pay for it!)
setting Inspect incoming files from the following interface to ALL and Inspect incoming and outgoing  file is almost equel expect the outgoing part. but i think this settings kicks our performace down, even compared to Deep & Archive Scan.
also our TP Policy is based on SRC & DST and not on Protected Scope. Does this mess up somehow with the profile?

my impression is, when using Protected Scope it is slower, SRC & DST makes it faster.
but we need more tests to give it a clear picture.

Software is always the latest and greatest, R81.20 HFA84
3600 (100Mbit line)  and 3800 (300Mbit line) appliances

Any ideas?

[PhoneBoy]

It might force more traffic into medium path to use Protected Scope, but it seems like the bigger issue is that ISP Redundancy is killing SecureXL.

[Timothy_Hall]

Using Protected Scope vs. Src/Dst should not directly affect what path traffic ends up in.  Using Src and Dst and leaving Protected Scope as Any may subject less traffic to inspection in the Medium Path as Phoneboy mentioned.

ISP Redundancy does cause all Internet-bound traffic to go F2F/slowpath, but only in Active-Active mode.  In Active/Backup mode it does not affect SecureXL.

Use of Security Zones does not kill templates.  I assume you mean by "kill templates" that the output of fwaccel stat shows that Accept Templates are "enabled" yet the Accelerated Conns percentage displayed by fwaccel stats -s is zero.  This is almost always due to policy construction in that some blade other than just Firewall is enabled in the first layer (ordered layers) or in the top/parent rules (inline layers); it can also be caused by setting "Protocol Signature" on service objects used in the top/first layer of the policy.  The new R81.20 command fwaccel templates -R will give you a detailed diagnosis, "Prevented by Policy" as a reason means one of the situations I just detailed is present in the policy.

Using deep scan (which invokes Active Streaming and security server process interaction), combined with scanning of SMB/CIFS traffic which tends to be high-speed internal traffic, combined with scanning all files in all directions is the fastest way to kill the firewall possible.  Archive Scanning is acceptable, deep scanning outside of a lab is not.  In theory deep scanning might catch certain evasion situations that the passive streaming approach might miss, but the resulting overhead of deep scanning is well in excess of any supposed security benefit gained in my opinion.

Use fwaccel conns to see what path a connection is in, lack of an "S" (streaming) flag means it is fastpath.  If "S" flag is present run the fw_mux or fw_streaming commands to see if the connection is Passive Streaming or Active Streaming.  If the connection does not show up at all in fwaccel conns at all, it is slowpath so use fw tab -t connections -z to see these connections and the reason they are slowpath.

[Thomas_Eichelbu]

Hello Timothy, 

thank you very much for your comprehensive summary.
regarding the usage of zones and SXL, i mean the usage Zones does not allow the creation of Drop Templates, sk131793.
The Kernel Parameter in this SK never worked for me.
I saw situations when a storm of dropped packets sent powerful firewalls to its knees because of the lack of Drop Templates (at least i think thats what happened) because Zones were used on the interfaces. Reason was wrongly configured MS Teams Mass event which triggered millions of point to point connections between all participants 🙂


when checking this:


what is MISP? perhaps ISP Redundancy?
NON TCP/UDP PROTO, maybe ESP?
and this "Set Security Zone Out Interface Failed" just 2%, but what is failing here?

we ran through all those commands, fw_mux and fw_streaming to analyze the traffic, since we want to use the whole battery of protections, and scan it to the maximum, we suffer from inconsistent throughput.

[PhoneBoy]

MISP stands for Multiple ISP, which suggests ISP Redundancy.
Non TCP/UDP is just that: traffic that isn’t TCP or UDP that passes the gateway (this traffic is not accelerated by SecureXL).
This could be ESP traffic that doesn’t terminate on the gateway, for instance.