NSX Identity Firewall – Deep Dive

Overview

One of the major challenges in the modern datacenter is to constantly improving our overall security implementation. In traditional firewalls, we’re building our policy rules based on the famous 5-tuple (Source IP, Source Port, Destination IP, Destination Port, Protocol) to match a specific flow.

It was a very good start for our first generation of the statefull firewalls, but centrality not enough to achieve better security in rapidly dynamic environments, where different users from different roles need to access our applications reside within the datacenter.

Today users are connecting to business applications from various locations such as: internal campus LAN, VDI or via VPN. The user could be a corporate employee or even an external contractor. In some cases, the same user can login from different computers on different locations inside the same company campus. In this growing scenario – is there any meaning for the user’s IP address anymore?

IT Departments needs to provide the same user experience for their customer regardless of the location/device that the end user is connecting from.  With NSX Identity firewall we can simplify the firewall rules and create simpler rule to allow a specific user/group to access an application. This is much easier than creating complex rules with different source IP address reflecting the location the user connects from.

Example of an identity firewall policy:

Picture1

Another concern is related to the security auditing of user activity inside the datacenter. One of the IT challenges is to investigate cybercrime events, the traditional firewall will have logs and events of the IP address transverse the organization firewall. But after we get suspicious IP, IT will need to understand who is the employee behind this IP (assuming that the attack was from within our network) we can eliminate this step by creating NSX Identity firewall that will record any user activity/access in the datacenter.

Starting from NSX-v 6.0 VMware have the ability to create firewall rules based on the identity of the user defined in the enterprise Active Directory– IDFW (Identity Firewall). In this blog post we will cover in deep dive all the aspects of this technology.

NSX Identity Firewall Usecases:

Access from physical PCs (Log Scrub):

In this usecase we would like to provide access for an employee or an external contractor to our datacenter (shown on the right side) directly from their physical laptop windows PCs or mobile devices without any agent installed on the physical PC. When the user is logged in to a windows domain machine with their Active Directory credentials, successful logon event will be generated inside the Active Directory. With NSX IDFW Log Scrub we’re relying on this event to detect the identity of the user and correlating the IP address. This method named Log Scrub because the NSX manager will need to scrub the logs from the AD to correlate the user ID and IP address to NSX Security Policy.

The firewall policy will be defined based on a user membership or groups membership in the Active Directory. The NSX firewall enforcement will be done at the datacenter’s workloads (on the right side).

Picture2

Guest Introspection:

In this scenario, the users (from the left side of the figure) will need to access first hop VDI- Virtualized Desktop Infrastructure or any vSphere VMs protected by NSX distributed firewall (shown in the middle of the figure below), and then they will get access to the datacenter workloads (on the right).  The NSX firewall enforcement will be done at the VM level.

Picture3

As you can see these are two different methods to achieve the same goal of Identity NSX firewall. Design considerations and compressions between the two methods will be explained later.

Now let’s start to explain how its actually works.

High Level Architecture Log Scrub:

In this scenario, users are accessing applications from physical domain-member devices like laptop or PC. With this solution, we are relying on Microsoft successful logon events generated at the AD. From this log event we can learn the identity of a user that just logged in and the IP address of the device that the user came from. Then, based on the firewall policy defined for the AD groups we can control the traffic enforcement at our virtual machines.

Picture4

The following steps describe this process:

 (1) The user is performing a login to a PC or laptop that are members of the corporate domain.

(2) Successful logon event is generated by the Active Directory.

(3) NSX Manager periodically (Every 5 sec) reads the AD event logs (Log scrub process).

(4) NSX Manager pairs the event logs and users defined at the security policy. The NSX Manager will store the user id and the IP address at the database.

The NSX manager will then translate the Security Group to machines and use what it learned to determine where the firewall policy need to be applied.

(5) NSX will push the firewall policy to related VM in the relevant security group.

