NSX Distributed Firewall – Micro Segmentation

Welcome Back !!

In this blog, we will be discussing about NSX micro-segmentation and implement one of the rule for the same.

Below are the High level points which we will be discussing in this blog.

Traditional Security Challenges.
How NSX Micro segmentation overcomes these challenges.
Write/implement a rule for 3-Tier application and validate the same.

Traditional Security Challenges

Traditional security policies align with the environment (web/app/db) rather than with applications, which we call Macro Segmentation in NSX.
This type of segmentation does not prevent lateral communication between workloads in a tier, if one machine of /24 (just an example, can be any CIDR) subnet gets compromised, Attacker can move freely around the entire /24 broadcast domain and access valuable data, since does not get applied within single broadcast domain.
Typically, certain high-level segmentation security policies are built in a traditional datacenter, These policies prevent various types of workloads from communicating with other types of workloads. However, this high-level segmentation does not prevent lateral communication between workloads in a tier. When threats breach the perimeter, their lateral spread is hard to stop.
Shared services can traverse tier boundaries without being checked.

About Micro Segmentation

Micro-Segmentation minimizes the attack surface of an application by restricting the application to communicate only with the resources that it absolutely needs.

Enforces segments of control around sensitive data and applications.
Provides consistent policy across private and public clouds.
Can only allow Application wise traffic by using NSX micro segmentation & restrict everything else.
Micro-segmentation denies attackers the opportunity to pivot laterally within the internal network, even after the perimeter is breached. Hence prevents the lateral spread of threats across an environment.

==============================================================================================================

Use-case

We have 3 segments named Web, App, Db.
By default all the communication among them is allowed, like “Web can directly reach db and vice- versa” we will confirm the same via few Ping & other tests during Prechecks.
We will be implementing required rules, which allows specific traffic needed for application to work and reject all other traffic.
Post Checks – We will perform the same tests which we performed during prechecks

==============================================================================================================

Firewall Rules to be implemented

==============================================================================================================

==============================================================================================================

Prechecks

By default all the communication among them is allowed, like “Web can directly reach db and vice- versa”
All current communication is happening via default rule id – 2 : which is ANY source – ANY Destination – ANY service.

All the current communication is happening via Default rule, which we can be validated via traceflow tool, where we can see Web to App traffic is getting hit on rule-id number 2, which is Default rule in DFW, screenshots attached for reference.

Policy & rules creation

We have created dynamic groups to create firewall rules, however using direct IPs/VM is very much possible, but it is recommended to use dynamic grouping whenever possible, for easier management.