How to implement network microsegmentation using Tungsten Fabric application security policies

Many enterprises concentrate on securing external traffic that enters their networks, but analysts estimate that 70-80% of traffic flows east-west on a flat network. At many organizations, users, applications, and devices practically have free range to communicate with each other, making it far too easy for malicious actors who have infiltrated a network to move laterally to sensitive data and systems. 

In the video below, Mirantis network engineer Wojciech Nawrot explains microsegmentation, a network security technique for data centers, cloud computing, and virtualization that reduces the attack surface and limits exposure of sensitive data and assets from attacks on east-west traffic. Watch his demo to learn from one of Mirantis’ top networking experts how to use open source Tungsten Fabric software-defined networking (SDN) to create and enforce microsegmentation policies across a network.

Note: Below is a transcript of Wojciech’s presentation, edited for clarity and length. It includes a helpful customization script you may want to use.

What is network microsegmentation, and why is it needed?

Traditionally, organizations have protected their network perimeter by screening north-south traffic on the network edge, but perimeter-focused defenses have no visibility into east-west traffic, which can be used by attackers to move laterally across workloads. 

This is where microsegmentation comes in. Microsegmentation is an approach to security that involves dividing a network into security zones and applying security controls to each security zone based on its requirements. The security zones isolate workloads, securing them individually with custom workload-specific policies. 

Image credit: Palo Alto Networks

Mirantis OpenStack for Kubernetes includes a Tungsten Fabric networking backend that provides a tag-based application security policy feature, which can be used to protect the application itself by screening clients' north-south traffic and to secure east-west communication between application tiers, deployment environments of the application instance, or the geographical location where the application is deployed. 

What is an application security policy in Tungsten Fabric, and what are its characteristics?

There are three different firewall features supported by Tungsten Fabric, which are security groups, network policy, and application policy. The major difference between them is that security groups and network policies apply to VM ports and virtual networks respectively, whereas the application policy applies to applications. The application policy segregates the east-west traffic based on dimensions such as application, tier, deployment, or site. 

Even though it's still possible to leverage the virtual network names or addresses to identify endpoints, one builds IP-less firewall policies using tags. It prevents the proliferation of IP-based firewall rules, which are difficult to manage and understand when troubleshooting. Tags are key value pairs associated with different entities in the deployment. They're basically used to identify objects and workloads. 

An application policy can be ported between different application deployments. For instance, if a development environment is deployed first, and staging and production environments are added later, no environment-specific rule updates are required for the existing firewall policy. The only thing which needs to be done is the assignment of appropriate tags to the ports of newly added VMs. 

It's not necessary to create brand new virtual networks and subnets every time a new application deployment is added. The VMs of different application instances such as development and staging may share the same virtual network segments, but the cross-deployment traffic won't flow between application layers if a deployment match condition is used as a part of a firewall rule. 

Tags can be generally assigned to different objects, but in our lab exercise we'll only tag VM ports using global tags. It's worth mentioning that both tags and application policies can be global or project-specific. 

As opposed to a Tungsten Fabric network policy, a Tungsten Fabric application policy does not interconnect virtual networks. If the workloads contained in a firewall rule belong to different virtual networks, a logical router or network policy must be added to enable connectivity between endpoints. No "deny all" rule has to be added at the end of the firewall policy as it’s contained in each firewall policy implicitly. 

Last but not least, an application policy cannot be configured from OpenStack, as it's a Tungsten Fabric proprietary feature, not supported by the Neutron API. That's why all application policy components in the lab will be set up through the Tungsten Fabric Web UI. 

What tags are used in Tungsten Fabric application security policies?

Tags are a key component for building firewall rules in an application policy. As already stated, tags are key value pairs which can be assigned to different objects, such as projects, networks, vRouters, or VM interfaces. In our lab exercise, we'll tag the VM ports by using the first three tag types shown in the table below.

The application tag will be leveraged to identify all the application components. The tier tag will group instances of the same type within the application, whereas the deployment tag will facilitate isolation of the application deployments, such as development and staging. 

Microsegmentation demo: Use Tungsten Fabric application policies to secure a simple three-tier application

In this exercise, I will show you how to do the following:

• Secure communication between different layers of a typical three-tier application

• Isolate two different application deployments sharing the same network segments

• Protect the application itself by securing its web server exposed to clients 

