Skip to main content

Checkpoint R80.10 - Upgrade using Blink Utility


The year is 2018. The war between the
Checkpoint community across the world and Checkpoint Software Technologies
Ltd. regarding the future of Checkpoint R77.30, is in full swing. The general
consensus of the Checkpoint community to extend R77.30 support timeline (from
the current May 2019) seems to be falling on deaf ears!!





In a desperate attempt to make
hay while the sun is still shining, administrators seem to be moving towards
R80.10, as soon as possible. To ease things a bit, Checkpoint has created a
"Blink" Utility. 





Here is how it works (Make sure that
you read the constraints at the bottom of this article):





You have newly ordered a Checkpoint
Security Gateway* for eg. CP 4600. It came with a default image R77.30, which
need to be upgraded to R80.10, without going through the hassles of clean
install (May be because, you do NOT want to rely on the on-site technician, or
because there is no Internet connectivity (hence no online CPUSE), or because
you just want to test this functionality, or because it's all the three!!)





Files required:





1. Download the Blink Utility here.





2. Download the Blink Security
Gateway* image here.





Actual Implementation steps:





 1. Create a new user
directory: 





[Expert@CP-GW1:0]# cd /var/log/MyDIR





2. Copy the two files in this
directory using WinSCP





3. Unzip the blink.tgz





Expert@CP-GW1:0]# tar -zxvf blink.tgz









4. Assign the execute permission to
the Blink utility:





[Expert@CP-GW1:0]# chmod -v +x blink





Execute the Blink utility by running the desired basic flow:









After the installation has finished successfully message, the gateway will reboot automatically, without any prompt. After reboot, the First Time Configuration Wizard (mini version of it) will be seen as below:









A word of caution:





1. This utility works wonders if you
are upgrading a new device, i.e. a device which doesn't have a considerable
configuration to start. 





2. It works even if you already have
a SIC established with your Security Management Server. 





3. There are several flavors of the
upgrade target versions. They can be found here.





* Security Gateway = The reason why I
have explicitly mentioned "Security Gateway" only (everywhere) is
because I haven't tested the Blink upgrade utility for Security Management
Server upgrades. As per Checkpoint, this is supported, though.





Happy Checkpoint Upgrading!!


Labels:

Comments

Post a Comment

Popular posts from this blog

Checkpoint - Exporting Objects in CSV format

Be it a Network Operations Manager, Security Architect or a Security Auditor, the people up the hierarchy always harangue the Security Engineers to compile the list of firewall objects or rules or policies or the traffic statistics and so on.. This can turn out to be quite hectic especially if there are no built in features to systematically provide the output in a "layman-readable" format. Come, Checkpoint's "Object Explorer..."  which not only provides the output in the "layman-readable" format, but also provides in-built filtering mechanisms, thereby ensuring that the Security Engineer doesn't have to rely on Google for building his scarce Microsoft Excel data filtering skills. The following screenshots will show how easy it is, with Checkpoint R80.10 to generate the firewall configuration inventory. On the SmartConsole Unified Portal, navigate to Menu >> Open Object Explorer... Select the Categories you wish to see in your output: Click o
Post a Comment
Read more

MITRE ATT&CK - Kerberos Vulnerabilities and Security

From the previous post, the summary of Kerberos authentication process is as below: For the initial authentication, the user’s client machine sends a request to the KDC  Authentication Service (AS) . The request includes details like the user’s username, and the date and time. All information except the username is encrypted using the hash of the user’s password. The KDC AS uses the username to look up its copy of the user’s password hash and uses it to decrypt the rest of the request. If the decryption is successful, that means the client used the correct password hash and the user has successfully authenticated. Once the user is authenticated, the KDC AS sends the user’s client a  ticket granting ticket   (TGT) . The TGT includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). Importantly, before sending the TGT, the KDC encrypts it using the password hash for a special account, the  KRBTGT account.  That password hash is s
2 comments
Read more

Tejas Jain - GCP Constraints & Random Facts

1.  Google Cloud Interconnect Security Cloud Interconnect does not encrypt the connection between your on-premises network and Google's network. Cloud VPN cannot be used with Dedicated Interconnect For additional security, use application-level encryption or your own VPN 2. While using Cloud CDN, the default time-to-live (TTL) for content caching is 3600 seconds = 60 mins 3. Cloud NAT sends only the translation logs and error logs to Cloud Logging service. 4. GCP Dedicated Interconnect - On Premises network device requirements:     10-Gbps circuits, single mode fiber or 100-Gbps circuits, single mode fiber     IPv4 link local addressing     LACP, even if you are using single circuit     EBGP-4 with multi-hop     802.1Q VLANs 5. While using Cloud VPN, the recommended MTU to be configured on the peer VPN  gateway = 1460 bytes 6. Each instance must have at least one network interface. The maximum number of network instances per instance is 8, depending on the instance's machine
1 comment
Read more