Distributed Firewalls
What is a feature of distributed firewalls? When considering distributed firewalls, let us start with the basics. Virtual computing changes the compute operational landscape by introducing a software abstraction layer that leads to open networking. All physical compute components (NICs, CPU, etc.) get bundled into software and managed as software objects, not as individual physical components. Virtualization offers many benefits in agility and automation, but its full capabilities are hindered by statically provisioning network functions. Server virtualization allows administrators to spin up a VM in seconds (Containers – 250ms), yet it potentially takes weeks to provision the physical network to support the new VM. The compute and network worlds lack any symmetry.
However, their combined service integration is vital to support the application stack. Network virtualization creates a similar abstraction layer to what we see in the computing world. It keeps the network in line with computing in terms of agility and automation. Network services, including Layer 2 switching, Layer 3 routing, load balancing, and firewalling, are now available in the software enabling distributed firewalls. Moving physical to software changes the operational landscape of networking to match that of computing. Both compute, and network is now decoupled from the physical hardware, meaning they can be provisioned simultaneously. These architectural changes form the basis for the zero trust networking design.
For additional pre-information, you may find the following helpful:
What is a feature of distributed firewalls? |
|
- A key point: Back to basics with the Firewall
Firewalls are differentiated in different ways: from the network size they are designed to work to how they protect critical assets. Firewalls can range from simple packet filters to stateful packet filters to application proxies. The most typical concept of a firewall is a dedicated system or appliance that sits in the network and segments an “internal” network from the “external” Internet. However, the Internet and external perimeters are not as distinguishable as they were in the past. Most home or SOHO networks use an appliance-based device for broadband connectivity that includes a built-in firewall.
The Virtual Switch
Initially, we abstracted network services with the vSwitch installed on the hypervisor. It was fundamental and could only do simple network services. There was no load balancing or firewalling. We introduce many more network services into the software with recent network virtualization techniques. One essential service enabled by network virtualization is distributed firewalls.
The distributed model offers a distributed data plane with central programmability. Rules get applied via a central entity, so there is no need to configure the vNIC individually. The vNIC may have specific rule sets, but all the programming is done centrally.
VM mobility is minimal if you can’t move the network state with it. Distributing the firewalling function allows the firewall state and stateful inspection firewall ( connections, rule tables, etc.) to move with the VM. Firewalls are now equally mobile. Something 10 years ago I thought I would never see. As a side note, docker containers do not move as VMs do. They usually get restarted very quickly with a new IP address.
What is a feature of distributed firewalls?
Distributed firewalls – Spreading across the hypervisor.
When considering what a feature of distributed firewalls is, let’s first discuss that the traditional security paradigms are based on a centrally focused design; a centrally positioned firewall device, usually placed on a DMZ, intercepts traffic. It consists of a firewall physically connected to the core, and traffic gets routed from access to the core with manual configuration.
There is no agility. We had a lot of firewalls deployed on a per-application basis, but nothing targeted east-to-west traffic. As you are probably aware, the advent of server virtualization meant there was more east-to-west than north-to-south. Traffic is staying in the data center, so we need an optimal design to inspect it thoroughly.
Protecting the application is critical, but the solution should also support automation and agility. Physical firewalls lack any agility. They can’t be moved. If a VM moves from one location to another, the state in the original firewall does not move with the VM. They were resulting in traffic tromboning for egress traffic. There are hacks to get around this, but they complicate network operations. Stretched HA firewall designs across two data centers are not recommended, as a DCI failure will break both data centers. Efficient ingress traffic should be fixed with proper application architecture and DNS-based load balancing.
- A world of multi-tenancy
We are in multi-tenancy, and physical devices are not ideal for multi-tenant environments. Most physical firewalls offer multiple contexts, but the code is still shared. To properly support multi-tenant cloud environments, we need devices built initially in mind to support multi-tenant environments. Physical devices were never built to support cloud environments. They evolved to do this with VRFs and contexts.
We then moved on to firewall appliances in VM format, known as virtual firewalls. They offer slightly better agility but still suffer traffic tromboning and a potential network chokepoint. Examples of VM-based firewalls include vShield App, vASA, and vSRX Gateway. There is only so much you can push into software. Generally, you can get up to 5 Gbps with a reduced feature set. I believe Paolo Alto can push up to 10 Gbps. Check the feature parity between the VM and the corresponding physical device.
Network Security Components
Network evolution now offers distributed network services among hypervisors. The firewalling function takes a different construct and is embedded in the hypervisor kernel network stack as a service. All hypervisors become one big firewall in software. There is no more extended single device to manage, and we have a new firewall-as-a-service landscape. Distributing firewalling offers a very scalable model. Firewall capacity is expanded along with the addition of different hypervisors offering a scale-out distributed kernel data plane.
So what is a feature of distributed firewalls? Well, scale comes to mind. Essentially, distributed firewalls performance scales horizontally as more hosts are added. Distributed firewalling is similar to connecting every VM directly to a separate firewall port. An ideal situation is yet impossible in the physical world. Now that the VM has a direct firewall port, there are no traffic tromboning or network choke points. All VM ingress and egress traffic gets inspected statefully at the source and destination, not at a central point in the network. This brings a lot of benefits, especially with the security classification.
Distributed Firewalls: Decoupled from IP addressing
In the traditional world, security classification was based on IP address and port number. For example, we would create a rule that source IP address X can speak to destination IP address Y on port 80. We used IP as a security mechanism because the host did not have a direct port mapping to the firewall. For the firewall to depict where traffic is sourced and destined, it had to use an IP address as the identifier.
This is no longer the case with distributed firewalls. Security rules are entirely decoupled from IP addresses. A direct port mapping from the VM to the kernel-based firewall permits the classification of traffic based on any arbitrary type of metadata; objects, tagging, OS type, or even detection of a specific type of virus/malware.
Many companies offer distributed firewalling; VMware with NSX is one of them, and it has released a VMware NSX trial allowing you to test for yourself. NSX offers Layer 2 to Layer 4 stateful services using a distributed firewall running in the ESXi hypervisor kernel. First, the distributed firewall is installed in the kernel by deploying the kernel VIB – VMware Internetwork Service. Then, NSX Manager installs the package via ESX Agency Manager (EAM).
Then, the VIB gets initiated, and the vsfwd daemon is automatically started in the user space of the hypervisor.
Each vNIC is associated with the distributed firewall. As mentioned, we have a one-to-one port mapping between vNIC and firewalls. Rules are applied to VM; the enforcement point is the VM virtual NIC – vNIC. The NSX manager sends rules to the vsfwd user world process over the Advanced Message Queuing Protocol message bus.
- DMVPN - May 20, 2023
- Computer Networking - April 7, 2023
- eBOOK – SASE Capabilities - April 6, 2023