- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
16 | |
11 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY