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


Important Message Before Proceeding

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.  This is only applicable if you have just launched the lab itself.


 

Conduct a Lab Status Check - If Applicable

 

The following is not applicable for current sessions.  If you are simply transitioning from the previous section to the next module you may proceed as normal to the next screen.  However, if you just launched this lab seconds ago, follow these Lab Status Check instructions.  

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Lab Overview - HOL-1823-01-NET - Palo Alto Networks Next-Generation Security Platform on VMware NSX

Lab Guidance


Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

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

How do you accelerate the deployment of business-critical applications without compromising security? How do you define dynamic security policies to protect against cyberthreats while keeping pace with data center virtualization?

VMware and Palo Alto Networks have partnered to deliver a solution that combines fast provisioning of network and security services with next-generation security in the data center. In this lab, learn how to configure the Palo Alto Networks virtualized next-generation firewall VM-300 with VMware NSX to secure VM to VM communications.

Network virtualization provides speed and flexibility when provisioning network and network services in the virtualized datacenter. But what is more important than speed and flexibility when provisioning such virtualized networks? Security and the securing of your virtualized networks!

Securing your VMs, your databases, your webservers, your file servers and your data stores should be of paramount importance to you and to the reputation of your company. Therefore, here within this hands-on-lab, you will learn how to do just that using the latest in next-generation enterprise security – The Palo Alto Networks VM-Series Firewall platform as integrated with VMware NSX.

Lab Module List:

 

Lab Captains:
Nithya NATESAN, Technical Marketing Engineer, Palo Alto Networks
Hassan HAMADE, Cloud Solution Architect, VMware

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

http://docs.hol.vmware.com

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

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


 

Location of the Main Console

 

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

 

 

Alternate Methods of Keyboard Data Entry

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

 

 

Click and Drag Lab Manual Content Into Console Active Window

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

 

 

Accessing the Online International Keyboard

 

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

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

 

 

Activation Prompt or Watermark

 

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

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

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

This cosmetic issue has no effect on your lab.  

 

 

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.

 

Lab Objectives and Development Notes


The lab objective is to demonstrate the capabilities of the Palo Alto Networks VM-Series firewall working in conjunction with Panorama, and how both integrate with VMware NSX. In addition, a main objective of this lab is to provide you with valuable hands-on experience for the purpose of learning how to deploy and configure this joint solution.

This lab uses the following components:


Key Concepts and terms

Some Components and Concepts of VMware and Palo Alto Networks


Before jumping into the modules it will be helpful to learn more about some of the key components, concepts and terms that you will be working with.  Here are overviews and descriptions of important components.   


 

VMware NSX

 

VMware NSX is the leading network virtualization platform that delivers the operational model of a virtual machine for the network. Just as server virtualization provides flexible control of virtual machines running on a pool of server hardware, network virtualization with NSX provides a centralized API to provision and configure many isolated logical networks that run on a single physical network.

Logical networks decouple virtual machine connectivity and network services from the physical network, giving cloud providers and enterprises the flexibility to place or migrate virtual machines anywhere in the data center while still supporting layer-2 / layer-3 connectivity and layer 4-7 network services.

 

Lab Architecture and topologies

Lab Architecture and topologies


The following diagrams illustrate physical and logical topologies implemented for this Lab:


 

Physical Topology

 

Two ESXi clusters will be deployed: RegionA01-COMP01 and RegionA01-MGMT01.

RegionA01-COMP01 is a compute cluster where workloads will be instantiated and connected to a logical switch. VMs from HR, Legal and Marketing organizations will be deployed there.

RegionA01-MGMT01 is a management cluster where control plane components of NSX will be instantiated. NSX controllers are typically hosted there (NSX controllers control VXLAN operations on compute clusters). 

 

 

Logical Topology for HR Organization

 

Three VMs from HR organization (two web servers and one DB server) are instantiated and connected to the same logical switch (VXLAN).

Traffic protection is enforced as follows:

-Inter-tier traffic (web server to DB server) is protected by the Palo Alto Networks VM-series firewall which provides advanced security capabilities with its single pass architecture in the form of App-ID, Content-ID, and User-ID.

-Intra-tier traffic (web server to web server) is protected by NSX DFW which provides near line rate performance for L2-L4 security functions. 

 

 

 

Three VMs from the Legal organization (two web servers and one DB server) are instantiated and connected to the same logical switch (VXLAN).

Traffic protection is enforced as following:

-Inter-tier traffic (web server to DB server) is protected by the Palo Alto Networks VM-series firewall which provides advanced security capabilities with its single pass architecture in the form of App-ID, Content-ID, and User-ID.

-Intra-tier traffic (web server to web server) is protected by NSX DFW which provides near line rate performance for L2-L4 security functions. 

Legal organization VMs are using the exact same IP addresses than HR organization VMs. The objective here is to outline the multi-tenancy  support with the NSX/Palo Alto Networks joint integration solution.

 

 

Logical Topology for Marketing Organization

 

Two VMs from the Marketing organization (one web server and one DB server) are instantiated and connected to the same logical switch (VXLAN).

Traffic protection is enforced as follows:

-Inter-tier traffic (web server to DB server) is protected by the Palo Alto Networks VM-series firewall which provides advanced security capabilities with its single pass architecture in the form of App-ID, Content-ID, and User-ID.

-Intra-tier traffic (web server to web server), when more web server VMs are added to the Marketing Organization, is protected by NSX DFW which provides near line rate performance for L2-L4 security functions. 

 

Important Message Before Proceeding with Module 1

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.


 

Conduct a Lab Status Check

 

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Module 1 - Palo Alto Networks VM-Series and VMware NSX dynamic security policy configuration (30 Mins, Intermediate)

Module 1 Overview


During this first lab you will focus on how to create dynamic security policies on the Palo Alto Networks VM-300 based on context from VMware NSX. Specific tasks will include: 

To successfully complete this module you will need to identify and correct ill configured settings within your policies, tags, and/or grouping.

At times during this lab, you will need to enter commands, usernames, and passwords using Command Line Interface (CLI) commands. Therefore, a text file named “README.txt” has been placed on the desktop of the environment so that you can easily reference these commands which will allow you copy and paste complex commands or passwords in the associated utilities CMD, Putty, console, etc., as necessary.

This README.txt file is divided into Module Sections and numbered. The manual will have a number associated with every CLI command. That command will be numbered in the README.txt file for you to copy and paste. Certain characters are often not present on keyboards throughout the world. This README.txt file also includes keyboard layouts which do not provide those characters.

Thank you and enjoy the labs!


Environment Setup


vCenter Login: Make sure the environment and all its systems, are up and running by checking within vCenter.  To do so launch and login to vCenter.    


 

vSphere Web Client to access vCenter

 

  1. Launch the Google Chrome browser and click on the vSphere Web Client bookmark.  
  2. To login to vCenter, simply check the box high-lighted and click Login.  You will not need to enter any credential values within either field for User name or Password.

Important note: your very first login to the vCenter Web Client might take up to 90 seconds, so please be patient. The subsequent logins will be faster (around 25 seconds).
The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware technologies.

 

 

vSphere Web Client to access vCenter

 

When logged into the vSphere web client, to view your datacenter.

  1. Click on the Home tab.
  2. Select Hosts and Clusters.

 

 

vCenter View

 

  1. Expand the vcsa-01a.corp.local > RegionA01 > RegionA01-COMP01 tree view on the left side of your screen so that you can see a listing of all of your running virtual systems running within this Datacenter Site A.  

