best practices for blocking URLs in a scenario where resources have different URLs but the same IP

[Oliver_222]

Please tell me the best practices for blocking URLs in a scenario where two resources have different URLs but the same IP.
The problem is that we block a malicious resource using a domain object in the access rules, but we see in the logs that this rule also blocks a legitimate resource.

Thank you

[Chris_Atkinson]

Is the URL filtering blade licensed / used for this gateway?

This works differently than your current approach (DNS objects in FW blade).

[Oliver_222]

Yes, the URL Filtering blade is enabled and licensed

[Lesley]

In case of 443, the fw will need to be able to see the cn in certificate or do full https inspection. 

Based on this you can create domain based object and the firewall will resolve it for you. 

Make sure you have correct blades: url filtering and enable either categorize https or full https inspection. 

[Oliver_222]

Blade is enabled.
Its settings have fail-close mode.
Also enabled checkboxes: Categorize HTTPS websites, Enforce safe search on search engines, Categorize cached pages and translated pages in search engines.
Added http, https, HTTPS_proxy, HTTP_proxy.

[the_rock]

Not sure how its configured under blades, but in my case, I always set it like below for url filtering:

fail mode -> block

categorization -> background

same for https inspection (under manage and settings -> blades)

Btw, just tested your scenario, works fine for me, no issues.

Andy

[Oliver_222]

Can you tell me how you tested it?
Did you enable HTTPS inspection and set the "Domains" object to ".cdn.stepik.net" in the allow rule and ".minboth.click" in the deny rule below?
I also want to mention that you should open the "stepik.org" website to see the redirect to cdn.stepik.net, which is blocked as minboth.click on CheckPoint.

[the_rock]

Yep, thats it. I wish I took a video or screenshot, apologies. My colleague is currently modifying our lab, since he has to put in more powerful firewall, so I cant access it at the moment, but thats the gist of it and yes, ssl inspection is on.

Andy

[the_rock]

Can you give an example? I can test it in my https inspection lab.

Andy

[Chris_Atkinson]

I'm not sure that's needed it appears simply about how DNS objects function, they are resolved to IPs.

URL filtering works differently by comparison.

[the_rock]

Right, thats true, I just wanted to see if I can simulate it in the lab.

Andy

[Oliver_222]

minboth[.]click is a domain that is blocked by an access rule.

cdn.stepik.net is a legitimate resource with the same IP that should not be blocked, but it is blocked in our environment.

[the_rock]

Is https inspection enabled?

[Chris_Atkinson]

Can you share how that rule looks are you using the destination or services column?

[Oliver_222]

We use the "Destination" column, which contains an object of the "Domains" type.

[Chris_Atkinson]

You will likely need to switch to using URL filtering rather than Domain objects.

At a minimum you could try a URL filtering rule / Layer above your current rule with the domain object to allow sites that you don't want blocked by it but this may not be fool proof.

[PhoneBoy]

Is your firewall in the path between clients and the DNS server they use?
If so, you might want to implement DNS Trap.
With Anti-Virus/Anti-Bot and DNS Trap configured, the malicious domain will resolve to the DNS Trap IP instead, which should be a harmless IP (the default IP provided is).

[Oliver_222]

Yes, user requests to the DNS go through CheckPoint.
We thought about this option.
How should we configure the DNS Trap so that we can specify which URLs are malicious and which are safe? If I'm not mistaken, CheckPoint determines this itself.

[the_rock]

Just MAKE SURE to NOT configure dns trap to any IP address used anywhere in the network.

Andy

[PhoneBoy]

DNS Trap is a Threat Prevention feature.
Domains already flagged as malicious ones in ThreatCloud will be rewritten to the DNS Trap IP.
You can create exceptions in your Threat Prevention policy using Custom Application/Site objects.
"Inactive" means allow, "Prevent" means block.