Tips on How to Create Filtering Policies for VMware NSX

In my last blog post I presented a blueprint for migrating applications to a VMware NSX virtualized data center. Ahead of VMworld, I next want to discuss VMware NSX’s strategy for creating filtering policies within this virtualized data center.

VMWare lets customers write filtering policies for any traffic that goes into an NSX data center, exits from it, or moves between different servers inside the NSX data center.  So any organization with a VMware virtualized infrastructure can write filtering rules and make policy choices for any traffic that has at least one of its endpoints within this virtualized data center.

Allow all

Of course, having the ability to create these filtering rules doesn’t mean that it’s easy to actually write them.  And one of the biggest concerns is what might happen when you turn these filtering policies on. For example, what if you have inadvertently created an incomplete or incorrect filtering rule – could it drop business-critical traffic or cause critical applications to stop functioning?

To alleviate these concerns and provide the beginning of a path to using NSX effectively, VMware ships the NSX product preconfigured with a default filtering policy that is completely permissive – it allows all traffic from any source to any destination with any service.  This permissive approach, known as ‘ANY-ANY-Allow’ filtering, contrasts sharply with the approaches from other firewall vendors that typically use a default ‘deny’ policy (a point which was highlighted by my colleague in his recent blog on Five Common Firewall Configuration Mistakes – and How to Avoid Them).

You may ask: ‘what’s the point of a security solution if it permits everything?’  However, there is sound reasoning behind this approach in this case.  VMware’s rationale is that users will be deploying NSX in environments in which there was previously no traffic filtering, so the risk is no greater than it was previous to the NSX deployment.  As such, to avoid causing disruption to business applications, NSX allows all traffic by default.  The advantage of this is that VMware customers can easily upgrade to NSX, and be confident that they will not be inhibiting, restricting or blocking critical traffic in any way during the transition.

Process of discovery

But once you’ve deployed NSX you do need to start creating filtering policies to make it an effective security solution. I suggest you start building up policies incrementally, while leaving the default position as ‘allow’.  To do this you need some mechanism to discover which traffic is actually going through the NSX environment, and use this information to identify the traffic that is valid and most critical (see tip below).  Once this traffic is identified go ahead and write explicit rules to allow it.

Over time, you’ll build up a series of ‘allow’ rules governing all types of traffic, while maintaining the ‘ANY, ANY, Allow’ rule as the default.  So in practice, what happens is that if traffic fits rule 1, allow it.  If not, but it fits rule 2, allow it, and so on. And finally, if it doesn’t fit any of the above rules, allow it anyway (by way of the ANY-ANY-Allow rule).

While you may think this is counter-intuitive because whatever happens you’re still allowing the traffic, but what this is actually doing is letting you discover all of the business-critical traffic that you need to allow – and preparing for the day when you flip the switch of the default policy to ‘deny’ and start filtering traffic based only on explicit rules, while discarding everything else.

So to deploy NSX, you should take a three-step approach:

• Deploy NSX with the default setting of ‘allow’.
• Use an iterative process of discovering and identifying the NSX traffic, and write explicit ‘allow’ rules for all valid business traffic that goes through the NSX environment.
• Change the default action from ‘allow’ to ‘deny,’ and start filtering traffic in the NSX environment for real to increase security within East-West data center traffic.

One more tip: instead of using VMWare’s default allow action, write your own explicit ‘ANY-ANY-Allow’ rule and place it at the end of your rules. Turn logging to “On” for this final rule, and track these log records to see the traffic is still getting through the VMware that has not been allowed by the existing explicit rules. Use this information to create additional explicit rules for that traffic. After a while the amount of logs produced due to the ‘Any-Any-Allow’ rule should go down to close to zero (it’s unlikely you’ll actually get to zero, but any remaining traffic will be bogus or rarely used traffic). At that point, you’ll be in a good position to switch over to the default position of ‘deny’.

If you’re going to VMworld next week, feel free to stop by AlgoSec’s booth #443 where we can show you how we help companies discover, migrate and manage their business application connectivity on VMware NSX.