Latest posts by Brandon Lee (see all)
- Improving security with VMware NSX and micro-segmentation - Mon, Jul 17 2017
The problem with traditional firewalls is they come into play with north–south traffic or traffic that is entering or exiting the datacenter. Currently, the higher security concern when it comes to malware traffic is east–west traffic or lateral-moving traffic in the data center. Once attackers get past the perimeter, few defenses may be present to stop the spread and damage caused in the internal network. This can lead to serious security concerns, especially when thinking about the various versions of ransomware as of late.
Conventional network segmentation ^
Segmenting traffic from different workloads via layer 2 and layer 3 boundaries has sufficed over the years to manage traditional internal network security. Generally, different business units will have their own IP ranges and virtual LAN (VLAN) IDs. The problem with this approach is that we are still dealing with large chunks of network traffic within that range that may not need to be able to access certain internal resources. Ideally, we need to apply data center network security down to each workload, server, virtual machine (VM), and so on—not simply a network range.
In addition to security concerns, another disadvantage to segregated networks that use a firewall or other device for routing is that traffic is what we call "hairpinned." This means the traffic has to leave the host, go up to the router, and then come back the way it came in the first place. Since the only purpose for this happening is to apply routing, filtering, and access control lists (ACLs), it is terribly inefficient when we might be dealing with hundreds or even thousands of nodes or workloads.
What is micro-segmentation? ^
When thinking about the aforementioned challenges with traditional network security, we can overcome its workload limitations with VMware's NSX. NSX provides a virtual network overlay on top of the physical network architecture. It is network agnostic in that you don't have to make physical network changes to use the NSX overlay.
The security benefits NSX can achieve greatly surpass the capabilities of tradition firewall technology at the perimeter—all because of the ability of NSX to accomplish micro-segmentation. Additionally, since the firewall and filtering power is inside the ESXi kernel layer, it is extremely efficient, and traffic flows and filtering can happen at near line speed. The "hairpinning" effect described above is no longer necessary.
What is the micro-segmentation that VMware NSX is able to achieve? Simply put, micro-segmentation in the context of VMware NSX is its ability to isolate and segment resources logically and apply security policies to those segments. This can be down to an individual VM workload. In addition, VMware NSX is able to integrate with an ever-growing number of firewall and security appliance vendors who extend the NSX feature set to include filtering all the way up to layer 7 (the application layer).
How to configure VMware NSX ^
Now that we have a high-level overview of what micro-segmentation is, let's look at how we can institute some basic micro-segmentation using VMware NSX. One of the key pieces of functionality that we have with VMware NSX is the Distributed Firewall. With this we can effectively control access based on various object attributes and not just IPs or VLAN IDs.
VMware NSX contains a powerful service composer that allows us to create dynamic groups based on these attributes. In the service composer below, we are creating a New Security Group that contains dynamic membership, which will do much of the heavy lifting for us. Once dynamic groups are in place, NSX will automatically apply the rules to new VMs provisioned that match the criteria of the dynamic memberships. The example below shows dynamic membership based on the VM Name, which takes into account the VMware inventory name of the VM.
Once we have our dynamic membership groups in place, we can use these for scoping firewall rules in the NSX Distributed Firewall. As we can see below, I have created three dynamic groups (App-Servers-Group, DB-Servers-Group, and Web-Servers-Group) that are already picking up the VMs we have in inventory that match the specified criteria.
Now, if we go back to the Distributed Firewall, we can edit either the Source or Destination and choose the security group as our object we are filtering on.
Notice below that selecting the Object Type: Security Group will list our security groups.
Since NSX processes the Distributed Firewall rules from the top down, we can create our rules so that we allow the appropriate VM communication and filter the rest. For example, a few simple rules below use the NSX security group we defined.
We are allowing HTTP/HTTPS traffic from the Web-Servers-Group to the App-Servers-Group and then allowing MS-SQL traffic from the App-Servers-Group to the DB-Servers-Group. We have changed the Default (TCP/IP) Rule to Block. Essentially we will be blocking any traffic other than what we have defined with our security groups.
By using the NSX Distributed Firewall, we can easily create logical segments in our resources that do not rely on IP subnets and VLAN IDs. Rather, they rely on a more intuitive scoping based on familiar object identification in vCenter. This provides a powerful way to secure resources.
By creating micro-segmented resources with VMware NSX's micro-segmentation techniques, we are making it harder for today's worst malware such as the WannyCry and Petya ransomware to propagate through the network.
Additional VMware NSX functionality such as the following can combat such malware attacks:
- Monitor port traffic to and from certain VMs such as port 445, which recent ransomware has exploited
- Redirect traffic directed to business-critical systems to undergo extra scrutiny with intrusion prevention system (IPS) solutions integrated with NSX
- Easily group at-risk systems with the service composer dynamic security groups
- Use the VMware NSX 6.3 and higher end-point monitoring functionality, which provides visibility inside the guest OS itself