Hol 1824 01 Net - PDF - en PDF

HOL-1824-01-NET
Table of Contents
Lab Overview - HOL-1824-01-NET - VMware NSX and Checkpoint vSEC ........................... 2
Lab Guidance .......................................................................................................... 3
Module 1 - Check Point Introduction, Configuration (30 minutes) (Basic) ......................... 9
Introduction........................................................................................................... 10
Exploring the VMWare Environment...................................................................... 12
Introduction to Check Point vSEC components .................................................... 33
Dynamic Enforcement........................................................................................... 49
Conclusion............................................................................................................. 58
Module 2 - Dynamic Policy Application with NSX Objects , vSEC Integration Components
and Processes (30 minutes) (Intermediate) ................................................................... 60
Introduction........................................................................................................... 61
Security Policy Inclusion........................................................................................ 63
Understanding vSEC Integration Components and Flows ..................................... 83
vSEC Processes in Depth....................................................................................... 90
Conclusion............................................................................................................. 97
Module 3 - Advanced Security Seamlessly Embedded into NSX (30 minutes) (Advanced)
........................................................................................................................................ 99
Introduction......................................................................................................... 100
Check Point Anti-Bot and Threat Prevention Tagging .......................................... 102
Testing Security Tagging...................................................................................... 110
Conclusion........................................................................................................... 121
HOL-1824-01-NET Page 1
HOL-1824-01-NET
Lab Overview -
HOL-1824-01-NET -
VMware NSX and
Checkpoint vSEC
HOL-1824-01-NET
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:
• Module 1 - Check Point Introduction and Configuration (30 minutes)

(Basic)
HOL-1824-01-NET
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.
• Module 2 - Dynamic Policy Application with vCenter and NSX Objects (30
minutes) (Intermediate)
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.
• Module 3 - Bot Detection, Quarantine, and Incident Response (30

minutes) (Advanced)
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:
• Lab Manual - Hau Tran, Sr. Systems Engineer, USA

• Module 1 - Tal Ein-Habar, Datacenter Security Expert, Israel
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
HOL-1824-01-NET
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.
HOL-1824-01-NET
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.
HOL-1824-01-NET
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".
HOL-1824-01-NET
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.
HOL-1824-01-NET
Module 1 - Check Point

Introduction,
Configuration (30
minutes) (Basic)
HOL-1824-01-NET
Introduction
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.
• Begin the tour of Check Point vSEC Components

• Basic navigation around NSX Manager and vCenter to see where the Check Point
vSEC components are configured
• Work through an example of how threats like bots can trigger a quarantine action
by Check Point and investigate how to configure this security safeguard and
monitor these events.
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.
HOL-1824-01-NET
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 management server installed with vSEC controller add-on.

• NSX managed environment with 2 security groups: web server running Apache
and DB server running MySQL.
• vSEC service deployed on ESXi cluster.
HOL-1824-01-NET
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
HOL-1824-01-NET
Login To vSphere Web Client
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.
HOL-1824-01-NET
Access to vSphere Web Client
You are presented with the vSphere Web Client home view.
1. Click on the VMs and Templates icon from the Navigation pane.
Navigate vSphere Web Client
HOL-1824-01-NET
The SDDC is a dynamic environment where Virtual Machines are spun up and turned
down, and vMotioned as needed to meet HA requirements. The vSphere client is the
central control plane for the SDDC. You can find the Check Point vSEC integration within
VMware vCenter (vSphere Client) along with NSX Manager. The Check Point security
objects and security policies are dynamically updated as changes take place within the
SDDC. This is the power of software-defined policies and objects.
Locate Dynamic Data Center Content
Let's take a look at one of the VM's in our inventory.
1. Click on WebSRV in the Navigation panel.

2. Click Summary tab.
3. In the right pane, we can see that the VM is running and assigned IP address:
192.168.120.51
4. The VM is a member of security groups: Web_Group and VMs.
5. Repeat steps 1-4 for DBsrv and note the VM properties, including the security
groups it belongs to.
HOL-1824-01-NET
NSX Security Groups are sets of vCenter objects such as clusters, virtual machines,
vNICs, and logical switches. This construct allows you to classify VMs, group them, and
assign security policies to them.
A VM reboot may be required
In the previous step, in Step 3, you might not see the IP address of the VM. If the IP is
blank it means that VMTools is not running on the guest. Please reboot the machine
1. Select WebSRV
2. Select Actions Menu
3. Select Power
4. Click on Power Off
HOL-1824-01-NET
Power on the VM
1. Select WebSRV
2. Click Start icon
You may have to wait approximately: 15 seconds for the IP address to appear
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.
HOL-1824-01-NET
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
HOL-1824-01-NET
Review Security Groups
1. On the Networking and Security screen, scroll down the left panel and click on
Service Composer.
You are presented with Security Groups tab for NSX Manager, IP: 192.168.110.42.
Note: You can move across the tabs, and resize and reorder the columns.
HOL-1824-01-NET
View the Details of the Security Groups
Security Groups are defined under Service Composer within NSX. In this lab, the
Security Groups have already been created for you to make sure that the lab functions
as designed.
1. Please note the list of Security Group names, and these are the very same
dynamic data center objects that are populated into Check Point.
View Which Servers Are Included In A Security Group
Notice the columns have the count of VMs associated with the Security Groups.
HOL-1824-01-NET
You now see there are VMs associated with some of the Security Groups. The Virtual
Machine column indicating there is (1) virtual machine currently associated with the DB-
Group and Web_Group security group respectively.
In subsequent modules we will be working with these virtual machines to generate

