Feature Brief: Microsegmentation with Distributed Firewalls
Introduction
The ability to do microsegmentation with a distributed firewall is one of the key features of VMware Cloud on AWS. Not only does it provide an easy way to create sophisticated security policies, but it also allows for these policies to be applied to even a small cluster without any extra networking components or devices. This feature uses the same technology as found in NSX Data Center, and the rest of this article will explain how it works.
Distributed Firewall Concepts
Without the distributed firewall, VMware Cloud is essentially one flat zone.
- All VMs on a logical segment can talk to each other.
- A VM on a logical segment can talk to a VM on a different logical segment.
- There is no East-West security.
This might be acceptable for customers using the cloud to host a specific application or for more test/dev workloads but as customers evacuate entire DCs into the cloud, they often require some level of segmentation.
A distributed firewall is essentially a virtual stateful Layer 4 (L4) firewall – it’s capable of inspecting the traffic up to the Layer 4 of the OSI model. In simple terms, it means it can look at IP addresses (source and destination) and transmission control protocol (TCP) / user datagram protocol (UDP) ports and filter the traffic based upon these criteria. The difference from a traditional firewall is that a distributed firewall is implemented in software, and is applied on a per-VM basis.
What’s unique about a distributed firewall is that it has contextual view of the virtual data center – this means our distributed firewall can secure workloads based on virtual machine (VM) criteria instead of just source and destination IP addresses. Traditional firewalling is based on source and destination IPs – constructs that have no business logic or context into applications. Our distributed firewall can secure workloads based on smarter criteria such as the name of the virtual machine or metadata such as tags. This enables us to build security rules based on business logic, using tags or naming convention (which, if well-built, can specify physical location, business application, whether a workload is test, dev or prod, etc.).
Using a distributed firewall, we can offer east-west firewalling within the data center and achieve micro-segmentation and ultimately reduce the impact of a potential security breach and achieve compliance targets.
Constructing Security Policies
Distributed Firewall security policies in VMware Cloud on AWS are organized by sections, and consist of rules that can make use of security groups. Each of these concepts are described in further detail below.
Sections
There are four higher-level sections of rules to organize security requirements. These higher-level sections are simply a way to build your security logic.
Emergency Rules: applies to temporary rules needed in emergency situations. For example, imagine that one of your VMs has been compromised: you might want to create a rule to block traffic to/from it.
Infrastructure Rules: Applies to infrastructure rules only. Infrastructure rules are global rules that define communications between your workloads and core/common services. For example: All Applications need to talk to the set of active directory (AD) and domain name system (DNS) Servers.
Environment Rules: Applies to broad groups to separate zones, such as, setting rules so that the production environment cannot reach the test environment.
Application Rules: Applies to specific application rules. For example, allow ‘app-1’ talk to ‘app-2’ or block traffic between ‘app-3’ and ‘app-4’.
Default Rules The default rules allows all traffic.
Traffic is evaluated by the emergency rules first, then by the infrastructure rules, the environment rules, the applications and finally by the default rule.
This last rule allows all traffic. With an ‘allow all traffic’ rule at the end, it means we are ‘blacklisting’ traffic before that (i.e. previous rules specify which traffic is NOT allowed).
Rules
You can create rules within each section, consisting of
• A source
• A destination
• A service
• An action: allow or deny
• Whether or not you want to log the activity
To define your sources and destinations, you can use security groups. Security groups can contain
• IP addresses
• VM instances
• VM names
• Security tags
This allows security policy to be applied to virtual machines based on specific membership criteria.
Security Tags allow you to assign labels to virtual machines according to business logic. These tagged virtual machines can be automatically made part of a group that is used for firewall policies. Tags can be represent business units, tenants, countries, environments (test, dev, prod), etc. A key benefit of tags is that they do not depend upon IP address, so security group membership does not change if a virtual machine’s IP address is changed.
In practical terms, security groups helps users greatly simplify their security policies and use metadata to build security policy instead of leveraging IP addresses like in “traditional” firewalls.
Services
A service is a combination of the ports and protocols required for a particular function.
VMware Cloud on AWS comes with a number of predefined services, and you can add your own services too.
Summary
By using rules based on security group, you can provide fine-grained network security for virtual machines even if they are on the same network segment. This allows for great flexibility in the network design, and along with compute and storage policies, lets you utilize a single VMware Cloud on SDDC for many different purposes, thus allowing for very cost-effective cloud usage.