FQDN objects allowing non-relevant IP addresses in R80.40 T78

[Kaspars_Zibarts]

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 😱

[Peter_Lyndley]

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 ?

[Kaspars_Zibarts]

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!

[Ilya_Yusupov]

Just updating the thread that we took it offline with @Kaspars_Zibarts  and we will update the thread once we identify RCA.

Thanks,

Ilya 

[Kaspars_Zibarts]

I can confirm that workaround did the trick! 

[_Val_]

@Peter_Lyndley do you have a TAC case open for this?

[Peter_Lyndley]

no, not yet

[Vladimir]

Aren't those "unexpected" IPs simply CDN's distribution points?

[Kaspars_Zibarts]

I have given my word to R&D not to tell. Before they have had official answer. But not CDN. 🙂 

[Meital_Natanson]

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:

1. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not already exit):

[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf

1. Edit the $FWDIR/boot/modules/fwkern.conf file in vi editor:

[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf

1. Add the following line (spaces and comments are not allowed):

dns_data_src_enabled=0

1. Save the changes and exit from Vi editor.
2. Check the contents of the $FWDIR/boot/modules/fwkern.conf file:

[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf

1. Reboot the Security Gateway.
2. Verify that the new value was set:

[Expert@HostName]# fw ctl get int dns_data_src_enabled

Do the same for the second member as well.

Thanks,
Meital (meitalna@checkpoint.com)

[Kaspars_Zibarts]

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.

[Meital_Natanson]

Hi @Kaspars_Zibarts 

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).

Regarding what is the impact on O365 updatable object if the feature will be off, I'll explain with an example:

One of the domains O365 object contains is *.manage.office.com domain.
When this feature is enabled, the GW is able to match domains like XXX.manage.office.com to O365 updatable object.

If the feature is off, such sub-domains may not be matched to O365 updatable object and it may cause few pages to not be loaded properly.

If there are more questions I would love to schedule a call to answer everything 😊

Thanks,
Meital (meitalna@checkpoint.com) 

[Kaspars_Zibarts]

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!

[Heath_Hendricks]

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?

[Kaspars_Zibarts]

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.

[Meital_Natanson]

Hi @Heath_Hendricks ,

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