Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
jond3rd
Explorer

Domain object allow other URL as well

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.

 

 

0 Kudos
18 Replies
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
jond3rd
Explorer

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
jond3rd
Explorer

Hi Chris,

 

It's in the Destination.

 

 

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
jond3rd
Explorer

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?

 

 

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
the_rock
Legend
Legend

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

0 Kudos
jond3rd
Explorer

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?

 

 

 

 

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
jond3rd
Explorer

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.

 

 

 

0 Kudos
Bob_Zimmerman
Authority
Authority

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.
0 Kudos
jond3rd
Explorer

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
0 Kudos
_Val_
Admin
Admin

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

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

0 Kudos
jond3rd
Explorer

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.

 

0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events