traffic and view results of security policy enforcement in SmartLog.
Server Quantity
1. Click the Web_Group row so it is highlighted. You see the number "1" in the
column for virtual machines, indicating one (1) VM is a member of the Web
Server Security Group.
You can click on the number value under the Virtual Machines column to see which VMs
are part of the security group.
HOL-1824-01-NET
View the Virtual Machines in Web-Group
1. To see which VM is a member, click the # 1 and you will see that WebSRV is the
VM that is a member of the Web Server Security Group.
Exit the group
Here it is important to point out that while Check Point consumes dynamic data center
objects from vCenter (vSphere Client), and security groups from NSX Manager, these
objects and security groups are typically built per requirements that fit a specific
security architecture.
HOL-1824-01-NET
Security Groups are typically built based on automatic grouping of VMs by function or
security zone. In this example, we follow a multi-tiered architecture reference. Other
businesses may create security zones based on other security parameters like
compliance (e.g. PCI, PII, HIPAA), user access (e.g. intranet, internet facing), data
residency and governance, etc.
This lab depicts the classic Web and DB tiers through use of NSX Security Groups for
Web Servers and DB Servers. In this lab, the VM name is the mechanism by which the
VM is automatically added to its respective Security Group.
Example: All VMs to function as web servers are built with "web" in the VM name. We
have a dynamic security group for Web Servers. Any VM with the name of "web" is
automatically added to the Security Group for Web Servers (Web_Group) and thus
inherits the attributes of the Security Group for Web. This is a simple way to create
dynamic security policy and micro-segmentation inspection and enforcement between
Web, App, and DB tiers.
1. Close the Web Group - Virtual Machines window by Clicking the X in the top
right corner.
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.
HOL-1824-01-NET
Name the Security Group
The Security Group Wizard Opens up and we can begin creating the new Security Group.
1. Enter App_Group for the Security Group name.

2. Click Next.
Please note that you can enter a description of this security group also. This can be
helpful when creating security groups that may share similar qualities as other security
groups. e.g. Security groups on the same network tier.
Define Membership Criteria
For this example, we want to create a Security Group for servers with "App" in the
name:
HOL-1824-01-NET
1. Click the first dropdown box and select Computer Name.

2. In the text, box, enter the text App.
3. Click on Next.
Now, any VM that gets created containing "App" in its name will be part of the
App_Group security group. This is one of the ways to create dynamic inclusion policy for
VMs, alleviating manual effort/errors or possible risk due to a possible compliance gap.
Select Object to Include
We can define which object to include in our Security Group. We will leave the object
type at Cluster for this example, but this could be changed to suit a more granular
approach.
Hint: This allows parent/child relationships along with the power of inheritance
1. Click on Cluster object RegionA01-MGMT01.

2. Click the Arrow to Select the object.
3. Click Next.
Now, any VM that is in the RegionA01-MGMT01 cluster, with "App" in its name, will be
part of our App_Group Security group.
HOL-1824-01-NET
Select Object to Exclude
We can also exclude objects from a Security Group. This allows great flexibility and
precision when assigned security attributes to objects in the SDDC.
1. Click on the Object Type dropdown to view the types of objects that can be
excluded.
2. We won't exclude any object, so click Next to continue.
Review Settings and Finish
We have completed the new App_Group Security Group. We can review the settings
here and confirm that we have the correct objects included and excluded.
1. Click Finish to complete the New Security Group Wizard.
HOL-1824-01-NET
We will not be using the App_Group Security Group as part of this lab, however in this
exercise you were able to see how easy it was to create a security group along with the
dynamic capabilities that can apply to other SDDC objects.
Confirm New Security Group
We are now back to the Service Composer screen where we can confirm that the
App_Group Security Group was created.
Edit an Existing Security Group
HOL-1824-01-NET
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.
Edit the App_Group Security Group
After clicking the pencil icon, you are presented with the Edit Security Group window
and the first configuration item is the Name and description page. For this example, we
want to modify the properties that define dynamic membership.
1. To modify the dynamic membership, either click on item 2; Define dynamic

membership. or click on Next.
HOL-1824-01-NET
Security Group Add Dynamic Membership Criteria
Currently, any Virtual machine that contains "App", is dynamically added to the Security
Group named App_Group. Let's modify the membership so that it has to meet an
additional condition to be part of the App_Group security group.
1. Click the Add button to add a second criteria.

2. Click the Dropdown menu and select Security Tag.
3. In the text box, enter the text Prod.
4. Since this is the only item we are changing, click Finish.
Now our App_Group will define membership for VM's that contain App in the name, and
have Prod as their security tag.
HOL-1824-01-NET
Security Group Dynamic Membership- Continued
Let's take a look at a Security Group and how we can use it to isolate an infected VM.
1. Click on the Security Group named Infected_VMs. Make sure this Security Group
name is highlighted.
2. Now click the Edit Security Group Icon to edit this Security Group.
HOL-1824-01-NET
Security Group Definitions
You are presented with Edit Security Group window for the Infected_VM Security Group.
1. Click on Define Dynamic Membership or Next.
Security Tag Criteria
HOL-1824-01-NET
1. Now you see that the the definition for the Infected_VM Group is based on the
Virtual Machine Security Tag Check_PointBotFound for ANTI_Bot high threat
violation found.
2. Click the Cancel control button. You are returned to the Service Composer page.
How does the tag get on the VM? The primary way is automatically tagging
compromised VMs through Check Point advanced security protections engine trigger for
Anti-Virus, Anti-Bot, and IPS engine trigger. Another way for VMs to get security tagged
could be through intervention by the VMware administrator.
This is important to understanding the power of immediately detecting and quarantining

