In NSX-T by using the Distributed Firewall (DFW) you can microsegment your network and enforce tight security on every VM-port.
This leads to a new security paradigm called
Zero Touch Network Access (ZTNA)
ZTNA means to implement the basic rule of:
Any communication which is not explicitly allowed is implicitly forbidden
Typically this is implemented by changing the last DFW rule (Layer 3 Default Rule) to DENY
However you can only do this last step if you first have explicitly allowed all necessary traffic for all applications and services.
Installing ZTNA in a bigger enterprise with a whole bunch of newer and older applications, a mixture of VMs and container applications, and a quite dynamic environment with constant changes is a work of Sisyphus.
The security group will always be 3 steps behind when separate development and implementation groups are installing new or modernizing existing applications.
Furthermore you often need to restrict your ZTNA to critical and important applications and leave the rest with a more generous security concept.
Thus to make it short: ZTNA is a strategy but in reality it is often only partly implemented.
Now let us look into basic concept of policy and rule in a DFW including important default values.
A policy can be applied to DFW, which means any port or you can specify one or more groups. (Selection is done by using the ports belonging to that group)
Note: In the latter case you cannot use the „Applied To“ field in the rules belonging to that policy.
Also per default policies are applied stateful, where the return traffic is automatically allowed on a per flow base.
A rule specifies Source,Destination, Service (L4 protcol and port), L7 context profile and can be applied either to DFW or to various groups if the policy has DFW in it´s „Applied To“ Field.
Default for Rules is that they are evaluated IN-OUT which means it will be checked indendently for either incoming or outgoing flows.
For our example we follow a sequence of DNS request and response between a VM belonging to an application and a DNS-server.
The DNS request will trigger a rule lookup for the quintuple of Layer 3 and Layer 4 Header information.
As we are matching the above shown application rule with an action of Allow we will forward the packet and also enter the Quintuple into the flow table so for subsequent packets we do not need to go through the rule table again.
When the packet reaches the ingress port of the DNS server the same lookup of rules will be done and the same rule as bevor will allow the traffic Incoming to the DNS server
Automatically the reverse packet flow will be allowed as we did not change the default of STATEFUL evaluation. The reverse quintuple will also be noted in the flowtable.
Typically if we have considered all allowed traffic for that application, we have a Zero Trust rule for VMs belonging to that application, so that no other communication can take place.
In that example when trying to connect to a Fake DNS server with a different destination address our Zero Trust per APP rule will block that access.
But is this enough, so that we really have considered all possible traffic and only allowed the correct one thus blocking any additional traffic coming from that application ?
Unfortunately NOT
As long as we do not have a complete ZTNA implementation with the last rule of any/any/any set to DENY our DFW rules in many cases can still be circumvented.
For the basic mechanism and information on that topic there is a quite good blog on
https://insinuator.net/2020/03/vmware-nsx-t-distributed-firewall-can-be-bypassed-by-default/
which I recommend to study.
Here in our blog we will graphically looking in detail into such an example:
Assuming that we are using all the default segment profiles and we consider an Intruder being able to change the IP address of our application.
The default segment profile have SPOOFGUARD disabled, so fake or changed IP addresses are neither detected nor blocked.
Now all our application specific rules do not match anymore, leaving the L3 Default Rule as a last Catch-all. And as long as we do not have a complete ZTNA security implementation this rule states ALLOW
Now the application by using a spoofed address can succesfully access a fake DNS server.
So what can we do to protect our VMs from such intrusion ?
We can change our profiles per segment or even per port.
And there are 2 profiles which are important and work hand in hand:
- IP Discovery Profile
Specifies the methods to discover IP addresses bound to a VM
- Spoofguard Profile
Enables or disables the checking of source IP address against discovered IP addresses
If correctly enabled by using methods like ARP snooping or others given by the IP Discovery Profile we check the Source address of the outgoing packet against our discovered IP bindings and if it does not match we will block that packet.
In that we we prevent IP Source Adress Spoofing independent of our DFW settings.
But what can you do if IP address discovery does not work for you, out of different possible reasons.
You can set up an anti-spoofing policy and rule in front of any application specific rule stating that any outgoing packet not having the correct source IP address specified in the group will be DENIED.
It is important to specifiy this rule on the correct port belonging to the app using the rule based Applied To field and to evaluate that rule OUT only.
If you like you can also specify the policy to be STATELESS, as there will be no reverse or return flow in case of DENY.
Resume:
This concludes my blog regarding DFW,ZTNA and Spoofguard. I hope it can help in a better understanding how to use DFW and Spoofguard to correctly secure your network, when full ZTNA cannot be reached.
Trackbacks/Pingbacks