Domain object allow other URL as well

[jond3rd]

Hi,

We have configured a non-FQDN domain object for a well known cloud provider (let's call it cloudprovider.net)

the domain object I've created looks something like .cloudprovider.net.

There is another site that is NOT in the access rule that somehow resolves to an IP belong to cloudprovider.net (let's call that othersite.com).

For some reason, firewall allows the traffic to othersite.com as well. Is it because the IP belongs to a domain that is allowed in the access rule? Does that mean that any URLs or sites that uses an IP belonging to cloudprovided.net will be allowed?

This is pretty much the output when I try to ping othersite.com

[Expert@myfw:0]# ping othersite.com
PING othersite.com (1.2.3.4) 56(84) bytes of data.
64 bytes from server-4-3-2-1.abc56.xy.cloudprovider.net (1.2.3.4): icmp_seq=1 ttl=240 time=10.7 ms
64 bytes from server-4-3-2-1.abc56.xy.cloudprovider.net (1.2.3.4): icmp_seq=2 ttl=240 time=10.3 ms
64 bytes from server-4-3-2-1.abc56.xy.cloudprovider.net (1.2.3.4): icmp_seq=3 ttl=240 time=10.3 ms
64 bytes from server-4-3-2-1.abc56.xy.cloudprovider.net (1.2.3.4): icmp_seq=4 ttl=240 time=10.3 ms

I know that I can just create a rule and block othersite.com but I was hoping the clean-up rule will take care of that and that there's a more decent solution to this situation.

[Chris_Atkinson]

Yes 'Domain' and 'Site' objects work differently, this is likely expected based on your current approach.

[jond3rd]

Hi Chris,

Thanks a lot for responding.

I think I am not clear on my post, sorry for that.

I didn't configure a 'Site' object. What I mean by 'Site' is another URL or internet site that is not configured in the firewall rule nor have any object created. It's just a web address that's been accessed via a browser.

My expectation is, the traffic to othersite.com will be dropped since there's no rule that specifically allow such traffic

[Chris_Atkinson]

Is the object you created in the "Destination" or "Services & Applications" column of the policy ?

[jond3rd]

Hi Chris,

It's in the Destination.

[Chris_Atkinson]

This will be translated to IP addresses, hence the behavior seen.

[jond3rd]

Hi Chris,

I know that it will be resolved to an IP address and will use it to process traffic, but wouldn't the firewall  check the host part of the URL first if there's a domain object created for it?

[Chris_Atkinson]

This is what URL Filtering is for, Domain objects also cater for other protocols where such checks aren't possible.

[the_rock]

I would say domain objects are mostly used when customers dont want to use urlf blade, and if fqdn is checked inside domain object, then it will ONLY resolve that fqdn, nothing else. If that option is unchecked, then I believe it resolves up to 10 sub-domains,

Maybe not the best example I am giving here, but you get an idea...so say domain object shows .*google.com and fqdn is unchecked, then it would probably resolve all of below (just an educated guess, but you get an idea)

news.google.com

photos.google.com

mail.google.com

and so on

Andy

[jond3rd]

Hi the_rock,

Thanks for responding.

I know how FQDN and non-FQDN domain object works.

if I have a destination .google.com in my rule and I access youtube.com via my browser, is it expected to be allowed since the IP of youtube.com belongs to google as well?

[the_rock]

Thats a good question...Im not 100% sure, so would review the logs and see if that rule allows it, because if yes, then it would certainly make sense.

Andy

[jond3rd]

Hi the_rock / Andy,

I have checked the logs and yes, access to othersite.com is allowed by the same rule where .cloudprovider.net domain object is the destination.

I have this assumption that it will not be allowed, but I guess I'm wrong.

Probably it's something that Check Point developers needs to work on.

[Bob_Zimmerman]

It depends on reverse DNS. In the specific case of YouTube, .google.com would not actually match it. Apparently, .1e100.net would:

➜  ~ dig +short youtube.com | xargs -L 1 -I % sh -c "echo %;dig +noall +answer -x %"
142.250.138.136
136.138.250.142.in-addr.arpa. 2770 IN	PTR	rw-in-f136.1e100.net.
142.250.138.91
91.138.250.142.in-addr.arpa. 2228 IN	PTR	rw-in-f91.1e100.net.
142.250.138.190
190.138.250.142.in-addr.arpa. 2336 IN	PTR	rw-in-f190.1e100.net.
142.250.138.93
93.138.250.142.in-addr.arpa. 3600 IN	PTR	rw-in-f93.1e100.net.

[jond3rd]

Hi Bob,

Apparently, *.google.com also returns similar DNS record pattern and since they will return the same reverse lookup result, it is very likely that both *.google.com and *.youtube.com will be allowed if you use a non-FQDN domain object. 

The same goes for domain *.blogger.com which apparently owned by Google as well. Check Point may need to re-visit how they treat and process non-FQDN domain objects.

I know that non-FQDN domain object should be the last option, but again for some, this is the ONLY option.

google.com.		25	IN	A	142.250.9.113
google.com.		25	IN	A	142.250.9.138
google.com.		25	IN	A	142.250.9.139
google.com.		25	IN	A	142.250.9.102
google.com.		25	IN	A	142.250.9.101
google.com.		25	IN	A	142.250.9.100

[_Val_]

Non-FQDN object should not be used, it is extremely bad for performance. Also, it is considered to have a star before the domain name, in your case, *.cloudprovider.net, and it does reverse lookup, so if an IP belonging to another domain shows as abc56.xy.cloudprovider.net in the reverse IP lookout, it will be allowed.

With that said, what you see is working as expected. 

[the_rock]

I heard lots of people say its bad for performance, but I know customer who uses them constantly and they say works amazing, never an issue with performance or anything else. Good point about the IP and another domain, thats definitely the case.

Cheers,

Andy

[jond3rd]

Hi Val,

This is exactly what I was thinking, it's because of the reverse lookup that was returned, seems defeating the purpose of just filtering out specific domains though. Not sure if Check Point has a plan to address this behavior though.

I agree, that non-FQDN must be the last option and  I can definitely see some performance degradation, but for some who don't have URLf blades, this seems to be the only option for them.

[PhoneBoy]

If you don't have App Control or URL Filtering, you are correct: Domain objects are the only way.
There are Network Feed objects in R81.20, but even there the domains are changed to IP addresses.

[the_rock]

That makes sense, its definitely reverse lookup that would make those other sites work.