Each of the high-lighted systems above should have an illuminated green arrow indicating the specified system is up and running.  At this time take a moment to click on some of these virtual systems to make sure they are indeed up and running.

  1. In addition, check the Summary tab for a few of them to see the information available such as CPU information, memory allocation, disk space, etc., for these VMs.  In the example here, the Summary tab information of the hr-web-02 web server is displayed.   

Please Note: It is likely your Tree view listing is slightly different than what you see here. If so, that is ok. The other VMs you are seeing will be used later during the last labs found in modules 3 and 4. At this time we are just checking to make sure all of the virtual systems are up and running as reflected by the green arrow preceding the name of each VM. Once that is done please continue ignoring the other VMs listed.

 

Examining the NSX Security Groups within NSX Manager


View the existing Security Groups by navigating to Networking & Security.


 

Networking and Security

 

  1. Go to the Home page.
  2. Click on Network & Security from either the left menu tree panel, or from the Inventories section of the Home tab.

 

 

Examining your Dynamic Address Groups


It's now time to introduce you to Panorama by Palo Alto Networks. As previously mentioned, Panorama provides centralized management for all of your physical and/or virtual Palo Alto Networks firewalls.  Panorama itself is available as either a dedicated management appliance or as a virtual machine.

Now login to Panorama to take a look at the Dynamic Address Groups. To do so, open a new browser tab within your current Chrome browser and click on the Panorama bookmark.

 


 

Panorama Login

 

After launching Panorama, by opening a new browser tab within your current Chrome session and clicking on the Panorama bookmark, your browser should display the Panorama login screen.  The credentials to login are:

              Username = admin

              Password = VMware1!

 

 

Examining the Security Policies


Security policies play a crucial role on firewalls.  As you know, these security policies state what can and cannot traverse the firewall. Applications like ping, SSH, FTP, etc., (among many others), going to and from various zones, while running on various ports, can be permitted or denied.  Take a look at what security policies are in place here within our environment.  


 

Policies Tab and Security Pre Rules

 

While still logged into Panorama, examine the security policy.  To do so click on the 1) Policies tab.  Then 2) make sure you're viewing the Pre-Rules of your Security policies from the left tree panel.  Then looking to the right under the "Name" column notice you have three rules.  Verify you have a policy rule for your HR web-server to HR database server traffic. This rule is called "HR Web to DB".  Familiarize yourself with this rule by looking at the field headers for each of the configurations.  Notice your Source and Destination Address settings and that this policy allows mysql traffic between the two. 

Let's now do some testing of these rules by generating some traffic. Without making any changes here move on to the next step.

 

 

Generating Traffic from your Web Server to the Database


At this time you are ready to do some testing.  Do so by generating certain types of traffic from the Web server to the Database server.  

Since you've just checked our security policies, you already know the types of traffic that will be allowed, or denied, between these two servers.  Now generate some traffic for the purpose of testing to make sure everything works as expected. If so, great!  But if not, then you will need to troubleshoot to find out why the tests failed.  Then once you know the reason why, you'll need to implement the solution to resolve.


 

Generating Traffic from hr-web-01

 

To generate some traffic let's begin by logging into the web server using "putty.exe".  You'll notice you already have a desktop icon and so simply click on the "hr-web-01" desktop icon.    

You will be logged in automatically as the username and password have been entered and saved for you.  In the event you need to manually enter the username and password to login, please see the README.txt file on the desktop for the credentials.

 

 

Troubleshooting Traffic Steering Problem


You need to determine what is preventing the VM-Series firewall from seeing the traffic generated during the PING test.  Start by checking the Dynamic Address Groups for both the HR web server and the HR database server.


 

Dynamic Address Groups as Listed and Configured within Panorama

 

1) From within Panorama click on the Objects tab. 2) Then make sure the left tree panel selection is "Address Groups".  Note there are currently two Dynamic Address Groups listed.  Check the HR-Web-Servers group first. Specifically, check the IP addresses of the "HR-Web-Servers" Dynamic Address Group (DAG).  3) To see these IP addresses you will need to click on "more" under the Addresses column.  

 

Preparing to Generate Database Traffic With Logging


Logs are an effective tool that can be used not only for reporting purposes, but for also enabling you to track and see what's taking place on the network. Then based upon what you're seeing, you can adjust accordingly to ensure a safe and secure network.  Additionally, you can use logs for troubleshooting purposes as well which is what you will continue to do next.  So in preparation for the next set of tests you will want to do some minor maintenance to the logs. This will ensure the logs you are seeing are both current and accurate.


 

Checking Traffic Logs

 

1) Notice the logs within the last 15 minutes of which there should be very few.  Most likely there will be only two log entries such as is displayed here.  Of the logs listed there should only be entries for the ping test that was run successfully.

Remember, you can always change the filter and you can always do a manual refresh.  Here the filter is set to the minimum setting of "Last 15 Minutes" and so set yours to the same if not already done so and then do a "Manual refresh".

Now continue to generate more log traffic but this time generate some database table calls.  To do so proceed to the next step.  

 

Generating Database Table Calls


For this step generate more traffic through the firewall using a database table call. To do so run a mysql command from one of the Web servers to the database.


 

Database Query

 

For this step use the README.txt file located on the desktop.  Open this file and under Module 1, look for the high-lighted command circled in red above. Copy this command to the clipboard from within the README.txt.  

The command to enter is:

mysqlshow --user=root --password=VMware1! --host=hr-db-01 employees employees

 

 

App-ID by Palo Alto Networks


What is App-ID?

App-ID is a patented traffic classification system developed by Palo Alto Networks. App-ID provides the ability to determine what application is traversing through the VM-Series firewall irrespective of the port, protocol, encryption (SSH or SSL) or any other evasive tactic that may be used by a suspect application.

How does App-ID work?

App-ID applies multiple classification mechanisms, application signatures, application protocol decoding, and heuristics to your network traffic stream to accurately identify applications.  All traffic is then matched against policy to check whether this type of traffic is allowed or not on the network or between your VMs.  Signatures are then applied to the allowed traffic identifying the application based on its unique application properties and its related transaction characteristics. These signatures also determine if the application is being used on its default port or is using a non-standard port. If the traffic is allowed by policy, the traffic is then scanned for threats and further analyzed for identifying the application in more detail.

What if the traffic is encrypted?  

App-ID has the ability to identify encrypted traffic determining the type of encryption (SSL or SSH) in use.  If a decryption policy is in place the session is decrypted and the application signatures are applied again on the decrypted flow.  Decoders for known protocols are then used to apply additional context-based signatures to detect other applications that may be tunneling inside of the protocol (e.g., Yahoo! Instant Messenger used across HTTP).  Afterwards decoders validate that the traffic conforms to the protocol specification and provide support for NAT traversal and opening dynamic pinholes for applications such as SIP and FTP.

Now that you know more about App-ID see how it works in action within the last remaining steps of this lab.  


App-ID for SSH


Within this step you'll see how, and why, ssh is blocked between the two VMs (hr-web-01 and hr-db-01).


 

Policies within Panorama

 

Go back to your browser and select the Panorama tab.  If necessary, login into Panorama.  

1) Once logged into Panorama review the current policy settings by clicking on the Policies tab.

2) From within the left tree panel view, make sure you are looking at the "Pre Rules" of the Security policy.  

3) Note the three policy rules which only allow the ping and mysql applications while denying everything else.

 

Lab 1 - Conclusion


