Check Point vSEC and securing the public/private cloud part 1

Hey everyone I wanted to talk about Check Points public/private cloud security solution called vSEC. I am going to make this a series of blog posts as the public/private cloud space is vast. So I will go through them one at a time.

The vSEC product is an exciting product that allows you to secure the East-West traffic while at the same time dynamically updating the physical gateways controlling the north-south traffic for a total holistic security solution. This allows the dynamic nature of the Software Defined Data Center (SDDC) and it’s agility and elasticity of an ever changing network that meets your needs, to apply equally to the security world. Gone are the days of non-stop change controls and a static security system that does not change without manual intervention. Now we have dynamic security in physical devices that keeps pace with dynamic virtual ones. This creates a new era in Data Center security.

Check Point vSEC leverages VMware NSX security automation for dynamic distribution and orchestration of vSEC for protecting East-West traffic. All while maintaining information sharing of the network to the physical world. If Check Point vSEC detects malware-infected VMs, it tags and automatically updates VMware NSX.

Meanwhile as the SDDC changes in location (IP’s etc) the Check Point infrastructure both virtual and physical are updated to reflect naming conventions as well IP address directly from vCENTER and the NSX controller.

I am currently working with my sales partner Jared Keesling and on occasion with Deanna Conrad. Both of which are rock star account managers here at Check Point. Together we are building a framework for the region that encompasses both security and the dynamic nature of today’s ever changing and growing network. Jared has helped build some amazing relationships in the Arizona, Las Vegas and New Mexico regions. Deanna has helped build some fantastic relationships in Education, Health Care and Government, here in this same region. Both of these superstar account managers have customers taking advantage of this great opportunity of security, automation, and elasticity of the vSEC product in their networks. I have been privileged to work with both of them as an SE.

Check Point Software realizes the importance of the virtual network both public and private cloud. In fact a recent forecast from predicted that a large portion of enterprise workloads will run in the cloud by mid-2018 either public or private.

It all adds up to an enlarged, complex and blurred attack surface for organizations, so they need a comprehensive solution to bridge security gaps and extend protections, visibility and control from data centers to the cloud in a way that works with the cloud’s elasticity and automation.

The use of cloud technologies both public and private such as VMware creates both a flexible and cost efficient landscape. However the new model of the hybrid datacenter can be more complex and requires a new approach to security. To stay ahead of threats, you need a modern security infrastructure designed for today’s dynamic networks. Check Point’s vSEC is a leap forward in security architecture, providing a modular, agile infrastructure that most importantly, is secure.

Backup your O/S Config in GAIA command line

Many people will open a command prompt in GAIA and will do a “show configuration” to see how they have their Check Point configured. They will then copy/paste that config into notepad to save for later.

However there is an easier way to do this. By using the command (From the CLISH prompt)

save configuration <filename>

The file will be placed in the home directory of the user you are logged in as.

Here is an example:

back

How to use command line for first time wizard in Check Point

I have been asked by many people how do I use the command line to get my system configured. By using another post I put on how to install my system with just a serial and Ethernet (See my post: How to install Check Point without getting on a plane) that will get the code on your box that you want.  Now using a serial connection we can get it configured using a template and a command ‘config_system‘.

Procedure:
1 ) Create the Template File:
[Expert@HostName:0]# config_system –create-template /path_to/name_of_template_file
2) Edit the template file you created- assign the desired values in the relevant fields. (See example file below)
 Note: to enable / disable IPv4 and IPv6, define the following fields:
      ipstat_v4 (manually / off)
      ipstat_v6 (manually / off)
      Starting from R80.10, these parameters have default values, but in                         older version you must configure them (manually or off).
3) save the file
4) Test to see if your file is good.
[Expert@HostName:0]# config_system –dry-run –config-file /path_to/name_of_template_file
5) Run the file
[Expert@HostName:0]# config_system -f /path_to/name_of_template_file
6) Reboot the machine to complete the configuration

Here are all the flags that you can use and what they do.

config

Example of how you edit the file using “True or False” answers:

# Mandatory parameters - change the values specific to your setup
hostname=NEW_GW
ftw_sic_key=

# Mandatory parameters - do not change
install_security_managment=false
install_security_gw=true
gateway_daip=false
install_ppak=true
gateway_cluster_member=false

Here is an example of a gateway configuration template for a cluster member ready to be connected to management. (For a single box ready for management change the line “gateway_cluster_member=true” to False)

After you use the config system command to create a template, you will have a file that looks like this(see below). Notice below what I have highlighted in BOLD.  If a cluster member is what you want make yours look like mine. Just change the fields appropriately (hostname, IPs etc…) Remember practice this first !

(To make the template see above)
#########################################################################
# #
# Products configuration #
# #
# For keys below set “true”/”false” after ‘=’ within the quotes #
#########################################################################

# Install Security Gateway.
install_security_gw=true

# Install Acceleration Blade (aka Performance Pack).
install_ppak=true

# Enable DAIP (dynamic ip) gateway.
# Should be “false” if CXL or Security Management enabled
gateway_daip=“false”

# Enable/Disable CXL.
gateway_cluster_member=true

# Install Security Management.
install_security_managment=false

# Optional parameters, only one of the parameters below can be “true”.
# If no primary of secondary specified, log server will be installed.
# Requires Security Management to be installed.
install_mgmt_primary=false
install_mgmt_secondary=false

# Provider-1 paramters
# e.g: install_mds_primary=true
# install_mds_secondary=false
# install_mlm=false
# install_mds_interface=eth0
install_mds_primary=
install_mds_secondary=
install_mlm=
install_mds_interface=

# In case of Smart1 SmartEvent appliance, choose
# Security Management only, log server will be installed automatically

#########################################################################
# #
# Products Parameters #
# #
# For keys below set value after ‘=’ #
#########################################################################

# Management administrator name
# Must be provided, if Security Management installed
mgmt_admin_name=

# Management administrator password
# Must be provided, if Security Management installed
mgmt_admin_passwd=

# Management GUI client allowed e.g. any, 1.2.3.4, 192.168.0.0/24
# Set to “any” if any host allowed to connect to managment
# Set to “range” if range of IPs allowed to connect to management
# Set to “network” if IPs from specific network allowed to connect
# to management
# Set to “this” if it’ a single IP
# Must be provided if Security Management installed
mgmt_gui_clients_radio=
#
# In case of “range”, provide the first and last IPs in dotted format
mgmt_gui_clients_first_ip_field=
mgmt_gui_clients_last_ip_field=
#
# In case of “network”, provide IP in dotted format and netmask length
# in range 0-32
mgmt_gui_clients_ip_field=
mgmt_gui_clients_subnet_field=
#
# In case of a single IP
mgmt_gui_clients_hostname=
# Secure Internal Communication key, e.g. “aaaa”
# Must be provided, if primary Security Management not installed
ftw_sic_key=sweet

#########################################################################
# #
# Operating System configuration – optional section #
# #
# For keys below set value after ‘=’ #
#########################################################################

# Password (hash) of user admin.
# To get hash of admin password from configured system:
# dbget passwd:admin:passwd
# OR
# grep admin /etc/shadow | cut -d: -f2
#
# IMPORTANT! In order to preserve the literal value of each character
# in hash, inclose hash string within the quotes.
# e.g admin_hash=’put_here_your_hash_string’
#
# Optional parameter
admin_hash=”

# Interface name, optional parameter
iface=eth0

# Management interface IP in dotted format (e.g. 1.2.3.4),
# management interface mask length (in range 0-32, e,g 24 ) and
# default gateway.
# Pay attention, that if you run first time configuration remotely
# and you change IP, in order to maintain the connection,
# an old IP address will be retained as a secondary IP address.
# This secondary IP address can be delete later.
# Your session will be disconnected after first time condiguration
# process.
# Optional prameter, requires “iface” to be specified
# IPv6 address format: 0000:1111:2222:3333:4444:5555:6666:7777
# ipstat_v4 manually/off
ipstat_v4=manually
ipaddr_v4=192.168.10.10
masklen_v4=24
default_gw_v4=192.168.10.1

