How to Deploy Websense In Stand-alone Mode on a Hyper-V Virtual Machine? #HyperV #Websense

Hyper-V | Network | June 23, 2022 by Charbel Nemnom

5 Min. Read

Share this post:

In this article, we will show you how to deploy Websense in stand-alone mode on a Hyper-V Virtual Machine.

Table of Contents

Introduction

Since the initial release of Hyper-V back in 2008, my hope was to move all the physical workloads to Hyper-V, however, one of the roles that were impossible to move is Websense Web Security!

Websense Web Filter and Security block web threats to reduce malware infections, decrease help desk incidents and free up valuable IT resources. More information on Websense.

Since then, I had several conversations with Websense and Microsoft folks and all the feedback came negative!

So what is the reason that Websense cannot run on Hyper-V virtual machines?

Websense feedback was that the Hyper-V server does not allow setting a virtual NIC (vNIC) to promiscuous mode, Websense does not certify and support the platform. Websense Network Agent requires a NIC set to promiscuous/stealth mode. As Microsoft does not intend to support this feature, Network Agent cannot successfully monitor traffic from other systems on its monitoring NIC.

If Websense is working with an integration mode other than Network Agent (Standalone mode), where port spanning is not necessary, then Hyper-V is a viable platform. The integration mode like Threat Management Gateway (TMG). While TMG has been officially deprecated by Microsoft, it is still supported until April of 2020.

The high-level architecture of standalone mode deployment in the physical world is shown in the figure below:

Microsoft feedback was, Hyper-V virtual switch does not offer promiscuous mode on its virtual interfaces.

In short, the promiscuous mode allows a network device to intercept and read each network packet that arrives in its entirety. The most typical use cases include network intrusion detection systems (NIDS), monitoring tools such as (Wireshark, Microsoft Message Analyzer, etc.), web security tools such as Websense, or recording of calls in VOIP-based centers such as MiaRec. This mode of operation is given to a network server that captures and saves all packets for analysis.

The Websense deployment and configuration are already well explained elsewhere, so I’ll keep the basics to Hyper-V here.

VMware does support promiscuous mode, but I believe in Hyper-V, so what is the solution?

Microsoft in Windows Server 2012/2012 R2 Hyper-V and later introduced the concept called (port mirroring) which can be enabled on any virtual machine vNIC adapter. There is quite some official documentation available if you want to set up port monitoring between two or more Virtual Machines.

How does port mirroring work?

Port Mirroring allows you to monitor virtual network traffic from one or many virtual machines (sources) to another virtual machine (destination). Port Mirroring works at the Virtual Switch level and to be precise, it’s the Hyper-V virtual switch extension capabilities that are being used to achieve port mirroring/capturing. The extensible vSwitch by itself uses port ACLs to set a rule that forwards traffic from one vNIC in a VM to another vNIC in another VM.

For example, if we need to monitor all traffic sent and received by both VM1 and VM2, you can run the following PowerShell cmdlets where MonitorVM has a network monitoring tool installed i.e. Wireshark in order to capture the traffic.

Set-VMNetworkAdapter VM1 –PortMirroring Source
Set-VMNetworkAdapter VM2 –PortMirroring Source
Set-VMNetworkAdapter MonitorVM –PortMirroring Destination

This is a great feature for internal traffic between VMs on the same physical host, but this does not solve my pain point with Websense, because we need to be able to monitor the traffic from a port on the physical switch to a virtual port (vNIC) inside a VM.

What about external traffic?

Hyper-V does not support setting a “promiscuous mode” flag on a virtual port, as you need to specify if a given port is supposed to be the source or the destination of the network packets.

The interesting part is that the official documentation does not state that you can also capture traffic from an external network or from the host parent partition. Waw this is what is needed in my scenario.

The Hyper-V Extensible Switch and the PowerShell module have the bells and whistles to tackle this problem.

What are the requirements to capture external traffic?

1) Two vNICs To Websense VM (Block NIC and Monitoring NIC).

2) Set the Mirroring mode of Websense VM monitoring vNIC to “Destination“.

3) Enable Microsoft NDIS Capture on the Hyper-V Virtual Switch Extensions where Websense VM is attached to.

4) Set the Mirror mode on the External port of the Hyper-V Virtual Switch where Websense VM is attached to reflect as the “Source“.