compromised or malware infected Virtual Machines can be achieved by dynamically
tagged the infected VM with the Security Tag for data center security violation, then
immediately placing the infected VM into the Infected VM Security Group. The Infected
VM Security Group object is already utilized in Check Point security policy where the
security policy quarantines any member of the Infected VM Security Group by dropping
all traffic to and from the VMs. When a VM is detected as being compromised, the VM is
dynamically security tagged, and through vSEC integration with NSX, the VM is
automatically thrown into a quarantine bucket where it is it completely locked down,
therefore eliminating any potential lateral threat to the SDDC.
HOL-1824-01-NET
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.
HOL-1824-01-NET
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.
Login to Smart Console
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.
HOL-1824-01-NET
The Checkpoint SmartConsole UI
You are presented with the SmartConsole Security Policy view.
Note: You see firewall rules specifically for SDDC:
• Dynamic Enforcement
• Data Center Micro Segmentation
• Advanced Threat Prevention Scenarios
HOL-1824-01-NET
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.
Viewing the Logs Screen
Let's take a look at the Logs screen.
HOL-1824-01-NET
1. To make sure we are looking at current data, click the Auto-Refresh icon.
2. You are presented with real time update of accepted traffic logs. Note the red
icons notifying you of Denied Traffic.
3. Green Icons are notifying you of Accepted traffic.
4. Click in the Search Query field, and from drop down, select action:Accept,
then press the refresharrow. You have effectively changes search criteria to show
current logs of accepted traffic.
You have effectively change search criteria to filter current logs for only accepted traffic.
Review log information
Double Click on a log instance of traffic that was accepted. This can be any row that
has the "green" accepted traffic icon. You are presented with details regarding this
specific log instance. Can you identify this traffic? What service and on which RULE was
this traffic accepted?
1. Source IP
2. Destination IP
3. Source Port
4. Service
5. Interface
Later you will see some data center objects and security group names. With vSEC and
NSX integration, we are able to pull in data center objects from vCenter, and Security
HOL-1824-01-NET
Groups from NSX Manager. We call these dynamic data center objects. Dynamic data
center object information flows with logs.
You will find SmartLog provides "understanding" of your organization's security policy
enforcement and resulting log details.
We will come back to this topic in Module 2.
Please leave SmartLog open and minimized.
Data Center Object for vCenter
1. On the left side navigation, Click back on the Security Policies
Navigate to the Data center object
1. Click on the Servers icon in the right pane.
HOL-1824-01-NET
Navigate to Data Center
1. Click on the Data Centers icon.
Select the vCenter Object
1. Double Click vCenter object.
HOL-1824-01-NET
vCenter object configuration
After double clicking the vCenter object, you are presented with the vCenter Server
properties window. In this lab, the data center server objects and connections have
already been created and established for you.
This properties window is where you define the vCenter service account information
necessary for vSEC to communicate with the vCenter.
1. You can now test connectivity to vCenter by clicking on the Test Connection
control button. If Test Connection is established from vSEC Controller to vCenter
Server, you see connection status "Connected" highlighted in green type.
2. Click OK to close this window.
NOTE: If the hostname does not work, try the IP address listed below
Hostname: vcsa-01a.corp.local OR 192.168.110.22

Username: administrator@vsphere.local
Password: VMware1!
HOL-1824-01-NET
Select NSX Server Object
1. Select the NSX Server Object.
NSX object configuration
In this lab, the data center server objects and connections have already been created
and established for you. This properties window is where you define the NSX Manager
service account information necessary for vSEC to communicate with and establish
connection to NSX Manager.
HOL-1824-01-NET
1. You can now test connectivity to NSX Manager by clicking on the Test Connection
control button. If SIC is established from vSEC Controller to NSX Manager, you see
connection status Connected highlighted in green type.
2. Click OK to close the window.
NOTE: IF the hostname does not work, try the IP address listed below
Hostname: nsxmgr-01a.corp.local OR 192.168.110.42

Username: administrator@vsphere.local
Password: VMware1!
Verify NSX Manager and vCenter forCheck Point

Integration
This lesson involves basic navigating around NSX Manager and vCenter to identify
where Check Point vSEC components are configured. Previous knowledge of NSX
Manager and vCenter are super helpful! The goal here is to familiarize yourself with the
various integration components in VMware.
NSX Manager - Host Prep
Launch vCenter Web Client and navigate to NSX Manager.
HOL-1824-01-NET
Note: In this lab, we have deployed One (1) NSX Manager, SiteA representing a single
datacenter In this lab, we are strictly working with site A and NSX Manager
192.168.110.42. In other NSX labs, you may see to sites.

HOL-1824-01-NET
page.

3. Click Login
HOL-1824-01-NET
From NSX Manager, click:
1. Installation from the left panel, then

2. Click the Host Prep tab.
You are presented with NSX Component Installation on Hosts. Host Prep reflects the data
center clusters and hosts where NSX Manager is deployed. In our lab, we have a single
cluster named RegionA01-MGMT01, and two (2) hosts we will be using.
Check Point vSEC deployment is aligned to VMware NSX Manager deployment. NSX
Manager deploys to the data center cluster and provides Network and Security
Extension services (network hypervisor and Distributed Firewall) for that cluster. Check
Point vSEC Gateway service deploys to the cluster where NSX Manager is deployed and
will protect all of the hosts and application VMs on that cluster.
HOL-1824-01-NET
NSX Manager - Service Deployments
Stay right where you are in NSX Manager, and now click on the Service Deployments
tab.
You are presented with Network & Security Service Deployments.
From this screen, you can see that the vSEC service is successfully deployed to the
RegionA01-MGMT01 cluster, the service is up, as well as the VMware port group, and IP
Address Pool being utilized by the vSEC Gateway service Virtual Machines (VMs). It is all
beginning to come together right?
NSX Manager
Next we want to navigate within NSX Manager settings to identify the IP Pool from the
previous step.
What is this IP Pool for?
It is for the vSEC Gateway service during deployment to as part of its autoconfigure
process.
HOL-1824-01-NET
When the vSEC Service is deployed from NSX Manager, a vSEC Gateway Virtual Machine
will deploy for each cluster member. The vSEC Gateway Service Virtual Machine
deployment is fully automated. If instances will deploy -- one instance will attach per
each cluster member.
How is this deployment process automated? The vSEC Gateway Service VMs are
deployed from the OVF template we described in earlier steps, the instances deploy,
boot up, grab an IP address from the NSX Manager IP Pool, auto configure, then connect
to Security Management Server with vSEC Controller, build the cluster object and
respective instance objects with topology, and fetch an initial security policy from
Security Management Server.
HOL-1824-01-NET
To see where the IP Pool is defined for use of automated deployment of the vSEC
Gateway Service VMs, navigate on the left panel, expand Network & Security
Inventory, click on NSX Managers, click on 192.168.110.42.
1. From NSX Manager 192.168.110.42

