Nutanix Flow with Microsegmentation
Nutanix flow is like your left hand and Microsegmentation is your right. You can use one without the other, but it sure will make your life more difficult. Using Flow for the first time totally opened my eyes. I could finally see, in complete detail, which computers and ports are talking to an application stack. No more "Let’s lock down that windows firewall port and see what happens.” Now you can finally see in real time what’s coming in and going out from a server. Once you have that wonderful knowledge. Simply switch from monitoring mode to applied. That’s when Microsegmentation (VM firewall) applies all the rules that were already discovered. Let’s not short change Microsegmentation. Not only can it apply VM firewall rules to a cluster, it treats multiple clusters as single firewall entity. It doesn't even matter if its across geographic sites. No Nutanix configuration changes are needed when moving a VM from site A to site B. Normally providing east/ west firewall rules would be a dauting task. Luckily, it’s no longer the case with Nutanix Flow and Microsegmentation. In fact, having Microsegmentation could have potentially saved several of my customers from CryptoLocker ransomware this year. Attacks are usually spread easily once inside the network. This is another way to keep the bad guys away from talking to servers that they shouldn’t have access to. Now let’s get to some examples.
Note: To minimize the length of this blog, I won’t be showing all steps that are required to setup Nutanix Flow with Microsegmentation.
- Client VMs have no protocol/ port restrictions to web servers
- Use Nutanix Flow to view network traffic to and from web servers
- Use Nutanix Microsegmentation to only allow the following:
- Port 80 traffic inbound to web servers
- Block all communication between Web servers
- Only allow ICMP outbound from web servers to client VMs
- Prism central with at least 32 GB memory
- AOS 5.5 or later
- AHV 20170830.58 or later. Not supported with VMware or Hyper-V.
- AppA_Client1 IP Address 10.21.193.210
- AppA_Client2 IP Address 10.21.193.230
- AppA_Web1 IP Address 10.21.193.75
- AppA_Web2 IP Address 10.21.193.60
Step 1. Create some categories. Categories are a way to logically group a set of VMs
- AppType: AppA_Client
- AppType: AppA_Client_Tier
- AppType: AppA_Web
- AppType: AppA_Web_Tier
Step 2. Apply categories to VMs
The following categories have been applied to VMs:
- AppA_Client1 and AppA_Client2
- AppA_Web1 and AppA_Web1
Step 4. Create Security policies
“Security policies are applied to categories (a logical grouping of VMs), and not to the VMs themselves.
Therefore, it does not matter how many VMs are started up in a given category. Traffic associated with
the VMs in a category is secured without administrative intervention, at any scale.”
Port 80 is allowed to all VM’s that are in AppA_Web_Tier category.
Summary of security policy:
- All VMs in AppA_Client_Tier will have access to AppA_Web_Tier on port 80
- VMs in AppA_Web_Tier cannot talk to each other.
- VMs in AppA_Web_Tier have no outbound access
- Monitoring mode is only being applied so there won’t be any restrictions
Pinging from AppA_Client1 to the two web servers. Its successful because there is no blocking.
This is where Nutanix Flow shines:
- Dotted blue lines to AppA_Web_Tier shows web port 80 traffic. This is allowed.
- Dotted inbound yellow lines to AppA_Web_Tier shows pings from VMs in AppA_Client_Tier. Only web traffic port 80 is should be allowed. Policy is still in monitoring mode, so all traffic is allowed inbound.
- Dotted outbound yellow lines from AppA_Web_Tier are pings to VMs in AppA_Client_Tier. This has not been approved. AppA_Web_Tier should have no outbound access. Policy is still in monitoring mode, so all traffic is allowed outbound.
- All the other outbound dotted yellow traffic are connections to DNS, DHCP, and pings to internet. In a production environment we would evaluate what dependencies are needed. Wanted to demonstrate how Nutanix Flow will find other dependencies.
- Hovering over dotted lines gives additional detail information on source IP/port.
Step 5. Apply security policy.
- AppA_Client_Tier VM’s will only have port 80 access to AppA_Web_Tier VMs
- Allowed all outbound traffic to 10.21.193.255/32 subnet
Security Policy Results:
Can no longer ping VMs in AppA_Web_Client_tier. Notice that web traffic still works to AppA_Web_Client_tier.
VMs in AppA_Web_Client_tier cannot ping each other nor to google.com per policy. Can only ping VMs in AppA_Client_tier. Everything is working as expected since security policies have been applied.