Now, let me present the network setup used in the lab. We'll make use of seven pre-configured CirrOS VMs: three for the development application deployment, three for the staging environment, and one for the client. There are three OpenStack networks: access, frontend, and a backend shared by development and staging app deployments. For CirrOS VMs to work with two network interfaces, we injected the following customization script:

#!/bin/sh
    sudo echo '' >  /etc/network/interfaces
    sudo echo 'auto eth0' >> /etc/network/interfaces
    sudo echo 'iface eth0 inet dhcp'  >> /etc/network/interfaces
    sudo echo 'auto eth1' >> /etc/network/interfaces
    sudo echo 'iface eth1 inet dhcp'  >> /etc/network/interfaces
    sudo /etc/init.d/S40network restart

Here is a visualization of all the components of the lab along with relevant traffic flows. As shown in the diagram, our three-tier Mirantis app comprises of development and staging deployments. The client VM can access the web server of the development and staging environments with ICMP, HTTP, and HTTPS only. Since our Mirantis app is a dummy, we'll use some dummy ports open by default on CirrOS VMs, which form respective application tiers. The web server will communicate with the application server using SSH, while the application server will use ICMP to access the database server. 

Network Setup for Tungsten Fabric Microsegmentation Demo

Keep in mind that the cross-deployment traffic between application layers is not allowed. For instance, the web server from the staging environment cannot SSH into the application server in the development environment. Similarly, the application server in the development environment cannot ping the database server in staging. Even though there are quite a few endpoints and traffic flows in the diagram, we'll configure just a couple of IP-less rules in the firewall policy, which will protect the application itself and segregate east-west network traffic between the application tiers and the deployments. 

By default, the OpenStack VMs start with port security enabled and the default security group assigned. In our exercise, we'll disable port security for all ports and remove security groups to make sure that all the interactions are controlled by the Tungsten Fabric application policy. Before we get started with application policy configuration in the lab, let me highlight the configuration steps to be performed. Keep in mind that all configuration actions will be conducted from the Tungsten Fabric web UI presuming that all the VMs with their ports and the respective OpenStack networks already exist. 

What are the steps to configure a Tungsten Fabric application security policy?

From a high level, the steps required to configure an application policy in Tungsten Fabric include the following:

1. Create Tags — Configure the deployment, tier and application tags, which are basically key value pairs.

2. Assign tags to VMIs — Assign the tags to VM ports (Neutron ports). This is probably the most time-consuming task. 

3. Define Service Groups — A service group is nothing more than a collection of protocols and ports for a specific network service, e.g., web, SSH, ICMP, etc.

4. Create Firewall Policies and Firewall Rules — Firewall policies are a collection of firewall rules referencing the service groups and the previously configured tags. Create them using the tier and deployment tags

5. Create Application Policy Set — An application policy set associates recently configured firewall policies with the respective application tag. Keep in mind that the application policy won't be active until the application tag is set. 

Note: The demo lab section of the video begins at 10:04.

Step 1: Create Tags

The application tag will be used to identify components of the Mirantis app. The deployment tag will be leveraged to isolate different app deployments, development and staging. And finally, the tier tag, which will be used to group instances of the same type. We've got the web server, the application server and the DB server. Once complete, we can get started with assigning tags to VM ports. 

Create a Tag in Tungsten Fabric

Step 2: Assign Tags to VMIs

Let's move on to the port section of networking. All VM ports will be assigned application, deployment and tier tags except the client VM, which is not a part of the application. We'll make use of our lab diagram to identify respective VM ports in the port list and to select appropriate tag values.

Edit Tags in Tungsten Fabric

Step 3: Define Service Groups

After tags have been assigned, we can proceed with service groups, which will be referenced later on in the firewall rules. Go to Security | Global Policies | Service Groups to configure services running within our application. For our dummy Mirantis app, we'll define web, SSH and ICMP services only as shown in the diagram.

Create a Service Group in Tungsten Fabric

Step 4: Create Firewall Policies and Firewall Rules

Once complete, we can move on to the firewall policy configuration. We go to firewall policies to proceed with configuration of two different IP-less firewall policies: one for client access and the other one for communication between application layers. The client access policy will comprise of two permit rules, allowing web and ICMP traffic between the virtual network the client VM lives in and the web server tier. The internal access policy will contain another two permit rules in the rule set: one for the SSH communication between the web server tier and the application tier, and the second for ICMP traffic between application and database tiers. 

