When you implement Zero Trust micro-segmentation, all ingress/egress traffic hitting your virtual NIC cards will be compared against a configured list of firewall policies. The packet will be dropped if there is no rule matching the specific traffic flow. A default deny rule at the end ensures that all unrecognized traffic is denied at the vNIC itself. From a security perspective this is called whitelisting or a positive security model , whereby only things that are specifically allowed are accepted—everything else is rejected.
In a traditional perimeter-based setup, deploying a Zero Trust architecture requires an enormous amount of work and time. All packets have to go through the perimeter firewall, where the filtering will take place based on the configured firewall’s rules. The packet has to travel up to the perimeter firewall, only to get dropped by the deny rule.
A common setup for this is to group the servers into different zones based on their functions. All management servers are grouped under the management zone, whereas monitoring servers are grouped under a different monitoring zone. The demilitarized zone (DMZ) contains servers that require special protection. Zones can be quite large; you can even put all the Windows workstations in a particular zone and apply similar policies to them all. This is logical, as most workstations require similar access settings.
All servers within the same security zone trust each other. This is the default behavior, because servers in the same zone have the same accessibility requirements. In such a scenario, there is nothing that stops a compromised server inside a zone from reaching the open ports in other servers inside the same zone. For SMB file share access, the common approach is to allow access to ports 135/445 from Windows workstations. As mentioned, nothing stops a vulnerable workstation from scanning and infecting other workstations in this case.
You can see how trust, even among servers in the same zones, can lead to disaster. Zero Trust eliminates all these concerns, as there is no default allow policy. Every packet is scrutinized against a set of rules, and it is allowed to pass only if it matches a specific allow rule.
This offers a multitude of advantages. The first one is that all flows will be logged and if an attack happens, you can identify the flow. This makes auditing easier. The Zero Trust model is tailored to meet modern threats.
Host-Based Firewalls
Traditional IT systems configure a host-based firewall (see Figure 2-1). The host-based firewall runs inside the operating system. It augments the perimeter firewall security. Together, they act as a perfect deterrent to malicious threats.
Traditional model
In a common production setup like the one shown in Figure 2-1, the perimeter and the host-based firewall act in unison to achieve the desired result.
How Zero Trust Can Be Deployed
Any new feature that requires a complete revamp of the IT systems is challenging to implement. Given the mission-critical applications running on the production system, this would be a strenuous task.
In general, any Zero Trust security system should be able to blend into the current architecture effortlessly. There are many ways you can use the core idea of the Zero Trust policies. Reference architecture from Google details how they removed the use of VPN and integrated the infrastructure stack to a policy-based Zero Trust network. With this implementation, users are granted access based on the device they are in and their access permissions. All user traffic is authenticated, authorized, and encrypted.
This approach is a big deviation from the current enterprise architecture. As discussed, anything that has a large impact on the IT system as a whole is tricky to implement in an already running production setup. Beyondcorp can fulfill most of these modern-day challenges and can be used in a variety of ways. It even has a Google tag, as they have been using this model for many years. However, an end-to-end change to the security model is not what most organizations are seeking when looking to deploy Zero Trust networks.
This book talks about VMware’s way of implementing the Zero Trust model and how it can easily assimilate into your existing setup.
VMware deployment is straightforward and has a decade-long record of working with enterprise customers. VMware is in a great position to develop a model where you can have a product that is easy to implement and meets all the standard requirements.
Apart from the Google and VMware implementations of the Zero Trust model, there are multiple ways to implement it. This book discusses VMware’s way of doing it and how to deploy it in an enterprise architecture in which a VMware-based stack is already running. Along with that, you can see how automating security policies and integrating them with third-party providers can give you tighter security. I will discuss integrating third-party products later in this book.
Prerequisites of Zero Trust
This section covers the prerequisites of Zero Trust.
Scalable Infrastructure
An infrastructure based on virtualization is a proven and mature design approach used in enterprise IT. There is no debate going on as to whether to virtualize or not to virtualize. Zero Trust requires an infrastructure built on a virtual layer. This doesn’t mean that you can never achieve the target using physical servers. There are models that can do that, but virtualization gives you a lot of advantages. You can add a rule based on a larger subset, and filter based on resource groups, virtual machines names, and cluster names. In a physical setup, these choices are not available.
Another advantage of a virtual layer is the limitless opportunity for automation. Without automation, given the pace at which application delivery is heading, you won’t be able to survive or manage a satisfactory IT infrastructure with up-to-date security settings. We are in the age of “Infrastructure as Code” and to make all these possible in the least disruptive way possible, you need a well-matured virtual layer.
Application Dependency Mapping
To create infallible security rules and policies, you need to know the dependencies and application flows. This is a must when you’re designing an IT infrastructure, especially when using Zero Trust networks. You are in the business of designing a security model where only the trusted flows are allowed. Security architects should know more about the application and their behavior in a broad sense. For example, does Application A need access or connectivity (even ICMP access) to Application B? Does this connectivity occur anywhere in the application flow if they are in different VLANs? If they need to be in the same VLAN, do they need L2 connectivity between them?
These questions have to be asked during the design phase. Only when all these questions are properly answered should you proceed with the later steps. Remember that there is a default deny at the bottom of the security rules. If you are not careful about this during the design phase, you might end up in trouble later.
Ports and Services
The straightforward way is to use third-party tools like Tuffin is to understand the different connectivity patterns. Ports used for ingress/egress traffic for the application have to be recorded. Other information—like management traffic and traffic to log servers and monitoring servers—needs to be taken into account when considering the flows.
Current Perimeter Firewall Policies
You can’t entirely exclude the perimeter firewall. In other words, you don’t break down the castle wall and abandon the gates once you determine that the door locks are strong enough. You have to configure the required Northbound security rules in the perimeter firewall, where the necessary initial filtering takes place, before the traffic enters the DC.
There are multiple options available, such as using a virtual firewall VM, where the VM acts like the perimeter firewall and does all the filtering. This can be useful according to the requirements and design approach. If traffic flow is high, nothing can beat the power of a hardware appliance.
Monitoring Logs
This section covers why you need log servers and how to monitor logs.
Why do you need a log server? Logs are critical components of any security infrastructure. You need logs for various purposes, like auditing and monitoring. Traditional methods, like sending the logs to the syslog or FTP server, have their shortcomings. With all the advancements in analytics, you are not looking just to store the logs; you need to analyze and get meaningful information from the data. This requires a modern log server setup. You can use any of the open-source log server systems, like the ELK stack, or you can go with options like VMware Log Insight.
Log server stacks based on the latest models will make your life a lot easier, with intelligent API queries where you can look for specific details and information.
Tools for Log Analysis
This book discusses the VMware log analysis offering called VMware Log Insight. Log Insight is a very useful tool when it comes to analyzing and creating reports on data trends. You can promptly find out a lot of information from the dashboard. You can even filter the logs specific to one ESXi server and logs related to the packets that hit a specific distributed firewall rule. When you use it with the right queries, it turns out to be a really powerful tool that will make your life easier. Chapter 7 is dedicated to log analysis and discusses this topic in more detail.
Auditing Purpose and Log Backup
The security auditor can audit security in any organization that has a healthy security practice. Critical logs need to be analyzed and stored for future reference and use. This data will be stored on a tape drive for long-term retention. A log server can make auditing tasks a lot easier. It provides an analytics dashboard on certain incidents and reports on the overall health of the system. This makes the job of the security administrator a lot easier in terms of generating reports.
Adding a New Application to an Existing Infrastructure
The process should be simple, straightforward, and automated. A design that enforces a lot of manual restrictions and processes in order to add a new resource isn’t scalable. Given the scale at which virtual machines are being created, this would soon become a very cumbersome process if you didn’t have any groupings or tags. VMware helps with the usage of tags and security groups. Virtual machines can be grouped under a wide range of options, and this can happen automatically if you create a virtual machine with a specific tag. The security rules associated with that tag are then applied to the vNIC.
You can learn about VMware’s way of doing this, as well as the best practices, in more detail. As a rule of thumb, any Zero Trust system should follow any features that will make the system easier to deploy and manage.
Geomigration for the virtual machine workload is achievable in an active-active data center setup. In such cases, there can be an L2 extension across the DC with a dark fiber cable. This setup will enable seamless migration of the workload between data centers along with a GSLB (Global Server Load Balancer).
In such a design, when the VM is migrated to the other DCs (such as from DC-A to DC-B), the security rules should also move. If any of these changes require manual attention, you will be looking at a huge mess in the future. As the migration itself can be automated according to the load, if your rules are not being migrated across, this can lead to security issues in the future. Fortunately, VMware has features like distributed firewall rules, that do this. As the security rules are applied to the virtual machine’s NIC, it moves along with the virtual machines, irrespective of the location or specific computers.
VMware NSX
Software-defined networking (SDN) is now becoming a standard. SDN enables better infrastructure automation and configuring networks through API interfaces. Given the movement toward immutable infrastructure, automation capabilities are a must for all infrastructure components. SDN enables you to virtualize the network layer by separating the control plane from the data plane.
Traditional network switch design combines the control plane and the data plane into the hardware switch and loads a proprietary OS like CISCO IOS or JUNIPER Junos to configure the networking stack. This worked fine for years. As the need for virtualizing the network stack arose, this model wouldn’t scale, leading to the SDN movement.
The VMware SDN stack provides end-to-end network virtualization by virtualizing infrastructure components like the firewall, router, load balancer, and VPNs into virtual functions. As mentioned, this is a prerequisite to creating an immutable infrastructure. To automate the application stack creation, you have to create networks, load balancers, and security rules. Virtualizing it makes it easier to automate these layers as well.
VMware provides a REST API interface to configure the network functions. This makes it easier to integrate the features into an existing automation tool. The book discusses these points more in later chapters.
Overlay: VXLAN
Overlay packet flow
VXLAN is used as an overlay network in VMware NSX. VXLAN is a tunneling protocol. Encapsulation of network packets and adding VXLAN headers happens at the VTEP port. The encapsulated packet travels through the network underlay as a normal IP packet. After reaching the destination, the packet will be decapsulated and sent to the right vNIC.
VXLAN Headers
VXLAN header
Communication over a VXLAN tunnel
In Figure 2-4, VNI 1000, VNI 2000, and VNI 3000 are the VXLAN networks attached to the virtual machines. VM packets, while coming out of the vNIC, will be encapsulated into these VNI IDs. The packet from the virtual machine will be the payload for the Compute-01 NIC. Once it reaches the Compute-02 NIC, decapsulation will happen at the VTEP port and the packet will be forwarded to the vNIC with the right VXLAN ID. If the flow is from VNI 1000 to VNI 2000, routing will happen at the compute where the packet originates. DLR will do the routing of the packet inside the computer hosts.
Distributed Router
DLR-based routing inside ESXi
VMware NSX Distributed Firewall
DFW internal view
The NSX Manager is the central management console for all the VMware NSX SDN-related configurations, including micro-segmentation. Even though other VMware toolsets can aid in creating the ruleset, the configuration should be done through the NSX Manager. The NSX Manager has to be integrated with VMware vSphere. After the integration, the NSX Manager can be accessed via a separate tab in the VMware vSphere interface.
Micro-segmentation rules can be configured from the VMware NSX Network and Security tab. VMware uses the RabbitMQ messaging bus to push the firewall rules to other computer nodes that host the application VM. During the ESXi host preparation, the DFW kernel module will be installed on all computer hosts in the cluster. The NSX Manager will send the policy actions to the RabbitMQ server process, which in turn pushes all the policies to the RB MQ client, which in this case is the vsfwd process. The vsfwd process receives the message and sends it to vSIP, which is a VIB that’s included in the host preparation. The VMware Internetworking Service Insertion Platform’s (VSIP) function is to push the policy rules to all DFW filters in the virtual machines.
There is a possibility to integrate a third-party firewall into the VMware’s IO chain. The IO chains are used to redirect the packet according to the intended configuration. Third-party IDS/IPS FW can easily be integrated into the VMware NSX suite using this method.
DFW Packet Flow
A distributed firewall instance per vNIC will have two tables—a rule table and a flow table. The rule table contains the firewall policies applied to that vNIC and the flow table (the connection tracker) contains the cached entries of the permitted flows. The firewall rule will be applied from top to bottom and the practice is to use a default deny rule at the bottom to secure the VM from unwanted traffic.
Rule Table
|
You can allow the external users to access Webserver-1 and Webserver-2’s HTTPS port. When the traffic starts flowing through the vNIC, it has to go through the IO chains. As there are no flow entries in the cache for the flow, DFW has to go through the ruleset and determine that Rule 1 and Rule 2 allow HTTPS traffic from an external user. This then updates the flow table, and further flows can be permitted through the cache.
As you can see, the Zero Trust approach includes a deny rule at the bottom by default, and it’s not explicitly mentioned in the ruleset. You don’t need communication flow between Webserver-1 and Webserver-2; the default deny rule blocks this traffic.
This feature can contain the spread of any attacker trying to attack a webserver. If one webserver is compromised, you can be sure that the attacker can access only the valid ports in this instance. This effectively contains the spread of many modern virus attacks, like Notpetya for example.
Summary
This chapter discussed the VMware NSX features and the internal details of the VMware distributed firewall. The next chapters go in-depth into implementing these security practices in a real-time infrastructure. You will learn more about adding distributed firewall rules and security groups.