CP Cloud IP range for CPUSE outbound ruleset

[Jerry]

hi mates, really quick one

have you got any clue (I guess some of you does) what would be more "narrowed" ip range for CP Clould CPUSE uses

I obviously found whois data about 194.29.32.0/20 but my Customer would like to narrow it even more specifically.

So far I found 194.29.39.27 constantly being queried by their MDS. Is there any way to narrow those ranges in order to rise request for the destination network used for CPUSE from either MDS or gateways within the infra?

Thanks in advance

--jerry--

[_Val_]

This IP belongs to Check Point autonomous range, but there is no guarantee it will not change in the future. The best shot in tackling it would be to script DNS resolution of the IP and feed it to the object once a day or so.

However, I do not understand the challenge here. This is a certificate based TLS connection from a trusted device to vendor controlled resource. Did you even disable implied rules with this customer?

[Jerry]

Thanks Valeri,

answering your last question - not I did not. Implied rules are in place just Customer wants to control "outbound" connectivity for its SMS Management HA by making the CPUSE rule allowing certain range for updates thats all. I do understand this is about tls-based controlled connection to the vendor cloud secure environment however, thw whole story is about very specific and restricted area where every packet "outbound" need to be controlled and inspected hence such little kind of paranoid approach (not my idea seriously)  

Cheers

[_Val_]

Thanks, now it is more clear. With R80.10 you can use FQDN in the allow rules on the FW, so you do not even need to have a script, actually. 

[Jerry]

fqdn with what host then ? what would you suggest if it comes to the CPUSE updates heading off to IL ranges ?  

[_Val_]

See below, there is another case for all FQDNs you need. However, neither of those is resolving to Israel, at least not from Switzerland where I am based. That is weird.

[Vladimir]

Valeri,

It may not be resolving to Israel due to use of the Akamai CDN by Check Point.

[_Val_]

I am not sure I understand what you are trying to say. The topic starter mentioned, that in his case he is able to provide CPUSE functionality for internal MGMT resources by opening access to a single IP address belonging to Check Point. That is strange, because none of the FQDNs required for CPUSE to function is resoling to this particular address.

It might be that different regions are resolving to different addresses. It is however unlikely that CH and UK are getting different IPs and by far weird one of those IPs belongs to Check Point IP space and not to Akamai itself.

[Vladimir]

I am referring to your post listing  ".deploy.static.akamaitechnologies.com" as one of the destinations. 

[Jerry]

also bear in mind I do know very well the very famous sk83520 so I'm very much aware about the update resources from the vendor

just wanted to offer customer little bit of peace of mind having narrowed a ruleset to control updates via CPUSE from their SMS HA boxes (seeing 1000s of attempts every day just like this one):

Time:                   2018-07-20T08:24:55Z
Interface Direction:    inbound
Interface Name:         Mgmt
Connection Direction:   External
Id:                     8e4192e6-0000-00c0-5b51-9c57..................
Id Generated By Indexer:false
First:                  true
Sequencenum:            49
Source:                 x.x.x.x
Source Port:            51663
Destination:            194.29.39.27
Destination Port:       443
IP Protocol:            6
Action:                 Accept
Type:                   Connection
Policy Name:            blablabla
Policy Management:      FW-X
Db Tag:                 {4487300A-4E2B-1A46-B153-3A...................}
Policy Date:            2018-07-20T08:18:28Z
Blade:                  Firewall
Origin:                 FW-X
Service:                TCP/443
Product Family:         Access
Logid:                  0
Access Rule Name:       CPUSE
Access Rule Number:     3
Rule UID:               44466533-2748-43e2-82ba-.................
Layer Name:             blablabla
Interface:              Mgmt
Description:            https Traffic Accepted from x.x.x.xto 194.29.39.27

Thanks for any hints/help anyway, always apprecaited  

[_Val_]

All domains you need to allow are listed in here

They are

• .updates.checkpoint.com
• .updates.g01.checkpoint.com
• .gwevents.checkpoint.com
• .gwevents.us.checkpoint.com
• .deploy.static.akamaitechnologies.com

As you can see, it is more than just one address. And neither one is resolving to one you have listed above