ipstat_v6=off
ipaddr_v6=
masklen_v6=
default_gw_v6=

# Host Name e.g host123, optional parameter
hostname=pocgw

# Domain Name e.g. checkpoint.com, optional parameter
domainname=

# Time Zone in format Area/Region (e.g America/New_York or Etc/GMT-5)
# Pay attention that GMT offset should be in classic UTC notation:
# GMT-5 is 5 hours behind UTC (i.e. west to Greenwich)
# Inclose time zone string within the quotes.
# Optional parameter
timezone=’Americas/Arizona

# NTP servers
# NTP parameters are optional
ntp_primary=192.168.10.5
ntp_primary_version=
ntp_secondary=
ntp_secondary_version=

# DNS – IP address of primary, secondary, tertiary DNS servers
# DNS parameters are optional.
primary=198.6.1.2
secondary=
tertiary=

See sk69701 for more information.

How does Amazon Web Service Work??

I wanted to tell everyone about a blog post written by Nick Matthews that describes in depth how all the connectivity works in AWS. Nick defines the terms used by Amazon, and what they mean. In his blog he uses some great network diagrams to help explain how it all fits together.

Check it out here:

https://aws.amazon.com/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-one/

https://aws.amazon.com/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-two/

There is also a 45 minute video on YouTube that walks through the AWS network presentation:

Did you know??? Check Point vSEC is a family of products that delivers advanced threat prevention security to public, private and hybrid cloud and software-defined data center environments. Easily and affordably, extend security to your Amazon cloud using rapid one-click deployment of the vSEC gateway which is available in the AWS Marketplace. Policy management is simplified with centralized configuration and monitoring of cloud and on premise security from a single console.

You can read more about vSEC here: http://www.checkpoint.com/products-solutions/private-public-cloud/index.html

 

How to update CPUSE from the command line.

My friend  and fellow SE (William Garner) had a condition where he needed to do a CPUSE update from the command line, which he did and he wrote up a procedure on how to do it.  By luck of the draw I ran into a situation where CPUSE needed to be updated as well.  So I thought I would post this simple and effective procedure on how to do it.

Important to Note:  If you are updating from build 839 and above continue with steps below, if not refer to sk106696.

Download the package. Download package at sk92449 (Section 3-A)

Transfer the package to machine into /some_path_to_updated_DA/ directory.

UnPack the package:

[Expert@HostName]# cd /some_path_to_updated_DA/
[Expert@HostName]# tar -zxvf DeploymentAgent_<build>.tgz

Install the Deployment Agent RPM (the currently running Deployment Agent will be stopped automatically):

[Expert@HostName]# rpm -Uhv – -force CPda-00-00.i386.rpm

Start the Deployment Agent:

[Expert@HostName]# $DADIR/bin/dastart

 

How to know what Jumbo Hotfix is installed on your Check Point device

I have been asked ‘how do you see what Jumbo HF you are currently on’. There is a simple command you can run from your device to tell you. If you are running R77 with at least Take 38 do this:

Short answer:
As Expert type: installed_jumbo_take –n

This should return with a simple number like 128. That means you are on Jumbo Hotfix accumulator 128.
If no argument is specified ( -n above), then the command will print:RXX.XX Jumbo Hotfix Accumulator take_N is installed, see skXXXXX”.

Long Answer:
For Take 38 and above

The same command applies to Jumbo that was installed using Gaia CPUSE and using Legacy CLI.

[Expert@HostName:0]# installed_jumbo_take [-n | -h]

If no argument is specified, then the command will print: “RXX.XX Jumbo Hotfix Accumulator take_N is installed, see skXXXXX”.
If “-n” argument is specified, then the command will print only the number of the Take (value “0” means that a reference to the Jumbo Hotfix Accumulator was not found in Check Point registry).
If “-h” argument is specified, then the command will print the usage help.

On VSX Gateway, this command must be run from the context of VS0 (run “vsenv” command).

For Take 37 and lower

