- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- Re: Threat Prevention is Not Block DNS Reputation ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Threat Prevention is Not Block DNS Reputation Which Policy Are Block
Hello,
My client have a concern on DNS Reputation traffic with High severity, but Checkpoint just detect on this traffic. And on the policy, we set block on High and Medium except Low that will detected.
So anyone know how can change it? Or which setting that could turn it block or detect? Below is the screenshot of the log.
Below is record detail:
Thanks for any idea.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the R81 Release Notes, there is a documented behavior change related to this:
-
Log description change for DNS sinkhole trap - log is changed to Prevent instead of Detect, the Security Gateway prevents users from reaching malicious sites.
Which suggests that, prior to R81, even though it is saying Detect, it is actually a Prevent action.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the Anti-Bot blade it's not set globally to "Detect Only" on the gateway/cluster object is it rather than According to policy?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mark,
In Activation Mode section, I selected According to policy option
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you able to share the screenshots of the threat prevention policy please? Screenshots of the profiles you have that shows which blades are activated and then from the protections section for Anti-bot. It's difficult to advise and be accurate without knowing what is currently in place around the profiles and protection configuration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Mark,
Check below screenshot for Threat Prevention policy and blades activated.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the screenshots, it does in fact look like your configuration is correct and as Jean-Francois Portmann has spotted the reply has been replaced with the DNS Trap Bogus IP which by default unless changed is. 62.0.58.94.
I would recommend populating the "Internal DNS Servers" so that the origin of actual request can be identified, so that the machine generating the traffic can be checked over.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The DNS request was not blocked but Check Point replaced the DNS reply with the DNS trap bogus IP. See sk74060.
Jean-François (Schafi)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jean,
After checked on SmartTracker, I can see the DNS Trap was Blocked but only DNS Reputation which action Detected. As on you mention on sk74060, what if I disable option on Malware DNS Trap? If Malicious DNS Query was replaced by Bogus IP, it seems to be a protection, but then, why it does not say "PREVENT" although the Confidence Level and Severity of the threat is HIGH in the log file?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Bogus Trap will replace the IP address that is returned as part of the DNS Answer in response to the original query. The DNS query itself was not blocked by instead the return value replaced. So in reality the DNS request wasn't actually prevented. I believe that based on my understanding this is how the DNS trap works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Phaneath,
DNS Reputation will ALWAYS be in DETECT mode only, this is default configuration and cannot be changed.
(as for I know after checking in various internal settings)
The first DNS query from the client will be allowed by the Firewall.
If DNS reply found to be Malicious, then CheckPoint Trap Bogus IP: 62.x.x.x will inform the Firewall.
Then subsequent packets towards that Malicious site will be PREVENT as per your policy.
.
Regards, Prabu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi! I have the same problem, my log only responds "Detected" to DNS Reputation.
Did you find any solution to this problem?
Tks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the R81 Release Notes, there is a documented behavior change related to this:
-
Log description change for DNS sinkhole trap - log is changed to Prevent instead of Detect, the Security Gateway prevents users from reaching malicious sites.
Which suggests that, prior to R81, even though it is saying Detect, it is actually a Prevent action.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Could you take a look at $FWDIR/conf/malware_config on management server? You should see there following section:
[resource_classification_mode]
dns=bg
http=policy
smb=policy
smtp=policy
Try changing "bg" to "policy" in dns line and installing the policy. I think that you should see some Prevents rolling after that
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Try looking here, check the Activation tab for each of these three categories.
--
CheckMates Break Out Sessions Speaker
CPX 2019 Las Vegas & Vienna - Tuesday@13:30
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like it works as intended to me. If you don't want to be able to identify the infected host you could try to deactivate DNS-trap in the Threat-profile settings.