This blog is related to earlier blogs: https://datacenterdennis.wordpress.com/2018/10/11/designing-a-nsx-security-framework/
This blog may help you implement micro-segmentation by providing helpful vRNI queries. You can use these queries to identify VMs which should be placed into the different segments.
You can read here what vRealize Network Insight is and how it works. This blog will help you using vRNI by identifying application-entities or security groups which can be used to create NSX Firewall rules.
And that’s exact were this blog can help you.
vRNI has a “google”-like seach bar, which can help you identifying the correct data based on analyzed network flows.
Identify VMs by there Operating System
Lets start with a simple query, which identifies all VM’s which have a Microsoft Windows operation system.
list vm where Operating System like windows
And yes, I’m aware that this query does not involve any flow analyses. But with this simple, but effective, query I want to show how easy (readable/writeable) your can create your own queries.
When you type your query, vRNI will automatically autocomplete your query.
Lets continue with a more complex queries.
Identify Shared Services
When talking about micro-segmentation, you want your shared services to be available at all times. The firewall rules allowing these services should be placed on top of the firewall rulebase.
So first lets start with identifying all shared services using:
flow where Flow Type = 'Shared Service' group by Port Name
This produces a list of services with are accessed by the majority of the VMs. This usually contains services like: DNS, NTP, LDAP, Kerberos, Syslog, smtp, etc.
Now we have identified all services, we have to find the corresponding systems. Below an example of one of these services.
Identifying Domain Controllers (using flow analyses)
The output of this query should actually be a no-brainer, as domain controllers are well known systems in an environment. This query will show the power of utilizing vRNI and shows a list of domain controllers based on the captured network flows.
list (destination vm) of flow where Flow Type = 'Shared Service' and Port Name = 'ldap'
We can break this query into multiple parts: The query starts with:
list (destination vm) of flow
Which, straightforward, lists all destination VMs based on flow analyses. By appending multiple ‘filters’ we can narrow the results. In this case there 2 filters are applied: ‘Flow Type = ‘Shared Service” and ‘Port Name = ‘ldap”.
The first Flow-Type filter is a filter based on flow-types identified by vRNI and filters on flow type “Shared Service”, which contains flows to systems which are being accessed by the majority of the VM’s in the environment (which are called “shared services”).
Let’s start talking about segmentation.
A small recap: with segmentation I mean creating a controlled path of communication. Think about this as: Internet to DMZ, to App, to database servers. As my example is stil function related I will be using non-function related names, I will be using tiering: Tier-1 (DMZ), Tier-2 (app), Tier-3 (databases).
Identifying Tier-1 Security Group members
The Tier-1 security group has VM-members who should be accessed from the internet or the campus. It’s the equivalent of a DMZ, but this DMZ is logically isolated (not physically): which is called DMZ Anywhere.
First start with identifying all VM’s which are accessed FROM the internet: This means the internet is the SOURCE and the VM is the destination.
flows where Flow Type = 'internet' group by destination vm
This query identifies all VM’s who are accessed from the internet (not the VMs that access the internet). This outcome only tells you half of the story: The VM’s which are accessed from the campus are not identified by this query, so we need to work on those: In order to identify VM’s who are accessed from the campus, you need to know that vRNI does not differentiate between campus and physical servers. vRNI differentiate between east-west and north-south traffic. IP addresses identified in RFC1918 that are not identified by a VM are identified by vRNI as Datacenter Internal East-west (aka Physical). We are looking for the North-South connectivity for the campus (based on rfc1918).
So in order to retrieve a list of VMs accessed from the campus we focus on VM’s with traffic sourced filtered from “physical” or from a specific external (North-South) subnet. In order to fulfill this query you must be aware of the network topology.
list(Destination Vm) of flows where Flow Type = 'Source is Physical' and port = 443 and protocol = tcp
The query shows you the VM’s which are accessed from all physical sources through port TCP/443. By applying the protocol and port filter you narrow the the results down, which makes the output less complex to verify.
If you are aware of campus network IP subnet, you can use the following query to view the VM’s which are being access from the campus on HTTPS.
list(Destination Vm) of flows where Source Subnet Network = '10.0.0.0/16' and port = 443 and protocol = tcp
Tier-2 (and lower) Applications
To identify Tier-2 applications we first need to group our Tier-1 systems, which you have gathered in the previous paragraph.
Add all the identified VM’s to a NSX Security group: This group is being used in the during this phase/this query.
list(Destination Vm) of flow where Source Security Groups = 'Tier-1 groupname' and Destination Security Groups != 'Tier-1 groupname'
This query identifies all the VM’s (or flows) which are accessed by the “Tier-1” NSX Security Group, but filters the intra-tier communication.
This same query can be used to identify Tier-3, tier-4 and so on.
Identify VMs which are using a specific network port
In order to identify VM’s which are using a specific port (for example HTTPS (tcp/443)) use the following query:
list(Destination Vm) of flow where (Port = 443 and Protocol = tcp)
This query can be used to identify the VMs for filtering firewall rules.
vRNI is a powerfull tool and the Google like searchbar really can help you achieve micro-segmentation. The firewall recommendations that vRNI can produce for NSX (using the plan security feature) is a nice feature, but it produces a unmanageable list of firewall rules. My advice is to utilize the output of above queries to create NSX security groups and manually create the firewall rules.