During this lab it was demonstrated how to go about the protecting of inter-tier application traffic - also referred to as east-west traffic. To do so you used the VM-Series firewall and the Panorama management station to integrate Palo Alto Networks security with VMware NSX. This stateful synchronization is possible through the Palo Alto Networks VM-1000 HV’s ability to maintain constant awareness of the changes made within the datacenter as it pertains to the ever adding, moving, and deleting of virtual machines, their applications AND their dynamic IP addressing. But that’s only half of the story. The other half includes the capabilities of the VMware NSX Manager which enables the synchronization that takes place between the Palo Alto Networks Dynamic Address Groups, and the VMware NSX Manager’s Security Groups, providing full datacenter awareness, and datacenter protection like no other.  Because it all takes place automatically. In fact, during the next module you walk you through a lab where you’ll see just how automatic everything is and how easily everything integrates to ensure an ever aware and secure datacenter. 


Important Message Before Proceeding with Module 2

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.  This is only applicable if you have just launched the lab itself.


 

Conduct a Lab Status Check - If Applicable

 

The following is not applicable for current sessions.  If you are simply transitioning from the previous section to the next module you may proceed as normal to the next screen.  However, if you just launched this lab seconds ago, follow these Lab Status Check instructions.  

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Module 2 - Deploying Palo Alto Networks VM-Series on VMware NSX to protect a multi-tier application in a multi- tenant environment (45 Mins, Advanced)

Securing the Data Center with the Palo Alto Networks VM-Series Firewall


VMware NSX DFW and Palo Alto Networks VM-Series are extremely complementary to one another in that both are designed to protect Virtual Data Center East-West traffic.

DFW provides in-kernel, stateful, port-based inspection while VM-Series provides next-generation firewall functionality which includes the advanced threat prevention capabilities of; IPS, anti-virus, anti-malware, data/file filtering, and DOS protection services, to name a few.

Within a data center a typical application structure is composed of multiple tiers.  In a 3-tier application, VMs are partitioned across WEB, APP, and DB tiers.  Each tier can be instantiated by a logical switch (VXLAN) or by a DVS port-group (VLAN).  This L2 broadcast domain is connected to a DLR (Distributed Logical Router) to enable inter-tier communications (the IP address of the DLR logical interface becomes the default GW for guest VMs).

DFW and VM-Series co-exist extremely well with both devices performing complementary roles to one another.  To properly design the security services architecture in a virtual data center environment, follow these recommendations:

 


 

Complementary use of DFW and VM-Series for Intra-Tier and Inter-Tier Traffic Protection

 

The diagram above shows the repartition of roles between the two components. Notice the traffic between the WEB servers is protected by DFW (with the same behavior for traffic between the APP servers as well for traffic between the DB servers).

With DFW, access control based on L2/L3 services and L2/L3 addresses is sufficient to prevent any lateral movement, or attack, from hackers.  For instance, L2 rules may control the ARP protocol while L3 rules can control the communications on specific TCP/UDP ports.

Also notice the traffic from the WEB server to the APP server (as well as traffic from the APP server to the DB server) is also protected by the VM-Series firewall.  This Inter-Tier traffic also contains critical data that must be deeply analyzed (up to layer 7) to prevent any threats or the propagation of malware across the different systems. This is how the VM-Series firewall reduces the attack surface by safely enabling only the applications that are allowed between the tiers while blocking everything else.

VM-Series sits off the data path.  This significantly reduces the need to design a complex virtual network topology as no change is required when inserting security services for VM to VM communications.  In order to leverage VM-Series, workload traffic must be redirected to the virtual appliance.  NSX provides a successful, granular, method for specifying the traffic that must be redirected to the VM-Series.  

A traffic redirection rule is based on Source/Destination/Service attributes (Source and Destination field can use any vCenter objects such as; VM name, Cluster, Resource Pool, or Security Groups.  The Service field can use any TCP/UDP port).  In consequence, it is very easy to define traffic from a specific Source VM to a specific Destination VM (with destination TCP port 443 for instance) while making sure that traffic is redirected to the VM-Series firewall for inspection.  In the same way, it is just as easy (as before) to specify traffic from a group of WEB VMs to a group of APP VMs (with the same destination TCP port) while making sure that traffic is also redirected to the VM-Series.  

 

 

Module Overview


Within this in-depth module, VMware NSX and the Palo Alto Networks VM-Series platform are configured to secure a multi-tier application (with web front-end servers and database back-end servers) in a multi-tenant environment. 

Legal organization VMs are used for the purpose of this module. Legal organization VMs are using the exact same IP addresses as HR organization VMs.

Throughout the module itself we will show how to define dynamic security policies on the VM-300 virtual firewalls based on context from VMware NSX. Take a look at the learning objectives where you will be focusing on how to deploy the Palo Alto Networks VM-Series platform while walking through each Lesson. These lessons will enable you to gain an understanding of, as well as perform, the following: 


Module Objectives and Development Notes


This is an in-depth module focusing on how to deploy Palo Alto Networks VM-Series while walking through each step from registration to security policy configuration.  Steps related to VMware NSX traffic steering are not included, i.e. student is assumed to have basic understanding of VMware NSX.  For this module the following servers will be used:

Management:

Application Servers:

Pre-configuration is required for the NSX Manager, vCenter, Panorama, hosts, and application servers

 


Review Security Tags for Legal Servers


Begin by ensuring the security tags for the servers of the Legal department are in order:


 

vSphere Web Client

 

Using the Google Chrome browser desktop icon, launch Chrome and select the bookmark titled, "Site A Web Client" within the favorites bar. After being directed to the VMware vCenter Single Sign-on page, check the "Use Windows session authentication" option and click "Login".

Important note: if you are loging in the vCenter Web Client for the first time, the login process might take up to 90 seconds, so please be patient. The subsequent logins will be faster (around 25 seconds).
The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware technologies.  

 

 

Hosts and Clusters

 

Once logged in, and from the 2) Home screen, click on 3) Hosts and Clusters.

 

 

Create NSX Service Profile for Multi-Tenancy


During this stage you need to create and define the Palo Alto Networks Security Zone used for multi-tenancy. We will create a new Security Zone for the Legal Department called "Palo Alto Networks profile Lgl" Notice the default zone "Palo Alto Networks profile 1 currently exist and will be used for all other traffic.


 

Back into Panorama

 

If Panorama is still up and running, access Panorama via the browser bookmark tab. If Panorama is no longer running, open the Chrome browser and click on the Panorama bookmark. Or you may launch the Panorama desktop icon to launch and login to Panorama.

  Username = admin

  Password = VMware1!

 

Verify the NSX Service Profile within the Palo Alto Networks Instance


During this stage you verify the NSX service profile is dynamically updated.  The Palo Alto Networks NGFW Global instance will show two service profiles: the default profile "Palo Alto Networks profile 1" and the newly created profile for the legal department "Palo Alto Networks profile Lgl"

 


 

Verifying the NSX Service Profile

 

Go back to your browser and click on the vSphere Web Client tab. If necessary login again using the Single-Sign-On Authentication.

Once logged and from the Home page of the vSphere Web Client

1. Click Home.

2. Click Networking & Security.

 

 

Create NSX Security Groups for legal servers


During this stage you need to create and define the additional NSX Security Groups that you will be using.  These will include the Web-Servers and Database Servers of the Legal Department.  Therefore, simply call these Security Groups "Legal-Web-Servers" and "Legal-DB-Servers".  After these two new Security Groups are created, create a traffic steering policy for all of the Web server to Database server traffic.  

 


 

Creating NSX Security Groups

 

Go back to your browser and click on the vSphere Web Client tab.  If necessary login again using the Single-Sign-On Authentication.

Once logged and from the Home page of the vSphere Web Client click 1) Home and 2) Networking & Security.

 

 

