Updatable Objects with akamai IPs

[hcfds_]

Greetings everyone,

Long time lurker, first time participant here.

I had a recent issue in a costumer with updatable objects. Basically, a site that should not be allowed, was accessible through a UO rule.

The site in question is www.ford.pt, and was being matched by two updatable objects: Check Point Services on rule base and Office365 Worldwide Services on HTTPS Inspection (bypass rule).

www.ford.pt resolves to two akamai IPs:

Non-authoritative answer:
Name: e24220.dscx.akamaiedge.net
Addresses: 2a02:26f0:7900::172f:bd3a
2a02:26f0:7900::172f:bc78
23.47.189.145
23.47.189.160
Aliases: www.ford.pt
www.ford.pt.edgekey.net

Using domain_tools we were able to see that 23.47.189.145 matched office365 FQDNs and cws.checkpoint.com

Given IP address: 23.47.189.145 |
---------------------------------------------------------------------------------------------------
| Domain name | FQDN |
---------------------------------------------------------------------------------------------------
| office.net | no |
| office365.com | no |
| r3.res.office365.com | yes |
| r1.res.office365.com | yes |
| r4.res.office365.com | yes |
| cws.checkpoint.com | yes |
| www.bing.com | yes |
| akamaiedge.net | no |

Which we can confirm:

Name: e31055.dscd.akamaiedge.net
Addresses: ...
23.47.189.155
23.47.189.145
Aliases: cws.checkpoint.com
cws-31055.checkpoint.com.edgekey.net

Name: e40491.dscd.akamaiedge.net
Addresses: ...
23.47.189.145
23.47.189.147
...
Aliases: r1.res.office365.com
wildcard.res.office365.com.edgekey.net

In sk131852 is stated that the domains are resolved to IPs, and these are the ones used: "The updatable object can be used in Access Control policy's source and destination columns and is matched on SYN packet according to IP only (the domains are resolved to IPs)."

This ends up allowing unintended access, specially when using CDNs like Akamai. What would be the best strategies to handle this?

In this specific case we are talking about machines that should not have any internet access except to some pre-defined destinations, but have Harmony Endpoint installed and need to access the necessary services for updates and signatures. We are looking into creating a supernode to handle this problem, but we use several UO in different rules and the problem might arise in other machines.

[PhoneBoy]

CDNs serve multiple customers, and as such, this is expected.
Additional inspection would be required (App Control with a Custom Application/Site, possibly full HTTPS Inspection) would be required to ensure only the specified domains were accessed on that CDN.

[hcfds_]

In this instance it matched a HTTPSi bypass rule created for Office 365 apps, as the IP was in both UO. But even if that didn't happen, it would still be allowed because the rule matches by resolved IP of the UO included domains.

I was trying to avoid creating a Custom App / Site with all the required URLs for Harmony Endpoint, but eventually we'll need to do that. As i understand it, even with supernode the endpoints need to communicate with Check Point services (but perhaps with less URLs).

The problem is worst in O365, as the list is huge and very dynamic. 

In the perfect scenario the Updatable Objects would be matched by domain, and not by IP. Is there any thoughts in doing this? Or some limitation that prevents it?

[PhoneBoy]

Updatable Objects are ultimately built on IP addresses provided by the application provider, not based on DNS names.
Network Feed objects (R81.20 and above) support DNS names, which means you could create your own list and keep it updated with minimal effort.

[hcfds_]

Thank you PhoneBoy, i didn't know about Network Feed Objects, this might help.

I think my question regarding UO, is that they are composed by domain names, and then resolved to IPs and matched by IP. Is there a reason why they aren't matched by DNS?

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

Domains name list for 'Check Point Services':

[1] maas-mgmt-connect-tunnels-service-ap-2.ap.portal.checkpoint.com

[2] resolver5.chkp.ctmail.com

[3] dnl-11.geo.kaspersky.com

[4] us-spark-activation.iaas.checkpoint.com

[5] crl.globalsign.com

[6] cloudinfra-gw.uk.portal.checkpoint.com

[7] smp-beta.checkpoint.com

...

I'm considering a "stupid" approach to bypass this problem, and keeping the lists up to date without manual intervention: creating a script that uses domain_tools to query the relevant Updatable Objects on the gateway, and populates the files on an external server used by Network Feed. But it seems a bit obtuse to use a list on a external server that is fed by objects that already exist in the gateway just to force it to match by domain instead of IP address.

Am I looking at this correctly? Or is there something I'm missing?

[PhoneBoy]

It's called TCP/IP for a reason: communication ultimately happens over IP.
Which means every DNS name ultimately gets turned into an IP...every single one.
That includes DNS names in a Network Feed. 
DNS is also cached in numerous places and the resolution is not always done at the time the communication takes place.
So blocking purely based on, say, a DNS lookup, is not foolproof. 
It's also not possible without full HTTPS Inspection to see if a connection to a specific IP is going to a desirable application or not (which itself might break the application).

[hcfds_]

So, Network Feed will also be resolved and matched by IP?

I understand that for this type of match we would need to check the server name in the handshake, and in some instances it would require HTTPSi. It would be interesting if we could use UO as Application / Service, matching by domain instead of resolved IP. Naturally it couldn't be used in all situations, as you mentioned some application don't work with HTTPSi, but it could be very helpful.

[PhoneBoy]

I double checked this with R&D owners and: yes, the FQDNs in Network Feed objects are turned into IPs.
This makes sense since Network Feed objects can be used without any NGFW/NGTX features enabled.
There are a couple of methods we use to keep Network Feed and Domain objects up to date, including:

• Periodic DNS Requests from the gateway (every minute, results cached for an hour)
• DNS Passive Learning (see sk161612)
• Reverse DNS Lookup (only applies to non-FQDN Domain Objects)

If you want to make sure that communication to a specific IP address is only accessing a specific application and not another application that happens to use the same IP, you would need to leverage a Custom Application/Site object (and likely HTTPS Inspection).

[the_rock]

There is something built in...

Andy