Ask the Expert: VMware NSX - Microsegmentation and Security

This Ask the Expert session is now open for questions. For the next couple of weeks our Subject Matter Expert will be around to reply to your questions, comments or inquiries about our topic.

Let’s make this conversation useful, respectful and entertaining for all. Enjoy!

Today security in the data center software defined has been a constant demand and increasingly specific as Gathner , which implies greater investment in tools for this area , according to Forrester and his model -Zero - Trust- one zero confidence zone is one that does not have not have confidence in any packet traveling through the network either internal or external to the data center , although it is a reference model . the dynamics of the data center should be on par with the threats today , the VMware solution is in tune with these challenges and aware at all times of the need for better mechanisms to a safer SDDC without the inherent complexity new tools has a solution that provides us plus a flexibility the following advantages to be essential for the solution of micro -segmentation :

• Isolation: Creating and Isolating networks using NSX Network Virtualization technologies
• Segmentation: Ability to segment workloads/applications on a granular basis using NSX Distributed Firewall.
• Advanced Services: Ability to bring in third party advanced security technologies from PAN, McAfee and others
• Policy Framework: Tie host, network and partner security components together with a seamless policy leveraging NSX Service Composer

This session will discuss some of the technical aspects of each point and how the solution VMware NSX makes its implementation is simplified and making safer Software Defined Data Center .

As I mentioned before traditional Datacenters are a shell in terms in security and the focus is in the perimeter, sometimes the same firewall is used to protect virtual workloads making challenge how to detail the protection in this ambit.

Fig Actual approach in traditional virtual datacenters

VMware NSX bring the answer to this and other challenges  enabling visibility inside the datacenter and how is protected the virtual datacenter as well as reducing the breach of security  in granular fashion  using distributed controls like DFW or Distributed Firewall.

                                              Fig. conceptual Virtual datacenter Security

First lets describe what is the DFW and how it works and mainly what brings to complement the picture on micro-segmentation.

A DFW is a Statefull firewall at hypervisor kernel level, this means that the DFW is running embedded in the VMware vSphere  but hidden from VMs, this means that is not a VM protecting other VM’s is an instance of a FW per each ESXi host you have in datacenter (running ESXi and working in cluster).

The inner layer of this firewall enforces firewall rules at vNIC level per every VM been protected, again is not a virtual appliance running part in the user space and some in kernel space like 3party appliance we try to describe further, so that the throughput is related to the number of physical nics in each ESXi hosts, as said this is a statefull firewall and work on OSi layers 2 to 4 but is able to offer a complete solution integrated with 3party vendors extend his capabilities up and including  layer 7.

As in traditional FW there is a central management for all the configuration but is only one for all the DFW instances per ESXi Hosts and there are three ways to manage and configure and consume is want so, for the DFW, using the vSphere Web Client, using a Cloud Platform or using Rest API.

Will see more in deep how the DFW works but first let’s map what bring to the Virtual Datacenter:

Micro-segmentation can enabling administrators with isolation between layers inside the virtual datacenter, this means that we are now able to enforce separate tiers and isolate the applications between each other’s by using overlay networks, breaking the physical limitation of implement vLANS.

Segmentation is another advantage, this means that we can have between those tiers switching and routing services and more over firewall services where we can control all the communications between tiers and making exactly what kind of packets we want to traverse and what direction horizontally without the need to determine a piece of hardware outside the virtual datacenter dealing with performance and nearest the applications.

Advance services and Policy framework, this advantage consists on take to upper layers the DFW by integrating 3^rd party vendors for advance security introspection, security policy enforcement, and other advance services offered nowadays in the market.

                                                       Fig. advantages from micro-segmentation

Now let see in deep the concept of DFW and service composer, there is something we need to understand before go deep in this awesome stuff, from security perspective NSX has two statefull firewalls, I would say inner core and extra core, in other words the conceptual FW for the North –South traffic inspection and the East-West traffic, the North-South FW service is present in the External Service Gateway, a VM format appliance which is able to provide this and other services.

In the other hand is the DFW the firewall we are going to describe, and both can be controlled by NSX manager as figure depicts

                                                            Fig. DFW and Edge Firewall

this will be continued...

Now let see in deep the concept of DFW and service composer, there is something we need to understand before go deep in this awesome stuff, from security perspective NSX has two stateFull firewalls, I would say inner core and extra core, in other words the conceptual FW for the North –South traffic inspection and the East-West traffic, the North-South FW service is present in the External Service Gateway, a VM format appliance which is able to provide this and other services.

In the other hand is the DFW the firewall we are going to describe, and both can be controlled by NSX manager as figure depicts

                                                                Fig.DFW and Edge Firewall

The distributed firewall is compose by two pieces or is taking care of two tables:

Rule ID table: used to store all the policies rules of the DFW

Flow entry table: used to caching all flow entries with permit action in the DFW