2. Click on the Manage tab, then click Grouping Objects
3. Select IP Pools
Here you find the IP Pool definition for the vSEC Gateway Service VMs. This is how you
identify within NSX Manager where traffic is configured to redirect to the Check Point
vSEC Gateway service, and how Check Point vSEC and VMware NSX Distributed Firewall
interact.
HOL-1824-01-NET
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.
HOL-1824-01-NET
Login to Smart Console

control button.
1. Username: admin
3. Click Login.
The Checkpoint SmartConsole UI
HOL-1824-01-NET
Creating A New Rule
First we will create new rule (Rule #2)
1. Highlight rule #1
2. Click on the Add rule below button.
HOL-1824-01-NET
Import objects from NSX
On the newly created rule (Rule #2).
1. Go to the Source column and Click the plus "+" sign.

2. Hover over the cell and click on the "Add new items" message that appears.
HOL-1824-01-NET
Select Objects
On the new dialog window that opens:
1. Click on the Import icon.

2. Choose NSX as your source.
Select Objects from NSX
You can choose the NSX objects two different ways:
1. Expand the Security Groups in the Navigation pane by clicking on the small
triangle
2. Select the Resource name.
3. Alternatively, you can highlight the resource, then click the plus "+" sign next to
the resource name in the Name column. In this instance, we will select the
Web_Group resource.
HOL-1824-01-NET
Verify Object is Selected
1. The "X" will be replaced with a Check Mark signifying that we have added the
Web-Group resource to our new rule.
2. Click on the "X" since we are finished selecting objects for our rule.
Complete the Rule
1. Double Click in the Name field of the rule we just created and enter the name
Web Rule.
We have now successfully created a new rule.
HOL-1824-01-NET
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.
HOL-1824-01-NET
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.
HOL-1824-01-NET
Maximize Smart Console
1. Click on the Smart Console icon in the taskbar.
Navigate to Logs and Monitor
1. Click on the Logs & Monitor link found on the left side navigation bar.
2. Click on the Double Arrow to maximize display space for the log screen.
3. Now look at the allowable traffic from the Main console (192.168.110.10) to the
WebSRV-Test web server (192.168.120.51), review the relevant security group
HOL-1824-01-NET
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:
• Click on this link

• Or go to http://tinyurl.com/nx5qxca
• Or use your smart device to scan the QCR Code.
Proceed to any module below which interests you most.
• Module 2 - Dynamic Policy Application with vCenter and NSX Objects (30
minutes) (Intermediate):
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.

minutes) (Advanced)
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.
and quarantine application VMs using NSX security group tagging.
HOL-1824-01-NET
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.
HOL-1824-01-NET
Module 2 - Dynamic Policy

Application with NSX
Objects , vSEC Integration
Components and
Processes (30 minutes)
(Intermediate)
HOL-1824-01-NET
Introduction
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:
• Creating and connecting from Check Point Security Management Server using
SmartDashboard to retrieve dynamic SDDC Data Center objects from vCenter and
Security Groups from NSX Manager
• Creating Data Center Objects Group and dynamically adding objects to the new
group
• Modifying the security policy rules to include SDDC dynamic objects and testing
dynamic update
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-1824-01-NET
• Check Point management server installed with vSEC controller add-on

• NSX managed environment with 3 security groups: web server running Apache,
application server, and DB server running MySQL
• vSEC service deployed on ESXi cluster
HOL-1824-01-NET
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.
HOL-1824-01-NET
HOL-1824-01-NET

page.

3. Click Login
Navigate to the WebSRV definitions
1. From left side navigation panel, select "VMs and Templates".
HOL-1824-01-NET
Review WebSRV summary information
Then select:
1. "WebSRV", then
2. Click on the Summary tab.
3. Review the IP address of the server, should be: 192.168.120.51
Reboot VM
In the previous step, in Step 3, you might not see the IP address of the VM. If the IP is
blank it means that VMTools is not running on the guest. Please reboot the machine
1. Select WebSRV
2. Select Actions Menu
3. Select Power
4. Click on Power Off
HOL-1824-01-NET
Power on the VM
1. Select WebSRV
2. Click Start icon
You may have to wait approximately: 15 seconds for the IP address to appear
Minimize your Chrome session
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
HOL-1824-01-NET
Note: You should automatically be logged on, however if you need to login in manually
please use the following credentials:
Username: Root
Password: VMware1!
Testing communication with DB server
From the command line, run the following commands:
1. ./connection-test.sh
2. ./exec_SQL_query_on_DB.sh
Now look at the results to see that you have the connectivity.
Leave the console connection open. You will continue working from this in the next
steps.
The web server is able to communicate with the db server via ICMP & SQL requests.
What Check Point security policy rules allows for communication from the web server to
the db server via ICMP & SQL requests?
Connecting into the Check Point SmartConsole
HOL-1824-01-NET
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.
Log into the SmartConsole

appears with the following credentials and then Click the Login control button.
1. Username: admin
3. IP: 192.168.110.16
HOL-1824-01-NET
Review predefind security policy
1. On the left side navigation bar, Click on Security Policies link
Review rules
View rule numbers: 6 & 7 to see the allowed traffic between the two servers.
You will see:
• MS-SQL
• ICMP-Requests
HOL-1824-01-NET
View security logs
Now, we will view the logs to see the vSEC gateway traffic. On the left side navigation
bar:
1. Click on the LOGS & MONITOR.
Review the security logs
1. To the left of the Query Search field, Click the auto-refresh icon. This icon has a
"right arrow" over the letter "A". See also the refresh arrow. Either can be utilized
when you initiate new search filters in SmartLog.
You are presented with real time update of accepted traffic logs. Distinguished with
green and red icons.
Note: Look at what traffic is denied and what is accepted.
HOL-1824-01-NET
Search the Log Traffic
Search on the logs for traffic originating from the Web Server to the DB Server. Look for
entries with "Web_Group"
Review information from a specific security log
1. Double click on one of the logs to view log details
Review the Log Details
1. Click on the "X" at the upper right side to close this window.
2. Minimize the SmartConsole Window
HOL-1824-01-NET
Review the IP address in the VMware vSphere Web Client
Next you will change the IP address of the Web Server and confirm that communication
still works and the security policy is automatically enforced with the dynamic change of
the data center object within vSphere.
1. Go back into the vSphere Web Client and select the WebSVR server. Note the IP
address of the WebSRV
• Hint: Chrome browser session may be minimized
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.
HOL-1824-01-NET
Reconnect into the web server via SSH
In order to continue the connection, go back to your Main Console desktop.
1. Click on the Putty icon (WebSRV-192.168.120.52) to open a new Putty SSH

session.
Note: There are 2 WebSRV Putty session shortcuts, make sure to select the appropriate
session with IP: 192.168.120.52
HOL-1824-01-NET
Confirm that the IP address has changed
Check that the IP has been changed (it may take up to 30 seconds):
1. Check the WebSRV VM properties in the vSphere Web Client (Hint: Chrome
browser session)
2. On the existing Putty session (192.168.120.52), run command: ifconfig
Testing connectivity between servers
HOL-1824-01-NET
After validation that the IP address has been changed, try to communicate from the
WebSVR to the DBsrv.
1. Run command: ./connection-test.sh
Minimize the Putty session
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:
Review logs
Look for the new logs from the new IP address (192.168.120.52)
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
HOL-1824-01-NET
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.
Changing the name of the server
Open the vSphere Web Client (Hint: Chrome browser).
1. Select the WebSRV on the left hand tree and right Click, choose Rename.
2. Change the name to: "Generic-SRV". Wait 30 seconds.
Checking connectivity between web and DB servers
Revert back to the 192.168.120.51 Putty session (Hint: The session minimized in the
Windows tray).
HOL-1824-01-NET
1. run command: ./connection-test.sh
Minimize the Putty session
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
Review security group defenitions
In the resulting screen, select "Define Dynamic Membership".
HOL-1824-01-NET
Review the condition for participation on that Security Group. The criteria states that
"VM Name" has to "contain" the word "web".
Since we just changed our server name, it no longer matches the criteria set for this
Security Group, therefore is now excluded.
Click Cancel to close this window
Revert the name of the Server
1. Return via the Home icon on the top of the page.
HOL-1824-01-NET
Review the VM's configuration
1. On the left hand navigation of the vSphere Web Client, select "VMs &
Templates".
Changing the name
Revert the name of the WebSRV.
1. Select the "Generic-SRV" VM, right Click and select "Rename"

2. Rename the VM to "WebSRV".
3. Click OK
HOL-1824-01-NET
Check connectivity
Wait for 30 seconds and return back to the Putty session (Hint: Minimized in the
Windows tray), run command:
1. ./connection-test.sh
Verify WebSVR properties in? the vSphere Web Client
Check to see that the "WebSVR" server is back in the Security Group. Navigate to the
vSphere Web Client (Hint: Chrome browser). On the left side navigation, select:
1. Click on Networking & Security
HOL-1824-01-NET
Review Security Group in the vSphere Web Client
Check to see that the "WebSVR" server is back in the Security Group. Navigate to the
vSphere Web Client (Hint: Chrome browser). On the left side navigation, select:
1. Select Service Composer in the Navigation pane.

2. Select the Web_Group Security Group
3. You should see "1" VM belonging to the the "Web_Group" Security Group.
Hint: You can Click on the number "1" to see which VM is part of the Security Group!
HOL-1824-01-NET
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.
• vSEC Gateway is based on the VMware Network Extensibility (NetX) API.

• vSEC Security Gateway protects East-West traffic, but can operate at Layers 2-7.
• vSEC provides additional Layers 5-7 capabilities like application identification,
application inspection and user identification to NSX environments.
• The traffic redirection is performed by the VMware NSX infrastructure redirection
policy is expressed by the user through VMware NSX Service Composer.
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.
HOL-1824-01-NET
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.
HOL-1824-01-NET
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 Controller polls VMware NSX Manager/vCenter every 30 seconds about

changes in VMware objects.
• Since a polling mechanism is used good vSEC Controller performance is
manageble > 1000 virtual objects from VMware NSX Manager/vCenter are used
in rules.
• vSEC Controller links to both vCenter and NSX Manager, the virtual objects
learned do not count to performance guidelines unless these learned objects are
used in Check Point security policy rules.
HOL-1824-01-NET
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:
• CMS_PROXY daemon connects to VMware vCenter to fetch the VMware objects

(web service request). Note: Check Point log is generated only if this connection
fails.
• CMS_PROXY daemon connects to VMware NSX to fetch the VMware Security
Groups (web service request). Note: Check Point log is generated only if this
connection fails.
• VMware NSX / vCenter return XML file (web service response).
• CMS_PROXY daemon parses the XML file (maps VMware objects and their IP
addresses) and sends the relevant information to FWM daemon (VMware objects
are displayed in SmartDashboard). Note: There are no logs or history for which
objects were fetched.
4. 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.
5. 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.
HOL-1824-01-NET
6. 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.
7. vSEC Controller decides if the $FWDIR/database/virtual_objects.db file on vSEC
Gateway has to be updated:
• vSEC Controller connects to vSEC Gateway (using the cprid_util utility) and
collects the MD5 of the $FWDIR/database/virtual_objects.db file on vSEC Gateway.
Example: cprid_util -timeout 120 -server serviceinstance-1-ab951e rexec -
verbose -rcmd md5sum /opt/CPsuite-R77/fw1/database/virtual_objects.db
• vSEC Controller compares the MD5 of its $FWDIR/database/virtual_objects.db file
with MD5 of the $FWDIR/database/virtual_objects.db file on vSEC Gateway.
• If the MD5 DO NOT match (IE: some VMware objects were changed, and vSEC
Controller holds an updated file), then CPRID daemon on vSEC Controller
connects to CPRID daemon on vSEC Gateway and overwrites the $FWDIR/
database/virtual_objects.db file on vSEC Gateway.
• Relevant kernel tables are updated on vSEC Gateway.
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.
HOL-1824-01-NET
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:
• Fail Open policy - All packets are accepted

• Fail Close policy - All packets are dropped
Traffic actually comes from the User Mode NetX API into
Check Point's user mode FWK daemon.
• In vSEC Gateway, the CoreXL Secure Network Dispatcher (SND) and CoreXL FW
Instances are threads created by FWK daemon.
• vSEC Gateway is preconfigured with a 1 CoreXL SND (fwk0_snd) and 3 CoreXL FW
instances (fwk0_0, fwk0_1, fwk0_2).
• The CoreXL SND and each of the CoreXL FW instances are assigned with a virtual
core.
• In vSEC Gateway with enabled CoreXL and SecureXL, the CoreXL SND receives
packets from shared memory (dvfilterklib).
• CoreXL SND determines traffic distribution between CoreXL FW instances.
• Packet is received by SecureXL on the selected CoreXL FW instance.
• Since vSEC Gateway has no virtual or physical data interfaces, the CoreXL SND
thread does not receive traffic through a network interface.
Traffic flows in the following way
• VMware ESX API places the traffic in shared memory on the vSEC Gateway
• CoreXL SND sends the traffic to the CoreXL FW instances
• CoreXL FW instances return the traffic to the CoreXL SND
• CoreXL SND sends the traffic over VMware API to the ESXi via the NSX DFW
vMotion and traffic handling
• At vMotion event in ESXi cluster, where a VM1 is moved from ESXi1 member
(running vSEC GW1) to ESXi2 member (running vSEC GW2).
• When vMotion reaches ~67%, the following occurs:
• vSEC GW1 gets a vMotion event from VMware that translates into by-passing
vSEC Service redirection for existing VM1 sessions.
• Traffic is now managed by NSX DFW only, based on the NSX policy (accepting
packets by default).
• New sessions are redirected to vSEC GW2 at ESXi2 member.
• Since the by-pass rule for existing sessions is enforced on all ESXi member in the
cluster, the existing sessions that were established before the vMotion, keep
being handled only by NSX rules (no redirection to vSEC GW).
HOL-1824-01-NET
vSEC Databases
vSEC Gateway
• vSEC Gateway database contains VMware Data Center objects is $FWDIR/

database/virtual_objects.db
• VMware Data Center objects that were added to Check Point policy, are saved as
virtual objects in the $FWDIR/database/virtual_objects.db file on vSEC Controller.
• During policy installation, these virtual objects are saved in the $FWDIR/
database/virtual_objects.db file on vSEC Gateway.
• This database is updated periodically by vSEC Controller.
• The active database is automatically backed up as $FWDIR/database/
virtual_objects.db.bak file.
• On vSEC Gateway, virtual objects are converted to dynamic objects and stored in
the $FWDIR/database/dynamic_objects.db file.
vSEC Controller
• The database on vSEC Controller that contains the VMware ESX Cluster object is
$FWDIR/database/vcenter_gateways_file.C
• VMware ESX Cluster object, ESX Cluster member and vSEC Gateways deployed
on each member, are saved in the $FWDIR/database/vcenter_gateways_file.C file
on vSEC Controller.
• Database on vSEC Controller that contains path to vSEC OVF package is $FWDIR/
conf/ve_set.C
• Path to OVF package is saved in the $FWDIR/conf/ve_set.C file on 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:
• Source = myGroup (this is virtual cloud group)

• Identity Source = vSEC Client
• Source Machine Group = RAD_All Users ("RAD_" is the current necessary prefix)
HOL-1824-01-NET
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?
• Communication between SmartConsole applications and Security Management

Server.
• Policy installation from Security Management Server to Security Gateway.
• Processing of logs from Security Gateway.
• Connects to the CMS_PROXY daemon to fetch VMware objects from VMware
vCenter.
• Connects to the CMS_PROXY daemon to fetch VMware Security Groups from
VMware NSX.
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"
HOL-1824-01-NET
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:
• "cpwd_admin list" command shows the process as "FWM".

• "ps auxw" command shows the process as "fwm".
vSEC Controller Process CMS_PROXY
What does CMS_PROXY do?
• Connects to VMware vCenter to fetch VMware objects.

• Connects to VMware NSX to fetch VMware Security Groups.
• Parses the XML file received from VMware NSX / vCenter (maps VMware objects
and their IP addresses) and sends the relevant information to either FWM
daemon or FWCLOUD daemon.
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:
• Started automatically by Check Point WatchDog.

• "cpwd_admin list" command does not show this process.
• "ps auxwwwww" command shows the process as "com.cp.cms_proxy.mainClass".
• On Multi-Domain Security Management Server, there is one cms_proxy process at
the MDS level.
vSEC Controller Process FWCLOUD
What does FWCLOUD do?
• Connects to the CMS_PROXY daemon every 30 seconds to fetch all involved

VMware objects from VMware NSX / VMware vCenter.
Useful Information:
HOL-1824-01-NET
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

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:
• Check Point log is generated only if this connection fails.

• Started automatically by cpd daemon.
• Starts running only if there is at least one VMware object in the policy.
• "cpwd_admin list" command shows the process as "FWCLOUD".
• "ps auxw" command shows the process as "arcus_proxy_start".
• On Multi-Domain Security Management Server, there is fwcloud process at the
level of each Domain.
vSEC Controller Process FWCLTAG
What does FWCLTAG do?
• Web service that listens for Threat Prevention Tagging commands sent from vSEC
Gateway and then tags the infected VM in VMware NSX.
Useful Information:
1. Path: $FWDIR/jre/bin/java loads files from $FWDIR/lib/Arcus/

2. Log file: $FWDIR/log/cloud_tagger.elg
Commands:

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"
HOL-1824-01-NET
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:
• "cpwd_admin list" command shows the process as "FWCLTAG".

• "ps auxwwwww" command shows the process as
"com.cp.cms_proxy.mainTagger".
• On Multi-Domain Security Management Server, there is fwcltag process at the
level of each Domain.
• The default logging level is enough to see the calculations for Threat Prevention
Tagging.
• Analyze the $FWDIR/log/cloud_tagger.elg file.
vSEC Controller Process CPVED
What does CPVED do?
• Listens to the VMware vCenter to update on creation and deletion on vSEC

Gateway and the number of cores on their ESX hosts.
• Gets notifications for VMware vCenter regarding Service Agents.
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:
• Started automatically by Check Point WatchDog.

• "cpwd_admin list" command shows the process as "CPVED".
• "ps auxwwwww" command shows the process as "com.checkpoint.VE.CPVED".
• The default logging level is enough. Analyze the $FWDIR/log/CPVED.elg file.
vSEC Controller Process VSEC
What does VSEC do?
• Script that enables (vsec on) vSEC / disables (vsec off) vSEC.
Useful Information:
HOL-1824-01-NET
1. Path: $FWDIR/bin/vsec
2. Log file: None
Commands:
1. Debug:
• Start the screen capture: [Expert@HostName:0]# script /var/log/

debug_of_vsec_script.txt
• Execute the script under debug: [Expert@HostName:0]# sh -x $FWDIR/bin/vsec
<on | off>
• When you see the Expert mode prompt, press CTRL+D keys.
• Analyze /var/log/debug_of_vsec_script.txt
Notes:
• On Multi-Domain Security Management Server, must be run from the MDS

context.
vSEC Process VSEC_CONFIG
What does VSEC_CONFIG do?
• Starts the VSEC SELECTION MENU to configure vSEC settings.
Useful Information:
1. Path: $FWDIR/bin/vsec_config
2. Log file: $FWDIR/log/vsec_config.elg
Notes:
• The default logging level is enough. Analyze the $FWDIR/log/vsec_config.elg file.
vSEC Gateway Process FWK
What does FWK do?
Check Point FireWall kernel in User Space.
• Useful Information:
1. Path: $FWDIR/bin/fwk
2. Log file: $FWDIR/log/fwk.elg
Commands:
HOL-1824-01-NET
1. To Stop: [Expert@HostName:0]# cpstop

2. To Start: [Expert@HostName:0]# cpstart
3. Debug:
• Start the debug: [Expert@HostName:0]# fw debug fwk on TDERROR_ALL_ALL=5

• Replicate the issue.
• Stop the debug: [Expert@HostName:0]# fw debug fwk off
• Analyze: $FWDIR/log/fwk.elg
Notes:
• "cpwd_admin list" command shows the process as "FWK".

• "ps auxw" command shows the process as "fwk".
vSEC Gateway Process VEM
What does VEM do?
• Controls the VEMD daemon, which updates the Identity Awareness PDPD daemon
about the changes in virtual objects that were configured on the vSEC Gateway.
• These updates are required in order to update the Source / Destination fields in
the FireWall logs.
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:
• Start the debug: [Expert@HostName:0]# vem debug on

• Stop the debug:
• [Expert@HostName:0]# vem debug off
• Analyze: $FWDIR/log/vem.elg
vSEC Gateway Process VEMD
What does VEMD do?
• Updates the Identity Awareness PDPD daemon (via the VEM process) about the
changes in virtual objects that were configured on the vSEC Gateway.
HOL-1824-01-NET
• These updates are required in order to update the Source / Destination fields in
the FireWall logs.
Useful Information:
1. Path: $FWDIR/bin/vemd
2. Log file: $FWDIR/log/vemd.elg
Commands:
1. Debug:
• Start the debug: [Expert@HostName:0]# vem debug on

• Stop the debug: [Expert@HostName:0]# vem debug off
• Analyze: $FWDIR/log/vemd.elg
• Analyze: $FWDIR/log/vem.elg
HOL-1824-01-NET
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!
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:
• Click on this link

• Or go to http://tinyurl.com/nx5qxca
• Or use your smart device to scan the QRC Code.
Proceed to any module below which interests you most.
• Module 1 - Check Point Introduction, Configuration (30 minutes) (Getting

started)
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.

minutes) (Advanced)
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.
and quarantine application VMs using NSX security group tagging.
HOL-1824-01-NET
With AV alone, bot infections are typically undetected exposing the SDDC to serious
risk.
How to End Lab
HOL-1824-01-NET
Module 3 - Advanced
Security Seamlessly
Embedded into NSX (30
minutes) (Advanced)
HOL-1824-01-NET
Introduction
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-1824-01-NET
• Check Point management server installed with vSEC controller add-on.

