NSX

Complement your VDI environment with NSX

IDS/IPS.

Posted by Chris Noon on Tue, Mar 16, 2021

The final post of this series will be around NSX IDS (Intrusion Detection System) and IPS (Intrusion Prevention System). Both these products are used to highlight attacks targetted around a VMware environment. While the dFW does a great job of providing zero trust access, what if someone tries to take advantage of that open access? This is the use case for IDS/IPS.

IDS and IPS used to be included with NSX-T Enterprise Plus (correct me if I’m wrong). However as of NSX-T 3.1, the licensing model has changed and IDS and IPS have moved into an ATP (Advanced Threat Prevention) license, which does/will include products such as LastLine and BitFusion. I think it’s key to note that users of the ATP license will benefit from not only the IDS and IPS but a bunch of VMware security complements.

IDS (Intrusion Detection System)

IDS is a detection system, it’s in the name. It analyses the traffic through particular flows and alarm when there appears to be an attack. This is a great way to understand which of your applications are vulnerable and the origin of the attacks, but it doesn’t stop them. You might ask, what’s the point?

There are a number of reasons you might want to enable IDS instead of IPS:

  • Understanding where your application landscape is vulnerable (or not) with no traffic intrusion.
  • Backing up budgetary requirements for additional security features, such as IPS (below).
  • Evaluating your current IDS/IPS solution.

If you’ve chosen to evaluate the NSX ATP solution, starting with IDS and you’ve seen tangible data. Then it might be time to consider implementing the IPS solution.

IPS (Intrusion Prevention System)

Now you’ve had a look at the IDS solution, let’s dive into the IPS solution. As the name suggests, it is a prevention system. This means that if it sees rouge traffic heading to or from your protected workloads, then it will block the offending traffic. Sign me up, right?! It does sound wonderful, but there are few things you should be careful of when implementing IPS solutions, not just NSX ATP.

  • There are such things as false positives. Meaning, legitimate traffic can be seen as malicious and subsequently be blocked. This is why reviewing traffic flows in the IDS model first is prefered, especially in brownfield environments.
  • The IPS process creates delays and is somewhat resource intensive. Only protect the VMs you want to protect and don’t provide a global protect all statement.

I love the idea of IPS implementations in greenfield as it provides added security from day 1. In brownfield environments, I would be somewhat cautious, as I mentioned above. You never know when your application or organisation will be attacked, so why not be over-prepared?

Why use IDS/IPS?

I think I’ve mentioned numerous reasons above, it all boils down to workload protection. Whether that be applications or VDI/RDSH instances, which has been the focus of this series.

I think the question shouldn’t be why use IDS/IPS, it should be why use NSX ATP! There are a number of standout reasons in my eyes:

  • The IDS and IPS solutions are easy to design and implement if NSX-T is already in situ. In fact, it is so easy, it actually shocks most people when you deliver a proof of concept.
  • One of the most important things, if not the most important, is the NSX IDS/IPS can be used for east/west traffic. There is no need to route traffic through a centralized appliance and hairpin the traffic back to the environment, which is the case for a lot of other IDS/IPS solutions. This also means you get protection for traffic flows within the data centre and the same layer two (2) domain.
  • NSX IDS/IPS aligns signatures relevant to the workloads you are protecting, it doesn’t apply all known bad signatures. This means if I am protecting my Windows 10 VDI estate with IPS, NSX will understand they are Windows 10 VM’s and apply signatures relevant to that OS. This means instead of processing through 10k worth of attack signatures, it processes a fraction of those. Speeding up the processing, lowering resource consumption without compromising on protection.

I understand I’m a VMware and NSX fanboy. But seriously, the ATP functionality is amazingly powerful and incredibly simple to implement. If you can, ask VMware or a VMware partner for a trial license and at least use the IDS functionality to evaluate your environment. You’ll be pleasantly surprised!

How to use IDS/IPS?

Testing IDS/IPS functionality is lengthy, to say the least. However, lucky for all of us, there is some dedicated VMware staff out there. Iwan has a terrific blog about testing IDS end-to-end.

https://nsx.ninja/index.php/NSX-T_IDS_end-to-end_testing

The post is long, but if you take the time to read through it, you’ll see that the implementation of IDS (and IPS) is simple and quick. It provides meaningful and readable results instantly.

I think the best thing about using the IDS/IPS functionality is the method of rule application. VMware and the NSX team have ensured the application of these policies feel as intuitive to the end-user as possible. They have essentially re-used the dFW application logic for IDS/IPS, allowing customers to start working with these features by re-using existing knowledge.

End of the Series

As of late, a lot of my customer interactions have been surrounding VDI/RDSH and how to protect them using NSX. I found that while the information is out there, I had to flick between multiple sites, depending on the specific topic. I hope people see this series as intended, one that talks about protecting VDI’s and RDSH sessions with a dash of automation thrown in, all in one place.