cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question

Threat Emulation logs, detect instead of prevent

Jump to solution

Hi all

I'm having issues with the TE blade. Despite I have the activation mode for some traffic in "prevent" by all cases, I see some logs with the "detect" action.

I already tried the suggested in sk106119 and sk106251, without success.

Before I talk to my local partner or open a SR I was wondering if could be some wierd incompatibility between the R80 mgmt and R77.30 gw?

Thanks lads

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Employee+
Employee+

Re: Threat Emulation logs, detect instead of prevent

Jump to solution

This is the answer I got:

From logs it looks like it is a known malware so it is likely that it was also dropped by AV.

The way that it works is that while TE is emulating other blades might decide to drop the connection. By the time TE is setting the connection to drop it is no longer in the table and the blade does not know if the connection was dropped or not so it produces a detect log.

In the second time the file is in the cache so it is prevented at roughly the same time it is prevented in AV so there is no discrepancy in the logs.

Can you check if this makes sense in your environment?

0 Kudos
3 Replies
Employee+
Employee+

Re: Threat Emulation logs, detect instead of prevent

Jump to solution

Hi Santiago,

I am not aware of such an issue.

Can you send a screen shot of this log.

Thanks,

Amir

0 Kudos

Re: Threat Emulation logs, detect instead of prevent

Jump to solution

Hi Amir,

I attached two logs, close both in time, with the same malicious file detected, one with detect action and other with prevent one

fwlog1.jpg

fwlog2.jpg

Thanks!

0 Kudos
Employee+
Employee+

Re: Threat Emulation logs, detect instead of prevent

Jump to solution

This is the answer I got:

From logs it looks like it is a known malware so it is likely that it was also dropped by AV.

The way that it works is that while TE is emulating other blades might decide to drop the connection. By the time TE is setting the connection to drop it is no longer in the table and the blade does not know if the connection was dropped or not so it produces a detect log.

In the second time the file is in the cache so it is prevented at roughly the same time it is prevented in AV so there is no discrepancy in the logs.

Can you check if this makes sense in your environment?

0 Kudos