Creating NSX Security Groups

 

1) As before name the new NSX Security Group. Name this one "Legal-DB-Servers".

2) Then click on Define dynamic membership.

 

Create Steering Policy for all traffic between Web Servers and Database Servers


In this step create policies to steer traffic from the Web servers to the Database servers through the NSX Manager.


 

Security Policy for Traffic Steering

 

Before beginning we wanted to let you know that there are two methods for configuring traffic steering.  We will use one method here in lab 2 and the other method in lab 4.

1) Set the policies via the "Security Policies" tab and so click on that tab now.  After doing so notice that one entry already exists - a policy that is only for HR.  Therefore, create a broader policy that will steer all Webserver to Database traffic. Then limit the HR traffic versus the Legal traffic from within PAN-OS.

2) Continue by clicking on the "Create Security Policy" icon that is circled in blue and labeled as sub-step 2.

 

 

Security Policy for Traffic Steering

 

You should see now the newly created Security Policy (there should be two in total now).  You must now apply this policy to its Security Group.  In this case that would be the database servers. To do so, make sure the first rule "Module2_Legal-Web-to-DB" is high-lighted as shown here. 1) Click the "Apply Security Policy" icon (circled in blue) to proceed.

 

Create Dynamic Address Groups (DAG)


Dynamic Address Groups (DAG) and the purpose they serve, was covered in Module 1.  In Module 2 you will walk you through the creation of said groups from within Panorama by Palo Alto Networks.  Before getting started, here's a recap on both Dynamic Address Groups (DAG) and Panorama.

Dynamic Address Groups (DAG) - Provide the ability to maintain awareness of changes in the virtual machines/applications and ensures that security policy stays in tandem with the changes in the network. This awareness provides visibility and protection of applications in an agile environment. This is made possible because Dynamic Address Groups are used as a source or destination object within security policies. Additionally, because IP addresses are constantly changing in a datacenter environment, Dynamic Address Groups offer a way to automate the process of referencing source and/or destination addresses within security policies. This is unlike static Address Objects that must be manually updated in configuration and committed whenever there is an address change (addition, deletion, or move), Dynamic Address Groups automatically adapt to these changes.

Panorama - Enables you to manage your distributed network of physical and/or virtual Palo Alto Networks firewalls from a centralized location while providing the ability to: View the traffic of each deployed firewall; manage all aspects for device configuration; push global policies; and generate reports on traffic patterns or security incidents all from one central location. Panorama is available as either a dedicated management appliance or as a virtual machine.

 


 

Back into Panorama

 

If Panorama is still up and running, access Panorama via the browser bookmark tab.  If Panorama is no longer running, open the Chrome browser and click on the Panorama bookmark.  Or you may launch the Panorama desktop icon to launch and login to Panorama.

 

 

Panorama

 

The credentials for Panorama are username = "admin" with password = "VMware1!"

Note: The README.txt file on the desktop will contain the credentials for Panorama, as well as for all of the servers to be used within this module.

 

 

Synchronize objects between NSX Manager and Panorama

 

Before creating the dynamic Access groups in Panorama, we need to synchronize Panorama with NSX manager so that the new security groups created in NSX are reflected in Panorama. For that, after you've logged in Panorama:

  1. Click on the "Panorama" tab
  2. Then click on the "Service Manager" tab under VMware NSX on the left hand-side of the screen
  3. Finally, click on "Synchronize Dynamic Objects"

Accept the warning message on the next screen that asks you "Do you want to proceed with the synchronize operation?"

 

 

Creating Dynamic Address Groups

 

Next, while still in Panorama:

1. Click on the Objects tab

2. Go to Address Groups

3. Click on the +Add icon at the bottom of the screen to create your Legal team Dynamic Address Groups.

 

 

Creating Dynamic Address Groups

 

In this portion of the lab there are six sub-steps to complete and so please follow along closely.  Start by:

1) Naming this Dynamic Address Group, "Legal-Web-Servers". (Note: Be sure to enter the name as seen here. For the purpose of this lab do not use the space character when naming the Dynamic Address Group).

2) Designate the "Type" of DAG by hitting the drop down arrow and selecting "Dynamic".  

3) Click on Add Match Criteria.  At this point another display box will appear adjacent and on the left. You may need to expand the Name field of the display box to see the full name of the available options.

4) Look for the "Legal-Web-Servers-securitygroup-ID#" and click on the green plus mark to add it. Note: The Security Group ID number may be different than what you see here - this is ok and so continue.  Notice the "Match" field within the display box on the right listing the Security Group as indicated by the blue arrow.

5) Next assign a color coded tag to this DAG by clicking on the drop down arrow and selecting the tag, "Legal Web Server".  

6) Click OK to complete the configuration.

 

 

Creating Dynamic Address Groups

 

Notice the newly created DAG of Legal-Web-Servers.  Now repeat the same process to create the Legal-DB-Servers Dynamic Address Group.  

1) To do so click the +Add icon at the bottom of the screen.

 

 

Creating Dynamic Address Groups

 

As before there are six sub-steps. Begin by:

1) Naming this Dynamic Address Group, "Legal-DB-Servers". (Note: Be sure to enter the name as seen here. For the purpose of this lab do not use the space character when naming the Dynamic Address Group).  

2) Designate the "Type" of DAG by hitting the drop down arrow and selecting "Dynamic".  

3) Click Add Match Criteria.  At this point another display box will appear adjacent and on the left. You may need to expand the Name portion of the display box to see the full name of the available options.

4) Look for the "Legal-DB-Servers-securitygroup-ID#" and click on the green plus mark to add it. Note: The Security Group ID number may be different than what you see here - this is ok and so continue. Notice the "Match" field within the display box on the right listing the selected Security Group as indicated by the blue arrow.

5) Assign a color coded tag to this Dynamic Address Group (DAG) by clicking on the drop down arrow and selecting the tag, "Legal DB Server".  

6) Click OK to complete the configuration.  

Note: If the Dynamic match criteria tags doesn't show up, do a "Synchronize Dynamic Objects" from Service Managers within Panorama.

 

 

Creating Dynamic Address Groups

 

At this point there should be two Legal Team Dynamic Address Groups, one DAG for the Web servers and another DAG for the DB servers.

Now move on to policy creation.

 

Create a Security Policy within Panorama


Create a security policy that will only allow mysql traffic between the Web servers and the Database servers. This will be done in Panorama.


 

Creating Security Policies

 

In Panorama:

1) Click on the Policies tab.  

2) Click on the 2nd policy listed so that the next policy created will follow immediately.  

3) Click on the +Add icon at the bottom left side of your screen.

 

 

Commit Configurations

 

At this time there should be four security policy rules listed.  Before proceeding make sure these rules are listed in the order that you see here.  Specifically, make sure the "Default Deny with Logging" rule is the last rule listed.  If this is not the case, simply click on the rule without opening it and then drag and drop this rule to the bottom of the list. Alternatively, you could also use the Move command which is located on the bottom task bar to move this rule to the bottom.  Either way, when ready please proceed to the next step.

1. Commit Operations: In order for the new configurations to be applied a series of two "Commits" will be required.  First you will need to Commit to Panorama. To do so click on the "Commit" command in the upper right hand corner.

 

Review NSX Security Group and DAG Membership


Review and verify the NSX Security Group and DAG Membership by ensuring successful registration.  Do this within vSphere Web Client.


 

VSphere Web Client

 

Launch the Chrome browser, if necessary.  Click on the "Site A Web Client" bookmark to access the VMware vCenter Single Sign-on page. Check the "Use Windows session authentication" box and click Login.

