NSX 6.4 was recently released, and while I haven’t even managed to finish drafting my blog posts for NSX 6.3, I had to jump on the new release. Why? It introduces some really cool features for segmenting traffic at Layer 7. There are some other reasons to upgrade (bug fixes, upgrade coordinator, HTML5 UI,sorta..) but really I wanted to play with the new Layer 7 abilities.
What’s the fuss about?
Conventionally, in order to limit network traffic from being able to traverse from one host to the next, you had to create different interfaces on a firewall or Layer 3 device and setup ACLs. This meant maybe having a public VLAN and a private VLAN and allowing only certain ports and IPs between the two interfaces to communicate. We know that NSX introduces the concept of VXLANs and, more specifically, the introduction of the Distributed Firewall (DFW) allows the administrator to restrict traffic flow based on host, cluster, resource pool, VM name, vNIC, etc. This disrupts the typical “3-tier” North/South traffic flow and provides so much more control over what VMs/services are allowed to communicate to one another. In fact, one of the neat things that this allows is Layer 2 filtering, or the ability to restrict one VM from talking to another over certain ports even though they’re in the same subnet on the same network – clever!
However, NSX 6.4 took it a step further! Next Generation firewalls (NGFW) are all the rage lately, bringing more layers of the OSI model into firewall control as well as adding features like Layer 7 inspection, inline AV, intrusion detection, etc. Before you get too excited, NSX does not offer AV or IDS (yet?), but it does offer Layer 7 features at the DFW! Tired of developers rolling out “new apps” only to find later that they’re using SSLv3? No problem – filter ALL traffic in the environment and do not pass any packet associated with SSLv3 – done! Want to block SSH from any VM with the “web” in its name? You got it!
But couldn’t we do this before?
Yes and no. Yes, you could do some Layer 7 packet inspection to do different things but now you can do it at the DFW. Further, yes, you can block SSH to/from any VM/Cluster/etc. participating in the DFW. However, when doing protocol filtering previously, you would limit communication over specific protocols – now you can inspect packets and see what the application layer looks like in the network flow and allow or block flow based on application IDs.
When setting up a DFW previously, you might block SSH like this:
The above rule results in:
However, what if people are more clever than you think and they decide to move SSH from TCP 22 to TCP 2202?
Well, damnit. Now we have to implement some sort of configuration management that routinely runs and checks config files to make sure services aren’t running on different ports – intentionally or otherwise. No – wait, that sounds absolutely terrible. Sure configuration management systems are great but that’s not my idea of fun. Instead, let’s just block SSH from running at the application layer!
Notice how the service specified in the screenshot above is prefixed with “APP_”? That’s because VMware has provided a number of pre-configured application IDs to help you manage context-aware firewall rules. So, what happens if we try to SSH to TestLayer7 VM over 2202 now?
Almost convinced? Here’s a little more evidence:
You can see that the network flow has been blocked by an “Application Context” referring to “APP_SSH”. It’s really nice that VMware included the context that blocked the flow, because otherwise you might have to dig through DFW rules to see why the flow is altered or not.
It’s really that simple!