5) Configure port mirroring on the physical switch to mirror any traffic on your firewall/router port ==> to the port that the Hyper-V server is connected to.

Step 1: Add Two Virtual NICs To Websense VM

Add-VMNetworkAdapter -VMName Websense -Name Block -SwitchName VM_vSwitch
Add-VMNetworkAdapter -VMName Websense -Name Monitor -SwitchName Mirroring_VM_vSwitch

Step 2: Set The Mirroring Mode Of The Monitoring Virtual NIC To “Destination”

Get-VMNetworkAdapter -VMName Websense | ? Name -eq Monitor | Set-VMNetworkAdapter -PortMirroring Destination

The same can be done in the Hyper-V Manager console or in Windows Admin Center.

Step 3: Enable Microsoft NDIS Capture Extension On The Virtual Switch

1) Open the Virtual Switch Manager on the Hyper-V Host.

2) Expand the virtual switch named “Mirroring_VM_vSwitch” and click on “Extensions“.

3) Enable Microsoft NDIS Capture under Extensions.

Step 4: Set The Mirror Mode On The External Port Of The Virtual Switch To “Source”

The Hyper-V PowerShell module includes the following cmdlets (Add-VMSwitchExtensionPortFeature, Get-VMSystemSwitchExtensionPortFeature, Remove-VMSystemSwitchExtensionPortFeature, and Set-VMSystemSwitchExtensionPortFeature) that can be used to manage port monitoring at the host level.

We need to configure the Hyper-V vSwitch name “Mirroring_VM_vSwitch” that any traffic that hits the external port “SOURCE”, has to be forwarded to the vNIC “Monitor” that we configured “DESTINATION” on Websense VM.

The following PowerShell cmdlets will help you to set the External vSwitch port to “SOURCE” Mirror mode:

$ExtPortFeature=Get-VMSystemSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port Security Settings"
$ExtPortFeature.SettingData.MonitorMode = 2
Add-VMSwitchExtensionPortFeature -ExternalPort -SwitchName Mirroring_VM_vSwitch -VMSwitchExtensionFeature $ExtPortFeature

Let’s validate the Monitoring mode is set to “SOURCE” by running the following cmdlet:

Get-VMSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port Security Settings" -SwitchName Mirroring_VM_vSwitch -ExternalPort | select -ExpandProperty SettingData

MonitorMode=2 is “SOURCE“, MonitorMode=1 is “DESTINATION“, and MonitorMode=0 is “NONE”

Once you run the above cmdlets on the Hyper-V host, all traffic passing on the external NIC of Mirroring_VM_vSwitch will be “mirrored” to Websense VM which port monitoring mode has been set to destination.

Step 5: Configure Port Mirroring On The Physical Switch

In this demo, we are mirroring the traffic to two destinations NIC interfaces where the Hyper-V host is connected, because we’re using NIC Teaming on the host and the “Mirroring_VM_vSwitch” is created on top of the team.

As soon as you start mirroring the traffic to the Hyper-V host, you can open Websense VM and observe the received traffic on the mirroring vNIC.

Once the above steps are followed, you should be able to start filtering the happy users :

What are the best practices?

1. Have separate dedicated physical NIC or team NICs on the host.
2. Have a separate external vSwitch, because Websense VM will be always available and you don’t want to flood your existing production vSwitch.

Closing thoughts

Keep in mind that all this works within the boundaries of the same physical host. This means that if you want to move Websense VM across nodes in a cluster or to a different host, you need to configure steps 3, 4, and 5 above on each node separately with the same virtual switch name. This means that when Websense VM is live migrated to a second node, it will continue monitoring the traffic. That works!

Happy filtering day!

Cheers,
-Charbel

About the Author

Charbel Nemnom

Charbel Nemnom is a Senior Cloud Architect, Swiss Certified ICT Security Expert, Certified Cloud Security Professional (CCSP), Certified Information Security Manager (CISM), Microsoft Most Valuable Professional (MVP), and Microsoft Certified Trainer (MCT). He has over 20 years of broad IT experience serving on and guiding technical teams to optimize the performance of mission-critical enterprise systems with extensive practical knowledge of complex systems build, network design, business continuity, and cloud security.

34 thoughts on “How to Deploy Websense In Stand-alone Mode on a Hyper-V Virtual Machine? #HyperV #Websense”