If Jumbo Hotfix Accumulator was installed using Gaia CPUSE:

[Expert@HostName]# $CPDIR/bin/cpprod_util CPPROD_GetValue “CPUpdates/6.0/BUNDLE_GULLI_HF_BASE_008” SU_Build_Take 0

If Jumbo Hotfix Accumulator was installed using Legacy CLI:

[Expert@HostName]# $CPDIR/bin/cpprod_util CPPROD_GetValue “Check Point Mini Suite/setup/GULLI_HF_BASE_008” Take 0

How to install Check Point remotely without getting on a plane

So I had someone recently want to do a fresh install of a current production box. They wanted to go from an older version to a newer one. The gateway was currently plugged in and running and they had console access to it.

However, the box was on the other side of the country from where they were, and there was no one remotely at the location to help. They didn’t want to get on a plane, so what do they do ???

No worries. This is what you do:

First we need to re-run the First Time Configuration Wizard again
1. Login to Expert mode:

# expert
2. Delete the special file:

[Expert@HostName]# rm -i /etc/.wizard_accepted

3. Reboot the appliance to apply the changes (not required for Gaia OS):

[Expert@HostName]# reboot

4. Important Note: If this machine was configured as Security Management Server, and user will reconfigure the machine to be only the Security Gateway, then the following files must be removed from the machine (otherwise, intermittent SIC issues (e.g., ‘SIC error no. 147’) will arise during policy installation onto this Security Gateway):

[Expert@HostName]# rm -i $FWDIR/conf/ICA.crl
[Expert@HostName]# rm -i $FWDIR/conf/InternalCA.*

5. Next time user logs into the Gaia Portal, the First Time Configuration Wizard start automatically.

Note: The credentials for Gaia Portal are not reset to the default.

Now that we can get back into the Wizard:  

You are prompted for installation choose “Install a Version from the Check Point Cloud” and do the following:

1. In the First Time Configuration Wizard, select Install a version from Check Point Cloud. Click Next.

deploy1

2. Define the Connection to Check Point Cloud. Choose an interface to connect to the Internet, and configure connection parameters.

deploy2

Click Next. This shows the versions that you can install from the Check Point Cloud.

deploy4
3. Choose the version to install. Click Finish.
Then after installation is done, it will be back with the install set to 192.168.1.1 connect to it with your console and in the GAIA clish you will need to change it to the IP address that you wish it to be, add your routing as well, then connect to it and run the first time wizard.

(ex. set interface Mgmt ipv4-address 10.200.200.60 mask-length 24 )
(ex. set static-route default nexthop gateway address 10.200.200.1 on )

Now you will be up and running with the new O/S and you did not have to have anyone help, nor did you have to get on a plane 🙂

R80 eXchange Point! Share your scripts !

This is a great new feature that Check Point has brought us. It is called the eXchange Point. What is that you ask? The eXchange Point is where users can go to have discussions as well as join the open API community.

Go to: https://community.checkpoint.com/welcome

r80-share

The open API community allows you to share scripts for the R80 code with other community members. Our policy can be created now with the GUI, command line, or just write a custom script to do it for you !

OR…

Don’t write a script at all, maybe someone already has one, check out the code library, maybe someone already has done it!

r80-devel

 

 

 

 

 

Using tcpdump for basic network troubleshooting through a security device.

Want to see if traffic is going through a gateway device? Here are some basic network troubleshooting tips on how you can validate that traffic is flowing through a security gateway and actually getting onto the wire.

Scenario one:

Sometimes the log says accept but maybe the traffic isn’t actually leaving the box.

Scenario two:

How about when you need to ‘prove’ to a network admin that traffic is in fact flowing, because they all believe it is the security gateway.

Answer: tcpdump

Most network people accept tcpdump as being an authority. By using tcpdump on both the incoming and outgoing interfaces you can answer either of those scenarios. Login to the box with ssh in two separate windows and run a tcpdump for the same traffic on both the incoming and outgoing interface.
As an example run a tcpdump on the interface where the connection comes from (internal) with the host IP of the device attempting to make the connection. Do this same tcpdump on the interface that the connection is to leave out of (external)

