Domain objects (FQDN mode) vs Custom Applications/Sites

[net-harry]

Hi,

From what I understand there are (at least) two ways to restrict/allow access to specific sites with DNS names:

1. Domain objects
2. Custom applications/sites.

Please note that I am excluding sites where we could use updateable objects and also sites where we could define a static IP address (or several) to an object.

If we want to allow access only to e.g. http://www.example.com, which one is better?

I have tried to list a few pros and cons with both solutions as of my understanding (let me know if something is incorrect). There might be other aspects that also influence the choice (CPU load, SecureXL, etc.) and it would be great to hear your recommendations.

Custom applications/sites:

Pros:
Can use wild cards and regular expressions

Cons:
Requires URL Filtering or Application Control license
Only for web traffic
Can only use ports that are marked for URL filtering

Access to "invalid" IP is allowed if host header is valid for HTTP traffic. (SNI check prevents this from happening for HTTPS).

Domain objects:

Pros:
Does not require URL Filtering or Application Control license
Can be used also for sources
Can use any port number
Can be used for more than web traffic (e.g. telnet, SSH)

Cons:
Does not allow wild cards or regular expressions
Requires that client and firewall resolves DNS to the same IP address

My current thinking is that "Custom applications/sites" should be used to restrict web traffic (if URL filtering license is available) and domain objects for other protocols (telnet, SSH etc.).

Please note that we are currently running R80.20 on open servers. Some of the firewalls are running on VSX.

Thanks for your help!

Harry

[PhoneBoy]

We discussed this not too long ago.
See: https://community.checkpoint.com/t5/General-Topics/The-difference-between-checkpoint-creation-domain...

One correction: a Custom Application/Site requires an App Control OR URL Filtering license.

[net-harry]

Dear PhoneBoy,

Thanks for the information! I have updated the post to also include application control.

I was not aware of the related thread, which was very useful. I have a couple of additional questions about "Custom Applications/Sites" and I hope it is ok to ask them here:

1. Is there any performance difference between using "Application/Site", "Application/Site Group" or a Category defined for the associated application(s)/site(s)?
2. If a user creates a host file entry on a client and specifies that www.microsoft.com resolves to IP address 1.2.3.4 and then connects to http://www.microsoft.com, do I understand correctly that "Custom Applications/Sites" would not be able to block this traffic?
3. If the request is instead for https://www.microsoft.com would that also be allowed, or would the security gateway detect that the certificate on the server 1.2.3.4 for www.microsoft.com is not valid (we have Categorize HTTP websites enabled) and block the connection?
4. Could the DNS cache feature in R80.40 that you mentioned in the other thread help to mitigate the risks?

Thanks for your help!

Best regards,

Harry

[PhoneBoy]

1. If you use some sort of generic regular expression, it might be slightly slower, but in general no.

2. That is a potential downside, yes, as we're looking at the host header. However, this is where the SNI verification we have in R80.30+ is helpful for HTTPS sites because we verify the SNI out-of-band to ensure the correct site is being connected to.

3. In releases prior to R80.30, it would only work if the site is listed in the DN of the certificate presented by the site. In R80.30 with HTTPS Inspection enabled (can be just any any bypass), we can use Verified SNI to validate the site. In R80.40, Verified SNI shouldn't require HTTPS Inspection to be enabled. All of this assumes Categorize HTTPS Sites is enabled.

4. All the DNS cache does is observe DNS lookups going to known DNS servers through the gateway. It is specifically geared for Domain objects.

[net-harry]

Thanks for the information!

If I understand correctly "Custom Applications/Sites" will not prevent HTTP (unencrypted) access to a malicious IP address if the host header has a DNS name that is allowed, even if we are running R80.40. Could you please confirm that this is the case also if we are using the built-in URL filtering categories?

Also, my understanding is that we could use domain objects to block this kind of access, since the firewall itself will do the DNS lookup and only allow traffic to that IP address. An alternative way to mitigate this would be to use a web proxy in front of the firewall, since the proxy would do the DNS lookup and should thus only send the HTTP request to valid IP addresses.

Does Check Point have any other way to prevent this kind of circumvention, e.g. using IPS or anti-bot?

Thanks for your help!

Best regards,

Harry

[PhoneBoy · Accepted solution]

You are correct in that we don't currently cross-check the host header with the IP address you're connecting to.
With HTTPS, this is done by confirming the SNI with the server as stated previously.

In cases where you need to allow access to specific HTTP sites and you want to ensure they don't go to a malicious location, you could potentially pair a custom application site with a Domain Object in a rule to ensure it only goes to that location.

All of that said, once a given connection is classified, that doesn't end our analysis of it.
If IPS/Anti-Bot sees known malicious behavior or the traffic starts looking like an application that you've blocked, the traffic will still be blocked.
It just won't do it when it sees the host header in this case.
Hope that makes sense.

[net-harry]

Thanks for the confirmation and information. That makes sense. I have updated the original post to also include this limitation of Custom Applications/Sites.