Use SpoofGuard to defend against malicious activity in VMware NSX
@SpoofGuard monitors network traffic to identify malicious activity and prevent phishing attacks. Before you enable SpoofGuard in @NSX, there are a few things you should know. Using SpoofGuard is an easy way to prevent phishing and web spoofing in @VMware NSX shops, but there are a few things you, as a network administrator, should know to determine what’s best for your environment.
SpoofGuard registers a VM’s IP addressand prevents that VM from communicating with any other IP addresses. If a VM administrator wants to change the IP address, he must coordinate it with the network administrator. Without this safeguard in place, a malicious user could easily hijack the IP address of an existing machine in the environment, impersonate that machine and bypass the firewall.
SpoofGuard isn’t an extra module on your ESXi hosts, but rather a component of the distributed firewall. It’s tightly integrated with the VMkernel, so, like other distributed firewall tasks in your network data path, it doesn’t significantly impact performance.
One of the reasons SpoofGuard doesn’t receive much recognition is that it’s often treated as an afterthought during NSX setup. Rather than focus on the SpoofGuard policy, which is disabled by default, administrators typically focus on routing and switching, firewall rules and NSX features, such as load balancers and virtual private networks, during initial setup.
Using SpoofGuard is as easy as locating the configuration under the Networking & Security main navigation panel and enabling the SpoofGuard policy. However, before proceeding, there are a few things you should know to determine what’s best for your environment.
Create SpoofGuard policies
As you can see in Figure A, in addition to the Default Policy, I’ve created three new SpoofGuard policies: the DB-Tier policy, the App-Tier policy and the Web-Tier policy. Each of these policies is connected to a logical network. For each new policy you create, you have the option of changing the Operation Mode to either Trust on First Use or Manually Inspect.
For the sake of this example, I’ve configured the three logical network policies to Trust on First Use, which means they allow VMs to communicate with the IP address the first time they come online. I’m able to do this because I created my VMs with vRealize Automation, which automatically assigns IP addresses with IP address management (IPAM). You can use the nsx-spoofguard-approve.ps1 script from GitHub to query your IPAM system and check whether to approve NSX SpoofGuard records.
The Default Policy applies to any VM not connected to one of these three registered logical networks. The administrator must manually intervene in order for these VMs to communicate with the discovered address. The Default Policy includes a setting that allows SpoofGuard to register self-generated addresses in the 169.254.0.0/16 and fe80::/64, but this setting isn’t enabled by default and, in most environments, isn’t something you want to enable.
You can assign SpoofGuard policies to distributed port groups, standard switch port groups and logical switch networks.