The security detection and protection of east-west traffic occupies an important position in the
cloud security system. How to effectively protect east-west traffic has become an important content of cloud security research. From the network level, this article summarizes in detail various traffic pulling methods when protecting east-west traffic, and compares and analyzes some mainstream solutions in the industry.
What is east-west traffic
Usually in a data center, we divide its network traffic into two types, one is the traffic between external users and internal servers in the data center, such traffic is called north-south traffic or vertical traffic; the other is data The flow of interaction between servers in the center is also called east-west flow or horizontal flow.
In the early days, 80% of the traffic in the data center was north-south traffic, but now 80% is east-west traffic. Data center network traffic has changed from "north-south"-based to "east-west" mainly. With the advent of
cloud computing, more and more services have had a huge impact on the data center traffic model, such as search and parallel computing. For other services, a large number of servers are required to form a cluster system to complete the work together, which causes the traffic between servers to become very large.
Along with this change in traffic characteristics caused by services, the network architecture of the data center has also changed from a typical three-layer tree structure to a large two-layer structure such as CLOS or Spine-Leaf. This large two-tier concept is no longer even limited to the inside of a data center, but also logically two-tier interconnection between data centers.
The east-west traffic we talked about in this article refers more to the traffic within the cloud computing system, that is, the traffic between virtual machines in the cloud. This traffic includes traffic between virtual machines in the same tenant and the same subnet; traffic between the same tenant and different subnets; of course, it may also be communication traffic between different tenants. The cloud computing system here mainly refers to the private cloud. For the public cloud, the principle is the same.
Why do we need east-west traffic traction
The traction of east-west traffic mentioned here is mainly to solve the problem of
cloud security. As described above, in cloud computing data centers, 80% of the traffic is east-west traffic, while traditional security solutions are usually based on the security protection of fixed physical boundaries, so they correspond to cloud computing data centers, that is, only The problem of security protection for north-south traffic has been solved, and the security protection for east-west traffic is basically powerless.
This inability can be summarized in two aspects: on the one hand, it is "invisible", such as the traffic between two virtual machines in the same host; on the other hand, it is "unrecognized", such as encapsulating tunnel headers such as vxlan Data traffic. For details, please refer to the article "SDN/NFV-based cloud security practices".
Faced with this problem, there are currently two main solutions for manufacturers. One is to "put in" the security device, which is to virtualize the traditional "security device box" and deploy it inside the cloud computing system, so that it can " Touch” and be able to carry out corresponding security protection; another way of thinking is to “lead out” the traffic, and pull the traffic that needs to be detected and protected from the cloud computing system, and then after the corresponding security equipment is “cleaned” Inject traffic back into the business system.
No matter which of the above schemes is used for east-west traffic security protection, it is inevitable that business traffic needs to be hauled and dispatched so that the corresponding traffic can pass through the corresponding protection equipment. In this case, the security protection problem of east-west traffic will be transformed from the inability of security equipment to "see" and "recognize" the traffic to how to dynamically and efficiently haul and dispatch east-west traffic.
According to the author's understanding, the east-west security solutions of mainstream domestic security vendors all implement security protection through this traffic traction method.
Flow traction pain points
For cloud computing IaaS services, its core is mainly to provide corresponding computing, storage, and network resources. Comparing these three main parts, the virtualization technology of computing and storage resources has been relatively mature and complete, but the virtualization of the network is relatively lagging.
Therefore, each cloud service provider (Cloud Service Provider, CSP) has also introduced a variety of different types of network solutions according to their own characteristics. For example, VMware usually uses the native mode of virtual switches, but also uses NSX's SDN solution. Some traditional CSPs based on OpenStack may use Neutron components of network virtualization, and more radical CSPs may even use SDN solutions integrated with Neutron, such as DragonFlow and OpenDove. Some vendors will introduce third-party independent network virtualization and SDN solutions. It's an exaggeration. It can even be said that there may be as many virtualized network solutions as there are CSPs.
Regardless of whether it is a cloud service provider or a third-party independent virtualized network manufacturer, when designing the cloud network of its standard product, it usually only considers the corresponding business needs, and there are few details on how to access security products. design.
From the user’s point of view, usually when users virtualize their business to the cloud, the first step is often to consider only the virtualization of their business system, and rarely consider security issues, especially some privately built early Cloud basically does not have any security design, and even many network configurations have not yet been automated.
For such a private cloud, if it is necessary to implement east-west traffic security protection and realize east-west traffic traction, it will inevitably involve changes to its existing network solutions. If it happens that the network solution is provided by a third-party vendor, then Cloud service providers, network vendors, and security vendors have come together to reconstruct this cloud network. Therefore, the story of "three monks without water" is basically easy to stage.
How to do traffic traction
The pain point belongs to the pain point. Although there are indeed various problems in east-west traffic traction scheduling, its security protection is unavoidable. Then before standardized methods come out (I believe that with the development of technology, there will be a standardized method Proposed), various manufacturers have also put forward a variety of traffic traction schemes according to their own characteristics.
The following article introduces several traffic traction solutions in detail based on mainstream solutions in the industry and NSFOCUS's accumulated experience in east-west security protection.
SDN drainage
Software-defined networking proposes a network architecture that separates the control plane and the data plane. In the cloud computing environment, SDN is increasingly deployed and applied, such as the typical open source combination solution OpenStack+OpenDaylight. Traditional communication/network vendors, such as Nokia and Juniper, have also launched their own set of cloud computing network SDN solutions, and SDN start-ups also have a similar set of solutions, such as BigSwitch's BCF (Big Cloud Fabric) and Spruce Network's DeepFlow.
The SDN logically centralized controller has a global network view and corresponding traffic information. Then, for the traffic that needs to be detected and protected in the cloud, the SDN controller can automatically issue the flow entry to complete the traffic traction. .
API interface drainage
API interface drainage mainly refers to the realization of east-west traffic traction scheduling by calling the standard drainage API of the cloud computing system. The difference between it and SDN-based drainage is that when SDN-based network vendors provide network design and planning for cloud computing systems, their standard solutions and interfaces usually do not include this drainage API for security protection. . Then, if you want to realize automatic traffic pulling through the API interface in the SDN network, it is necessary for the SDN network manufacturer and the security manufacturer to carry out a certain degree of adaptation and development, so as to realize the automation of the entire drainage process.
The API interface drainage here is usually implemented through the standard drainage API provided by cloud service providers, typically the drainage interface provided by VMware. The cloud security platform adapts to the drainage interface of VMware to realize the automation of the entire east-west traffic traction protection. Of course, the typical implementation of this kind of automated drainage in VMware is also based on its SDN controller NSX.
Of course, if its VMware cloud platform does not include NSX, manual configuration can also be used to achieve the traction and scheduling of east-west traffic to the secure resource pool. For details, please refer to the hardware box method of obtaining network traffic in the cloud.
Agent drainage
For the case that the cloud network is a non-SDN network, how to realize the traction scheduling of east-west traffic? This section mainly introduces two ways of proxy drainage in this section and micro-agent drainage in the next section.
Agent drainage, as the name suggests, is to add a drainage agent to the cloud computing system. Of course, it is also called a drainage engine or a drainage platform. In fact, the functions implemented are the same. For the related drainage operations performed by the SDN controller in the SDN network, this agent is here completely implemented.
The security control platform sends the corresponding drainage request to this drainage agent, and the drainage agent issues corresponding drainage instructions according to the location of the host machine where the virtual machine is located and the current network conditions of the virtual machine, and completes the corresponding network configuration to achieve traffic pulling.
This kind of drainage method is easy to understand from the principle point of view. But there are also great difficulties in implementation. Because the drainage agent needs to have in-depth understanding and operating authority of the cloud computing system when performing drainage operations, each agent has a relatively high degree of coupling to the cloud computing platform, and its portability and reproducibility are relatively poor.
This kind of drainage agent is mainly deployed to realize the security protection of east-west traffic. The agent is usually provided by the security vendor, and the work of the agent is to change and operate the cloud computing system network, so it needs Security vendors and network vendors have close cooperation to complete accurate and efficient traffic traction.
Micro-agent drainage
The difference between a micro-agent and an agent is mainly reflected in that the agent is deployed on the host computer of the computing node, and the corresponding configuration of the virtual network is changed to complete the corresponding traffic traction scheduling. The micro-agent is like traditional terminal security software, deployed inside the virtual machine, then this micro-agent can modify or mark data packets at the virtual machine's network protocol stack or network card level to complete the traffic pulling work. Representative manufacturers such as Kingsoft and Fortinet.
The advantage of this method is that on the one hand, it can complete traffic pulling without adapting and modifying the virtualized network of the cloud computing system; on the other hand, it can make full use of the computing power of the virtual machine without additional security-related Virtual machine investment.
In this way, an agent needs to be installed in the customer's virtual machine, so there will be a corresponding trust problem. If the customer's data is sensitive or the level of confidentiality is relatively high, it is generally unlikely that such a solution will be accepted.