In addition to endpoints, services, and direction, the firewall rules of the internal access policy will be configured with a deployment tag acting as a match tag. This prevents the traffic permitted by policy rules from flowing between different tiers of development and staging app environments. Please note that there won't be any deny rules in the firewall policy rule sets, because they are not required. As per the Tungsten Fabric security principle, everything which is not explicitly allowed, is denied.

Create a Firewall Policy in Tungsten Fabric

Keep in mind that the firewall policies we've just configured don't need to be modified every time a new application deployment is added. The only thing to do is to tag network ports of recently added VMs. Also note that the multi-dimensional traffic segregation is achieved with a couple of basic tag-based firewall rules, instead of an extended rule set comprising IP addresses of endpoints. 

Step 5: Create Application Policy Set

In the final step, we'll associate the firewall policies we've created with the application. Be aware that the application policy for an application won't be active until an appropriate application tag is selected. If for any reason an application policy or an application needs to be disabled, it suffices to strip the application tag from the application policy configuration instead of removing the application policy itself. 

Create an Application Policy Set in Tungsten Fabric

Which tests can be used to check a Tungsten Fabric application security policy?

To make sure that the application policy works, we'll execute a number of connectivity tests from the client VM towards the web server and between different application tiers, including cross-deployment connection attempts. Furthermore, we'll inspect actions taken by the firewall policy for both allowed and denied traffic on the compute nodes by using the Tungsten Fabric flow command. Finally, we'll take a look at the security dashboard and the traffic groups for some stats and to visualize interaction between different application components. 

Let's get started. In the first step, we'll check HTTPS connectivity between the client VM and the web server in both development and staging environments. The web server in the development environment has responded. The web server in the staging environment has responded as well. 

Let's check the flow table. As we can see, for the traffic matching specific flows, the action is all over Forward. 

Let's now take a look if the client VM can ping the web server in both development and staging environments. The flow table on the node where the client VM is living shows the matched ICMP traffic is forwarded. 

Finally, let's figure out what happens if we try to SSH the web server from the client VM. As we can see, the SSH traffic is dropped by the firewall policy. If we disassociate the application tag from the application policy set, the application policy will not control the application traffic anymore, and we'll be able to SSH the web server from the client VM. 

Now let's check if the application policy secures the east-west traffic between different application tiers within a deployment and between different deployments. As shown in the diagram, the web server tier and the application tier communicate using SSH. Let's try to SSH the development and staging application VMs from the development web server.

The SSH communication within the development deployment works, but the cross-deployment SSH traffic is dropped. It can be observed by executing the flow -l command. Even though all the application and web server VMs share the same network segment, SSH traffic won't flow between the development web server and the staging application server, because the deployment tag has been used as a match tag inside the firewall policy. As soon as the application policy is disabled, the cross-deployment SSH traffic starts to flow.

In the last test, we will verify if the application and the database tiers can talk with each other using ping, as shown in the diagram. We'll also prove that ICMP works only within a deployment, and no other traffic than ICMP is permitted between tiers. 

We'll go to the development application server and ping the development DB server and staging DB server accordingly. The development DB server responds. The staging DB server does not respond because of firewall policy, which blocks cross deployment traffic. SSH is not allowed at all between application and DB tiers within the deployment and between deployments, because of the implicit "deny all" rule. 

Tungsten Fabric Traffic Groups Visualization

All the interactions between different application components can be easily visualized using the traffic group chart. The outer circle represents the deployment, whereas the inner circle shows different application tiers. The blue curves symbolize inter-tier traffic, which is allowed by the application policy, while the orange curves depict the traffic denied implicitly. An example of permitted traffic is the SSH interaction between the web server and the app server in both staging and development environments. The highlighted orange curve shows the denied attempt of cross-deployment ICMP communication between the application and the database tiers. 

Traffic Groups Chart in Tungsten Fabric

Tungsten Fabric Security Dashboard

Last but not least, in the security dashboard section, among other things, we can observe the top applications, top tiers, top sites, top deployments, top virtual networks, and top virtual machine interfaces (VMIs) with deny in terms of sent and received traffic.

Security Dashboard in Tungsten Fabric

We hope this information was useful for you! 

Contact us if there are other technical topics you’d like us to present or if you want to learn about OpenStack engineering and architecture services from Mirantis.