(6) The user can now access from a physical PC/laptop a VM inside the datacenter and have the access and policy he/she was allowed.

Guest Introspection High Level Architecture

In the figure bellow I will describe the process to show how NSX Identity Firewall is performing Guest Introspection. With Guest Introspection, we are relying on thin agent installed on the Guest OS machines.  This thin Agent detects the logon user Id and his IP address and report this information to the NSX manager. We’re using VDI or the VMs as a “jump server” before the user can access the destination application located on the Datacenter (shown on the right icon and running as a VM or a bear metal server).

The enforcement point of the NSX firewall will is at the VM or VDI level.

The Virtual Access deployment Guest Introspection (GI) will be explained into details on this blog.

Picture5

Here is the high level of flow of the user access process:

(1) User login to a Virtual Machine (The VM can be part of Virtual Desktop Infrastructure-  VDI) with AD credentials.

(2) On each VM the thin agent (This is VMTools with Guest Introspection installed) running inside the guest os, detects the login event and update the Service Virtual Machine (SVM) with a user id and IP address combination.

(3) The SVM update the NSX manager with these details user details plus AD Group Memberships.

(4) The NSX Manager will store the user id and the IP address inside its database. \

NSX manager will then translate the Security Group to VMs and understand where the NSX firewall policy needs to be pushed.

(5) NSX will push the firewall policy to the related VM in the relevant security group.

(6) The user will be able to access the application inside the datacenter from his VM.

NSX Guest Introspection:

Guest Introspection (previously called “Endpoint Security” – EPsec) allows NSX deep inspection at the guest OS without installing any 3rd-Party agents.

 

Guest Introspection allows the following security features:

  1. NSX Identity Firewall.
  2. NSX Activity Monitor.
  3. NSX Data Security.
  4. Agentless Anti-Virus 3rd-Party.
  5. File Integrity 3rd-Party.

At this blog post we will focus on the NSX Identity Firewall.

Picture6

The Guest Introspection consists of three major components:

Thin Agent:

Inside the Virtual Machine Guest OS we need to install Thin Agent (This is actually just an add-on to the existing VMTools drivers) – known as network introspection. This agent will communicate with the “MUX” via Virtual Machine Communication Interface (VMCI) Channel.

MUX Module:

When we enable Guest Introspection on the cluster level, NSX will install a new VIB (vSphere Installed Bundle) on each ESXi host in our cluster. The new VIB is called “epsec-mux” and MUX module acts as a Multiplexer accepting messages from the Thin Agent running in the VM via VMCI channel, then delivers the information to the SVM (Service Virtual Machine) via a TCP session.

All of the Internal TCP communication of the MUX to SVM is done via PIPA IP address 169.254.1.X over ports 48651-48666.

As a part of Guest Introspection deployment, a new standard switch called “mservice-vswitch” is created at each host, and a new port group named “vmservice-vswitch” will be used for the communication.

Service Virtual Machine – SVM:

On each host in the cluster that we’ve enabled “Guest Introspection” on, NSX will deploy a Service Virtual Machine (SVM).  The SVM will offload the activity needs to be done inside the VM Guest OS and communicate with NSX Manager to send updates and to get new configurations. The SVM have two interfaces: one interface is connected to the standard vSwitch for the MUX traffic, and the Second interface to the management IP defined by the admin to enable the communication to the NSX manager. This communication is done via vDS.

 

Enable NSX Identity Firewall

Log Scrub – Physical Access

We need to configure NSX manager to read AD groups Security Events Logs.

We can use the same user or different user for the integration with AD.

The First Step to enable Log Scrub is the connect the NSX to the AD.

Click on the NSX Manager icon, then click on his IP Address, in this example it’s 192.168.110.15.  Click on Manage -> Domains -> Click on the Green + icon to add a Domain:

picture7

In the figure bellow we need to define a standard domain user in order to have the ability to read the AD schema of users and Groups. With this information, we can later define the NSX firewall policy based on these AD objects.

