Back in 2012 there was quite the hubbub around VMware acquiring a company called Nicira. At the time Nicira was known for software defined networking and a lot of people thought that this was a shot across the bow at traditional networking vendors. As many of you probably already know, Nicira became VMware NSX, but I didn’t really ever see a heightened “war” of SDN involving the acuisition.
Despite all the talk at the time, I never really got a good idea of what the actual value to an organization and since then I haven’t heard a whole lot except the standard SDN arguments: you can automate the configuration of your network (in this case your virtual network), you can reduce the number of network configuration issues you have when you deploy a new host, etc. And, while I don’t work a lot with super-large organizations, many of the companies pretty much gave a collective “Big Whoop!”. A lot of them looked at their VMware environment and while hosts got added and removed, the overall virtual network didn’t have a whole lot of change, and they therefore didn’t feel like there was a big need for them. So if that wasn’t a compelling reason, why deploy NSX?
I had the honor of attending Networking Field Day 15 in sunny California. VMware presented on NSX in what I believe was their first presentation at a Tech Field Day event. I’m glad they did, because it gave me a view into something that I think may be compelling for some organizations: security.
Behold, the Power of Micro-Segmentation!
With NSX, users can deploy an enterprise firewall in their VMware environment that can configure policies down to the vNIC level. What this means is that you can basically set a stateful firewall policy per VM.
“But I already have a firewall!” you might say and that’s great. NSX does not remove the need for you to have a hardware firewall in your environment. NSX micro-segmentation is additive and provides another layer to your layered security architecture. If someone gets through your perimeter firewall or an internal firewall too, this can still potentially protect your virtual machines. But in addition to that, if you have virtual machine to virtual machine “east-west” traffic on the same host, that traffic won’t hit your hardware firewall unless you force it to trombone out of the host and back in.
One of the things that I was worried about when VMware was talking about NSX micro-segmentation and firewalling was that a lot of people have trouble identifying what traffic to block on a perimeter firewall, how are they going to define what traffic should be allowed to a single vNIC? VMware has a tool called Application Rule Manager (ARM) that allows an organization to analyze up to 30 virtual machines at a time to identify normal traffic and help you build a firewall policy based on those traffic patterns. In my mind, this is super handy to spin up for a month, see what sort of traffic baseline you get and then lock down the VM moving forward.
What’s the Catch?
As you can tell, I like the concept of being able to deploy security policy so granularly in your virtual environment, but like me you may also want to know what the catch is. So here are a couple of shortcomings or potential shortcomings that might be out there.
As I mentioned in the last section, NSX provides a stateful firewall and while I’m not a security wonk, my security friends have repeatedly told me that stateful firewalls can only do so much. If some bad actor decides to determine what sort of traffic your policy is allowing to a VM they could potentially hide their traffic using trusted port numbers and encrypted traffic. Depending on what the normal traffic to a virtual machine is what has been compromised in your environment, the difficulty of someone taking advantage of this will vary (because you can lock down traffic between IP addresses, etc, like any stateful firewall).
The second thing that I don’t have an answer for, so I don’t know if it is a concern or not is resources required for running micro-segmentation and the centralized edge services gateway (this firewalls north-south traffic). In the presentation at Networking Field Day, VMware was asked about this and they basically said, “Don’t worry about it, it won’t be a problem” without actually getting at what the resource usage was. Admittedly, the NSX firewall is running at the kernel level from the way I understand it, so it won’t fight for resources within a virtual machine, but the compute for the kernel still has to come from somewhere. If traffic floods into the virtual firewall and starts taking up more and more resources what goes first, the VM compute or the compute that is being used by the kernel for the NSX firewall and at what point does it cause a traffic bottleneck? I don’t know the answer, and maybe this isn’t even something to be concerned about, but since I don’t know it goes in this section.
Wrap it Up
Ok, so we’ve had our brief overview. What’s the verdict? I think that for organizations that are looking to add another layer into their layered security architecture, NSX can offer value. Even without deep packet inspection, by adding stateful firewalling that can lock down a virtual machine to communicate in pre-defined ways with pre-defined hosts you can add one more way to defend your virtual environment. Additionally, by using the Application Rule Manager tool, administrators who don’t understand traffic patterns for certain virtual machines can get help with defining firewall policies.
I occasionally attend various Tech Field Day events organized by Gestalt IT. These events are sponsored by networking vendors who thus indirectly cover our travel costs. In addition to a presentation (or more), vendors may give us parting gifts ranging from their own products, to usb keys and various swag. Additionally, VMware provided a voucher for an NSX training class and test. While I have not taken either yet, I have informed them I would be interested in the class.
The vendors sponsoring Tech Field Day events don’t ask for, nor are they promised any kind of consideration in the writing of blog posts, and as always, all opinions expressed here are entirely my own and not those of sponsoring vendors, my employer and/or its affiliates, and all the mistakes are my fault (but please do feel free to point them out, I gladly correct factual errors).