As many firewall in the market DFW enforces firewall rules from top to bottom the first packet who reaches the DFW is analyzed then if the flow exists in the flow entry the packet is checked against the FW rule otherwise if the incoming packet is not in the flow table then is check the Rule Id table and only then if, is permitted the flow is caching so that when other packet reached the firewall only check the flow cache if the rule is to drop the packet the packed is discarded.

Of course this is not new from the state full firewall functionality but is an elegant way to characterize the how the DFW works all at line rate speed at hypervisor level, of course there is other piece in the picture that answer the question what happen when there is another third party vendor in place? Well in principle is the same the only difference is the packet flow internally at hypervisor at fast plane and slow plane to send the packet to be analyzed by the engine of the 3^rd party vendor, but let’s describe the architecture of DFW.

                                                                Fig  packet processing by DFW

Just ot remember the DFW is working or works at hypervisol level, then at Vnic level and there is the enforcement of policies,  but let hold on for a moment on describing the complete architecture: (try to follow with the figure below) VMware NSx cosnis of  two components fundamental pieces for the micro-segmentation, and plase forgo for a moment about NSX controllers, those are no necessary for a microsegmetnation deployment but in case of VXLAN sure you will need them, so let [s assume that we hace the basic componentes as goes are: the web client important piece to consume the DFW services, this can be substitude by a Cloud platform manager or a rest client like postman, o perl, ppython scripts pointing to the ResAPI exposed by the NSX manager, then we have the NSx manager and the vCenter server those two are the control plane one for vSphere layer and VDS (a.k.k vSphere Distributed Switch) , the NSX manager as control plane for the DFW since this is instanciated on every ESXi host in a cluster(not indivualy ) for matters of explannation we have in the picture only one Esxi host from that prepare cluster for DFW in other words you hav eto install in every ESXi host oof a cluster the vSphere Installation bundle from NSX manager (NSX manager comes with it so don’t worry to try to get that piece from somewehere else).

Ok, the Nsx manager is containing the vpostgress DB, the Identity Engine and the clien for some sort of bus messaging protocol as application but not worries this is only informative and maybe just maybe if you have a problem there let GSS guys take of you since all of this embeded, so , the AMPQ client inside the NSX manager talks with the vsfwd which is on char of the FW processing, just like the vCenter does with the vpxa for the objects and resources inside the ESXi hosts for make the forecast and calculations for demand and available resources, then this module “vsfwd” been in the user space or slow plane keeps a deep communication to the vSIP or the vSphere Integration Platform or the  VMware Internetworking Service Insertion Platform I put it like that since I have found sometimes confusing called in way or other but is the same, so this vSIP is a daemon in the Kernel space or fast plane whitin the ESXi host and this one  is on chager of all the data plane for the DFW it receives the firewall rules from NSX manager and enfoce in the VNIC level of every VM in that particular ESXi host, in addiotion this will take care of desition on what to to if there is a thir party vendor engine in place and what to do with the packet to be analized by this engine and then go back to the VM.

                                                                Fig. NSX architecture

The order of processing is formed in slots inside the VNIC the first 4 are for vSphere NSX and the last for other product engines like Palo Alto Networks, TrenMicro, Hydra, Rapid7 so on so forth, there Is not an specific order but it counts to 16 slots.

                              Fig.service chaining or service serialization in DFW for NSX

This will be continued….

Hi +vRay, how easy is it to implement a security scheme zero trust as it is mentioned in Forrester with the NSX tool?

We have define how the DFW works and his interaction with 3 party vendors, so let’s check some functionality of this, well you can have a function of a  flat Firewall running on the hypervisor, but what makes so special NSX is the way we can set rules thru the service composer.

So what Is the service composer piece and how is related with DFW ?, well first depending on how are you securing your virtual datacenter maybe using one flat Logical Switch (virtual wires) or in tie-ring way having each bunch of VMs in their own isolate logical switch it is possible to build some architectures like shown:

                                             Fig. DFW security topology

Taking this is a account we still working with object VM as a piece of building the 5 tuple for Firewall rules, but there is more, you can leverage of vCenter Server object all time you need to build your firewall rules every object but folders, so your firewall rules are more human understandable, so Service composer uses this object to automate the creation of rules on the fly, for example assume when have 2 VM’s VM1 and VM2 an you need to secure the layer between them making or not communication on ports defined , ok assuming they are in logical switch (single tier different VMs or apps) you can set a policy rule against this logical switch in where VM with some criterion can fit and automatically allow or deny these ports, at glace VM1 is a DB server and VM2 is running a WEB server app on it, for that reason when need that WEB server only be possible to communicate to the DB VN by port 1433 and nothing else and this WEB VMs have open the 80 port to the world (it is just a simple example  and there is much more to adequate like the infrastructure services for each VM like ntp, dns etc.)

                                             Fig. dispousal of VMs in two tier.

An important piece in security in VMware NSX is the concept of Security Group, as I mention in the example before, the service composer uses objects of vCenter to grouping VMs dynamically and this grouping is called security groups, something like a logical container of VMs on which we can apply security policies (open or close ports ) we need to notice that all these vCenter Objects are dependent of the vMtools on VMs and we describe the functionality with an example:

Let’s say that  we have two logical switches attached to a logical router (at this moment think on the router as a flat logical router running in ESXi host level similarly to DFW) just a big note the security is orthogonal to network topology and is not dependent of other features on NSX, so we have those two logical switches and each logical switch has two VMs running applications windows or Linux within, when we use the Service Composer and create a SG (security Group) called windows and the projection is over the two logical switches the action will be “include all VMs called windows in the security group Windows o WIN or APP-Windows whatever could be the criterion but only take in account the simplest way is the more efficient” in auto those VMs will be include in the SG in this picture you can see the name of the SG is SG-WINDOWS and VM1 and VM3 are part of the security group, the name of the logical switches are WEB Logical-switch-1 [or the real name ID of the Virtual Extensible Network : 5001] and the second one is called APP logical-switch-2, then if we want to apply SP(Security policies) on the SG we just set the DFW rules to be applied and be something like the figure below:

                                                   Fig. Security Groups on DFW NSX

As you can see the VMs in the example lives and contents for resources with others in same clusters of ESXi hosts, this mean for instance Distributed Scheduler on cluster decides to move VMs from one ESXi hosts to another the security will be stick with the VM no matters what happens in same way the engine service will not lost the VM to keep minoring on security behavior,.

Conclusion:

DFW is a big power tool to make easy the security implementation something that in recent years was nearly impossible due to nature of virtualization, empowering clients with all functionalities in the market today at line speed and with the nature of a VM, is more ahead to come but the future now about VMware NSX is making valuable solutions for today dynamics of business.

It is relatively transparent, since the very nature of the tool allows us to segment between virtual machines, so that the virtualizer or hypervisor in this case ceases to be a trusted zone where traditional schemes the perimeter firewall to address IP level "protects" the VMs, the answer to the question? which is what happens within the realm of the kingdom of hypervisor if a VM is committed ?, Well the answer is that security NSX is embedded so that it contained the problem, if it is necessary to stop maintenance hardware, the VM can be moved freely without reconfiguring their safety, or even if the VM is discarded and an equal is created with the same name, for example, is automatically added to the protection group has been applied.

Specifically it is not only possible to have a model like the zero trust something that was unthinkable a while ago, but it is also possible to propose more advanced security services leveraging with third parties and network services the solution offers.

regards

+vRay

What would happen if I have a general fail on NSX DFW?

Although very unlikely, the recovery mode is similar to an appliance physical network, unless the cost of having vApp is far from a physical appliance, plus the dump configuration backup, in the natural normal behavior if example one of the ESXi host that has an instance of DFW has problems effect is to block traffic safety, however sometimes this behavior is not expected but can be determined from when a fault is present the vM can be evacuated another ESXi hosts without reconfiguring the DFW, we also have a control plane and data plane in case of failure of control plane the plane data is independent and "saved" rules are maintained in each instance DFW by default.

regards

What's the minimun ESXI hosts do I need for DFW?

Hi there,

As per best practice a common deployment is composed with minimum 3 ESXi hosts in the management cluster for DRS rules and each NSX controller with anti-affinity rules to "live" in each ESXi, there is not minimum for NSX edge cluster as well for payload or all the ESXi that will support the virtual production applications, but at the end it depend, in my experience sometimes 3 or 2 ESXi hosts with a huge amount of RAM and CPU is like a waste for this reason even counting  (in management cluster) with other tools so it is possible to have living the NSX controllers in one cluster but it a kind of risk that we have to understand/justify why.

regards

Can one protect physical machines with this tool?

In some way it can, but in strict sense of the word the DFW cannot see the traffic between physical instances, let me explain my idea with an example.

let's assume we have a cluster with NSX Distributed Firewall prepared, we have tiers like DB and app tier, but we need to have interaction with legacy systems or because we can do something to virtualized them maybe a cost or a license we don't know just let's assume we have to back up the App tier and the DB tier, this means that VMs in DB tier and VMs in the App tier need some interaction with the backup application running in a physical server and is network base backup application, so we have installed agents in each tier, so how to protect the designated as network for backups? who to make secure and avoid some other VM's that can be attached to this backup network be able to "see" the traffic between agents of backup and the physical backup server without compromise the security? well DFW will set a bunch of rules for traffic in and out of the virtual tiers (DB and App) in this way we can set by means of grouping the IP addresses of physical servers as an object inside the firewall and make it part of a rule avoiding this problem, so for instance could be something like this:

source                         destination               service                    action               action applied to

physical_servers_ip       DB_tier                    any_ecxep_permit         block               backup_network or dvPortgroup

                                                                  explicit

regards.