VMware Hands-on Labs - HOL-1824-01-NET


Lab Overview - HOL-1824-01-NET - VMware NSX and Checkpoint vSEC

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You can use the Table of Contents to access any module of your choosing.  Each module is designed to be independent, allowing you start from any module.  However if this is your first time taking this lab, it is highly suggested to start from the first module and progress foward.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

IMPORTANT NOTE: When you first begin the lab, be sure to check the Lab Status indication on the Main Console. If Lab Status shows READY, start the lab. If the Lab Status shows FAILED, then end the lab and start a new lab.

Regarding Screen Resolution: Main Console screen resolution is set for 1024x768. The VMware Learning Platform will automatically scale the desktop based on the available screen real estate in the your web browser, and can further adjust as you resize the console window.

Lab Abstract:  Data centers are adopting virtualized and cloud environments to gain operational flexibility and lower operational costs. These changes have led to a dramatic increase in network traffic going east-west, or laterally within the data center. However, when it comes to security, the focus has been on protecting the perimeter, and there are few controls to secure east-west traffic inside the data center. This presents a critical security risk where threats can traverse unimpeded once inside the data center. Furthermore, traditional security approaches to this problem are unable to keep pace with the dynamic network changes and rapid provisioning of applications in a virtualized environment.

NSX Distributed Firewall (DFW) provides basic L2-L4 distributed firewall services. The
Check Point vSEC integration empowers you with advanced security services and L5-L7
support to include: IPS, Application Control and URL Filtering, Identity Awareness, Anti-
Virus, Anti-Bot, and Threat Emulation. Additionally, Check Point Security Management
enables you to seamlessly manage both your enterprise Check Point physical gateways and
virtual appliances.

Check Point vSEC empowers you with Security as a Workload within the SDDC – now your advanced security protections seamlessly keep pace with rapid deployment and provisioning of your applications.

Lab Module List:

Take this module to navigate Check Point vSEC components and NSX integration in a pre configured lab environment. Learn the capabilities delivered with vSEC and NSX, explore the vSEC components, and where traffic is redirected to vSEC.

Take this module to learn the power of dynamic security policy in the SDDC. Learn how NSX Security Group objects are updated with vSEC and then utilized in the Check Point security policy.

Gain hands-on experience using Check Point vSEC Anti-Bot engine to detect, contain, and quarantine application VMs using NSX security group tagging.  With AV alone, bot infections are typically undetected exposing the SDDC to serious
risk.

 Lab Captains:

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Check Point Introduction, Configuration (30 minutes) (Basic)

Introduction


IMPORTANT NOTE: When you first begin the lab, be sure to check the Lab Status indication on the Main Console. If the Lab Status shows READY, start the lab. If the Lab Status shows FAILED, then end the lab and start a new lab.  Please feel free to ask for assistance at anytime.

This module contains the following lessons:

In this module, you will learn about the capabilities delivered with Check Point vSEC integration with VMware NSX Manager and vCenter. You will be armed with new skills regarding the Check Point vSEC components and managing vSEC; where to look within NSX Manager to identify the vSEC integration components; how threats like bot detection along with security policies are configured, monitored, and reported on within Check Point.

After taking this module, you will gain confidence regarding vSEC and the integration with VMware vCenter and NSX Manager. You will also understand the methodology in which traffic is redirected to vSEC.

HOL Lab Notes: This HOL Check Point partner lab environment has been prepared and the following configuration steps have already been completed:

1. VMware vCenter Server and NSX Manager are deployed.

2. vSphere Data Center, Cluster, and Data Center objects are configured.

3. The ESXi hosts in the cluster have the Agent VM configured.

4. vCenter runtime settings are properly configured.

5. NSX Manager is installed on the appropriate clusters.

6. IP address pool to be used for the vSEC Gateways has been created.

7. Check Point R80.10 Security Management Server is deployed.

8. The vSEC Security Gateway Service is configured and the vSEC Controller is registered to vCenter and NSX Manager respectively.

9. The vSEC Cluster object is defined.

10. vSEC Security Gateway instances are assigned as Cluster Members.

11. Best Practice: VMware tools are installed on each VM.

12. Best Practice: Spoof Guard is enabled for the port group.

Environmental Components:


Exploring the VMWare Environment


This lesson involves basic navigating around NSX Manager and vCenter to identify where the relevant features are configured. Previous knowledge of NSX Manager and vCenter are helpful! The goal here is to familiarize yourself with the various integration components in VMware.


 

Opening vSphere Web Client

 

