topic Re: FQDN objects allowing non-relevant IP addresses in R80.40 T78 in Firewall and Security Management

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

Kaspars_Zibarts — Wed, 28 Oct 2020 20:49:16 GMT

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 😱

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

Peter_Lyndley — Wed, 28 Oct 2020 21:18:19 GMT

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 ?

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

Kaspars_Zibarts — Thu, 29 Oct 2020 06:58:55 GMT

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!

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

Ilya_Yusupov — Thu, 29 Oct 2020 08:14:10 GMT

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

Thanks,

Ilya

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

_Val_ — Thu, 29 Oct 2020 08:54:59 GMT

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

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

Kaspars_Zibarts — Thu, 29 Oct 2020 09:36:41 GMT

I can confirm that workaround did the trick!

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

Peter_Lyndley — Thu, 29 Oct 2020 16:39:34 GMT

no, not yet

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

Vladimir — Thu, 29 Oct 2020 17:49:37 GMT

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

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

Kaspars_Zibarts — Fri, 30 Oct 2020 22:59:12 GMT

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

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

Meital_Natanson — Sun, 01 Nov 2020 19:52:54 GMT

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:

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

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

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

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

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

dns_data_src_enabled=0

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

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

Reboot the Security Gateway.
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)

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

Kaspars_Zibarts — Mon, 02 Nov 2020 07:41:35 GMT

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.

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

Meital_Natanson — Mon, 02 Nov 2020 15:09:20 GMT

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)

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

Kaspars_Zibarts — Wed, 04 Nov 2020 07:30:04 GMT

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!

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

Heath_H — Wed, 11 Nov 2020 14:55:32 GMT

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?

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

Kaspars_Zibarts — Wed, 11 Nov 2020 15:12:00 GMT

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.

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

Meital_Natanson — Wed, 11 Nov 2020 15:18:35 GMT

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