- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Updatable Objects contain non-FQDN Domain obje...
- 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
Updatable Objects contain non-FQDN Domain objects?! -> can decrease performance significantly!
stumbled on this sk162577 lately about non-FQDN Domain object causing "decrease the performance of the Security Gateway significantly" ...this sent my on my quest to eleminate non-FQDN Domain Objects in my rulebase...
to get rid of non-FQDN Domain Objects i used "Updatable Objects" like:
- Check Point Services
- Microsoft Updates - HTTPS bypass
but today i found this sk90401 which gives me the command:
fw ctl multik print_bl dns_reverse_unmatched_cache
The dns_reverse_unmatched_cache table keeps the IP addresses that are not matched to any of the domain objects in the policy (the table is filled only if you have at least one non-FQDN object in the policy).
...so according to this i use non-FQDN Domain objects...
so after a bit of research i found this nice command to list the content of "Updatabel Object" in another sk161632 :
domains_tool -uo "Microsoft Updates - HTTPS bypass"
and this gives the following output:
Domains name list for 'Microsoft Updates - HTTPS bypass':
[1] tsfe.trafficshaping.dsp.mp.microsoft.com
[2] *.delivery.mp.microsoft.com
[3] *.vortex-win.data.microsoft.com
[4] login.live.com
[5] settings-win.data.microsoft.com
[6] sls.update.microsoft.com
[7] update.microsoft.com
[8] *.update.microsoft.com
...even the "Check Point Services" hat *.maas.checkpoint.com in it!!!
so to sum it up:
DO NOT USE "Updatable Objects" because they will "decrease the performance of the Security Gateway significantly" (according to sk162577
@Checkpoint: why do you use non-FQDN in "Updatable Objects" ???!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How did you measure this performance decrease ? I read that This can decrease - so it is not inevitable. And sk161612: Domain Object Enhancement - DNS Passive Learning gives other insights...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes you are right, it "can" decrease... would be nice if we can find out when this is the case... measuring the difference is not that simple in my case, a lot of work to do to eliminate the updatable objects (with non-FQDN in it)
...and up to today, i did not have a performance issue with the non-FQDN Domain objects (but i have DNS Passive Learning enabled), so hope it stays that way...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Open a informational SR# with TAC - even sk162577 suggests to refer to TAC...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello Buddy,
Can you explain how exactly "DNS passive learning" helps in a situation where there is no Reverse DNS entry for non-FQDN domain object ?
does the new custom updatable object in R81 is the generic datacenter ? and how is it different from network feed object apart from the flat option available on the last ?
thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Generic data objects allow you to block known bad IP addresses using json format. Network feed works with both combo IP/fqdn as well. As far as say indicators, thats mostly used when AV blade is enabled to block pages, similar to how you would do using combination of urlf blades and https inspection.
Kind regards,
Andy
If you need some examples, I have great lab where all this is enabled and actually working 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the Security Gateway is in the path between the client and the DNS Server (which must be explicitly configured if it is different from that which the gateway is configured to use), we can use the result of that DNS lookup to populate the cache in the gateway because…the gateway can see it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SK refers to a specific object type: Domain objects configured with a non FQDN.
These types of objects have been around since the earliest versions of Check Point and require a reverse DNS lookup (IP to name), which doesn’t usually provide an appropriate result anyway (eg if the service is hosted in AWS or similar).
This SK does not apply to our Updatable Objects, ioc_feeds, or other places where a wildcard FQDN is used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, if we use non-FQDN objects, gateway does ‘reverse DNS queries’ and ‘DNS Passive Learning’. (sk120633)
Reverse DNS queries can cause traffic latency (sk162577)
Using non-FQDN objects, is there a way to use only DNS Passive Learning and avoid revers DNS queries?
I mean, I can stop DNS passive Learning but I can’t stop reverse DNS
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't believe you can disable the reverse DNS lookups when you use non-FQDN objects.
It's how those objects are designed to work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had done this, cant even count how many times, never had a single problem.
Andy
