Anti-Virus log prompt: "background classification mode was set"

[Jeff_Gao]

Dear 

FW:23500     Version:R80.10       Hotfix:R80_10_JUMBO_HF_Bundle_T56_sk11638

I have set hold mode,refer to screenshots below:

TP configuration as follow:

But the log shows as follow:

Description:

                  Connection was allowed because background classification mode was set. See sk74120 for more information.

"loop.sawmilliner.com" is a C2 and malware site,as follow:

I have set classification mode to hold,why still show "background classification mode was set"

Thanks！

[_Val_]

You are looking to the wrong Software Blade. Threat Prevention is for downloads. For Site classification, you need AC and URL Filtering to be changed.  

[Jeff_Gao]

Thanks,but log match anti-virusblade.This behavior is in the DNS request phase.Can't it be blocked by tp at the DNS request stage?

[G_W_Albrecht]

Look here:

[Jeff_Gao]

Thanks，I will try it.

[Gaurav_Pandya]

Hi,

I have the same issue. I have put the URL filtering setting to Hold mode but still i am getting same logs of "It is allowed because background classification mode was set" in the logs.

[That_CP_Guy]

Was this ever resolved? I am facing the exact same issue. Thanks.

[Hely_C]

I am also facing same issue. anyone has an idea?

[Craig_Myers]

I have a customer with this same issue.  Does Check Point have a configuration fix for this or is this a bug?

[Angel_Lumbreras]

Hello, same issue here, any news about it?

[Trevor_Bruss]

Isn't this because Checkpoint changed how DNS classification occurs? So check out:

https://supportcenter.checkpoint.com/supportcenter/portal?action=portlets.SearchResultMainAction&eve...

Even though in your policy you've set Hold that will be relevant only for http, smtp, and smb. DNS will still be in background mode for optimization purposes. You'd have to manually change that in you malware_config file on the gateway if you want DNS to be in Hold mode as well.

I think what you are seeing here is normal based on the log you showed as this was a DNS query that got bypassed.

[LuisRamP]

Hi @Trevor_Bruss 

Does this change to Hold increase the performance the appliance when processing all DNS queries?
Is it healthy to switch from background to Hold?

Regards.

[RamGuy239]

I'm wondering the same thing. I've stumbled onto this issue myself on a Gaia R81.20 installation. Several logs show:

Id: 9f3b54d2-28a9-b2e7-6438-d9230001000b
Marker: @A@@B@1681423200@C@2998816
Log Server Origin: *removed for privacy reasons*
Time: 2023-04-14T04:40:03Z
Interface Direction: outbound
Interface Name: eth5
Id Generated By Indexer: false
First: false
Sequencenum: 39
Threat Prevention Policy: *removed for privacy reasons*
Threat Prevention Policy Date:2023-04-13T17:29:14Z
Service ID: domain-udp
Source: *removed for privacy reasons*
Source Port: 55277
Destination: 2001:500:40::1
Destination Port: 53
IP Protocol: 17
Session Identification Number:0x6438d923,0x1000b,0xd2543b9f,0xe7b2a928
Protection Name: Swift.TC.c754KqbG
Malware Family: Swift
Description: Connection was allowed because background classification mode was set. See sk74120 for more information.
Confidence Level: High
Severity: High
Malware Action: DNS server resolving a site known to contain malware for a client behind it
Protection Type: DNS Reputation
Threat Prevention Rule ID: 170CAD95-2A46-46C7-B72A-C2ABE51782D8
Protection ID: 00283EC74
Vendor List: Check Point ThreatCloud
Action Details: bypass
Log ID: 2
Scope: *removed for privacy reasons*
Suppressed Logs: 1
Last Hit Time: 2023-04-14T04:41:04Z
Action: Detect
Type: Log
Policy Name: *removed for privacy reasons*
Policy Management: *removed for privacy reasons*
Db Tag: {DB09EBF5-3C1A-4046-8ACA-0BA7610D30E3}
Policy Date: 2023-04-13T17:29:09Z
Blade: Anti-Virus
Origin: *removed for privacy reasons*
Service: UDP/53
Product Family: Threat
Sent Bytes: 0
Received Bytes: 390
Resource: **bleep**90.duckdns.org
Interface: eth5
Description: *removed for privacy reasons* performed dns server resolving a site known to contain malware for a client behind it that was detected
Threat Profile: *removed for privacy reasons*
Bytes (sent\received): 0 B \ 390 B

I knew about the Threat Prevention Engine settings, so I tried changing Anti Virus and Anti Bot from Background to Hold. Didn't change anything. I get similar logs from both the Anti Virus and Anti Bot blade:

Id: c1b5f4f7-67b8-28c9-6438-cb0600010014
Marker: @A@@B@1681423200@C@2545885
Log Server Origin: *removed for privacy reasons*
Time: 2023-04-14T03:39:50Z
Interface Direction: outbound
Interface Name: eth5
Id Generated By Indexer: false
First: false
Sequencenum: 11
Threat Prevention Policy: *removed for privacy reasons*
Threat Prevention Policy Date:2023-04-13T17:29:12Z
Service ID: domain-udp
Source: *removed for privacy reasons*
Source Port: 53299
Destination: 194.62.182.53
Destination Port: 53
IP Protocol: 17
Session Identification Number:0x6438cb06,0x10014,0xf7f4b5c1,0xc928b867
Protection Name: nanocore.TC.cai
Malware Family: Nanocore
Description: Connection was allowed because background classification mode was set. See sk74120 for more information.
Confidence Level: High
Severity: High
Malware Action: DNS server resolving a C&C site for a client behind it
Protection Type: DNS Reputation
Threat Prevention Rule ID: 170CAD95-2A46-46C7-B72A-C2ABE51782D8
Protection ID: 0019B95C1
Vendor List: Check Point ThreatCloud
Action Details: bypass
Log ID: 2
Scope: *removed for privacy reasons*
Suppressed Logs: 1
Last Hit Time: 2023-04-14T03:40:51Z
Action: Detect
Type: Log
Policy Name: *removed for privacy reasons*
Policy Management: *removed for privacy reasons*
Db Tag: {DB09EBF5-3C1A-4046-8ACA-0BA7610D30E3}
Policy Date: 2023-04-13T17:29:09Z
Blade: Anti-Bot
Origin: *removed for privacy reasons*
Service: UDP/53
Product Family: Threat
Sent Bytes: 0
Received Bytes: 121
Resource: cnam.myvnc.com
Interface: eth5
Description: *removed for privacy reasons* performed dns server resolving a c&c site for a client behind it that was detected
Threat Profile: *removed for privacy reasons*
Bytes (sent\received): 0 B \ 121 B

Checking https://support.checkpoint.com/results/sk/sk74120, the SK does mention:

Note: Starting from R75.47 and R76, Anti-Bot Resource Classification mode for DNS is performed in the "background" on the Security Gateway. To learn more, see sk92224 - Resource Categorization for Anti-Bot / Anti-Virus DNS Settings optimization.

There is no mention of the possible impact of doing the change mentioned in https://support.checkpoint.com/results/sk/sk92224.

I suspect most of the logs I see are somewhat misleading as our R81.20 gateways use Network Feeds, some including domains for use as a blacklist in the Network Policy. Judging by traffic logs and the timestamp, it seems like the gateway is resolving the domains from the blacklist. As a result of the network feed consisting of well-known bad domains, the gateway is trying to resolve the domains querying our local Windows DNS server. As soon as the Windows DNS server resolves the domain, the Anti Virus and Anti Bot start kicking in (seems a bit random whether it is the Anti Virus or Anti Bot blade) and drops it as "DNS Reputation". And some of these queries end up in detect because "Connection was allowed because background classification mode was set.".

It doesn't look good to have Smart Event telling there are a bunch of attacks not getting prevented, so I'm tempted to make this change to look better. But at the same time, I'm sceptical about the impact this change might have as I feel these logs aren't all that important as it's just the gateways themselves triggering the behaviour when resolving the Network Feed objects containing bad domains.

Reason for me to be sceptical about the change is how changing Anti Virus and Anti Bot in Smart Console does not affect DNS. Surely there is a reason why it behaves this way and you have to start fiddling with manual edits of local files for it to start holding DNS traffic.

[RamGuy239]

I tried changing DNS from bg to hold in $FWDIR/conf/malware_config. As far as I can see, it does not seem to impact performance on the gateway in any meaningful way. At least not so far. But it does affect DNS resolution speeds. A lot of basic DNS resolving on the gateway and local resources behind the gateway has this 2-5 seconds delay.

I suppose this is to be expected. The logs showing how DNS Protection couldn't interfere when in background mode point to the protection spending too long to be able to stop it while in background mode. DNS Protection will also match legitimate DNS traffic for it to judge it as safe, so enforcing "Hold" might cause a delay for all DNS traffic depending on how fast the DNS Protection can classify the traffic.

You will not see delays for every DNS attempt as a lot will be in the DNS Protection cache and not get delayed, and a lot of the traffic is being classified rapidly, not causing a delay, to begin with. But we will have random DNS with a 2-5 second delay when enforcing "hold".