In the Main Console desktop, launch Chrome from:

  1. The Chrome shortcut in the Taskbar or
  2. The Chrome icon on the Desktop

 

 

Navigate to the Home Screen

 

 

  1. Now click on the Home control button at the top of the vSphere Web Client.

The Home control button is great helper for getting back to the top level view in vSphere WebClient.

 

 

 

Consuming vSEC through Service Composer

How does it work?

To truly perceive the effectiveness, efficiency, and elegance of complementary security services delivered to the SDDC by Check Point vSEC integration with NSX Manager, it is important to understand the method in which traffic is redirected from NSX Distributed Firewall to Check Point vSEC Gateway service.

Three VMware NSX components are involved:

NSX Service Composer is the VMware component that enables vSEC Gateway service to be available to a set of vCenter objects.

NSX Service Composer is where NSX Security Groups are created and managed.

NSX Security Groups are sets of vCenter objects such as clusters, virtual machines, vNICs, and logical switches. Distributed Firewall Policy (DFW) rules.

The DFW security policy is mapped to Security Groups to be redirected to vSEC, and traffic redirection rules are created on the vSEC service profile.

Let's navigate to NSX Service Composer.

 

 

NSX Manager Security Groups

 

From the Home drop down:

  1. Select Networking & Security

 

 

Create A Security Group

 

Let's create a Security Group.

  1. Click on the New Security Group icon to create a new Security Group.  This will start the Security Group Wizard.

 

 

 

Edit an Existing Security Group

 

There will be many occasions where we need to change the properties of a Security Group.  Let's practice on our App_Group Security Group.

  1. Highlight the App_Group Security Group we just created.
  2. Click the Edit Security Group icon.

 

Introduction to Check Point vSEC components


This lesson involves touring the Check Point vSEC Components

Using Check Point SmartDashboard, you will connect to Check Point Security Management Server, and go through steps to retrieve dynamic SDDC Data Center objects from vCenter and Security Groups from NSX Manager

What's new with Check Point vSEC? First, you will want to understand Check Point vSEC with VMware NSX involves two key components:

  1. The vSEC Controller, which is an extension to the Check Point Security Management Server (R80 and above) and perform integration between Check Point SMS and VMware vCenter / NSX Manager.
  2. Check Point vSEC Gateway (security gateway service), which inspects traffic and enforces security policy at the hypervisor level.

 

Check Point R80.10 Smart Console

 

From the Main Console desktop.  

  1. Double Click the SmartConsole R80.10 icon to launch the Check Point SmartConsole. SmartConsole is the GUI used to manage global enterprise security policy and physical and virtual security gateway enforcement points.

Note:  If the vSphere Web Client is still open, minimize this first.

 

 

Check Point R80.10 SmartLog

 

From within Check Point SmartConsole on the left side.

  1. Click the LOGS & MONITOR icon.

This is the GUI console used to view security logs in real time.

 

 

Data Center Object for vCenter

 

  1. On the left side navigation, Click back on the Security Policies

 

Dynamic Enforcement


This lesson shows how to import resources from vCenter and NSX into the Check Point Security Policy and explain how to view them in the logs.


 

Check Point R80.10 Smart Console

 

From the Main Console desktop.  

  1. Double Click the SmartConsole R80.10 icon to launch the Check Point SmartConsole. SmartConsole is the GUI used to manage global enterprise security policy and physical and virtual security gateway enforcement points.

Note:  If the vSphere Web Client is still open, minimize this first.

 

 

Creating A New Rule

 

