Escolar Documentos
Profissional Documentos
Cultura Documentos
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 Page 2
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.
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.
HOL-1824-01-NET Page 3
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.
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
HOL-1824-01-NET Page 4
HOL-1824-01-NET
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.
When you first start your lab, you may notice a watermark on the desktop indicating
that Windows is not activated.
HOL-1824-01-NET Page 5
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.
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.
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 Page 6
HOL-1824-01-NET
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.
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.
HOL-1824-01-NET Page 7
HOL-1824-01-NET
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 Page 8
HOL-1824-01-NET
HOL-1824-01-NET Page 9
HOL-1824-01-NET
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.
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:
2. vSphere Data Center, Cluster, and Data Center objects are configured.
6. IP address pool to be used for the vSEC Gateways has been created.
8. The vSEC Security Gateway Service is configured and the vSEC Controller is
registered to vCenter and NSX Manager respectively.
HOL-1824-01-NET Page 10
HOL-1824-01-NET
12. Best Practice: Spoof Guard is enabled for the port group.
Environmental Components:
HOL-1824-01-NET Page 11
HOL-1824-01-NET
HOL-1824-01-NET Page 12
HOL-1824-01-NET
Login into the vSphere Web Client. The vSphere Web Client should be the default home
page.
HOL-1824-01-NET Page 13
HOL-1824-01-NET
You are presented with the vSphere Web Client home view.
1. Click on the VMs and Templates icon from the Navigation pane.
HOL-1824-01-NET Page 14
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.
HOL-1824-01-NET Page 15
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.
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 Page 16
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
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.
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 Page 17
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.
HOL-1824-01-NET Page 18
HOL-1824-01-NET
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 Page 19
HOL-1824-01-NET
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.
Notice the columns have the count of VMs associated with the Security Groups.
HOL-1824-01-NET Page 20
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.
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 Page 21
HOL-1824-01-NET
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.
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 Page 22
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.
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 Page 23
HOL-1824-01-NET
The Security Group Wizard Opens up and we can begin creating the new Security Group.
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.
For this example, we want to create a Security Group for servers with "App" in the
name:
HOL-1824-01-NET Page 24
HOL-1824-01-NET
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.
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
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 Page 25
HOL-1824-01-NET
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.
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.
HOL-1824-01-NET Page 26
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.
We are now back to the Service Composer screen where we can confirm that the
App_Group Security Group was created.
HOL-1824-01-NET Page 27
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.
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.
HOL-1824-01-NET Page 28
HOL-1824-01-NET
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.
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 Page 29
HOL-1824-01-NET
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 Page 30
HOL-1824-01-NET
You are presented with Edit Security Group window for the Infected_VM Security Group.
HOL-1824-01-NET Page 31
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.
HOL-1824-01-NET Page 32
HOL-1824-01-NET
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:
HOL-1824-01-NET Page 33
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.
1. Username: admin
2. Password: VMware1!
3. Click Login.
HOL-1824-01-NET Page 34
HOL-1824-01-NET
• Dynamic Enforcement
• Data Center Micro Segmentation
• Advanced Threat Prevention Scenarios
HOL-1824-01-NET Page 35
HOL-1824-01-NET
This is the GUI console used to view security logs in real time.
HOL-1824-01-NET Page 36
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.
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 Page 37
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.
HOL-1824-01-NET Page 38
HOL-1824-01-NET
HOL-1824-01-NET Page 39
HOL-1824-01-NET
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
HOL-1824-01-NET Page 40
HOL-1824-01-NET
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 Page 41
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
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.
HOL-1824-01-NET Page 42
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 43
HOL-1824-01-NET
Login into the vSphere Web Client. The vSphere Web Client should be the default home
page.
HOL-1824-01-NET Page 44
HOL-1824-01-NET
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 Page 45
HOL-1824-01-NET
Stay right where you are in NSX Manager, and now click on the Service Deployments
tab.
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.
It is for the vSEC Gateway service during deployment to as part of its autoconfigure
process.
HOL-1824-01-NET Page 46
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 Page 47
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.
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 Page 48
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.
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 Page 49
HOL-1824-01-NET
1. Username: admin
2. Password: VMware1!
3. Click Login.
HOL-1824-01-NET Page 50
HOL-1824-01-NET
• Dynamic Enforcement
• Data Center Micro Segmentation
• Advanced Threat Prevention Scenarios
1. Highlight rule #1
2. Click on the Add rule below button.
HOL-1824-01-NET Page 51
HOL-1824-01-NET
HOL-1824-01-NET Page 52
HOL-1824-01-NET
Select Objects
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 Page 53
HOL-1824-01-NET
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.
1. Double Click in the Name field of the rule we just created and enter the name
Web Rule.
HOL-1824-01-NET Page 54
HOL-1824-01-NET
HOL-1824-01-NET Page 55
HOL-1824-01-NET
HOL-1824-01-NET Page 56
HOL-1824-01-NET
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 Page 57
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!
If you are looking for additional information on Securing the SDDC with Check Point
vSEC and NSX, try one of these links:
• 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.
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.
HOL-1824-01-NET Page 58
HOL-1824-01-NET
With AV alone, bot infections are typically undetected exposing the SDDC to serious
risk.
HOL-1824-01-NET Page 59
HOL-1824-01-NET
HOL-1824-01-NET Page 60
HOL-1824-01-NET
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.
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.
• 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 Lab Notes: This HOL Check Point partner lab environment has been prepared and
the following configuration steps have already been completed:
2. vSphere Data Center, Cluster, and Data Center objects are configured.
6. IP address pool to be used for the vSEC Gateways has been created.
HOL-1824-01-NET Page 61
HOL-1824-01-NET
8. The vSEC Security Gateway Service is configured and the vSEC Controller is
registered to vCenter and NSX Manager respectively.
12. Best Practice: Spoof Guard is enabled for the port group.
Environmental Components:
HOL-1824-01-NET Page 62
HOL-1824-01-NET
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 Page 63
HOL-1824-01-NET
HOL-1824-01-NET Page 64
HOL-1824-01-NET
Login into the vSphere Web Client. The vSphere Web Client should be the default home
page.
HOL-1824-01-NET Page 65
HOL-1824-01-NET
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 Page 66
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
HOL-1824-01-NET Page 67
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!
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?
HOL-1824-01-NET Page 68
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.
1. Username: admin
2. Password: VMware1!
3. IP: 192.168.110.16
HOL-1824-01-NET Page 69
HOL-1824-01-NET
• Dynamic Enforcement
• Data Center Micro Segmentation
• Advanced Threat Prevention Scenarios
Review rules
View rule numbers: 6 & 7 to see the allowed traffic between the two servers.
• MS-SQL
• ICMP-Requests
HOL-1824-01-NET Page 70
HOL-1824-01-NET
Now, we will view the logs to see the vSEC gateway traffic. On the left side navigation
bar:
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.
HOL-1824-01-NET Page 71
HOL-1824-01-NET
Search on the logs for traffic originating from the Web Server to the DB Server. Look for
entries with "Web_Group"
1. Click on the "X" at the upper right side to close this window.
2. Minimize the SmartConsole Window
HOL-1824-01-NET Page 72
HOL-1824-01-NET
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
1. ./change_ip.sh
Note: You will lose connectivity to that server after you run this command.
HOL-1824-01-NET Page 73
HOL-1824-01-NET
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 Page 74
HOL-1824-01-NET
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
HOL-1824-01-NET Page 75
HOL-1824-01-NET
After validation that the IP address has been changed, try to communicate from the
WebSVR to the DBsrv.
Now go back to the SmartConsole (Hint: It should be minimized in the Windows tray).
On the left side navigation bar:
Review logs
Look for the new logs from the new IP address (192.168.120.52)
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 Page 76
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.
1. Select the WebSRV on the left hand tree and right Click, choose Rename.
2. Change the name to: "Generic-SRV". Wait 30 seconds.
Revert back to the 192.168.120.51 Putty session (Hint: The session minimized in the
Windows tray).
HOL-1824-01-NET Page 77
HOL-1824-01-NET
Lets review why the connection has failed. Revert back to the vSphere Web Client (Hint:
Chrome browser).
HOL-1824-01-NET Page 78
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.
HOL-1824-01-NET Page 79
HOL-1824-01-NET
1. On the left hand navigation of the vSphere Web Client, select "VMs &
Templates".
HOL-1824-01-NET Page 80
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
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:
HOL-1824-01-NET Page 81
HOL-1824-01-NET
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:
Hint: You can Click on the number "1" to see which VM is part of the Security Group!
HOL-1824-01-NET Page 82
HOL-1824-01-NET
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.
HOL-1824-01-NET Page 83
HOL-1824-01-NET
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 Page 84
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:
HOL-1824-01-NET Page 85
HOL-1824-01-NET
HOL-1824-01-NET Page 86
HOL-1824-01-NET
• 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.
HOL-1824-01-NET Page 87
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:
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.
• 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
• 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 Page 88
HOL-1824-01-NET
vSEC Databases
vSEC Gateway
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 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:
HOL-1824-01-NET Page 89
HOL-1824-01-NET
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.
Useful Information:
1. Path: $FWDIR/bin/fwm
2. Log file location: $FWDIR/log/fwm.elg
Commands:
HOL-1824-01-NET Page 90
HOL-1824-01-NET
Notes:
Useful Information:
Commands:
Notes:
Useful Information:
HOL-1824-01-NET Page 91
HOL-1824-01-NET
1. Path: $FWDIR/bin/fwcloud
2. Log file: $FWDIR/log/fwcloud.elg
Commands:
Notes:
• Web service that listens for Threat Prevention Tagging commands sent from vSEC
Gateway and then tags the infected VM in VMware NSX.
Useful Information:
Commands:
HOL-1824-01-NET Page 92
HOL-1824-01-NET
Notes:
Useful Information:
1. Path: $FWDIR/bin/cpved
2. Log file: $FWDIR/log/CPVED.elg
Commands:
Notes:
• Script that enables (vsec on) vSEC / disables (vsec off) vSEC.
Useful Information:
HOL-1824-01-NET Page 93
HOL-1824-01-NET
1. Path: $FWDIR/bin/vsec
2. Log file: None
Commands:
1. Debug:
Notes:
Useful Information:
1. Path: $FWDIR/bin/vsec_config
2. Log file: $FWDIR/log/vsec_config.elg
Notes:
• Useful Information:
1. Path: $FWDIR/bin/fwk
2. Log file: $FWDIR/log/fwk.elg
Commands:
HOL-1824-01-NET Page 94
HOL-1824-01-NET
Notes:
• 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:
• 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 Page 95
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:
HOL-1824-01-NET Page 96
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!
If you are looking for additional information on Securing the SDDC with Check Point
vSEC and NSX, try one of these links:
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.
HOL-1824-01-NET Page 97
HOL-1824-01-NET
With AV alone, bot infections are typically undetected exposing the SDDC to serious
risk.
HOL-1824-01-NET Page 98
HOL-1824-01-NET
Module 3 - Advanced
Security Seamlessly
Embedded into NSX (30
minutes) (Advanced)
HOL-1824-01-NET Page 99
HOL-1824-01-NET
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.
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.
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:
2. vSphere Data Center, Cluster, and Data Center objects are configured.
6. IP address pool to be used for the vSEC Gateways has been created.
8. The vSEC Security Gateway Service is configured and the vSEC Controller is
registered to vCenter and NSX Manager respectively.
12. Best Practice: Spoof Guard is enabled for the port group.
Environmental Components:
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
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.
Login into the vSphere Web Client. The vSphere Web Client should be the default home
page.
On the next screen after logging in, perform the following selections:
1. Click on NSX Managers. In the next step, click on NSX Managers to expand.
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.
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.
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.
1. Username: admin
2. Password: VMware1!
3. Click Login
On the next screen after logging in, perform the following selections:
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.
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.
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!
1. ./propogate_bot.sh
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.
1. Username: admin
2. Password: VMware1!
3. Click Login
Review Logs
Review the logs and see how the WebSRV in being identifid as a Bot infected and then
inserted into the Infected_VMs group.
Once you see that activity in the logs, on the left side navigation pane:
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:
Check to see if the connection can be established, you should see the Ping results
Log into the vSphere Web Client. The vSphere Web Client should be the default home
page.
1. Select WebSRV
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.
From NSX Manager, security tags can be assigned or detached by the VMware
administrator or Security team using vSphere Web Client.
1. Click on NSX Managers. In the next step, click on NSX Managers to expand.
First:
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.
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!
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.
Version: 20170920-131115