Supports HTTPS Inspection and Domain object.

[Hllrdm]

Hello. 

I am testing HTTPS Inspection work with Domain Object work. I created a test rule for .checkpoint.com and set the Action to Bypass.
But I found that the ssl certificate is spoofed for all Check Point resources except for the checkpoint.com home page. For example, for usercenter.checkpoint.com, the certificate is swapped for the certificate we import in the Security Gateway settings.

Can you please help me how I can put domain objects in bypass mode. And is this functionality supported by Check Point?

Check Point version R81.10

Output: enhanced_ssl_inspection = 1

 

[_Val_]

For FQDN, this is a full name, not a wildcard for multiple subdomains. Create another Domain object fro usercenter.checkpoint.com, and also for www.checkpoint.com

[Hllrdm]

How do we inspect the entire .checkpoint.com domain?
If we remove the flag on the FQDN, are all sites (usercenter.checkpoint.com, help.checkpoint.com) inspected except checkpoint.com?
Or does CheckPoint not provide for bypass of the entire domain and you have to create a domain group and explicitly specify the nodes that are not inspected there?

[Hllrdm]

For example, I added two more objects -- .accounts.checkpoint.com and .usercenter.checkpoint.com and they have the FQDN flag enabled. They stopped being inspected.
For .checkpoint.com I turned off the FQDN, so I assumed that checkpoint treated it as a domain and hel.checkpoint.com would not be inspected, but I found that the certificate for hel.checkpoint.com was also spoofed. Could you help us solve this problem?

 

[_Val_]

Never ever remove FQDN mark, it will kill performance on your FW. Basically you need to list all sites. There is a finite number of those 🙂

[Tobias_Moritz]

@_Val_  I totally agree to the "never ever remove FQDN mark", because of CP is falling back to do reverse DNS lookup again (in some topologies, passive DNS learning may help).

But I always wondered what CP gateway does when trying to match an updateable object with wildcard domains in it. Do you know it?

Here is an example from updateable object "Webex Services":

# domains_tool -uo "Webex Services"

Domain tool looking for domains for 'Webex Services' and its children objects:

Domains name list for 'Webex Services':

[1] *.cisco.com
[2] cme-linuscmesquaredafram-035-afram-admin.wbx2.com
[3] cme-linuscmewdfw2wdfw2-027-wdfw2-public.wbx2.com
[4] mln1mcccl01.webex.com
[5] bottomlinetechnologies.webex.com
[6] *.walkme.com
[7] cme-linuscmewdfw2wdfw2-481-wdfw2-public.wbx2.com
[8] 0a4f0f5de2ab23da1a6b-0ebfd742e5f97efaf8e29d5671af2106.r94.cf1.rackcdn.com
[9] *.webex.com
[10] temas.s3.amazonaws.com
...

If it does fall back to old reverse DNS lookup, customers will get the performance penalty for that without even knowing it (because they may not think about how these objects work).

If it just ignores these entries, I guess it does not work as expected.

I really must have something missing here in my head. Anyone can help me out?

[Patrick_Taphorn]

Great Question @Tobias_Moritz!   I've had the same thoughts concerning Updateable Objects and how Checkpoint would handle the wildcard domains in those objects.   Looking forward to a response from Checkpoint folks.

[_Val_]

Look one comment above 🙂

[_Val_]

Updatable objects are pre-populated on GWs by different means (either CP own list or vendor list of IPs is used for various cases), but they are not using reverse DNS lookup.

[Tobias_Moritz]

Thank you very much for this relieving answer, Val. 🙂

Is it too greedy to ask if you can eleborate further? Is there any way we can see the actual list on gateway which is used for matching of updatable objects (as it cannot be the list of domains_tool -uo because of your answer)?

I love transparency because this can be very helpful during debugging sessions. And usually, Check Point is very transparent in how they implement stuff, so that guys like Tim or Heiko e.g. can write nice guides around it 🙂

[_Val_]

Mostly, we rely on distribution lists provided by relevant vendors. Those lists and URLs for them are listed in sk131852. For Webex specifically, the list is published and updated on the daily basis. It consists of IP ranges and associated domain names. 

GWs do not get those lists directly from Webex, though. All UO are populated though Check Point own cloud services: updates.checkpoint.com and dl3.checkpoint.com. 

In case of FQDN domain objects, GW resolves those in advance with the help of WSDNSD. 

To check IPs and domain names, you can use domains_tool -ip <ip address> & domains_tool -d <domain name> commands.

Bottom line, there is no reverse DNS lookup for either FQDN domain objects or Updatable objects, ever. 

There is no magic, just tech 🙂

[_Val_]

Also, other than main "static" check point sites, you can also use updatable objects (sk131852) for all Check Point cloud entities listed in sk83520