For instance you would see:

SYN (from Client) – Enters Internal Interface — SYN (from Client) Exits External Interface to Server or destination.

Or

ICMP Echo Request (From Client) – Enters Internal Interface — ICMP Echo Request (from Client) Exits External interface to Server or destination.
Whether or not you see the SYN-ACK or the ICMP Echo Reply come back the other way will be solely dependent on the server or network at that point. I used to use this quite a bit when needing to “prove” it is not the security gateway.

You will have to adjust for NAT if you are using it in this scenario however it all still applies.

How to setup the tcpdump (assuming you are ssh’d to the security gateway and in expert mode):

Session 1: Traffic entering internal interface:

tcpdump –n -i [interface name] host <IP of host>  (ex… tcpdump –n –i eth0 host 10.1.1.1 ) or preferably be more specific with your source/destination  (tcpdump –n –i eth0 host 10.1.1.1 and host 192.168.1.1)

Session 2: Traffic exiting external interface:

tcpdump –n -i [interface name] host <IP of host>  (ex… tcpdump –n –i eth1 host 10.1.1.1 ) or preferably be more specific with your source/destination  (tcpdump –n –i eth1 host 10.1.1.1 and host 192.168.1.1)
You can obviously get more and more granular with tcpdump however this is a good starting point.
Here are some examples if you want to run some generic tcpdumps or you want to filter certain things, and then put it in a pcap format.

Session 1:

tcpdump -nnei [interface] not port 22 and not port 18192 and not port 67 and not port 18190 and not port 137 -w /var/log/tmp/external.cap

Session 2:

tcpdump -nnei [interface] not port 22 and not port 18192 and not port 67 and not port 18190 and not port 137 -w /var/log/tmp/internal.cap
Have fun. 

Backup Scenarios

I have had people ask me about my other backup post about the types of backups you can do. Everyone wants to know “when” should they do a specific type of backup. Well I took this right from sk105385

BACKUP

Backup files are taken on a regular basis, and it is recommended to always perform a backup before performing an upgrade. A backup creates a compressed file that contains the Check Point configuration including the networking and operating system parameters, such as routing and interface configuration etc., but unlike a snapshot, it does not include the drivers.

A backup, unlike a snapshot, can be restored on the same or a different appliance running the same Check Point version and hotfixes, but the backup file contains the MAC addresses of the original appliance, on which it was taken, and these MAC addresses will be restored as well.

Before restoring a backup to replacement hardware, the original MAC addresses on the replacement hardware should be recorded. After restoring the backup on the new machine, the MAC addresses should be changed back to the original (recorded) MAC addresses. In Gaia this can be done via the WebUI, For SecurePlatform please contact Check Point Support for assistance with this.

To migrate the configuration between a replacement SecurePlatform appliance or a replacement Gaia appliance, instead of restoring a backup on a replacement appliance, it is recommended to use the migrate export and migrate import tools or the upgrade_export and upgrade_import tools found in $FWDIR/bin/upgrade_tools/.

SNAPSHOT

Snapshots are typically performed when the appliance was first installed and in a maintenance window before performing a major upgrade. A snapshot creates a file that contains a binary image of the entire root (lv_current) disk partition. This includes all of the operating system and various Check Point software files, such as specific drivers.
The log partition is not included in the snapshot, so any locally stored Firewall logs will not be saved.
Snapshots are appliance-specific and can only be restored on the same hardware.

migrate export / upgrade_export

The migrate export (Pre-R75) or upgrade_export (R75 and later) utility backs up all Check Point configurations independent of hardware, OS, or version, but does not include OS information. This utility may be used to backup management server configurations and is intended for upgrades or migration of database information to new systems with hardware changes, BUT will not work when downgrading to an earlier version.

It is recommended to perform an export at least every month or more often, depending on how frequently changes are made in the policy or network. It is also highly recommended before upgrading or migrating to a new version. Does not cause interruption of the services so it can be performed anytime outside a maintenance window.

References:

sk105385