Important note: if you are loging in the vCenter Web Client for the first time, the login process might take up to 90 seconds, so please be patient. The subsequent logins will be faster (around 25 seconds).
The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware technologies.

 

 

vSphere Web Client

 

1) Click on Home and then go to 2) Hosts and Clusters.

 

 

Review NSX Security Groups

 

From the browser tab click on the vSphere Web Client tab to verify these same IP addresses are within the Security Groups for these two verified servers.  

To do so when you're back in vSphere, 1) click Home and then 2) Networking & Security.

 

Generate Traffic


To check your work and to ensure all of the groups, policies, and configurations have been correctly configured, test by generating traffic through the firewalls.  


 

 

Click the "legal-web-01" desktop icon to login to this server.

 

Inspect Panorama Traffic Logs


Checking the Traffic Logs from within Panorama


 

Panorama Traffic Logs

 

Go back to the browser and go back into Panorama.  From within Panorama:

1. Click on the Monitor tab.

2. Go to Logs > Traffic log.  

3. Do a manual refresh.

Note: it can take up to 20 seconds for Panorama to start reporting the traffic. This is not representative of a production setup where trafic monitoring would be instantaneous. The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware and partner technologies.

Notice the Traffic Logs indicate a successful test as you see the source and destination IP addresses, and the mysql application, which was properly allowed by the firewall. This verifies a successful test and a successful lab. Great job!

This completes Module 2. Please proceed to the conclusion.

 

Lab 2 Conclusion


In this lab many activities were carried out and in doing so, you gained an awareness and appreciation of how easy it is to deploy, integrate, and manage this joint solution by VMware and Palo Alto Networks.  For instance, recall how quickly and easily you were able to deploy new VMs, and groups of VMs, using VMware NSX.  Or how easy it was for VMware NSX to perform traffic steering so that ALL traffic went through the Palo Alto Networks VM-Series firewall for the purpose of ensuring an ever aware and secure datacenter.  All with just a few clicks via a practically seamless integration between the Palo Alto Networks VM-Series firewall and VMware’s NSX.  And all while not having to make any changes to the infrastructure of the datacenter itself.

As with the previous lab, you saw the power, benefit, and efficiency when it came to ease of deployment; ease of integration; ease of configuration; ease of overall management, and ease of synchronization between the Dynamic Address Groups within the Palo Alto Networks firewalls, and the Security Groups within the VMware NSX Manager. Both of which provide a stateful synchronization to ensure all changes in the form of VM additions, deletions, moves, and dynamic IP addressing, which means no manual changes in the infrastructure and/or reconfiguration on your part required! Reason being, all datacenter changes were automatically recognized and registered within the NSX Manager and so the datacenter is always secure, even when the traffic is intra-datacenter traffic among VMs.

Finally, this lab demonstrated the capability of the VMware and Palo Alto Networks joint solution to support multi-tenant environment. Even if different tenants use the same IP addressing for their workload VMs, this is fully embraced by the solution. Each tenant can now be securely protected, at a granular level of VM to VM traffic flows.

On behalf of Palo Alto Networks and VMware, we thank you for sitting our labs. We hope you enjoyed each lab as much as we enjoyed preparing each one of them for you.  It is our sincere hope that we successfully demonstrated how easy it is to manage and secure the ever changing datacenter!

 


Important Message Before Proceeding with Module 3

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.  This is only applicable if you have just launched the lab itself.


 

Conduct a Lab Status Check - If Applicable

 

The following is not applicable for current sessions.  If you are simply transitioning from the previous section to the next module you may proceed as normal to the next screen.  However, if you just launched this lab seconds ago, follow these Lab Status Check instructions.  

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Module 3 - Using Distributed FireWall (DFW) to Protect Intra-tier Traffic (30 Mins, Basic)

Module Overview


In this module VMware NSX DFW is configured to secure intra-tier traffic between web front-end servers. This module shows how to define dynamic Security Groups (based on VM name and based on Logical Switch) and how to use them in DFW policy configuration.

During this module (30 minutes) the focus will be on the various NSX DFW features and functions.  The lessons learned will enable you to gain an understanding of, as well as perform, the following: 

 


Create NSX Security Groups


Create two new NSX Security Groups using dynamic inclusion based on VM name (for Legal web servers) and using static inclusion based on Logical Switch / static exclusion based on VM (for HR web servers).


 

vSphere Web Client

 

Log into the vSphere Web Client.  To do so launch the Chrome browser and click on the vSphere Web Client bookmark named "Site A Web Client".  At the VMware vCenter Single Sign-on page, click the "Use Windows session authentication" box to login using Single Sign-on.

Important note: if you are loging in the vCenter Web Client for the first time, the login process might take up to 90 seconds, so please be patient. The subsequent logins will be faster (around 25 seconds).
The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware technologies.

 

 

Networking & Security

 

Once logged in, and from the 1) Home screen, click on 2) Networking & Security.

 

 

Service Composer / Security Groups

 

Click on 1) Service Composer and then on 2) Security Groups.

Note: If you have previously performed modules 1 and 2 of this Hands-on-Lab you will have a similar view and screenshot.  However, if you have just started here at module 3 you will not see some of the Security Groups that are displayed here.

 

 

 

1) Click on the New Security Group icon to create a new Security Group.

 

 

Create new Security Groups for HR Web Servers

 

1) Click on the New Security Group icon to create a new Security Group.

 

Create NSX DFW Security Policies


Use the two Security Groups previously created in the DFW policy rules to enable, or disable, intra-tier traffic between the web servers of the Legal organization.  Then do the same for the servers of the HR organization.

Note: There are two methods to configure traffic steering.  We used one method in lab 2 and so now we will use the other method here in lab 3.

The following security policies will be implemented:

Legal:

source: Legal Web Servers | destination: Legal Web Servers | Services: ICMP | action: allow

source: Legal Web Servers | destination: Legal Web Servers | Services: ANY | action: block

 

HR:

source: HR Web Servers | destination: HR Web Servers | Services: ICMP | action: allow

source: HR Web Servers | destination: HR Web Servers | Services: ANY | action: block


 

DFW Menu

 

Click on 1) NSX Home and then on 2) Firewall.

 

 

Create a New Section

 

1) Click on the Add section icon and then 2) enter as the section name, "INTRA-TIER protection".

3) Click OK to complete the operation.

 

 

Create new Policy Rule

 

Click the 1) Add rule icon and then click on 2) the arrow to expand Section in order to see all the defined policy rules.

 

 

Create Remaining Policy Rules

 

By following step-by-step procedures you successfully created a DFW policy rule using Security Groups.  In fact, you successfully created the INTRA-TIER protection rule number 1.  This rules permits ICMP.  

Continue now on your own, by repeating the steps you have just performed, to create three additional rules. These three remaining rules are required in order to secure the environment.

The three remaining rules are named below and each contain the specific values required for each rule:  

Name:  Legal-Web to Legal-Web ANY

Source:  (Security Group)  Legal-Web-Servers-Module-3

Destination:  (Security Group)  Legal-Web-Servers-Module-3

Services: Any

Action:  Block

 

Name: HR-Web to HR-Web ICMP

Source:  (Security Group)  HR-Web-Servers-Module-3

Destination: (Security Group)  HR-Web-Servers-Module-3

Services: ICMP Echo, ICMP Reply

Action: Allow

 

Name: HR-Web to HR-Web ANY

Source:  (Security Group)  HR-Web-Servers-Module-3

Destination: (Security Group)  HR-Web-Servers-Module-3

Services:  Any