• NSX managed environment with 2 security groups: web server running Apache
and DB server running MySQL.
• vSEC service deployed on ESXi cluster.

HOL-1824-01-NET
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.

HOL-1824-01-NET
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


HOL-1824-01-NET
page.

3. Click Login
Navigate to Networking and Security

HOL-1824-01-NET
On the next screen after logging in, perform the following selections:
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 configuration
1. Click on NSX Managers. In the next step, click on NSX Managers to expand.
Select NSX Manager
1. Select NSX Managers link on the left side navigation pane.

2. Click on NSX Manager with IP address 192.168.110.42

HOL-1824-01-NET
Review Security Tags
After expanding NSX Manager 192.168.110.42, perform the following steps:
1. Click on the Manage tab

2. Click Security Tags tab
You are presented with a list of Security Tags that can be utilized by NSX Manager. You
can see that most of them are natively created by VMware but you have 2 extras that
have been created by Check Point (Anti-bot and Anti-virus).
Now you know where the security tag comes from for usage in the vSEC integration with
NSX Manager.

HOL-1824-01-NET
Review Infected Machines Security Group
Next, perform the following steps:
1. On the top left corner, Click the Back button a few times until you return to the
Networking & Security tree
2. Select Service Composer to see the different Security Groups.
3. Select the "Infected_VMs" Security Group, right click and select "Edit Security
Group".
4. Select the "Define dynamic membership". Review the inclusion criteria to
understand how the security tags are being used.
Open the Check Point SmartConsole