First we will create new rule (Rule #2)

  1. Highlight rule #1
  2. Click on the Add rule below button.

 

 

Navigate to Chrome browser

 

  1. Minimize the Check Point Smart Console screen.
  2. Open Chrome browser from the Windows shortcut bar at the bottom of the Main Console.

 

 

Open Test Web page

 

  1. Open a new tab in Chrome.
  2. Click on WebSRV-Test bookmark
  3. Verify that traffic to the web server is working.

 

 

Maximize Smart Console

 

  1. Click on the Smart Console icon in the taskbar.

 

Conclusion


After taking this module, you have gained confidence regarding VMware vCenter, VMware NSX, Check Point vSEC, vSEC components, and integration with VMware vCenter and NSX Manager.

Good work!

Please continue to the next module OR end your lab.


 

You've finished Module 1

Congratulations on completing Module 1!

If you are looking for additional information on Securing the SDDC with Check Point vSEC and NSX, try one of these links:

Proceed to any module below which interests you most. 

Take this module to learn the power of dynamic security policy in the SDDC. Learn how NSX Security Group objects are updated with vSEC and then utilized in the Check Point security policy.

Take this module to solve the problem of detecting, containing, and quarantining application VMs that have been bot compromised. Check Point vSEC Anti-Bot engine to detect, contain, and isolate application VMs in the SDDC that have become compromised by bot infections seeking to control the VM. Key learnings in this module involve understanding the methodology of bot detection and quarantine of the infected VM through Check Point vSEC and predefined security policy for containment and isolation of bot infected VMs, and notification of the security event in SmartLog and to security tagging the infected machine within NSX Manager.

Gain hands-on experience using Check Point vSEC Anti-Bot engine to detect, contain, and quarantine application VMs using NSX security group tagging.

With AV alone, bot infections are typically undetected exposing the SDDC to serious risk.

 

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 2 - Dynamic Policy Application with NSX Objects , vSEC Integration Components and Processes (30 minutes) (Intermediate)

Introduction


IMPORTANT NOTE: When you first begin the lab, be sure to check the Lab Status indication on the Main Console. If the Lab Status shows READY, start the lab. If the Lab Status shows FAILED, then end the lab and start a new lab. Please feel free to ask for assistance at anytime.

This module contains the following lessons:

In this module, you will learn how to solve the problem of protecting East-West traffic in the SDDC against lateral threats. This lesson you will teach you how Check Point vSEC supports dynamic security policy enforcement for the SDDC.  When dynamic data center object changes, these changes are updated in real time and automatically.  There is no need to make manual changes or push security policy to the vSEC Gateways.  

Specific tasks that you will accomplish in this module:

After taking this module, you will have new confidence regarding the way dynamic objects are updated, understand the granularity in managing SDDC dynamic objects, and grasp the significance relating to the ease of SDDC dynamic objects being automatically updated within the security policy -- with dynamic objects, there is no need to manage changing IP addresses or push security policy changes.

HOL Lab Notes: This HOL Check Point partner lab environment has been prepared and the following configuration steps have already been completed:

1. VMware vCenter Server and NSX Manager are deployed.

2. vSphere Data Center, Cluster, and Data Center objects are configured.

3. The ESXi hosts in the cluster have the Agent VM configured.

4. vCenter runtime settings are properly configured.

5. NSX Manager is installed on the appropriate clusters.

6. IP address pool to be used for the vSEC Gateways has been created.

7. Check Point R77.30 Security Management Server is deployed.

8. The vSEC Security Gateway Service is configured and the vSEC Controller is registered to vCenter and NSX Manager respectively.

9. The vSEC Cluster object is defined.

10. vSEC Security Gateway instances are assigned as Cluster Members.

11. Best Practice: VMware tools are installed on each VM.

12. Best Practice: Spoof Guard is enabled for the port group.

Environmental Components:


Security Policy Inclusion


In this lesson you will learn how Check Point vSEC supports dynamic security policy enforcement for the SDDC. When dynamic data center object changes, these changes are updated in real time and automatically. There is no need to make manual changes or push security policy to the vSEC Gateways.


 

Dynamic SDDC Changes - IP Address

It is important for you to see how dynamic objects helps with operational efficiency in the SDDC. The SDDC is dynamic environment where VMs spin up, go to sleep, change IP address, etc.  

To demonstrate how vSEC integration with NSX provides dynamic security policy, you will change the IP address on the web server (WebSRV) and verify:

  1. The WebSRV VM still inherits the security policy of the Web Security Group without a security policy push
  2. The change IP address is updated automatically within Identity Awareness, which you will see in the logs.

In the next steps, you will open a console connection to WebSRV and change the IP address of the web server.

 

 

Login To vSphere Web Client

 

In the Main Console desktop, launch Chrome from:

  1. The Chrome shortcut in the Taskbar or
  2. The Chrome icon on the Desktop

 

Login into the vSphere Web Client.  The vSphere Web Client should be the default home page.

  1. Enter Username administrator@corp.local
  2. Enter Password VMware1!
  3. Click Login

Note: The username and password should be defaulted.

 

 

Open a SSH connection to the WebSRV

 

On the desktop of the Main Console machine

  1. Click the Putty session icon WebSRV-192.168.120.51

Note:  You should automatically be logged on, however if you need to login in manually please use the following credentials:

Username: Root

Password: VMware1!

 

 

Connecting into the Check Point SmartConsole

 

From the Main Console desktop, Double Click the SmartConsole R80.10 icon to launch the Check Point SmartConsole. SmartConsole is the GUI used to manage global enterprise security policy and physical and virtual security gateway enforcement points.

 

 

Change the WebSRV IP address

 

Return back to the Putty session and run command:  

  1. ./change_ip.sh

Note: You will lose connectivity to that server after you run this command.

 

 

Review logs on the Check Point Graphical User Interface

 

Now go back to the SmartConsole (Hint: It should be minimized in the Windows tray).  On the left side navigation bar:

  1. Click on the LOGS & MONITOR.

In the logs, view the previous connection in the logs:

 

 

Revert to the original web server IP

 

The next step is to return to the first IP.  In the same Putty session (Hint: It should be minimized in the Windows tray), run command:

  1. ./revert_ip.sh

You will lose connectivity to that session, minimize this Putty session.

You understand that IP address changes are automatically updated with the vSEC integration with NSX. The web server is a member of the Web_Group Security Group in NSX and the dynamic object in Check Point Security Management utilized in the security policy for the Web_Group is updated automatically, in real time, without the need for policy push or any manual intervention.

 

 

Review configuration on the vSphere Web Client

 

Lets review why the connection has failed.  Revert back to the vSphere Web Client (Hint: Chrome browser).

  1. Select Networking & Security
  2. Click on Service Composer
  3. Select the Web_Group, virtual machines number = 0
  4. Right click Web_Group and select Edit Security Group

 

 

Revert the name of the Server

 

  1. Return via the Home icon on the top of the page.  

 

Understanding vSEC Integration Components and Flows


In this lesson you will learn more about the Check Point vSEC with VMware NSX integration, how it works, vSEC traffic flow, helpful to know daemons, files, and databases.


 

vSEC Controller and vSEC Gateway Service Virtual Machine (SVM)

Check Point vSEC Controller - The Security Management Server / Multi-Domain Security Management Server capable of managing Check Point vSEC Gateways. Makes the Check Point Security Management Server dynamically data center aware with VMware NSX and VMware vCenter Server integration. This lets vSEC Controller make dynamic security policies, manage vSEC Gateways and physical gateways, and provides complete visibility for data center security. vSEC is based on the VMware Network Extensibility (NetX) API.

Check Point vSEC Gateway - The Service Virtual Machine (SVM) in the VMware virtual environment. Inspects all traffic that goes to, from, or inside the protected Security Group. It leverages the VMware NSX API for traffic redirection and inspection, securing traffic between virtual machines across the virtual network without altering the network topology. Secures data center traffic between virtual machines across the virtual network.  vSEC Gateway is deployed on each VMware ESXi cluster member and integrated into VMware NSX.

Check Point vSEC Cluster - Two or more vSEC Gateways synchronized for High Availability or Load Sharing.

Check Point vSEC Service Manager - vSEC component. Deploys and manages the service communication between Check Point products and the VMware NSX through VMware REST API.

 

 

vSEC Under the Hood

 

vSEC Gateway inspects all traffic that is directed to and from, or within the protected Security Group  (NSX Security Group).

Components:

  1. VMware ESX host includes multiple ESXi hosts in an ESXi cluster make the physical infrastructure.
  2. VMware NSX Manager defines Security Groups and redirection policy.  From VMware NSX Manager, vSEC Controller learns Security Groups.
  3. VMware vCenter Server manages ESXi hosts.  From VMware vCenter, vSEC Controller learns vCenter inventory: VMs, ESX/ESXi Clusters, vApps, Resource Pool, Data Centers, Hosts, and Cluster Folder.
  4. Check Point vSEC Gateway Service VM inspects traffic between VMs in the Security Group, and traffic coming in and going out of the Security Group.
  5. Inspected Virtual Machines.
  6. Protected Security Groups are collections of objects from the vSphere inventory, protected by NSX.
  7. SDDC core includes switching and routing infrastructure of the SDDC.
  8. Check Point Physical Security Gateway is supported for North-South physical appliance for inspection and enforcement.
  9. Check Point vSEC Controller is the Software-Defined Data Center (SDDC) aware Check Point Security Management Server.  vSEC Controller works with one (1) VMware NSX manager and one (1) VMware vCenter Server.  

Notes:  

 

 

vSEC Specific Daemons and Files

 

  1. SmartDashboard (on SmartConsole Client) connects to FWM daemon on vSEC Controller.
  2. FWM daemon connects to CMS_PROXY daemon.
  3. CMS_PROXY daemon connects to VMware NSX / vCenter:
  1. VMware objects are manually added by the administrator to rules.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Controller.
  2. FWM daemon installs the policy on the vSEC Gateway.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Gateway.  Relevant kernel tables are updated on vSEC Gateway.
  3. On vSEC Controller, FWCLOUD daemon "asks" the CMS_PROXY daemon (web service request) to fetch all involved VMware objects from VMware NSX / vCenter every 30 seconds (default).  Note: Check Point log is generated only if this connection fails.  CMS_PROXY daemon parses the XML file (maps VMware objects and their IP addresses) and sends the relevant information to FWCLOUD daemon.  Note: There are no logs or history for which objects were fetched.  VMware objects are saved as virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Controller.
  4. vSEC Controller decides if the $FWDIR/database/virtual_objects.db file on vSEC Gateway has to be updated:

 

 

Walk Through vSEC Traffic Flow

Traffic Flow in ESX/ESXi server with deployed vSEC Gateway.

  1. Packet is generated on VM #1 to be sent to VM #2.
  2. Packet is intercepted by VMware DFW.
  3. According to the configured VMware redirection policy, the packet is redirected to the vSEC Gateway for inspection.
  4. Packet appears in the shared memory of VMware dvfilterklib library.
  5. Secure Network Dispatcher (SND) thread within the FWK daemon gets a notification using the NetX API about the packet sent to the vSEC Gateway.
  6. Packet is sent to the global CoreXL FW instance by the SND, and a decision function is called to decide which CoreXL FW instance should handle this packet according to the 5-tuple (Source_IP, Source_Port, Dest_IP, Dest_Port, Proto).
  7. Packet is inspected by the selected CoreXL FW instance.
  8. Packet is accelerated by SecureXL, if acceleration is possible/needed.
  9. SND thread thread within the FWK daemon thread within the FWK daemon gets a notification using the NetX API that a packet needs to be sent out of the vSEC Gateway.
  10. Packet appears in the shared memory of VMware dvfilterklib library.
  11. Packet continues down its original path from VM #1 to VM #2.
  12. When packet arrives at VM #2, it is redirected to the vSEC Gateway for inspection.

Helpful Notes:  

If traffic is redirected to the vSEC Gateway, without any policies configured on the vSEC Gateway, then the traffic will pass according to Failure Policy that was defined by the vSEC administrator:

 

 

vSEC Databases

vSEC Gateway

vSEC Controller

 

 

vSEC Gateway Logs

vSEC Gateway logs are based on the Identity Awareness infrastructure.  In R77.30 vSEC Gateway, Identity Awareness must be enabled to see any traffic logs.  With vSEC Gateway, the Identity Awareness is included.

Check Point log for matched rule will show the Name of Check Point Data Center Group (name of virtual object).  

Log example:

 

vSEC Processes in Depth


This lesson provides you will valuable insight regarding the main Check Point vSEC Controller processes.  This will allow you to understand what system level processes are running, how they are executed, and what they do. 

The goal here is to arm you with additional knowledge that will help you gain deeper knowledge around.  This could aid in optimization, customization, troubleshooting, integraton by knowing: critical processes, what each process does, process interactions, check whether process is running, along with some basic level debugging and the relevant log file to be investigated.

Important source information for this lesson comes from the Check Point Advanced Technical Resource Guide vSEC for VMware NSX (ATRG: vSEC for VMware NSX), solution ID sk111060.  All credit goes to the authors of this ATRG.  

For brevity sake in this lab, only the most essential information is provided within this module.  To obtain the full ATRG: vSEC for VMware NSX, solution ID sk111060, please visit Check Point's Secure Knowledge Base.

For extended details regarding all of Check Point processes, please refer to Check Point Secure Knowledge article, solution ID sk97638, titled Check Point Processes and Daemons.  


 

vSEC Controller Process FWM

What does FWM do?

Useful Information:

  1. Path: $FWDIR/bin/fwm
  2. Log file location: $FWDIR/log/fwm.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWM -path "$FWDIR/bin/fw" -command "fw kill fwm"
  2. To Start: [Expert@HostName:0]# cpwd_admin start -name FWM -path "$FWDIR/bin/fwm" -command "fwm"
  3. Stat Process: [Expert@HostName:0]# cpwd_admin list  
  4. Stat Process: [Expert@HostName:0]#  ps auxw

Notes:

 

 

vSEC Controller Process CMS_PROXY

What does CMS_PROXY do?  

Useful Information:

  1. Path: $FWDIR/jre/bin/java loads files from $FWDIR/lib/Arcus/
  2. Log file location: $FWDIR/log/cloud_proxy.elg

Commands:

  1. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  2. To Start: [Expert@HostName:0]# arcus_proxy_start

Notes:

 

 

vSEC Controller Process FWCLOUD

What does FWCLOUD do?

Useful Information:

  1. Path: $FWDIR/bin/fwcloud
  2. Log file: $FWDIR/log/fwcloud.elg

Commands:

  1. To see the current poll time: [Expert@HostName:0]# cpd_sched_config print
  2. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  3. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWCLOUD
  4. To Start:[Expert@HostName:0]# arcus_proxy_start
  5. On Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLOUD -path $FWDIR/bin/arcus_proxy_start -command "arcus_proxy_start"
  6. On Multi-Domain Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLOUD -path $MDS_TEMPLATE/bin/arcus_proxy_start -command "arcus_proxy_start"

Notes:

 

 

vSEC Controller Process FWCLTAG

What does FWCLTAG do?

Useful Information:

  1. Path: $FWDIR/jre/bin/java loads files from $FWDIR/lib/Arcus/
  2. Log file: $FWDIR/log/cloud_tagger.elg

Commands:

  1. To Stop: [Expert@HostName:0]# arcus_proxy_stop
  2. To Stop: [Expert@HostName:0]# cpwd_admin stop -name FWCLTAG
  3. To Start: [Expert@HostName:0]# arcus_tagger_start
  4. To Start on Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLTAG -path $FWDIR/bin/arcus_tagger_start -command "arcus_tagger_start"
  5. To Start on Multi-Domain Security Management Server: [Expert@HostName:0]# cpwd_admin start -name FWCLTAG -path $MDS_TEMPLATE/bin/arcus_tagger_start -command "arcus_tagger_start"

Notes:

 

 

vSEC Controller Process CPVED

What does CPVED do?

Useful Information:

  1. Path: $FWDIR/bin/cpved
  2. Log file: $FWDIR/log/CPVED.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpved stop
  2. To Start: [Expert@HostName:0]# cpved start

Notes:

 

 

vSEC Controller Process VSEC

What does VSEC do?

Useful Information:

  1. Path: $FWDIR/bin/vsec
  2. Log file: None

Commands:

  1. Debug:  

Notes:

 

 

vSEC Process VSEC_CONFIG

What does VSEC_CONFIG do?

Useful Information:

  1. Path: $FWDIR/bin/vsec_config
  2. Log file: $FWDIR/log/vsec_config.elg

Notes:

 

 

vSEC Gateway Process FWK

What does FWK do?

Check Point FireWall kernel in User Space.

  1. Path: $FWDIR/bin/fwk
  2. Log file: $FWDIR/log/fwk.elg

Commands:

  1. To Stop: [Expert@HostName:0]# cpstop
  2. To Start: [Expert@HostName:0]# cpstart
  3. Debug:  

Notes:

 

 

vSEC Gateway Process VEM

What does VEM do?

Useful Information:

  1. Path: $FWDIR/bin/vem
  2. Log file: $FWDIR/log/vem.elg

Commands:

  1. To update the PDPD daemon with the current IP addresses of virtual objects:[Expert@HostName:0]# vem update
  2. Debug:

 

 

vSEC Gateway Process VEMD

What does VEMD do?

Useful Information:

  1. Path: $FWDIR/bin/vemd
  2. Log file: $FWDIR/log/vemd.elg

Commands:

  1. Debug:

 

Conclusion


After taking this module, you are very confident in your knowledge regarding the method in which dynamic objects are updated, you understand the granularity in managing SDDC dynamic objects, and you have learned the significance regarding ease of SDDC dynamic objects being automatically updated within the security policy -- there is no need to manage changing IP addresses or push security policy changes.

Good work!

Please continue to the next module OR end your lab.


 

You've finished Module 2

Congratulations on completing Module 2!

If you are looking for additional information on Securing the SDDC with Check Point vSEC and NSX, try one of these links:

Proceed to any module below which interests you most.

Take this module to navigate Check Point vSEC components and NSX integration in a pre configured lab environment. Learn the capabilities delivered with vSEC and NSX, explore the vSEC components.

Take this module to solve the problem of detecting, containing, and quarantining application VMs that have been bot compromised. Check Point vSEC Anti-Bot engine to detect, contain, and isolate application VMs in the SDDC that have become compromised by bot infections seeking to control the VM. Key learnings in this module involve understanding the methodology of bot detection and quarantine of the infected VM through Check Point vSEC and predefined security policy for containment and isolation of bot infected VMs, and notification of the security event in SmartLog and to security tagging the infected machine within NSX Manager.

Gain hands-on experience using Check Point vSEC Anti-Bot engine to detect, contain, and quarantine application VMs using NSX security group tagging.

With AV alone, bot infections are typically undetected exposing the SDDC to serious risk.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 3 - Advanced Security Seamlessly Embedded into NSX (30 minutes) (Advanced)

Introduction


IMPORTANT NOTE: When you first begin the lab, be sure to check the Lab Status indication on the Main Console. If the Lab Status shows READY, start the lab. If the Lab Status shows FAILED, then end the lab and start a new lab. Please feel free to ask for assistance at anytime.

This module contains the following lessons:

In this module, you will learn how to solve the problem of detecting, containing, and quarantining application VMs that have been bot compromised.  Check Point vSEC Anti-Bot engine to detect, contain, and isolate application VMs in the SDDC that have become compromised by bot infections seeking to control the VM. Key learnings in this module involve understanding the methodology of bot detection and quarantine of the infected VM through Check Point vSEC and predefined security policy for containment and isolation of bot infected VMs, and notification of the security event in SmartLog and to security tagging the infected machine within NSX Manager.

After taking this module you will learn:

1. You cannot rely on Anti-Virus to detect and quarantine bot infections, it is difficult for AV to detect bot infections due to the fact that even unsophisticated bots do an excellent job of hiding and evading AV engines.
2. Once the infected VM is quarantined it is easy to manage remediation within the SDDC.

HOL Lab Notes: This HOL Check Point partner lab environment has been prepared and the following configuration steps have already been completed:

1. VMware vCenter Server and NSX Manager are deployed.

2. vSphere Data Center, Cluster, and Data Center objects are configured.

3. The ESXi hosts in the cluster have the Agent VM configured.

4. vCenter runtime settings are properly configured.

5. NSX Manager is installed on the appropriate clusters.

6. IP address pool to be used for the vSEC Gateways has been created.

7. Check Point R77.30 Security Management Server is deployed.

8. The vSEC Security Gateway Service is configured and the vSEC Controller is registered to vCenter and NSX Manager respectively.

9. The vSEC Cluster object is defined.

10. vSEC Security Gateway instances are assigned as Cluster Members.

11. Best Practice: VMware tools are installed on each VM.

12. Best Practice: Spoof Guard is enabled for the port group.

Environmental Components:


Check Point Anti-Bot and Threat Prevention Tagging


Virtual Machines identified by Check Point vSEC Gateway as infected, can be automatically isolated and quarantined.  This is accomplished by Check Point vSEC tagging the infected virtual machines and sharing this information with the VMware NSX Controller.  Additionally, automated remediation services can be triggered by an orchestration platform.  Threats are quickly contained and the appropriate remediation service can be applied to the infected VM.

In this lesson, you will learn about how Threat Prevention tagging is implemented in vSEC with NSX integration.

A bot is malicious software that allows cybercriminals to remotely control computers and execute illegal activities such as stealing data, spreading spam and distributing malware. Check Point Anti-Bot security software detects bot-infected machines, prevents bot damages by blocking bot C&C communications, and is continually updated from ThreatCloud, the first collaborative network to fight cybercrime.


 

How it works

 

  1. A VM is infected with malware.
  2. Malware on the VM tries to communicate with C&C server.
  3. The Check Point Anti-Bot blade on vSEC Gateway blocks this traffic and sends a tag command that contains the IP address and the Type of the infected VM to the vSEC Controller.
  4. The vSEC Controller sends the IP address of the infected VM to VMware vCenter Server.
  5. VMware vCenter Server returns VMware Managed Object Reference ID (MoRef ID) of the infected VM.
  6. vSEC Controller sends the Type and the VMware Managed Object Reference ID (MoRef ID) of the infected VM to VMware NSX Server.
  7. VMware NSX Server adds the relevant security tag to the infected VM.

 

 

NSX Manager Security Tag Definition

 

In the Main Console desktop, launch Chrome from:

  1. The Chrome shortcut in the Taskbar or
  2. The Chrome icon on the Desktop

 

 

Open the Check Point SmartConsole

 

From the Main Console desktop, Double Click the SmartConsole R80.10 icon to launch the Check Point SmartConsole. SmartConsole is the GUI used to manage global enterprise security policy and physical and virtual security gateway enforcement points.

 

Testing Security Tagging


From NSX Manager, security tags can be assigned or detached by the VMware administrator or Security team using the vSphere Web Client.

Check Point vSEC provides advanced Threat Prevention for data center traffic between virtual machines across the virtual network.  It proactively stops malware and zero-day attacks in the datacenter environment.


 

Open an SSH connection to the WebSRV

 

On the desktop of the Main Console machine

  1. Click the Putty session icon WebSRV-192.168.120.51

Note:  You should automatically be logged on, however if you need to login in manually please use the following credentials:

  1. Username: Root
  2. Password: VMware1!

 

 

Initiating a Bot Attack

 

From the command line, run command:

  1. ./propogate_bot.sh

Minimize the Putty session.

Note: This command will initiate a Bot attack to a host system with ip address: 172.16.47.44. During the attack open the SmartConsole from the Main Console to see what is happening.

 

 

Log into the Check Point SmartConsole

 

Enter SmartConsole Security Management Credentials SmartConsole credentials window appears with the user name (admin) and IP Address fields prepopulated (192.168.110.16). In the password field, enter VMware1! and then Click the Login control button.

  1. Username: admin
  2. Password: VMware1!
  3. Click Login

 

 

Review Logs

 

Upon login, on the left side navigation pane:

  1. Click the LOGS & MONITOR icon.

 

 

Review Anti-Bot logs

 

Review the logs and see how the WebSRV in being identifid as a Bot infected and then inserted into the Infected_VMs group.

See the yellow highlighted icon to denote it is infected.

 

 

Review Infected_VMs security policy

 

Once you see that activity in the logs, on the left side navigation pane:

  1. Click on SECURITY POLICIES
  2. Double click the Infected_VMs group under the Source column in rule number 5.

 

 

Review Infected_VMs Security group

 

Check if you can see the IP address of the WebSRV in that machine.

 

 

Connection Test

 

Return to the Putty session (Hint: It should be minimized in the Windows tray).  In the console:

  1. Type: CTRL & C to stop the attack.
  2. Then run command: ./connection-test.sh

Check to see if the connection can be established, you should see the Ping results

 

 

Log into the vSphere Web Client

 

In the Main Console desktop, launch Chrome from:

  1. The Chrome shortcut in the Taskbar or
  2. The Chrome icon on the Desktop

 

Log into the vSphere Web Client.  The vSphere Web Client should be the default home page.

  1. Enter Username administrator@corp.local
  2. Enter Password VMware1!
  3. Click Login

Note: The username and password should be defaulted.

 

 

Review Web server configuration

 

From left side navigation panel, select:

  1. Select VMs and Templates

 

 

View NSX configuration

 

From NSX Manager, security tags can be assigned or detached by the VMware administrator or Security team using vSphere Web Client.

Continuing with the vSphere Web Client, navigate to:

  1. Click on the Home icon at the top of the page.
  2. On the left side navigation panel, select the Networking & Security.

 

 

Review NSX manager config

 

 

  1. Click on NSX Managers. In the next step, click on NSX Managers to expand.

 

 

Review Security Tags VM count

 

First:

  1. Click on the NSX Manager with IP address 192.168.110.42, then
  2. Click on the Manage tab, then
  3. Select the Security Tags tab.

You are presented with a list of Security Tags that can be utilized by NSX Manager. You now see the CheckPoint.Bot.Found security tag definition. This is the security tag definition that you just looked at when viewing the vSEC Controller Service Manager Menu.

Last:

4.   Select the Checkpoint.bot.found tag, right click and select the Detach Security Tag.

 

 

Detach VM from Security Tag

 

  1. Highlight the WebSRV server.
  2. Click the Right Arrow to  move it to the right side and click OK.  

Hint: Use the right/left arrows to move the object

 

 

Test connection between Web and DB

 

Return to the Putty session connected to the WebSRV.  Hint: It may be minimized in the Windows tray

Run command:

  1. ./connection_test.sh
  2. Look at the Ping results, if the Ping results are sending packets, then you released that server from the quarantine.  The WebSVR is no longer in quarantine and can now communicate on the network.

We can now see how security tags can be assigned automatically through vSEC Threat Prevention tagging.  This feature tags and quarantines VMs infected by a bot or a virus, to apply stricter policies to the tagged VMs.

 

Conclusion


After taking this module, you understand how the Check Point VSEC Anti-Bot engine works with VMware NSX integration, how security tagging works, and have confidence in Check Point Anti-Bot engine to detect, isolate, contain, and quarantine a bot compromised VM, and the power of VSEC and NSX Manager integration -- VSEC updates NSX Manager of the bot incident and with the compromised VM “infected VM” tag. The compromised application VM is quarantined, no traffic to or from this compromised VM is permitted, and remediation of the compromised application VM is now made easy.

Good work!

Please continue to the next module OR end your lab.


 

You've finished Module 3

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1824-01-NET

Version: 20170920-131115