Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Kaspars_Zibarts
Employee Employee
Employee

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

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:

image.png

And my test rule confirms that the "real" IP and "fake" IPs are accepted by the rule:

2020-10-28_21-27-17.jpg

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 😱

 

15 Replies
Peter_Lyndley
Advisor
Advisor

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
Employee Employee
Employee

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!

2020-10-29_7-46-54.jpg

 

0 Kudos
Ilya_Yusupov
Employee
Employee

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

 

Thanks,

Ilya 

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

I can confirm that workaround did the trick! 

 

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Peter_Lyndley
Advisor
Advisor

no, not yet

0 Kudos
Vladimir
Champion
Champion

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

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

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

Meital_Natanson
Employee
Employee

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
Employee Employee
Employee

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.

 

0 Kudos
Meital_Natanson
Employee
Employee

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
0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

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_H
Contributor

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?

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

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.

0 Kudos
Meital_Natanson
Employee
Employee

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events