- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
I'm not too sure if it is also relevant to non-VSX gateways but if you are running R80.40 and using FQDN I would suggest to check it straight away
Say I created a rule that uses FQDN as a destination that should resolve to one IP only:
updates.checkpoint.com - 104.121.238.27
But domains_tools show me 20(!) extra IP addresses associated with this FQDN:
And my test rule confirms that the "real" IP and "fake" IPs are accepted by the rule:
So basically we have no trust in any of FQDN based rules right now in R80.40 - it can be open to anything!
Really worried now as I checked some other FQDN objects and they were even worse with 50+ IPs associated with them instead of 1 😱
Interesting - we've seen inconsistent results with 2 firewalls (non-VSX) running R80.40 JHF78 and FQDN. Same policy - different outcome !!
One where the application control correctly drops the traffic to an FQDN domain object, the other allows it through.
One gateway is resolving one IP for the FQDN, the other is resolving two IPs , same DNS server(s) configured in the same order on Gaia.
Anyone from TAC care to comment ?
Just tried on newly built non-VSX gateway in the lab with one FQDN objec only and this bug might allow connecting to gateway itself on 0.0.0.0 not only some random additional public IPs!
Just updating the thread that we took it offline with @Kaspars_Zibarts and we will update the thread once we identify RCA.
Thanks,
Ilya
I can confirm that workaround did the trick!
@Peter_Lyndley do you have a TAC case open for this?
no, not yet
Aren't those "unexpected" IPs simply CDN's distribution points?
I have given my word to R&D not to tell. Before they have had official answer. But not CDN. 🙂
Hi,
I'm Meital Natanson, R&D Group Manager at Check Point.
My group is the R&D responsible for Domain objects.
In order to improve non-FQDN domains matching and updatable objects matching, we introduced ‘DNS Passive Learning’ feature in R80.40 and R80.30 JHF T196 and above (sk161612).
This means that the GW “listens” to DNS traffic that pass through the GW which is destined to predefined DNS servers in order to learn non-FQDN domains and their IP resolving for better and accurate matching.
The feature is enabled only when DNS servers are properly configured on the GW and non-FQDN objects (or specific updatable objects) are used in the policy.
What you described above is because with this feature enabled, we keep the DNS resolved IP and its additional records for the queried domain.
This is the current behavior and we plan to publish a change in the upcoming weeks.
Meanwhile, you can disable the feature by either changing the policy by not using non-FQDN (if this is an option) or disabling it on the GW with the following commands:
[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf
[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf
dns_data_src_enabled=0
[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf
[Expert@HostName]# fw ctl get int dns_data_src_enabled
Do the same for the second member as well.
Thanks,
Meital (meitalna@checkpoint.com)
Thanks alot @Meital_Natanson for detailed description! It really helps as I feel much better when I can explain faults 🙂
Quick question though we were on Take 219 on R80.30 before upgrade and did not experiance any issues. Not too sure if that's important info for you guys?
Additionally would turing off DPL cause any issues to O365 Updatable object? We did not have any non-FQDN objects so I suspect that "fault" was somehow triggerred by O365 UO.
In R80.30 JHF this feature is selectively enabled while in R80.40 it's enabled to all (depends on the rulebase configuration of course).
O365 updatable objects is one of the updatable objects that use this feature because it contains both IPs and Domains (as appears in MS feed).
You are making me nervous @Meital_Natanson 🙂 You are basically implying that CP updatable object might not fully match MS O365 requirements for subdomains (domains that are specified with a wildcard, i.e *.manage.office.com)
I'll send you an email, we can take this offline for now!
So just to try and understand impact a little more:
1) A gateway running R80.10 isn't impacted, correct?
2) If I don't use Updatable objects, and only use FQDN domain objects (FQDN box is checked), is there an impact on R80.40 irrespective of the setting?
When will this setting be editable via the policy vs. having to manually edit the kernel configuration on each gateway? Especially seeing as the default setting for R80.40 gateways could significantly reduce the security of the gateway when using domain or updateable objects.
Is this actually being fixed, or is the fix just to disable the feature at this time and render use of updatable objects less than ideal?
I guess @Meital_Natanson is the best to answer but R80.10 is not affected - passive DNS was introduced after R80.30 T196.
I believe if you don't use Updatable Objects, you should be OK. That was my understanding at least.
Hi @Heath_H ,
1) Correct. In pre R80.30 GWs, passive DNS learning feature doesn't exist hence issue is not relevant.
2) No. The issue may happen only when using specific updatable objects or non-FQDN domain objects.
The fix will be released in the incoming JHF releases of R80.30, R80.40 and R81 - the fix handles the additional records properly and not disabling the whole feature.
Thanks,
Meital
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY