Portable Gas Stove,Gas Burner,Outdoor Burner,Burners For Industrial Stove Ningbo Best Channel Import & Export Co., Ltd. , https://www.zjnbbtc-metal.com
SDN-based cloud platform for network security and simulation environment design and exploration
Abstract: This article mainly explores the combination of cloud platform and SDN network in the teaching of network security and the network to meet various teaching network security simulation, network offense and defense and network enforcement exercises. At the same time, with SDN network and controller technology to achieve various levels of network attack simulation, flow control, traffic distribution and traction processing. At the same time, through the SDN network system to meet various levels of network security teaching simulation and actual simulation experiments.
Keywords: cloud platform, SDN, KVM, virtual machine template, flow control, OpenFlow, Vmware
In view of the increasingly serious cyber security situation in China, talent training and environmental simulation tests need to be accelerated. However, cyber security involves a wide range of areas and the environment is complex. It is difficult to comprehensively reflect the problems of the entire area. How to solve the training of network security personnel and environmental simulation tests has become an important issue. We designed a comprehensive and reliable network security personnel training and cyber security training simulation testing environment based on the big data cloud computing environment for the entire demand.
The adoption of big data cloud computing environments and flexibility is in full compliance with network security simulation environment and flexibility requirements. Because it provides a flexible enough environment construction and flexible environment setting mode. You can save and build unlimited possibilities through system templates. So that it can be called and reorganized at any time. The use of big data cloud computing method to establish and set up network security environment simulation and network law enforcement simulation.
The complexity of the environment required for cybersecurity and law enforcement involves a relatively large number. There is a need for a system and network system that can flexibly meet such needs. In the specific design and application, we use all SDN-based network systems to support and meet such needs.
SDN technology
The ultimate goal of the SDN (Software Define Network) network is to serve diverse business application innovations. Therefore, with the deployment and promotion of SDN technologies, more and more business applications will be developed. Such applications will be able to easily call the underlying network capabilities through the SDN northbound interface and use network resources on demand.
SDN promotes service innovation is an indisputable fact in the industry. It can be widely used in cloud data centers, broadband transmission networks, mobile networks and other scenarios. The provision of network resource services for cloud computing services is a very typical case. As we all know, in the current cloud computing business, server virtualization and storage virtualization have been widely used. They pool the underlying physical resources and then distribute them to users on demand. In contrast, traditional network resources are far from reaching similar flexibility, and the introduction of SDN can solve this problem well.
Through the standard southbound interface, SDN shields the differences of the underlying physical forwarding devices, realizes the virtualization of resources, and opens up a flexible northbound interface for upper-layer services to perform network configuration on demand and invoke network resources. Existing OpenStack, CloudStack, Hpyer-V, Vmware and other well-known cloud computing technologies are cloud management platforms that can work at the SDN application layer. By adding SDN management plug-ins, managers, and users to their network resource management components. The SDN northbound interface can be used to easily call the SDN controller's open network capabilities. When cloud host networking requirements (such as setting up user-specific VLANs) are sent out, related network policies and configurations can be centrally formulated on the interface of the cloud management platform, and then the SDN controller can be driven to automatically and uniformly send relevant On the network device.
Therefore, network resources can be presented to business application developers in the same way as other types of virtualized resources with the abstract resource capabilities. Developers do not need to spend a lot of overhead to perform additional adaptation work for the differences of the underlying network devices. Helps with the rapid innovation of business applications.
SDN Controller and Northbound Interface Technology
The SDN control layer is the brain of the SDN. It is responsible for the centralized and unified control of the underlying forwarding devices. At the same time, the interfaces for the upper layer services to provide network capabilities are also playing a decisive role in the SDN architecture. The SDN controller is also the focus of SDN. From the technical realization point of view, in addition to the southbound network control and northbound service support, the controller also needs to pay attention to the expansion of things to avoid performance and security bottlenecks caused by SDN centralized control. The SDN controller is also facing south and north. The core technology was introduced into the east-west direction to effectively solve the problems of communicating with each layer and controlling the horizontal expansion of the cluster.
At present, there are many open-source controller implementations based on the OpenFlow control protocol in the industry, such as NOX, Onix, and Floodlight. They all have their own unique features designed to support link discovery, topology management, policy formulation, and table entry delivery. The basic operation of SDN network operation. Although different controllers still have differences in function and performance, the technical features that SDN controllers should have can be summarized. The experience and lessons learned from the development and practice of these open source systems will help promote SDN control. The standardization of development.
In addition, the controller used for network centralized control is the core of the SDN network, and its performance and security are very important. Its possible excessive load and single point of failure have always been problems that need to be solved in the SDN field. At present, the industry also has a lot of discussions about it, and put forward many innovative methods from many aspects such as deployment architecture and technical measures.
The SDN controller controls the network mainly through the southbound interface protocol, including link discovery, topology management, policy formulation, and table entry delivery. The link discovery and topology management are mainly to control its use of the southbound interface. The channel carries out unified monitoring and statistics on the information reported by the underlying switching device. The policy formulation and entry delivery are the controllers using the downstream channel of the southbound interface to perform unified control over the network device.
The SDN northbound interface is an interface opened by the controller to upper-layer service applications. Its goal is to enable the service application to conveniently call the underlying network resources and capabilities. Through the northbound interface, developers of network services can call various network resources in the form of software programming; at the same time, the upper layer network resource management system can globally control the resource status of the entire network network through the northbound interface of the controller and unify the resources. Scheduling. Because the northbound interface directly serves business applications, its design needs to be closely linked to business application requirements, with diverse features. At the same time, whether the design of the northbound interface is reasonable and convenient so that it can be widely used by business applications will directly affect the market prospects of SDN controller vendors.
Different from the existing international standards such as OpenFlow in the southbound interface, the northbound interface still lacks the industry-recognized standards. Therefore, the protocol formulation of the northbound interface has become the focus of competition in the current SDN field. Different participants either from the perspective of the user or from From the perspective of operations, or from the perspective of product capabilities, many proposals have been made. It is reported that there are currently at least 20 controllers, each of which will provide a northbound interface for upper application development and resource layout. Although the northbound interface standard is still difficult to reach a consensus at present, sufficient openness, convenience, and flexibility will be important criteria for measuring the quality of the interface. For example, the REST API is the preferred interface form for developers of upper-level business applications. Some traditional network equipment vendors provide programming interfaces on their existing equipment for direct invocation by business applications. They can also be considered as one of the northbound interfaces. Their purpose is to improve configuration management without changing the existing equipment architecture. Flexibility to deal with open protocol competition.
The controller is responsible for the centralized control of the entire SDN network, and plays a very important role in grasping the entire network resource view and improving the delivery of network resources. However, the centralized control capability also means that the security and performance of the controller office become the bottleneck of the entire network; in addition, a single controller cannot handle the SDN network across multiple regions and requires multiple SDN controllers. Distributed clusters to avoid the reliability, scalability, and performance issues of a single controller node. At present, the East-West interface for communication and connection between multiple controllers has not yet defined standards, but experts say that some very mature clustering technologies can be applied to SDN networks to solve the above problems.
SDN Switch and Southbound Interface Technology
One of the core concepts of SDN is to strip the control function from the network equipment and realize the network programmable through the central controller so as to optimize the utilization of resources and improve the efficiency of network management and control.
Although the SDN switch working at the infrastructure layer does not need excessive consideration of logic control, it is still the device responsible for the specific data forwarding processing in the SDN network. In order to complete high-speed data forwarding, the SDN switch must follow the working principle of the switch. In essence, whether it is a switch or a router in a traditional device, its working principle is to compare certain characteristic fields in the data packet with some entries stored in the device when a packet is received, when a match is found. Then according to the requirements of the items in the corresponding treatment. The SDN switch is a similar principle, but the difference from the traditional device is that the entries in the device are not generated locally by the device itself according to the surrounding network environment, but are issued by the remote controller. Various sophisticated control logic (such as link discovery, address learning, routing calculations, etc.) need not be implemented in the SDN switch.
SDN switches can ignore the implementation of control logic, focus on data processing based on entries, and the performance of data processing has become the most critical indicator to evaluate the pros and cons of SDN switches. Therefore, many high-performance forwarding technologies have been proposed, for example, based on multiple The technology of high-speed processing of the table in a pipeline manner. In addition, considering the mixed work of SDN and traditional networks, the SDN switch supporting mixed mode is also the focus of current device layer technology research and development. At the same time, with the emergence and improvement of virtualization technologies, the virtualized environment will be an important application scenario for SDN switches. Therefore, SDN switches may have various forms such as hardware and software. For example, OVS (Open vSwitch) is a switch based on open source software technology that can be integrated into a server virtualization hypervisor. It has complete switch functions and plays an important role in virtualization networking. effect.
The SDN switch is only responsible for high-speed network forwarding. The saved forwarding table information for forwarding decisions is from the controller. The SDN switch needs to work under the control of the remote controller. The device state and control commands related to the SDN switch need to pass through the southbound direction of the SDN. The interface communicates to achieve centralized and unified management.
In this project and in the design, full use of SDN-based switches to build the entire network system can meet the increasingly complex needs. At the same time, it flexibly dispatches related network resources and rebuilds various network forms. At the same time, the SDN controller can meet the complex network application requirements of the entire analog system.
OpenFlow technology
Accompanying SDN technology is the Openflow protocol. The name of the OpenFlow standard is the OpenFlow Switch Specification, so it is itself a device specification that specifies the basic components and functional requirements of the OpenFlow switch that is the forwarding device of the SDN infrastructure layer, and is used to control the switch by the remote controller. OpenFlow protocol.
The best-known southbound interface is currently the OpenFlow protocol advocated by ONF. As an open protocol, OpenFlow has broken through the barriers of traditional network equipment vendors to interface with equipment capabilities. After years of development and with the joint efforts of the industry, OpenFlow has been improving and can fully solve various problems facing SDN networks.
Currently, OpenFlow has gained extensive support from the industry and has become a de facto standard in the SDN industry. For example, OVS switches can support the OpenFlow protocol. OpenFlow solves the problem of how the control layer issues the entries for the SDN switch to match the data flow to the forwarding layer device. At the same time, the ONF also proposes the OF-CONFIG protocol to remotely configure the SDN switch. And the goal of management is to better implement centralized management and control of decentralized SDN switches.
The important position of OpenFlow in the SDN field is self-evident, even if everyone once had OpenFlow is equivalent to the SDN misunderstanding. In fact, OpenFlow is only one of the southbound interfaces that can be used in the SDN implementation based on open protocols, and there may be many subsequent southbound interfaces (ForCES, PCE-P, etc.) that have been applied and promoted successively. But it must be admitted that OpenFlow is born for SDN, so it is the best fit with SDN. It is believed that with the vigorous promotion of all parties in the industry led by ONF, its development prospects in the future will also become more clear.
The OpenFlow switch communicates with the remote controller using a secure connection-based OpenFlow protocol. Among them, the flow table (Flow Table) is a key component of the OpenFlow switch and is responsible for high-speed query and forwarding of data packets.
Flow table concept
In OpenFlow v1.1 and v1.2, although the flow entry in the switch still consists of three parts, the corresponding name has changed. Among them, the header fields and actions defined in v1.0 are renamed Match Fields and Instructions, respectively. The reason why the header field is renamed is because the tuple information such as the ingress port in the flow entry does not belong to the header of the data packet, so it will be more accurate to change it to the match field. The use of the term directive instead of action is mainly due to the introduction of multiflow tables in OpenFlow switches. In a multi-flow table scenario, although the data packet matches in the top-level table, the subsequent operation of the switch may still be to transfer it to the next-level table to continue matching, instead of immediately following the flow table as in v1.0. Actions do specific operations on data packets. Therefore, the new version of OpenFlow renames related actions to instructions. The flow table structure defined in OpenFlow v1.1 and v1.2 is shown in Figure 1-2.
Figure 1-2 Flow Table Structure of OpenFlow v1.1 and v1.2
After OpenFlow v1.3, the contents of the flow table structure changed again, adding priority, timeouts, cookies, etc., thereby expanding the three parts of the original flow table structure to Six parts, as shown in Figure 1-3.
Figure 1-3 Flow Table Structure of OpenFlow v1.3
As shown in Figure 1-3, the description of each field of the flow table structure of OpenFlow v1.3 is as follows.
Match Domain: Matches packets. Includes incoming port and packet headers, and optional metadata specified by the previous table.
Priority: The matching order of flow entries.
Counter: Updates the count of matching packets.
Instruction: Modify the action set or pipeline processing.
Timeout timer: The longest effective time or maximum idle time of a stream.
Cookie: opaque data value selected by the controller. The controller is used to filter flow statistics, flow changes, and flow deletions. However, it cannot be used when processing data packets.
Openflow key technologies
OpenFlow provides an open protocol through which users can control flow tables in different switches. Researchers can easily control the direction of data flow by selecting the data forwarding paths and how they need to be handled. In this way, researchers can experiment with innovative routing protocols, secure network models, new network services, and even replace existing TCP/IP protocols in the network. A complete OpenFlow network consists of an OpenFlow controller and one or more OpenFlow switches.
The OpenFlow switch is the core part of the entire OpenFlow network and mainly manages the forwarding of the data layer. After receiving the data packet, the OpenFlow switch first looks up the forwarding port on the local flow table. If there is no match, the data packet is forwarded to the controller, and the control layer determines the forwarding port. The OpenFlow switch consists of three parts: the flow table in the switch, the secure channel connected to the remote controller, and the standard OpenFlow protocol used to connect the switch to the controller:
(1) Each entry in the switch flow table table contains one action, and Flow performs the corresponding actions after matching the entries.
(2) The security channel connects the interface between the switch and the controller to realize the transmission of network data packets and interaction commands between the controller and the switch.
(3) OpenFlow protocol describes the standard of information used for interaction between the controller and the switch, and the controller and switch interface standards.
The OpenFlow switch works as follows:
(1) Open the OpenFlow controller, exchange information with the OpenFlow switch through the secure channel and complete the connection.
(2) Several flow entries can be stored in the flow table of the OpenFlow switch. Each flow entry consists of matching fields, counters, and actions.
(3) After entering the OpenFlow switch, the data flow matches the match field in the flow entry, finds the data flow modification count value of the flow entry, and then the OpenFlow switch processes the data packet according to the query action.
(4) If the data flow entering the OpenFlow switch does not match successfully, it is sent to the controller through the secure channel, and is processed by the decision module of the controller.
The OpenFlow controller is responsible for controlling the flow table in the OpenFlow switch. Including basic operations such as adding, modifying, and deleting flow tables. The implementation of these basic operating functions is based on the program developed on the controller. The hardware device that implements the controller is more flexible. It can be a PC running a simple application, and can also be simulated by a virtual machine. The functional design of the control program on the controller enables the OpenFlow network to provide rich applications that reflect the flexibility and scalability of the OpenFlow network.
The OpenFlow protocol is used for communication between switches and controllers in an OpenFlow network. The OpenFlow protocol stipulates that when the switch and the controller exchange the control information, the message is transmitted through the secure channel that is reliably transmitted. The control information includes establishing a connection message, configuring a switch message, reading a status message, modifying a status message, configuring a queue message, and the like. The main function of the controller message is to implement operations such as the switch sending packets to the controller through the secure channel and the controller issuing commands to the switch.
Cloudy environment simulation
A large number of experiments and network simulation tests are needed in the network security and law enforcement professions. If you need to build a complete and reliable system, it will be very difficult and impossible to achieve. Because there is too much knowledge and understanding in network security and law enforcement, and it is very complicated. We hope to build a complete and reliable network security and law enforcement environment simulation and testing environment through virtualization cloud technology and SDN network technology. In this way to meet the teaching and practical needs.
The core includes several aspects. Including all current network virtualization environments (KVM series, VMware, Xen, Microsoft Hyper-V, etc.). Meet all network security environmental requirements. All switches use high-density SDN switches. The interfaces are all 10G fiber. SDN switches use 40G direct connections.
The schematic diagram of the connection between the SDN system and the cloud system is as follows:
The overall connection architecture of the cloudy system is as follows:
The system contains all current virtualized environments. This can meet the needs of practical education. Among them, VMware and Microsoft Azure are commercial products. Xen and KVM series are open source products. Through a variety of virtual environment systems to meet a variety of environmental simulation needs. Involving the network can be accomplished through SDN controller, OpenFlow configuration and other software.
Typical case DDOS attack cleaning. We can meet this experimental requirement with the following SDN architecture.
Network security and law enforcement test environment simulation, through the virtualization platform to make a variety of platforms and environments standard template library. Easy to share and call. Can include Microsoft Windows Server series, Linux series, FreeBSD series, Solaris series, Mac OS series, etc. can be established into a standard environment, and then generate a standard template for a total of all user calls, integration and application.
System image
The current image information can be displayed, including the image name, operating system type, operating system version, operating system architecture, image availability status, image size, and creation time.
Can see shared mirrors and private mirrors
By establishing a unified security environment image (public mirror and private mirror). Public mirroring is a unified environment and structure. Private images are built for special or dedicated systems. By matching the mirroring environment with the SDN network, we can meet our design requirements. For experiments involving cyber attacks, it is necessary to configure block domains and traffic traction on the SDN to ensure system and network security.
to sum up
The above technical discussion is a preliminary experience summary. The technology and flexibility involved in cyber security and law enforcement are incalculable. Adopting traditional architecture and methods cannot meet the demand. We hope that we can start to discuss the relevant technologies and improve the structure together with our peers. The current use of a cloudy architecture and SDN network to build is able to meet the currently known network security and law enforcement teaching needs. At the same time, I hope that everyone will jointly study progress.