Downloading CPUSE updates outside of Check Point Cloud

[JozkoMrkvicka]

Hello all,

Not all companies are allowed to have internet access for their managements and gateways. With internet access, installing the latest Jumbo or even upgrade to Major releases is just one command. What just comes to my mind is the idea that CPUSE can be used in case there is no internet access, but you can choose whether use internet or some internal IP address where will be stored all needed packages.

Something like 2 new CPUSE commands:
1. set installer source internet
2. set installer source local <IP_ADDRESS>

In case admin would like to use a local repository, CPUSE will connect to the server over https and download packages from there.

I am fully aware that a similar idea is already created by Central Deployment Tool (CDT) or using SmartUpdate.
What is even better is to use dedicated API and later UI like was mentioned by @Dorit_Dor.

[PhoneBoy]

Everything that's released via CPUSE also appears in SecureKnowledge and can be downloaded.
It's possible to upload/import these packages to a local system.

Obviously, that's not quite as easy/simple as having an internal CPUSE server.
Would make for an interesting RFE.

[Chris_Atkinson]

Out of interest are the same gateways already leveraging Private ThreatCloud for AV/AB updates in this environment or some other approach?

[JozkoMrkvicka]

No.

I am just thinking aloud here 😄
What would be an even better idea is to have a single machine which will have internet access and can download and serve all needed packages for internal managements and hosts.

Example:
I will deploy 1 VM which will have 2 interfaces - one WAN (Internet) and second LAN (internal).
This VM can connect via WAN interface to Check Point CPUSE download servers and download all needed packages which can be then served over LAN interface for all internal stuff.
All internal managements and gateways can configure the source of all CPUSE packages as that VM, over LAN interface. No need to have internet access for all management and gateway, just 1 VM will have internet access.

[Chris_Atkinson]

Addressing these types of requirements was part of the vision of "Private ThreatCloud" deployments, please discuss with your local SE for the latest information if it's of interest.

[Martin_Valenta]

This challenge i've simply resolved by having linux server where i download packages from CP and then just gateways via curl_cli download package and import it to CPUSE.

[G_W_Albrecht]

Yes, that is just a simple approach that makes sense. In smaller environments, a PC with local and internet access, Putty and WinSCP will do the same trick. Although the proposed two new commands seem simple, a local server for CPUSE packages (all currently available, including all flavors of large BLINK files) does to really...

[JozkoMrkvicka]

In case we need to install some hotfix on many gateways, we will download package from internet to our workstation, then using WinSCP to copy package to our jumpserver (GAIA based) and from there download/upload needed package to GWs using scp command.

Idea to use linux server is not bad. Can you share syntax for curl_cli ?

[Martin_Valenta]

Something like this:
with auth header:
curl_cli -k -O -H "Authorization: Basic xxxxxxxx<hash>xxxxxxx" https://10.223.227.31/cpstuff/Check_Point_R80_20_JUMBO_HF_Bundle_T87_sk137592_FULL.tgz
with password prompt for username:
curl_cli -k -O -u <userID> https://10.223.227.31/cpstuff/Check_Point_R80_20_JUMBO_HF_Bundle_T87_sk137592_FULL.tgz

without any auth:
curl_cli -k -O https://10.223.227.31/cpstuff/Check_Point_R80_20_JUMBO_HF_Bundle_T87_sk137592_FULL.tgz

[Tsahi_Etziony]

@JozkoMrkvicka - thanks for the interesting suggestion. We completely understand the need to have a fully functioning CPUSE even in environments where GWs are not connected to the outside world. 

It is quite complicated to add these commands to CPUSE and have CPUSE connect to a different file storage, because CPUSE does not use the Check Point cloud as a simple file storage, and there is a protocol that is used to control which packages are offered to which machine. 

One option is indeed PTC, but I think this might be an overkill for this simple use case. another option is to use CDT to push the relevant packages to CPUSE, or manually ask CPUSE to import the relevant packages. 

You wrote "What is even better is to use dedicated API and later UI like was mentioned by @Dorit_Dor.", and this is exactly where we are heading. Indeed we are about to release central deployment capabilities that will be available from Smart Console and hopefully will make your experience a lot simpler. The first phase will require both the management server and the GW to be connected to the cloud, but our road map focuses on more isolated environments - we will add a repository to the management, and also allow the management to serve as a proxy for the GWs' Deployment Agent (CPUSE). 

But I will also check if we can use the development of the management repository and allow any file storage repositories like you suggested, and then we will be able to add these commands. 

[JozkoMrkvicka]

Thank you @Tsahi_Etziony for your response and feedback !

Looking forward to seeing some improvements in CPUSE area 🙂