VMware Cloud on AWS SDDC v1.9 was officially released on the 16th January 2020 and includes a wealth of enhancements with regards to the NSX Distributed Firewall and Inventory Groups. The release notes for SDDC v1.9 can be found below if you want to check out all the new features that are available with this release:
https://docs.vmware.com/en/VMware-Cloud-on-AWS/0/rn/vmc-on-aws-relnotes.html
In this article, I am going to show you how to protect a simple 3-Tier Application using the NSX Distributed Firewall and some of the enhancements around Inventory Groups. A policy-based VPN has already been established from on-premises into VMC and the application has already been deployed into a single network segment as per the diagram below:
A policy-based VPN has been configured to allow the following traffic:
On-Premises to VMC
10.1.9.0/24 - 10.101.1.0/24
10.1.9.0/24 - 10.2.0.0/16
VMC to On-Premises
10.101.1.0/24 - 10.1.9.0/24
10.2.0.0/16 - 10.1.9.0/24
The on-premises firewall has been configured to allow all traffic between the network segments and an ANY - ANY - Allow rule has been configured on the Compute Gateway Firewall to allow all traffic into the 3-Tier App Semgemt. I could lock this down but I want to focus on the Distributed Firewall security aspects for this particular blog post:
Prior to configuring the distributed firewall, I check the application is working as expected by accessing the webserver from the on-premises management segment (10.1.9.0/24) to verify connectivity:
Since this is the only application that will currently be running in VMC and I want to ensure maximum security, I switch from a Blacklist security approach to Whitelist with logging. This a new feature of VMC and set's the default ANY - ANY rule to deny with logging rather than allow. When setting the security approach you have the following options:
Blacklist - This option creates a default ANY-ANY rule to allow all traffic. This is the default option for the distributed firewall.
Blacklist with logging - This option creates a default ANY-ANY rule to allow all traffic with logging enabled.
Whitelist - This option creates a default ANY-ANY rule to block all traffic. All communication is denied access including DHCP traffic.
Whitelist with logging - This option creates a default ANY-ANY rule to block all traffic with logging enabled. All communication is denied access including DHCP traffic.
The option can be changed in the Cloud Services Portal (CSP) under Networking & Security then Distributed Firewall:
I verify connectivity has been dropped by pinging my WEB, APP and DB servers as well as try to access the application via http://10.101.1.11
The Distributed Firewall rules that I want to implement are as follows:
I only want to allow SSH and ICMP from my on-premises management segment to the 3-Tier App for support/troubleshooting purposes. I then want to allow anything to talk to my webserver but only over HTTP (TCP port 80). My web server needs to talk to my app server also over HTTP and finally, the application servers communicates with the database server using the MySQL service (TCP port 3306). Since we have a whitelist security approach all other communication will be blocked thus preventing any lateral movement by any malicious hacker. An example of this would be a hacker compromising my web server and laterally trying to move, say over a known MySQL exploit, into the database server to extract any data.
I’m going to use NSX Inventory Groups as the basis for my DFW ruleset and dynamically add members to the groups based on tags, which is new with v1.9 of the SDDC. Using tags has the added benefit that if I need to scale out any portion of my application i.e. add more web servers then I can simply deploy the server, assign a tag to the server an automatically ensure the correct security posture is applied to the workload without having to modify any firewall rules. I’m going to start by creating the following Inventory Groups with the following membership criteria:
Web Servers - Dynamically add workloads to the group when a
Web tag is applied to the VM
App Servers - Dynamically add workloads to the group when an
App tag is applied to the VM
DB Servers - Dynamically add workloads to the group when a
DB tag is applied to the VM
3-Tier App - This group will have static membership and I will add the Web Servers, App Servers and DB Servers group into it. Nested groups are also a new feature released as part of SDDC v1.9.
On-Premises Management - This group will have static membership which will include the CIDR range of the on-premises management segment (10.1.9.0.24)
To create an Inventory Group simply log into the Cloud Services Portal (CSP) and navigate to your SDDC. From here click on the Networking & Security, Groups and then Add Group:
I'm going to call this group Web Servers and give it a suitable description. Click on the Set
Members link to set the membership criteria:
I now want to click on Add Criteria and specify Virtual Machine Tag Equals Web and click Apply:
Finally, I can click Save to commit the changes:
I now have my first Infrastructure Group which will dynamically add VMs whenever a Web tag is applied to them. I will now continue and create the App Servers and DB Servers groups based on the App and DB tags.
I'm now going to create my 3-Tier App group with the membership being the Web Servers, App Servers and DB Servers groups:
To nest groups select Members and check the groups that you want to be nested:
Finally, the last group that I need to create is my On-Premises Management group:
This group is going to be based off the CIDR range 10.1.9.0/24 so select the IP/MAC Addresses option and enter the range:
I now have all the required Infrastructure Groups created and can start building out my Distributed Firewall ruleset:
The Distributed Firewall has been completely overhauled as part of SDDC v1.9 with a ton of great new features. The interface has been updated and now includes rule categories which are evaluated based on priority precedence i.e. Emergency rules will be evaluated before Environment rules:
1 - Ethernet - Applied to all SDDC network traffic
2 - Emergency
- Used for quarantine and allow rules
3 - Infrastructure - Define access to shared services. Global rules - AD, DNS, NTP, DHCP, Backup, Management Servers
4 - Environment - Rules between zones - production vs development, inter-business unit rules
5 - Application
- Rules between applications, application tiers, or the rules between microservices
Configurations can now be saved and published at a later date/time (Maybe within a change window) and we can also fully exclude VMs from having DFW policies applied. These are just a few of the improvements, remember to check the release notes for more.
One of the huge usability improvements in SDDC v1.9 is the ability to dynamically re-prioritize rules by dragging and dropping them into place. You can also filter rules by name, source, destination or service and can edit rules inline on the UI. This makes creating and modifying DFW rules much more efficient.
We are going to create the required rules for our 3-Tier App and the first thing we need to do is create a new policy within the Applications section. The name of the policy can be modified inline:
Click on the three dots to the right of the rule and click Add Rule:
Give the rule a suitable name, in our example, we want this rule to allow Admin access to the 3-Tier App from the On-Premises Management Network for troubleshooting and support purposes:
Within the Source set it to the On-Premises Management Infrastructure Group:
Set the Destination to be the 3-Tier App group:
Now the services we want to allow are SSH and ICMP (If the service you require is not available you can add custom services):
We can see that our admin access rule is in place but since we have not published the ruleset this is currently not live:
I'm now going to create the complete ruleset for the application based on the following requirements:
Once the ruleset has been created remember to publish it otherwise it will not be realised within NSX.
The final task is to tag our VMs with the correct tags which will ensure they are added to the corresponding infrastructure groups and the correct security policy should be applied. Navigate to the Virtual Machines section and edit one of the VMs:
Tag the VM with the required tag. In our example, this would be either Web, App or DB:
Ensure all VMs in scope are tagged accordingly:
You can check to ensure the VMs have been tagged correctly and they appear in the security group by viewing the group members:
My Web Servers group now has WEB01 as a member:
Using groups and tags has the operation benefit of not having to make any changed to rules if I scale up the application. If I add a new Web Server all I simply have to do it tag it with the Web tag (Ideally through automation) and the correct security policies will be applied to the workload from day one.
Now the Distributed Firewall policies have been created and the VMs tagged let's check to ensure my application is working as expected. If I browse to the Web Server I can see that I can successfully connect to the 3-Tier Application:
From my desktop which is in the On-Premises Management CIDR range, I can successfully ping all workloads:
I can also successfully SSH into the Web Server but notice that I cannot SSH or ping from the Web Server to the Database Server:
VMware Cloud on AWS SDDC v1.9 is an update packed with new features and functionality and just shows the power of the platform in helping customers migrate and secure their workloads with familiar tooling.
