Threat Prevention Policy - Protected Scope - Not working?

[Michael_Horne]

Hello All,

We have an issue with some traffic triggering an IPS Block for some traffic.

The FW Blade log:

This is triggering a IPS Blade Log:

We tried to bypass the Zscaler traffic from the IPS. We do this generally as Zscaler should in theory already be doing security checks.

This did not have any effect. We were still getting the same log messages.   As a test I implemented a Threat Protection rule which used "Destination" instead of "Protected Scope":

When we use this test rule, then the logs stop.  Why understanding was (and other articles on the Community back this up) that "Protected Scope" is for matching "Source or Destination", but in this case it does not seem to work.

Is there any other difference between "Protected Scope" and using "Source" and "Destination", that we should be aware of that might explain this behaviour?

Many thanks,

Michael

[PhoneBoy]

Protected scope refers to things behind the gateway, whether it is used as a source or destination.
Zscaler is clearly not in the protected scope in this case.

[Tobias_Moritz]

Phoneboy, with "things behind the gateway" you mean based on topology (defined in database), right?

So protected scope is only usable for things, which are reachable over an interface NOT defined as external from the affected gateway point of view, did I understand you right?

And when using source or destination field in TP policy instead of protected scope field, this limitation does not apply, right?

While this would be a good explanation for the effect Micheal showed us here, I'm really suprised it works this way.

[G_W_Albrecht]

Protected Scope contains objects that will be inspected when either connecting to or being connected from somewhere. This could contain Updateable Objects like O365 o.s.

[Michael_Horne]

Hello,

This would definitely explain the behavior.  In the Threat Prevention Admin Guide I do not see this mentioned.  The closest to a  definition I can see is: "The list of network objects you want to protect."  Is the protected Scope then only relevant to interface topologies that are marked as "internal"?

Many thanks,

Michael

[G_W_Albrecht]

I find that this is explained very throughly in Threat Prevention R81.10 Administration Guide p.50ff Protected Scope ! Also see sk114806: ATRG: Threat Emulation (20) Performance considerations and Best practices and sk120933: How to configure the Protected Scope in Anti-Virus Settings for file downloads

[Michael_Horne]

Hello,

This definition is quite good, but does not explicitly clarify the comment as to whether the Protected Scope can cover objects that are external to the local security gateway. The comments you made about the use of updatable objects references which is part of the definition would indicate that the protects scope could include external resources, as it is highly unlikely that there are updateable objects for internal resources, unless is a customer created one. Everything I have seen referenced implies that external resources can be used as the protected scope. Hence my original question.

[G_W_Albrecht]

I read as follows:

Protected Scope objects can be

Network objects, such as Security Gateways, clusters, servers, networks, IP ranges, and so on. From R80.10, dynamic objects and domain objects are also supported in the Threat Prevention Policy.

Network object groups

Updatable objects (from R80.40)

IP address ranges

Roles

Zones

So naturally you can use external objects if needed, but in everyday life i would just include all internal networks to protect my clients and servers that will be inspected when either connecting to or being connected from somewhere. Also see the mentioned Performance considerations and Best practices !

[Tobias_Moritz]

Thank, Günther, for the detailed explanation and I agree to that suggestion, but how does this explain the different behavior observed by Micheal when putting the network group object in Protected Scope field versus putting it in Destination field?

[G_W_Albrecht]

I would suggest to ask TAC about this different behavior !

[Timothy_Hall]

Similarly to Access Control, in the Threat Prevention policy the Protected Scope matching is performed pre-NAT.  So for an outbound connection that is presumably Hide NATted, the original inside IP must be specified there for a proper match.  For an inbound connection that is statically NATted, the outside Internet-routable IP address must be specified since that is the one present in the packet prior to any NAT operations.  This applies equally regardless of whether source or destination (or both) are being NATted by the firewall.

[Pawel_Szetela]

Hi Timothy,

Can You clarify:

"... For an inbound connection that is statically NATted, the outside Internet-routable IP address must be specified since that is the one present in the packet prior to any NAT operations. This applies equally regardless of whether source or destination (or both) are being NATted by the firewall."

If we have object with automatic static NAT do we have to create another object with public IP and use it in policy? Is it relevant for Protected Scope or Source or Destination in Threat Prevention?

Reagrds,