DNS Trap Protection

[Juraj_Skalny]

Hello Guys,

I would like to follow up on the following posts :

https://community.checkpoint.com/t5/Logging-and-Reporting/Threat-Prevention-dns-trap-and-resource-ca...

https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/Some-DNS-request-not-block-by-AV-bl...

What we would like to find out is how log firewalls keeps the information about malicious domain in cache?

DNS request is changed for Bogus IP by firewall as long as the malicious domain is in cache.

The problem we see is that the cache is maybe too short as "Connection was allowed because background classification mode was set. See sk74120 for more information." for the same malicious domain appears in logs too often.

We would expect to see this classification event once and then lots of changes to Bogus IP. But that is not the case.

There is no documentation on CP covering this info or how to change it. Or we have just overlooked it.

In our understanding this way lots of malicious activities are just allowed only because firewall needs to let go of DNS resolution requests because those needs to be classified in the first place over and over again.

Thanks and regards,

Juraj

[Garrett_DirSec]

good post.    I can't help but wonder if @Dorit_Dor and team going to release new DNS protection product @ CPX 2020.    This would mirror some of their primary Gartner competitors.   In addition, it would be nice if CP services and advanced features would help identify issues with DNS services and provide recommendations and/or protections to guard against mis-configuration, etc.   

.02 -GA

[TP_Master]

Hi Garrett,
Since this post is about DNS Trap I know you are aware of this feature and the DNS Reputation feature we've had for years now. Other than the misconfiguration detection that you've mentioned, do you feel something else is missing from our offering vs. our competitors regarding DNS security?

[TP_Master]

Hi Juraj,

Your understanding of the mechanism is correct - we expect only few logs with "Connection was allowed because background classification mode was set. See sk74120 for more information.". But in the screenshot you attached we can't see if the logs have this line or not.

Note that since we are not really dropping the packet/connection, the logged action when the bogus IP is returned is DETECT. So your example, without seeing the logs themselves, on its face looks as working as expected.

You can paste here or send me via DM an export of those logs including the field that mentions the background mode.

[Juraj_Skalny]

Hello,

please see the picture attached.

Hope its going to be readable.

Two firewalls are involved in this instance.

Both classified adspot.tfgapps.com as malicious at the bottom of the screen.

We see reoccurring classification for the same domain over and over again as you go higher up to the top of the screen.

I have also attached a file just in case.

Thanks a lot,

Juraj

[TP_Master]

@Juraj_Skalny I looked at the screenshot.

If you look closely you see these are 3 security gateways over a few days (COLLO-FW2, CZPR-FW2 and CZPR-FW1).

Also as I mentioned, you need to look at only those that had the message about "background mode".

By default the cache expires after 12-24 hours (we also have a mechanism to purge the individual cache entry if domain is found malicious while it is in the clean cache), so you'd expect a gateway to ask again on different days, or many hours apart.

The only case I've see in your example is CZPR-FW1 asking on 7/Nov 13:31:36 and then asking again on 7/Nov 16:21:20. 

Several cases that can make this happen:

1. The gateway was rebooted between those times.
2. The gateway had a configuration (non-default, you can find it in an SK) that cleans the cache upon policy installation and policy was installed.
3. The cache was filled between those times, in that case old entries are cleaned to make room for new ones.

Hope that helps

[Juraj_Skalny]

Hello,

@TP_Master  CZPR-FW1 and CZPR-FW2 are actually in cluster.

This was maybe confusing example.

I would like to give single gateway and single user example.

Please correct me if Im wrong in the following statement.

Malware which is active on user computer is allowed to talk to C&C site (because classification in the background) every day even:

 - if gateway was not rebooted

 - policy was not installed (which SK describes cache flush with policy push?)

Have no clue how to investigate if the cache was filled or not.

is there any particular reason why the cache lasts only 12-24 Hours?

Thanks,

Juraj

[TP_Master]

Here we see that DNS request was allowed (BTW - this is only about the DNS request, not the actual connection! that's important to say. It could very well be that URL reputation stopped this later on) - ONCE on 11/Nov 4:41pm, Once on 13/Nov 4:34pm, once on 14/Nov 4:14pm, and twice on 14/Nov 8:47pm. The other ~600 requests were blocked.

[Juraj_Skalny]

Hello,

@TP_Master  what you say makes sense. Thank you for that.

I would have also a question in relation to the protections for threat Prevention layer.

I can see that the following sections are set just as detect for even built-in profiles. Do we need to change it to Prevent maybe?

Reputation URLs for Antibot 

Reputation Domains for Anti-Bot

Thanks,

Juraj

[TP_Master]

The actual enforcement is according to the confidence level and the settings on the relevant profile (Optimized profile for example dictates "Low confidence"->Detect, "Medium" and "High confidence"->Prevent.
I will check about the usability issue in this screen, but enforcement works as I mentioned.

[Juraj_Skalny]

Hello,

@TP_Master 

I was digging little bit further and and tried to trace if DNS Trap is really effective.

Here is what I found:

Malware infected machine makes successful connection to the C&C site by the time gateway classifies domain as malicious.

Maybe I am mistaking. Please kindly comment.

Please see the print screen:

Thanks,

Juraj

[TP_Master]

Very effective: See the ALLOW logs only appear after the lines where the connection was allowed due to Background mode (roughly once a day). You don't see the ALLOW logs to all the other dozens/hundreds of DNS requests for that domain.

[CheckPointerXL]

any workaround to avoid detect DNS/background classification ? maybe by increasing the RAD queries per connection ?? (ckp_regedit -a SOFTWARE\\CheckPoint\\FW1\\$(cpprod_util CPPROD_GetCurrentVersion FW1) RAD_QUERIES_NUMBER_PER_CONNECTION XXXXX)   

it is not clear to me what is triggering this behavoir to gateway...if i understood correctly, dns name is not in cache to local gateway... not possible to prevent quickly instead of resolving name later?

[Chris_Atkinson]

Please refer sk92224: Optimizing the categorization of DNS traffic by changing the Resource Classification Mode, for Anti-Virus and Anti-Bot

For the wider thread:

* Note R81 above changed the logging for the DNS malware trap to Prevent (refer release notes for more info).

* R81.20 (Titan) introduced several new DNS security techniques.