Regardless of how a person finds out about Spoofguard, I’ve found it causes a lot of confusion about it’s purpose, and the role it plays within the SDDC. Typically, people end up questioning me about it’s purpose because of two reasons:
- Someone has found out about it while researching utilizing NSX in general
- Specific investigation into utilizing NSX with a security partner via Network Introspection has been performed, and they have found articles regarding steering traffic from virtual machines that do not have VM Tools installed.
Let’s take a look at what Spoofguard is designed to do.
Spoofguard is a tool that is designed to prevent virtual machines in your environment from altering their existing IP address. In the instance that a virtual machine’s IP address does not match the IP address on record in Spoofguard, the virtual machine’s vNIC is prevented from accessing the network entirely. There are a few reasons that this could be valuable in an environment:
- Preventing a rogue virtual machine from assuming the IP address of an existing vm – This is the traditional rationale as to why one would utilize Spoofguard: a physical or virtual machine comes online with the same IP address as an existing machine. More maliciously, an attacker could utilize ARP poisoning to intercept traffic from the victim to it’s gateway (á la Ettercap).
- Ensuring the IP addresses of virtual machines cannot be altered without intervention – In some environments, it’s preferable that virtual machines cannot alter their IP addresses without proper change control review. Spoofguard facilitates this by ensuring that the virtual machine owner cannot simply alter the IP address and continue working unimpeded. In this case, the team responsible for the vSphere/NSX environment would have the additional responsibility of ensuring the new IP address (configured by the VM owner) would be allowed via Spoofguard.
- Guaranteeing that distributed firewall (DFW) rules will not be inadvertently (or deliberately) bypassed – For DFW rules created utilizing IP sets as sources or destinations, the possibility always exists that a virtual machine could have it’s IP address changed, thereby bypassing the rules in question.
Before we get into specifics surrounding the above examples, I’d like to call out something I struggled with myself, which is that Spoofguard in NSX does NOT operate like what you may think of in regards to anti-spoofing, especially if you have a traditional firewall background.
Anti-spoofing in the traditional sense typically revolves around a layer-3 device (firewall) calling out what networks should exist behind each interface. In a simple example, anti-spoofing prevents a firewall with a publicly accessible IP addressed interface from allowing inbound traffic that is sourced from a private IP. It’s a sort of sanity check around making sure that the traffic being received by the firewall for processing should actually be able to originate from behind that interface.
Spoofguard operates by ensuring that the vNIC it is protecting is utilizing the IP address that it should. If Spoofguard believes your vNIC’s IP is 192.168.0.1, then any attempt to source traffic from another IP address on that vNIC (simplest example is if you altered the IP address on the virtual machine), then Spoofguard will block all access to/from that vNIC entirely.
Sound good? Ok, Let’s dig a little more explicitly into the above situations.
For option 1, Spoofguard can prevent this specific situation by preventing any virtual machine from accessing the network at all until it’s specific IP address has been approved. This would require using Spoofguard in what I consider it’s strictest mode, which would require each and every virtual machine’s IP address to be manually approved before being allowed access to the environment.
Option 2 is really no different than option 1; in this instance, all IP addresses would need to be approved within Spoofguard before the virtual machine is allowed access to the network. One differentiation, in my mind, would be this option would allow for a Spoofguard policy to be built using the “Automatically Trust IP assignments on their first use”, which allows the virtual machine to hit the ground running with the address it has when it comes online. This assumes that you trust your environment when you enable Spoofguard, and you also trust new virtual machines as they initially come online.
Option 3 is one that familiarized me the most with Spoofguard, as it’s often tied to the DFW and third party security options, such as Checkpoint or Palo Alto. You’ll often find articles about “Steering traffic from VMs that do not have VM Tools” that mention utilizing Spoofguard. While I don’t want to get into the specifics of traffic steering in this article, what I do want to call out is, in instances where a virtual machine does not have VM Tools, utilizing Spoofguard will only guarantee that the IP address on the vNIC of that virtual machine is as you believe it should be, and is not a mandatory component of traffic steering at all.
Remember, one of the key selling points of DFW is to utilize vCenter objects, such as the virtual machine itself, within rules. When you do this, VM Tools (or now, in NSX 6.2, there are options like DHCP and ARP snooping) is utilized to tie the virtual machine’s IP address to it’s vCenter object within the DFW policy.
If you use a virtual machine object within a DFW policy, and that virtual machine does not have VM Tools (and there’s not DHCP or ARP snooping), then any rules utilizing that object will not have an IP address associated with it at all; it’s effectively a blank entry.
In this scenario, this means that specific DFW rules you’ve created for this virtual machine will not match at all, and, as with any firewall rule set, traffic will continue to be evaluated against the existing rules until a match is found. If you have inadvertently allowed a liberal rule below your specific one (the specific one doesn’t match, because there is no association between that vCenter object and the virtual machine’s IP), then traffic to/from this virtual machine could match this more liberal rule, which would not have been your intent.
To create rules for virtual machines that do not have VM Tools, you must create an IP Set, which contains the IP address of that virtual machine, and then use that IP Set in lieu of the virtual machine’s vCenter object (again, and not to beat a dead horse, but this assumes that you are NOT using the additional detection methods of DHCP and ARP snooping). In this case, since the IP address of the virtual machine matches the IP set, traffic to/from this virtual machine will match against your intended DFW rules.
However, this sets up another potential security scenario. When utilizing vCenter objects in DFW rules, presuming the virtual machine has VM Tools on it, the IP address of the virtual machine can safely be altered, as these changes are communicated back via VM Tools to NSX. So, if your virtual machine was 192.168.0.1, and you changed this IP address within the OS to 192.168.0.10, the IP address change would be made dynamically within the DFW, and traffic to/from this new IP address would still match against any existing firewall rules.
IP Sets, however, are not dynamic. Compared with the above example, the DFW rule using an IP Set of 192.168.0.1 would cease matching once the virtual machine’s IP address was changed to 192.168.0.10. This presents a point of concern, as how can we be certain that the appropriate DFW rules will continue to match in the event of a virtual machine not utilizing VM Tools?
Spoofguard provides a method to address such a situation. In the event that the virtual machine without VM Tools alters his IP address, Spoofguard will prevent ALL access to and from this virtual machine’s vNIC. What this means is, if it’s a legitimate IP address change, you’d presumably be notified by the virtual machine owner, so you can alter the IP Set to the new IP as well as amend the Spoofguard policy. Otherwise, that virtual machine is cut off from the network.
Regardless of the reason as to why Spoofguard is enabled, what you must understand is that it is an all-or-nothing approach. Once Spoofguard has associated an IPv4 address (or IPv6 addresses) with a vNIC, if the IP address is altered on that vNIC, Spoofguard will block ALL access to and from that vNIC.
A few notes…
While I didn’t intend to get as deep as I did regarding Spoofguard, I do have a few points about it that I’d like you to keep in mind in regards to how it operates today, and I didn’t feel like they fit within the confines of what I had written above. With that said:
- [UPDATE] – After writing this initial posting, a co-worker was testing and informed me that he was able to approve multiple IP addresses for a single vNIC in NSX 6.2. I have now successfully verified this via lab. Looks like the existing NSX 6.2 documentation has not been updated properly. Spoofguard allows for 1 (one) IPv4 address and multiple IPv6 addresses per vNIC. Keep this in mind before attempting to utilize the solution. As far as I am aware, there is no way around this if you are utilizing multiple IPv4 addresses per vNIC.
- Spoofguard policies are applied to Distributed Port Groups, Legacy Port groups, or Logical Switches.
- A vNIC can only have a single Spoofguard policy applied to it. The default Spoofguard policy, which is disabled by default, “owns” all of the vNICs in the NSX prepared environment. As you create new Spoofguard policies that are applied to the target port groups/switches, you’ll see the vNICs are removed from the Default policy and added to the new one.
- This does present the possibility of having your Default policy being active (which would encompass everyone), and then selectively removing vNICs by creating a new policy (set to disabled) for their attached port groups/switches, if there is the need to not run Spoofguard on certain vNICs. However, this applies to all vNICs attached to said port group/switch; you cannot selectively choose where Spoofguard policy is applied based on just the vNIC or the virtual machine.