NSX Identity Based Firewall – Part 3: Implement IDFW using Guest Introspection

Manish Jha

Welcome to part-3 of the NSX IDFW series. The first post discussed the overview and architecture of NSX IDFW, and the second post discussed implementing NSX IDFW using Active Directory Event Scraping.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to NSX Identity Firewall

2: Implement IDFW using Event Log Scraping

In this post, I will discuss NSX Guest Introspection, which is another logon detection method that NSX uses to enforce identity-based firewall rules.

What is NSX Guest Introspection?

Guest Introspection for VMware NSX is a user space agent installed inside a virtual machine to provide network connection control and monitoring capability. This daemon provides network connection control and monitoring capabilities by utilizing the capabilities offered by the netfilter libraries and the netfilter kernel subsystem. For Windows OS, guest introspection is packaged and delivered with VMTools. 

Guest Introspection provides the following features:

  • Packet filtering (IPv4 and IPv6 over TCP/UDP) and controlling.
  • Network connection monitoring (TCP and UDP).

Guest Introspection Components

The NSX guest introspection framework comprises the following components:

  1. Thin Agent: This component is installed on guest VMs as part of VMTools installation and collects login events, connection, and identity information from the guest VM.
  2. Context MUX: This component acts as a proxy for communication between the guest VM and the ESXi host. It also relays events, information, and security profiles based on a policy rule for a protected VM to the NSX firewall.
  3. OpsAgent: This component gets installed on the ESXi host as part of the host preparation and is used to consume NSX defined security configuration consisting of policies based on profiles, rules, and groups. It consumes the security configuration and provides it to Context MUX. Context MUX uses this information to decide what guest VMs should be mapped to what security services for protection.

The following IDFW components work in conjunction with the guest introspection modules to implement IDFW rules:

  • NSX-proxy: Receives configuration from NSX Manager and configures the data plane.
  • VSIP: Enforces Identity Firewall rules in the datapath.
  • Context Engine: Forwards VM events to the VSIP module for rule enforcement.

Identity Firewall Enforcement Workflow

Identity firewall rules are enforced as follows:

  1. The user logs into the guest VM with AD credentials
  2. The user initiates a network connection to the required application/server.
  3. The thin agent detects the login event and the network connection. It then sends the connection and identity information to the Context Mux.
  4. The Context Mux receives the guest VM events and forwards them to the Context Engine.
  5. The Context Engine forwards the connection and the identity information to the VSIP module for rule enforcement.
  6. For the first connection, a login event is sent to the NSX manager through the NSX-proxy. NSX-proxy also updates NSX Manager with user ID and AD group memberships.
  7. The NSX Manager will store the user ID and the IP address inside its database. The NSX manager will then translate the security group to VMs and understand where the NSX firewall policy needs to be pushed.
  8. NSX will push the firewall policy to the related VM in the relevant security group.

NSX Security Groups and AD Group Correlation

Before diving into implementing the IDFW rules, let’s first understand how NSX translates Active Directory Groups into the Security Groups created in NSX. 

In Windows operating systems, security groups are identified by a unique value called a security identifier (SID). The SID value of a security group stays the same across all operating systems. When a user authenticates to Active Directory (AD), any AD security group to which he belongs has that SID appended to his logon credentials in validating his authorization.

The identity firewall rules are stored in the datapath using the SID of a group instead of its name. NSX Manager is responsible for translating the names of security groups into SIDs before passing the configuration information to the Central Control Plane (CCP).

Note: I am not covering the steps of enabling IDFW in this post, as I already covered the steps in the previous post.

The thing agent is the juice of the IDFW guest introspection method. This can be enabled during VMTools installation or post-installation by modifying the install.

In my lab, the VMTools were already installed, so I modified the installation. 

Enable the NSX File Introspection and NSX Network Introspection options under VMCI Drivers. The function of the selected drivers is:

  • The NSX Network Introspection (vnetWFP.sys) driver intercepts the network traffic and user activity on the guest VM.
  • The NSX File Introspection (vsepflt.sys) driver intercepts file and process activity on the guest VM.

Note: Identity Firewall requires VMware Tools version 11.2.5 or later.

I have the following firewall rules/policy configured in NSX DFW.

Policy: Block HTTPS traffic for users of the Development AD group and allow access to users of the Engineering group.

  • Rule Definition 1: If any user of the Engineering AD group accesses vCenter Server on port 443/HTTPS, it will be allowed.
  • Rule Definition 2: If any user of the Development AD group accesses vCenter Server on port 443/HTTPS, it will be rejected.
  • Rule Definition 3: If any other user who does not belong to the Engineering or Development AD group accesses vCenter Server on port 443/HTTPS, the connection will be blocked.

When the user manishj, who belongs to the development group, accesses the vCenter URL, the page does not load. However, if he tries to access the NSX Manager UI, the page loads.

Another user, “John,” who belongs to the engineering group, has now logged into the guest VM.

John can access the vCenter server URL as he is in the allowed list of the DFW ruleset. 

IDFW Logging

In the DFW, you can validate IDFW enforcement by checking the hit count of the firewall rule.

On the NSX manager, the IDFW events can be captured by running the command: cat /var/log/proton/nsxapi.log | grep FIREWALL | egrep -i “login|logout”

IDFW rule realization in the datapath (ESXi host)

Connect to the ESXi host where the Windows jumpbox is running and run the summarize-dvfilter command against the VM.


To see what firewall rules are applied at the vNIC level of the Winjump VM, run the command: vsipioctl getrules -f <dvfilter-name>

Rules 3059 & 3060 list the addrset UUID and the source UUID (which corresponds to the AD group). 

 


The addrset in the rule belongs to the destination IP address 172.16.10.10 (vCenter IP) and the winjump IP 192.168.1.2

The extended src attribute displays the UUID of the Active Directory group’s SID. 

An alternate way to fetch the addrset and SID is by connecting to the nsxcli command on the ESXi host.

You can query the Active Directory to correlate the SID with the AD group name to validate that rules are enforced on the right AD groups.

If you have logging enabled at the policy level in the DFW, you can review dfwpktlogs to validate IDFW enforcement.

For example, the below logs show that RuleID 3059 is permitting a TCP 443 connection from 192.168.1.2 towards 17.16.10.10

And that’s it for this post. 

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.

Leave a Reply