HOL-1824-01-NET
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.
Logging into the SmartConsole

control button.
1. Username: admin
3. Click Login
Review SmartConsole Infected Machines rules
On the next screen after logging in, perform the following selections:
1. On the left side navigation panel, select Security Policies

2. Select Policy
3. Take a look at rules numbered 4 & 5 to understand what access the Infected_VMs
have

HOL-1824-01-NET
We can now understand how Check Point vSEC Gateway identifies VMs as infected and
automatically isolates adn quarantines them by tagging the infected VM and sharing
this information with the NSX controller. This allows us to quickly contain threats and
the apply the appropriate remediation service to the infected VM.

HOL-1824-01-NET
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
Initiating a Bot Attack

HOL-1824-01-NET
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

control button.
1. Username: admin
3. Click Login
Review Logs
Upon login, on the left side navigation pane:

HOL-1824-01-NET
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.

HOL-1824-01-NET
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

HOL-1824-01-NET
Log into the vSphere Web Client

HOL-1824-01-NET

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

3. Click Login
Review Web server configuration
From left side navigation panel, select:

HOL-1824-01-NET
1. Select VMs and Templates
Review Web Server configuration
1. Select WebSRV
Review Security Tags
1. Click on the Summary Tab.

HOL-1824-01-NET
2. In the Security Tags box, you now see this VM has the Check_Point.BotFound
security tag assigned to it.
3. In the Security Groups Membership box, you see that WevSRV is a member of
the following security group: Infected_VMs group.
Now the WebSRV VM is isolated with no possibility to connect / infect other VMs/Servers
in the same enviroment.
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.