Action: Block

 

Click on 1) + icon (as shown in the previous picture) to add these three new rules. There are two different areas in the user interface, as shown in the picture, for creating those rules. Using either options has exactly the same effect so just choose one.
New rules should always be created at the bottom of the previously created rules because the order of rule definition is important with DFW (as is the case with all firewalls). Reason being, rule evaluation is always performed from top to bottom and then acting upon the first rule that matches the packet pattern.
IMPORTANT NOTE: If necessary, using the 2) Move Rule Down, icon to move your rule down or use the Move Rule Up icon to move your selected rule up. These icons are encircled in red.    

 

 

Checking NSX DFW Policies


Test 1:  Check the configurations and their impact to the NSX DFW by running a series of ICMP and SSH connection tests between the VMs.


 

 

Click on 1) legal-web-01 icon. A new SSH window will appear with automatic login to legal-web-01.

2) Type the command ping -c 5 legal-web-02 to test for an ICMP response from the legal-web-02 server back to the legal-web-01 server.  

Notice the "5 packets transmitted, 5 received, 0% packet loss" response indicating that ICMP is indeed allowed on the DFW.  

 

 

Modify the NSX DFW Rules to Enable SSH

SSH is blocked by rule 2 for the Legal organization and by rule 4 for the HR organization. The task is to enable SSH. To do so add this protocol to Rule 1 and to Rule 3.

 

 

Test 2: Connectivity Test - SSH

Now test the configuration changes by running a series of SSH connections between the VMs checking for successful connectivity.

 

 

 

1) Double click on the legal-web-01 icon for automatic login to legal-web-01.

2) Enter the command ssh legal-web-02 to begin an SSH session to the legal-web-02 server.

An ECDSA key Fingerprint Authenticity message will be displayed. Type yes to continue the connection.

The Remote system will prompt for a password; enter VMware1!

A welcome message on legal-web-02 will be displayed upon successful authentication.  Notice the prompt is now for legal-web-02. Success verified!

 

Lab 3 Conclusion - Summary of What Was Learned (copied)


By now you have an increased awareness and appreciation of how easy it is to deploy, integrate, and manage this joint solution. You witnessed how quickly and easily you’re able to deploy new VMs, and groups of VMs, via VMware NSX. In addition, you witnessed how easy it is for VMware NSX to provide traffic steering so that ALL traffic goes through the Palo Alto Networks firewall ensuring an ever aware and secure datacenter.  You also experienced how easy this was done with just a few clicks while using an almost seamless integration solution between the Palo Alto Networks VM-Series firewall and VMware’s NSX.  And all without having to make any kind of changes to the infrastructure of the datacenter itself.

As in the previous lab, you saw the benefits of: ease of deployment, ease of integration, ease of configuration and management, and ease of synchronization between the all of the components of this joint solution. You also experienced how quickly and seamlessly you can secure all of the servers within your datacenter, by inspecting and managing the east-west traffic taking place within your datacenter.

On behalf of Palo Alto Networks and VMware, we’d like to thank you for sitting our labs. We hope you enjoyed our labs, as much as we enjoyed preparing them for you, and we hope we successfully demonstrated how easy it is to manage and secure your ever changing datacenter!

 


Important Message Before Proceeding with Module 4

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.  This is only applicable if you have just launched the lab itself.


 

Conduct a Lab Status Check - If Applicable

 

The following is not applicable for current sessions.  If you are simply transitioning from the previous section to the next module you may proceed as normal to the next screen.  However, if you just launched this lab seconds ago, follow these Lab Status Check instructions.  

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Module 4 - Using Advanced Palo Alto Networks Security Policy to Protect Application Tiers (45 Mins, Advanced)

Module Overview


Objectives and Development Notes

In this module, the Palo Alto Networks VM-Series firewalls are configured to protect the introduction and spread of malware in an NSX datacenter.  Using the virtual firewalls the student will create security policy rules to monitor for threats and to prevent the spread of malware.  

During this module you will gain an understanding of advanced threat protection and how to protect the spread of malware between application tiers in a virtualized datacenter.


Create Traffic Redirection to VM-Series Firewall


Secure the web and database servers of the Marketing organization by redirecting all traffic to the VM-Series Firewall for traffic inspection.


 

Login to vSphere Web Client

 

1) Launch the Chrome browser and click on the vSphere Web Client bookmark.  

2) Check the "Use Windows session authentication" box and click Login to login via VMware vCenter Single Sign-On

Important note: if you are loging in the vCenter Web Client for the first time, the login process might take up to 90 seconds, so please be patient. The subsequent logins will be faster (around 25 seconds).
The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware technologies.

 

 

Cluster Site A:  mktg-db-01 VM

 

1) Select the mktg-db-01 VM by clicking on it.  Then note this VM is already assigned an NSX Security Tag of "Mktg-DB-Server".  Also note this VM's Security Group Membership as being assigned to the "Mktg-DB-Servers" group.  Also see the IP addresses for the servers of this VM.  Now proceed to conduct the same review of the mktg-web-01 VM.

 

 

Create Traffic Redirection to VM-Series Firewall - Create Two Security Rules in NSX.

 

1) Click on the Firewall setting of NSX and 2) go to the Partner Security Services tab. Notice the two existing sets of rules highlighted in the previous picture. Those sets were created in Modules 1 & 2.
Note: if you haven't done module 2, you would only see one set of security rules, "Module1_HR-Web-to-DB".

3) Click on the Add Section icon to begin creating the security rules for this module, module 4.

4) Name the rule "Module 4 Marketing".  To make sure this new rule will be the first rule, be sure to select the "Add above" radio button so that it will be placed above the rule created for Module 2.

5) Click SAVE to complete the configuration.

 

 

Create the Second Rule - Web Server to DB Server

 

1) Click the green Add Rule + icon in the upper left corner.

2) For this new rule 2, within the Name column click on the + create icon.

3) Name this new rule "Web Server to DB Server" and then click OK to complete for this action.

Note: ignore the warning message in red displayed above the firewall rules - this is an expected behavior. The message will go away once once you are done configuring the security rule.

 

Configure VM-Series Firewalls Using Panorama


Login to Panorama to manage and configure the VM-Series firewall.


 

Login to Panorama

 

1) Within the browser open another browser window.  

2) Click on the Panorama bookmark.

3) Log into Panorama with username = "admin" and password "VMware1!".

 

 

Synchronize objects between NSX Manager and Panorama

 

Before creating the dynamic Access groups in Panorama, we need to synchronize Panorama with NSX manager so that the new security groups created in NSX are reflected in Panorama. For that, after you've logged in Panorama:

  1. Click on the "Panorama" tab
  2. Then click on the "Service Manager" tab under VMware NSX on the left hand-side of the screen
  3. Finally, click on "Synchronize Dynamic Objects"

Accept the warning message on the next screen that asks you "Do you want to proceed with the synchronize operation?"

 

 

Create the Mktg-Web-Servers Dynamic Address Group

 

There are nine steps in this configuration so be careful to complete each step:

1. Click on the Objects tab.  

2. Make sure you are in Address Groups.  

3. Click the + Add icon to create a new Dynamic Address Group.

4. Name the new Address Group "Mktg-Web-Servers".  

5. For Type use the drop down arrow to select Dynamic.

6. For the Tags field use the drop down arrow to select the "Mktg Web Server" color coded tag.

7. Click the + Add Match Criteria icon.  

8. Select the "Mktg-Web-Servers-securitygroup-13" and click the green + icon.

9. Click close to complete this configuration.

 

 

