DNS traffic in DETECT mode in VSX

[Matlu]

Hello, Mates

I have a problem with Threat Prevention.

I have a VSX cluster with several VSs.
One of my VSs has the TP layer (AV/AB/IPS) enabled, the VS does not have HTTPS Inspection enabled, and it is working with a default rule in the TP layer with the “Optimized” profile.

The problem is that there are many logs with “Detect” action even though the profile detail is in PREVENT mode.

The logs invite us to review SK74120, but the problem arises when we apply the SK, because when we change the DNS “behavior” to HOLD mode following the SK instructions, we affect many other services, such as sending/receiving emails that pass through this VS.

The TAC is investigating the possible root cause of this problem, since the goal is for this traffic to be prevented and not just labeled as DETECT.

In VSX environments, how does traffic flow inspection work? Does traffic that crosses through a VS that has Internet access and has the TP layer enabled always have to pass through the VS0 as well, and only then is this traffic sent to ThreatCloud for review?

Thank you for your opinions.

[Chris_Atkinson]

To confirm you implemented sk92224 which triggered/caused the degradation?
Latency is expected here but you can try tuning the relevant cache size perhaps.

The "traffic" does not traverse VS0. The Gateway itself will source related DNS / RAD requests from VS0 however.
I'll quote historic sk113084 as it describes in the "cause" section how this can be problematic in some scenarios.

Note also the following previous fixes:

Take 43 Released on 8 January 2024
PRJ-48847, PMTR-88858	Threat Prevention	Anti-Virus Blade triggers the "Detect" logs for DNS traffic, although these malicious DNS requests were prevented.
PRJ-48973, PRHF-30090	Anti-Virus	When Anti-Virus DNS classification is set to Hold mode, the first DNS trap log of malicious Domains shows "Detect" in the Action field, although the connection was successfully blocked.

[Matlu]

Hello

What is the best solution for these cases where Threat Prevention with its blades practically does not act preventively against traffic that should be blocked?

Should the parameter be changed?

This change recommended in the SK has not helped us because on the contrary, it has given us more problems with legitimate traffic.

So, if for example DNS traffic is not blocked, but you need it to be blocked, at least those queries to malicious domains, what can be done here?

Look for other alternatives within what Check Point's solution offers?

Use blocking by other blades, or use blocking by IoC, etc?

Thanks

[Chris_Atkinson]

As indicated you can try manipulation of the cache size / investigate with TAC but some latency is expected.

You can also review based on the topology if the control is suitable here or should be enforced elsewhere by a different / separate gateway.

Lastly you could explore secure DNS resolvers, be those the ones available in Harmony SASE for DNS filtering or other options.

[PhoneBoy]

The issue you are experiencing with DNS not being "prevented" is because it requires Hold mode to eliminate, as explained previously.
Every other vendor would require a similar configuration.

Implementing DNS Trap (as mentioned elsewhere) would certainly help with the number of these messages.

[PhoneBoy]

The log you've provided is for DNS.
A typical DNS transaction involves only two packets: the lookup request and the response.
A grand total of two UDP packets.

When running in Background mode, the determination about maliciousness is made after the client receives the response in most cases.
This is why the log is flagged as Detect and is expected behavior.
To prevent, in this case, you have to use Hold mode, though it has issues, as you've described.

This isn't specific to VSX.

[Wolfgang]

@Matlu did you enabled "Malware DNS trap"-feature? sk74060 - Anti-Virus Malware DNS Trap feature

The DNS reply is modified with the trap IP and all connections to that IP will be blocked. The initial DNS-request is allowed but with this you can identify the client which is requesting the malicious site.