HOL-1824-01-NET
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.

HOL-1824-01-NET
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

HOL-1824-01-NET
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.

HOL-1824-01-NET
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!
How to End Lab

HOL-1824-01-NET
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

Hol 1824 01 Net - PDF - en PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Hol 1824 01 Net - PDF - en PDF

Caricato da

Copyright:

Formati disponibili

HOL-1824-01-NET

Regarding Screen Resolution: Main Console screen resolution is set for

Lab Module List:

• Module 1 - Check Point Introduction and Configuration (30 minutes)

• Module 3 - Bot Detection, Quarantine, and Incident Response (30

• Lab Manual - Hau Tran, Sr. Systems Engineer, USA

Location of the Main Console

Activation Prompt or Watermark

This cosmetic issue has no effect on your lab.

Alternate Methods of Keyboard Data Entry

Click and Drag Lab Manual Content Into Console Active

Accessing the Online International Keyboard

Click once in active console window

1. Click once in the active console window.

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

Module 1 - Check Point

This module contains the following lessons:

• Begin the tour of Check Point vSEC Components

1. VMware vCenter Server and NSX Manager are deployed.

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.

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

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.

• Check Point management server installed with vSEC controller add-on.

Exploring the VMWare Environment

Opening vSphere Web Client

In the Main Console desktop, launch Chrome from:

1. The Chrome shortcut in the Taskbar or

Login To vSphere Web Client

1. Enter Username administrator@corp.local

Note: The username and password should be defaulted.

Access to vSphere Web Client

Navigate vSphere Web Client

Locate Dynamic Data Center Content

Let's take a look at one of the VM's in our inventory.

1. Click on WebSRV in the Navigation panel.

A VM reboot may be required

Navigate to the Home Screen

Consuming vSEC through Service Composer

How does it work?

To truly perceive the effectiveness, efficiency, and elegance of complementary security

Three VMware NSX components are involved:

Let's navigate to NSX Service Composer.

NSX Manager Security Groups

From the Home drop down:

1. Select Networking & Security

Review Security Groups

View the Details of the Security Groups

View Which Servers Are Included In A Security Group

In subsequent modules we will be working with these virtual machines to generate

View the Virtual Machines in Web-Group

Exit the group

Create A Security Group

Let's create a Security Group.

Name the Security Group

1. Enter App_Group for the Security Group name.

Define Membership Criteria