Create the Mktg-DB-Servers Dynamic Address Group

 

There are nine steps in this configuration so be careful to complete each step:

1. Click on the Objects tab.  

2. Make sure you are in Address Groups.  

3. Click the + Add icon to create a new Dynamic Address Group.

4. Name the new Address Group "Mktg-DB-Servers".  

5. For Type use the drop down arrow to select Dynamic.

6. For the Tags field use the drop down arrow to select the "Mktg DB Server" color coded tag.

7. Click the + Add Match Criteria icon.  

8. Select the "Mktg-DB-Servers-securitygroup-12" and click the green + icon.

9. Click close to complete this configuration.

 

Create Security Policy Rules


Create Security Policy Rules for the VM-Series firewall using Panorama.


 

Create First Policy Rule - Allow Mktg Any to Web.

 

1) Click on the Policies tab.

2) Make sure you are on the Security > Pre Rules page. 3) Click the + Add icon at the bottom of the screen.

4) On the General tab name the new rule "Allow Mktg Any to Web".

5) Click the Source tab.

 

Create Security Policy Rules Continued


Create Security Policy Rules for the VM-Series firewall using Panorama.


 

Create Second Policy Rule - Mktg Web to DB Server.

 

1) Click on the Policies tab.

2) Make sure you are on the Security > Pre Rules page. 3) Click the + Add icon at the bottom of the screen.

4) On the General tab, name this new rule "Marketing Web to DB Server".

5) Click the Source tab.

 

Implementing Vulnerability Protection


Create a Vulnerability Protection Profile to secure and protect the MYSQL environment from a SQL Injection attack and also from a brute force attack.


 

Create a Vulnerability Protection Profile

 

Begin to create the Vulnerability Protection Security Profile by cloning the Default Profile.  To do so:  

1. Click on the Objects tab.

2. Navigate to Security Profiles > Vulnerability Protection.

3. Select the existing "default" profile and check the box.

4. Click Clone and then

5. Click OK to complete this action.

 

Vulnerability Attacks - SQL Injection and SSH Brute-force Attacks


Test the Security Policy to ensure the proper defense of the web server from an SQL Injection attack.


 

Launch a SQl Injection Attack

 

1. Open a new browser window

2. Click on the SQL Injection bookmark

3. The web request will begin and take note of the IP Address of the HTTP Web server.  Also, if you would like put your cursor in the address bar and scroll to the end where you will see SQL commands such as "group_concat%28user_login,0xa,user_pass%29,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,262,7,28,29,30,31,32,33,34,35,36,37,38,39,40%20from%20wp_users”}".  

To be sure, reload the page multiple times to be persistent with the attack by sending the SQL Injection attack multiple times.  

When you feel ready, check the logs within Panorama to ensure alert of the attack.

 

 

Check the Threat Logs for Vulnerability Threats

 

1. Click the Panorama tab to go back into Panorama.

2. Go to the Monitor tab

3. Select the Threat Logs

4. Manually refresh the log. Then notice the log entry for the HTTP SQL Injection Attempt with the Severity level of medium.

Note: it can take up to 20 seconds for Panorama to start reporting the trafic. This is not representative of a production setup where trafic monitoring would be instantaneous. The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware and partner technologies.

 

 

Attempt a Brute Force Attack Using SSH

 

1. Click and launch the mktg-web-01 desktop icon to launch a Putty session to this server.

2.  Enter the following commands:

Change directories to the /SCRIPTS directory with the cd /SCRIPTS command.

Do a listing of the directory contents with the ls command.

Notice the mysql-brute-force-attack.sh shell script that is present.  Enter the more command for this filename to view the script.  The script itself shows that it will loop forever and will send bad user and bad password attempts to the host=mktg-db-01 server.

3. Run this script with the ./mysql-brute-force-attack.sh command. Notice the constant and excessive output once the command is run.

./mysql-brute-force-attack.sh

 

 

 

 

Check the Threat Logs For This Attack

 

1. Move back to Panorama to check the Monitor Tab > Logs > Threat log.

2.  Conduct a Manual Refresh to refresh the logs.  Notice all of the "MySQL Authentication Brute-force Attempt" attacks from the web server to the database server. Also note the Severity level of high.

Note: it can take up to 20 seconds for Panorama to start reporting the trafic. This is not representative of a production setup where trafic monitoring would be instantaneous. The HOL infrastructure is not meant to replicate a production environment but to rather showcase VMware and partner technologies.

 

 

Ensure Protection in Place with No Impact From These Attacks

 

1) Open another browser tab and 2) click on the wordpress bookmark icon.

Take notice that even though multiple attacks are taking place, one to the mktg-web-01 server and another to the mktg-db-01 server, there is no impact as the web page still launches as expected.  

This is a clear indication of the Palo Alto Networks VM-Series firewall negating these attacks, providing protection to both of these VM servers!

At this time you may now cease the ssh brute force attack by going back to the putty session and entering the ctl-c command to stop the script.  And you may also close the browser session that is spawning the SQL injection attack.  

 

Lab 4 Summary Conclusion


During this lab you learned how to create traffic redirection rules to the VM-Series firewall using NSX Distributed FireWall UI (Partner Security Services tab).  You also learned how to create Dynamic Address Groups and Security Policy Rules on Panorama.  

Most importantly, you successfully implemented vulnerability protection to secure traffic going to the Marketing web server as well as traffic going from the Marketing web server to the Marketing database server.  

Then by creating a Vulnerability Projection Security Profile and applying it to the existing Security Policy Rules, you experienced how fast and easy it was to trigger Layer 7 Application inspection for the purpose of preventing malicious attacks, such as the SQL Injection and Brute Force attacks employed during this lab.

At this time we'd like to extend our congratulations for successfully completing this lab.  We hope you have enjoyed this module and have gained a richer understanding of Advanced Threat Prevention as provided by Palo Alto Networks VM-Series firewall.

 


Important Message Before Proceeding with Module 5

Important Message Before Proceeding


Check to Make Sure the Lab Status State is Set to Ready.  If Not, Restart a New Lab Session.  This is only applicable if you have just launched the lab itself.


 

Conduct a Lab Status Check - If Applicable

 

The following is not applicable for current sessions.  If you are simply transitioning from the previous section to the next module you may proceed as normal to the next screen.  However, if you just launched this lab seconds ago, follow these Lab Status Check instructions.  

Before getting started, conduct a quick lab status check to make sure the "Lab Status" state is set to "Ready" mode. If the lab status state is set to a mode other than "Ready", end this lab and restart a new lab session.  

Continuing this lab while in a Lab Status State of anything other than "Ready" may result in a poor lab experience due to latency, unexpected errors, and lost work.

___________________________________________________

Note: to examine the exact status of your POD, check the following file C:\HOL\LabStartup.log:

          Start->All Programs->Maintenance->baretail LabStartup

If you see a message with "FATAL ERROR: ....... . Delete deployment", stop immediately the lab and restart a new one.

 

Module 5 - Panorama driven workflows for NSX (30 Mins, Advanced)

Module Overview


In this module, Palo Alto Networks VM-Series firewalls are configured using Panorama driven workflows, which was introduced in v8.0.

You will gain an understanding of how to secure inter-tier traffic by configuring security policies and traffic redirection to Palo Alto Networks VM-Series firewalls using Panorama driven workflows. A hand shake between Panorama and NSX Manager is established by creating Dynamic Address Group with appropriate NSX matching criteria in Panorama. This automatically creates new Security Groups in NSX Manager. Once VM's are pulled into this automatically created Security Groups in NSX Manager and traffic is redirected to the VM-Series firewalls, appropriate security policies takes effect.

