Anti-Spyware Behaviour and Inline Cloud Analysis

[nohash4u]

Hello All, 

I have run into some curious behaviour with Anti-Spyware. High severity threats tagged as threat type 'spyware' are coming through the firewall with an action of alert, despite all configurations pointing to an action that should either be reset-both, or sinkhole. 

I have confirmed the following: 

• The security policy rule that matches the traffic does have the correct security profile group set. 
• The security profile group set does reference the specific Anti-Spyware security profile. 

Within the Anti-Spyware profile here is the breakdown: 

• Signature Policies 
  • Severity medium, high, and critical all have an action of reset-both.  
• Signature Exceptions 
  • None. 
• DNS Policies 
  • All signature sources have a log severity set to high, and an action of sinkhole. 
• DNS Exceptions 
  • None. 
• Inline Cloud Analysis 
  • Enabled. 
  • The action for all models is set to alert. 

Could this behaviour be a result of inline cloud analysis?

Is there a way to tell if the traffic flow has had inline cloud analysis applied to it? If so, I have not found a way to tell as of yet. I have checked the columns available in the threat logs, as well as the Detailed Log View, but to no avail. 

I would like to note that the threat ID is identified in each traffic flow. An example is 109010004.  

As always: any insight is much appreciated! 

[kiwi]

Hi @nohash4u ,

Try enabling the threat category in the detailed threat logs (enable the column if needed). 

Notice in my example screenshot how the inline-cloud-c2 category has the "alert" action for high severity threats indicating that the Inline Cloud engine took action as opposed to the anti-spyware engine (where the action would be reset-both).

Hope this helps,

-Kim.

[nohash4u]

Hello @kiwi, 

Thanks for the great insight on how to determine if a threat is identified via Inline Cloud Analysis. In my case I have yet to see this appear under the threat category column.

Here is an example:

On another thread - it is almost as if layer 7 inspection is not occurring or functioning properly. I did notice the security policy rule that matches these traffic flows has the 'Disable Server Response Inspection' option enabled. Would this have an implication on DNS related traffic flows ? Even so, I find it interesting that the flow is marked with a certain severity, and yet the prescribed action is not enforced. 

Lastly, could this be timeout related? I have noticed via the detailed log view that the flows start with an action of alert, and end 30 seconds later with an action of allow.  

Thanks again for your insight. 

[Raido_Rattameister]

Enabling "Disable Server Response Inspection" is very insecure practice because you will bypass whole server to client flow from inspection.

Could make sense only for incoming traffic towards web servers that you control and really trust that they are not hacked and don't host anything malicious and you really need to reduce load on the firewall.

[nohash4u]

Thanks for confirming. The documentation also strongly advises against enabling DSRI. I did not configure this device, but I will pass this along in my future discussions. 

Regardless, the main unknown is the action of alert for high severity DNS based threats being inconsistent with the configuration on the firewall.  Would enabling DSRI interfere with the enforcement behaviour? If so, why is the action alert with the threat ID identified as something that should be sinkholed, reset-both, etc? 

More than happy to open a TAC case, but I thought I would ask here first!