picture8

In this example, we will use the “nsxread” user name. this user Is defined in the AD as just a regular “Domain Users” member without any special permission.

nsxread

A user with permissions to read the logon/logoff events should be used for this section.The permission requirement is depended on the OS the AD that are running. The protocol used to read this information can be CIFS or WMI.

picture9

Depending on the Guest OS the AD running we need to have different permissions for the user we are using to read the Security Log Access from the AD.

Windows 2008 or later domain servers:

The user defined to read the security event logs in Windows 2008 must be member off “Event Log Readers” group. If we are using the on-device User-ID agent, the account must also be a member of the “Distributed COM” Users Group.

In the figure bellow we can see a “nsxlog” user defined in AD 2008 server, as you can see the user is a member of “Event Log Readers”:

picture10

Windows 2003 domain servers:

Assign Manage Auditing and Security Logs permissions through group policy.

 

Event Logs ID:

During the log scrub process the NSX manager will collect the following Microsoft event IDs:

For windows 2008/2012 – Event ID: 4624

For Windows 2003 – Event ID: 540

After defining the LDAP Options and the Security Logs Access we need to simply click finish.

picture11

Creating Security Groups:

Before creating the NSX security policy defined with AD groups, we need to create NSX Security Groups and reference this Security Group in the NSX policy.

For Example, we will create SG for Sales group:

picture12

To choose the AD group we need to change the Object Type to “Directory Group” and then select one of the AD groups. In this example, we chose AD-Sales:

picture13

Now we can create the NSX DFW Policy. The source object in this rule is the AD-Sales Security Group:

picture14

Now users that are members of the sales AD group can login to their physical machine and access the “Internal Services” application defined in this NSX policy rule via HTTPS.

Enable IDFW With Guest Introspection:

The IDFW can work with Guest Introspection, there are few steps needs to be done in order to enable Guest Introspection.

Install the Guest Introspection service.

In the NSX interface go to: Installation -> Service Deployment. Click on the Green button and select Guest Introspection as shown in this example:

picture15

Select the Cluster you want to enable  Guest Introspection on:

picture16

Now we need to configure the Datastore where the SVM will be deployed, the portgroup that will be used for the communication with the NSX manager after the deployment and the IP address assignment for management. Then Click Next -> Finish

picture17

After a few minutes, NSX Manager will deploy one SVM per ESXi host in the cluster we chose. The footprint of this SVM is very small: 2 vCPU and 1G RAM per SVM.

picture18

In this example, we have only one ESXi host name esx-03a.corp.local in Regin01-COMP02 Cluster, so we have only Guest Introspection SVM:

picture19

On each SVM we have 2 vNIC with two IP address.

The first vNIC is VM-RegionA01-vDS-COM (Connected to vDS) and is used for communication with the NSX manager. The Second vNIC “vmservice-vshield-pg” is connected to a standard virtual switch.

The Management IP of this SVM is 192.168.100.150 (This IP was given us by a DHCP as part of the installation of Guest introspection in the cluster). The Second IP 169.254.1.24 was created automatically as part of the SVM deployment and used for communication between the SVM and the MUX process running inside the ESXi host.

picture21

After the deployment of the Guest Introspection we need to connect the NSX manager to the AD in order to be able to read the AD schema of user and groups, but we don’t need to read the AD security events logs !!!

The process of the integration with the AD is the same as describe in the Log Scrub chapter except for this, Mark  the “No” in this question:

picture22

Design Consideration:

We have explained two different methods to configure IDFW with NSX.

You can now ask: what method is better?  the quick answer; it depends! 🙂

It depends on the scenario of the customer and the environment, these will determine the right approach.

Here is a small compression I’ve created of the two method:

picture23

 

Special thanks  to Daniel Bakshi that help me a lots to review this blog post.

Posted in Design, Firewall Tagged with: , , ,

Leave a Reply