This module will leverage Servers in HR and Legal Organization to enable communication (like ping and SSH) between them.


Create new Dynamic Address Groups


Create new Dynamic Address Groups for HR-Web Servers and Legal-Web Servers in Panorama.


 

Log into Panorama Client

 

  1. Click on the Panorama bookmark in Chrome
  2. Username: admin
  3. Password: VMware1!
  4. Click Log In

 

 

Add a Dynamic Address Group

 

  1. Select Objects tab.
  2. Click Address Groups in the left pane.
  3. Click Add to create new Address Groups.

 

Create new policies in Panorama


Create Security policies to enable ICMP ping and SSH communications between HR-Web and Legal-Web Servers.


 

Log into Panorama Client

 

  1. Click on the Panorama bookmark in Chrome
  2. Username: admin
  3. Password: VMware1!
  4. Click Log In

 

 

Panorama Client

 

  1. Go to Policies tab
  2. Select Security Pre rules in the left pane
  3. Select VM-Series-DG in Device Group drop-down
  4. Click Add.

 

 

Create Security Policy Rule

 

  1. Enter Security Policy name as Allow HR Web to Legal Web.
  2. Select Rule Type to be intrazone.
  3. Then click Source tab.

 

 

Re-order rules

In order to effectively leverage this newly created policy, re-order it to Rule position number 6 and disable the super rule that Allows all ping and SSH.

 

Auto-generate traffic steering rules in Panorama


Panorama can auto-generate traffic redirection rules based upon satisfying the following criteria;

  1. DAGs created with matching NSX tags in the format '_nsx_<DAGName>'.
  2. At least one Security policy should reference the DAGs created in Step1 in the Source Address or Destination Address.
  3. Security policy Zone should be intrazone.

 

Create Traffic Steering Rule

 

  1. Click Panorama tab.
  2. Under VMware NSX plugin, click Steering Rules section.
  3. Click Auto-Generate Steering Rules.
  4. When a pop-up to confirm the operation appears, click Yes.

 

Verify Security Groups and Firewall policies in NSX


The DAGs created in Panorama, auto creates a new Security Group in NSX. The auto generated traffic steering rules in Panorama will appear in NSX Firewall rules.

Both of these can be verified in NSX after a successful Panorama commit.


 

Verify Security Groups

 

  1. Open the vSphere Web Client and Click on the Home Button.
  2. Click on Networking and Security
  3. Select Service Composer.  
  4. Click Security Groups tab
  5. Verify the newly created Security Groups. Also note that these security groups dont have any VM's in it just yet. We will pull in VMs into these Groups at a later step.

 

 

View Partner Security Services

 

  1. While still within Networking and Security, Click Firewall.
  2. Highlight the Configuration pane
  3. Click Partner security services tab.
  4. A newly added section that begins with PAN_ should be automatically created here. This should match the auto generated traffic steering rules in Panorama. Note that the Action is set to redirect to Palo Alto Networks Firewalls.

 

Add VMs into Security Groups


Note that the Panorma created security groups did not have any VMs in it. Now add HR Web server and Legal Web server VMs into relevant security groups.


 

Add VMs to security groups

 

  1. In the vSphere Web Client, within Networking and Security, click Service Composer.
  2. Security Groups tab.
  3. Right click Palo Alto Networks NGFW_Module5-HR-Web.
  4. Select Edit Security Group.

 

Verify traffic redirection



 

 

  1. Double click HR-web-01 putty icon on the Desktop and issue the command ping -c 5 legal-web-01 to verify that HR Web Servers are able to ping Legal Web Servers.
ping -c 5 legal-web-01

 

Lab 5 Summary Conclusion


In this module, you were able to create Security Groups, Security Policies as well as perform Traffic Redirection from within Panorama using the Panorama driven workflows feature in v8.0. The traffic flow between HR Web and Legal Web Servers were redirected by NSX and inspected by Palo Alto Networks VM-Series firewalls.


Overall Conclusion

Summary of what we've learned


By now you have an increased awareness and appreciation of how easy it is to deploy, integrate, and manage this joint solution. You witnessed how quickly and easily you’re able to deploy new VMs, and groups of VMs, via VMware NSX. In addition, how easy it is for VMware NSX to provide traffic steering so that ALL traffic goes through the Palo Alto Networks firewall ensuring an ever aware and secure datacenter. All within a few clicks via a practically seamless integration between the Palo Alto Networks VM-Series firewall and VMware’s NSX, and all without having to make any kind of changes to the infrastructure of the datacenter itself.

As in the previous lab, you saw the benefits of: ease of deployment, ease of integration, ease of configuration and management, and ease of synchronization between the all of the components of this joint solution. You also experienced how quickly and seamlessly you can secure all of the servers within your datacenter, by inspecting and managing the east-west traffic taking place within your datacenter.

On behalf of Palo Alto Networks and VMware, we’d like to thank you for sitting our labs. We hope you enjoyed our labs, as much as we enjoyed preparing them for you, and we hope we successfully demonstrated how easy it is to manage and secure your ever changing datacenter!

 


Appendix - Lab Check

Introduction


This appendix section provides information to check status of all LAB components - in order to ensure both NSX and Palo Alto Networks solutions are working properly.


NSX - Check Controllers Status


To check the status using the vCenter web UI, go to NSX Home --> Installation --> Management and check status of the three NSX controllers.


 

NSX Controller Nodes Status Check - Normal

 

 

NSX - Check Logical Network Preparation


Using vCenter web UI, go to NSX Home -> Installation -> Logical Network Preparation and check configuration status for the two clusters.


 

Logical Network Preparation Tab - Configuration Status Check

 

Note: if a red exclamation point icon appears instead of the green check mark icon, click on the icon and then click on resolve to correct the issue.

 

NSX - Check VM-Series Service Deployment


Using vCenter web UI, go to NSX Home -> Installation -> Service Deployments tab and check status of the VM-Series deployment.


 

Service Deployments - Installation Status Check

 

Note: if a red exclamation point icon appears instead of the green check mark icon, click on the icon and then click on resolve to correct the issue.

 

vCenter - Check the VM-Series


Using vCenter UI, verify the VM-Series are all powered on.


 

Summary Tab - Power State Status Check

 

 

ESXi Host - dvFilter Slowpaths


Open a SSH session on esx-01a (and esx-02a) and type the following command:

1)  At the prompt enter the command: summarize-dvfilter

Check to make sure the Slowpaths section is populated as shown below.


 

Slowpaths Check:

 

 

Panorama - Managed Devices


Using Panorama UI, check to make sure both VM-Series firewalls appear properly under Panorama --> Managed Devices.


 

Managed Devices Check - Two VM-Series Firewalls

 

 

VM-Series - Serial Number


Open a SSH session on the VM-Series and type the following command:

1. At the prompt enter the command: show system info

Check to make sure the Serial Number field is populated and not set to 0 (this validates VM-Series has a proper license and will be able to function properly.  This license is based on a VM UUID).


 

VM-Series License Check

 

 

VM-Series - Configuration Deployment


Open an SSH session on VM-Series and verify the configuration is properly deployed using the following commands:

# show interface all

# show jobs all

Run each command separately.  


 

Run the "show interface all" command

 

1)  Run the show interface all command to display the two Ethernet interfaces (ethernet 1/1 and ethernet1/2).  Both should be in vwire mode.

 

 

Run the "show jobs all" Command

 

1)  The show jobs all command should display the first job-id (1) with Status = FIN and Result = OK.

 

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-1823-01-NET

Version: 20170920-131028