KR20200069632A - Method, apparatus and computer program using a software defined network to avoid didos attack - Google Patents

Abstract

The present invention relates to a method for preventing a DDoS attack by a controller in a software defined network, wherein a first switch, a second switch, and a third switch are connected to the controller. According to the present invention, the method comprises the steps of: collecting information on a network layer (L3) of traffic from the first switch at the controller; collecting, by the controller, information on a transport layer (L4) of the traffic from the second switch; and collecting information on a presentation layer (L6) and an application layer (L7) of the traffic from the third switch in the controller.

Description

How to evade DDoS attacks using software-defined networks, device and computer programs {METHOD, APPARATUS AND COMPUTER PROGRAM USING A SOFTWARE DEFINED NETWORK TO AVOID DIDOS ATTACK}

The present invention relates to a method and apparatus for tracking traffic of a network using software-defined networking and evading a DDoS attack based on the traffic.

Recently, network function virtualization technology is making new changes to the overall hardware-oriented network architecture. Network function virtualization, or NFV, is a concept that separates hardware and software, which are components of the network, and virtualizes the functions of physical network equipment to run on a virtual machine (VM) server, hardware equipped with a general-purpose processor, and a cloud computer. .

According to this, various network devices such as routers, load balancers, firewalls, intrusion prevention, and virtual private networks can be implemented as software on a general server, which can escape the vendor dependency of network configuration. This is because expensive dedicated equipment can be replaced with general purpose hardware and dedicated software. Furthermore, it has the advantage of being able to quickly respond to traffic changes as well as reduce equipment operation costs.

Meanwhile, software-defined networking, that is, SDN technology, is characterized by separating the functions of a complex control plane from a data plane. According to this, the complex functions of the control plane are processed by software, and the data plane performs only simple functions indicated by the control plane such as network packet delivery, ignore, and change.

By applying these technologies, new network functions can be developed with software without the constraints of complicated hardware, and at the same time, various attempts that were impossible in the previous network structure have been made possible.

The NFV and SDN are separate technologies, but may complement each other. This is because various network functions implemented in software by NFV can be efficiently controlled using SDN.

Open Networking Foundation, “Specification 1.2.0”

In a software defined network according to an embodiment of the present invention, a method for a controller to protect a DDoS attack is connected to a first switch, a second switch, and a third switch, and the network layer of traffic from the first switch in the controller Collecting information about (L3); Collecting, by the controller, information on a transport layer (L4) of the traffic from the second switch; And in the controller, collecting information about the presentation layer (L6) and application layer (L7) of the traffic from the third switch.

In a software defined network according to an embodiment of the present invention, a method for a controller to defend a DDoS attack is connected to a first switch, a second switch, and a third switch, and the controller is configured to network traffic from the first switch. Collecting information about the layer (L3); Collecting, by the controller, information on a transport layer (L4) of the traffic from the second switch; And in the controller, collecting information about the presentation layer (L6) and application layer (L7) of the traffic from the third switch.

According to the present invention, traffic information for each OSI layer can be collected by distributing to a plurality of switches, thereby effectively preventing a DDoS attack without degrading network performance.

1 is a diagram for describing software-defined networking.
2 is a flow chart for explaining a method for defending a DDoS attack according to an embodiment of the present invention
3 is a flowchart illustrating a traffic tracking method according to an embodiment of the present invention

The present invention is not limited to the description of the embodiments described below, and it is apparent that various modifications may be made without departing from the technical spirit of the present invention. In describing the embodiments, descriptions of technical contents that are widely known in the technical field to which the present invention pertains and which are not directly related to the technical subject matter of the present invention will be omitted.

Meanwhile, in the accompanying drawings, the same components are represented by the same reference numerals. In the accompanying drawings, some components may be exaggerated, omitted, or schematically illustrated. This is to clearly describe the gist of the present invention by omitting unnecessary descriptions not related to the gist of the present invention. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

It should be understood that the term “flow rule” in the specification of the present invention refers to a network policy applied by a controller server in a software defined network from the viewpoint of a person skilled in the art.

Furthermore, in this specification, the open flow switch may be understood as a concept including a switch supporting only the open flow protocol, a virtual switch supporting the open flow protocol, and a general L2 switch supporting the open flow protocol.

1 is a view for explaining the configuration of a software-defined network. Referring to FIG. 1, a software defined network may include a controller server 100, network equipment 200 and a host 300. The network equipment 200 and the host 300 may be referred to as a node, and a link may mean a connection between two nodes.

The controller server 100 functions to manage the network equipment 200, and centrally manages and controls the plurality of network equipment 200. Specifically, the controller server 100 is an application that functions such as topology management, path management related to packet processing, link discovery, and flow management, which is a packet flow. It can be implemented in a mounted form.

The network equipment 200 functions to process packets under the control of the controller server 100. An example of the network equipment 200 is an open flow switch.

In the software-defined network, the controller server 100 and the open flow switch 200 must exchange information with each other, and the OpenFlow protocol is widely used as a protocol for this. That is, the open flow protocol is a standard specification that can communicate with each other between the controller server 100 and the open flow switch 200.

According to the open flow protocol, the switch 200 exchanges information with the controller server 100 through a control channel, and one or more flow tables, group tables for pipeline processing, The meter table and/or network interface for packet delivery may have one or more ports.

On the other hand, a DDoS attack means an attack that attacks a system maliciously and shortens the resources of the system, preventing it from being used for its intended purpose. Attacks such as making a number of connection attempts to a specific server, preventing other users from using the service normally, or terminating the server's TCP connection may be included in this range.

The means, motives, and targets of DDoS attacks can vary, but they can generally interfere with or disrupt the functioning of Internet sites or services. Typically, DDoS is played against famous sites, such as banks, credit card payment gateways, or root name servers.

This DDoS attack occurs at the network layer (Layer 3), transport layer (Layer 4), presentation layer (Layer 6), and application layer (Layer 7).

Layer 3: UDP reflection attack

Layer 4: SYN flood

Layer 6: SSL abuse

Layer 7: HTTP flood or DNS query flood

As such, the DDoS attack occurs for each layer of the OSI, and when the attack of each layer corresponds to one network device, a large load may be generated on the corresponding network device. Furthermore, in order to respond to the conventional DDoS attack, dedicated equipment for traffic tracking must be installed in the network, and if the dedicated equipment has a load, overall network performance may deteriorate.

However, this problem occurs because network devices such as switches basically operate independently in a legacy network. Since a switch that collects traffic information can check only traffic passing through the switch, a separate device is required to track traffic of the entire network.

However, in a software defined network, the switch is under the control of the controller and processes the traffic. More specifically, the controller can grasp the network topology in advance and determine the overall network policy, and the switch receives the flow rule from the controller and processes the traffic based on this.

The present invention focuses on the characteristics of such software-defined networking in order to solve the problems of the prior art. According to an embodiment of the present invention, traffic information for each OSI layer may be collected by distributing in a plurality of switches.

Since one network device does not track traffic information of all layers of the entire network, according to an embodiment of the present invention, a DDoS attack can be effectively prevented without degrading network performance.

For example, in the example of FIG. 2, traffic 260 forwarded from the host 205 to the host 250 through the first switch 210 to the third switch 230 may be considered.

According to an embodiment of the present invention, the controller may collect information on the network layer L3 of traffic 260 from the first switch 210. More specifically, when traffic 260 flows into the first switch 210, the first switch transmits a message, which is a packet for querying the path of the corresponding packet, to the controller, and the controller content of the message, which is a packet received from the first switch 210 By analyzing, it is possible to collect information on the network layer of the traffic 260.

Subsequently, if the controller determines that the traffic 260 corresponds to a DDoS attack based on the L3 information of the traffic 260, the controller may be configured to drop the traffic 260 or bypass the route by sending a flow rule to the first switch 210.

According to an embodiment of the present invention, the controller may collect information on the network layer L3 of traffic 260 from the first switch 210. More specifically, when traffic 260 flows into the first switch 210, the first switch transmits a message, which is a packet for querying the path of the corresponding packet, to the controller, and the controller content of the message, which is a packet received from the first switch 210 By analyzing, it is possible to collect information on the network layer of the traffic 260.

Subsequently, if the controller determines that the traffic 260 corresponds to a DDoS attack based on the L3 information of the traffic 260, the controller may be configured to drop the traffic 260 or bypass the route by sending a flow rule to the first switch 210.

Meanwhile, according to another embodiment of the present invention, a dedicated flow table for packet analysis may be added to the open flow switch, and flow information for L3 may be collected based on this. The dedicated flow rule for packet analysis is located at the entrance of pipeline processing of the open flow switch, and has a feature that does not affect the flow rule for traffic processing. More detailed description of this will be described later in the description of the accompanying FIG. 3.

Meanwhile, information about the transport layer L4 may be generated in the traffic 260 passing through the first switch 210 in the second switch 220. L4 layer information may be collected using the NetFlow protocol.

For example, if the second switch 220 supports the NetFlow protocol, statistical information may be generated in units of 5 tuples such as source IP address, destination IP address, source port, destination port, and protocol type for traffic 260. The statistical information generated by the second switch 220 may be transmitted to the controller, and the controller may track traffic by collecting statistical information of the entire network and calculating a packet path or filtering for necessary information.

Subsequently, if the controller determines that the traffic 260 corresponds to a DDoS attack based on the L4 information of the traffic 260, the controller may set the second switch 220 to drop the traffic 260 or bypass the route.

Meanwhile, information about the presentation layer (L6) and the application layer (L7) may be generated in the traffic 260 passing through the second switch 220 in the third switch 230.

More specifically, when network equipment supporting application-level packet analysis is installed in the third switch 230, the network equipment can check packet contents by configuring tapping or inline of packets. For example, DPI (Deep Packet Inspection) can check whether a packet is a video file or a voice file, and whether there is no content that violates security, as well as the type of content.

Information about the contents of these packets can be transmitted to the controller, and the controller can be used to determine whether a DDoS attack is achieved by collecting information from the entire network. That is, if the controller determines that the traffic 260 corresponds to a DDoS attack based on the L6 and L7 information of the traffic 260, the controller may set the traffic to drop the traffic 260 or bypass the route by sending a flow rule to the third switch 230.

3 is a flowchart illustrating a method of tracing a layer 2 level traffic according to an embodiment of the present invention.

In step 310, the controller may configure a network topology.

For example, the controller may acquire switch location and port information located in a network using the LLDP protocol. Furthermore, the controller may configure the network topology by acquiring the location and port information of the host located in the network using a message that is a packet received from a switch connected to the host.

In step 310, the controller may add the ids of the flow tables constituting pipeline processing of all switches by one. That is, it is possible to secure a flow table (flow table 0), which is an entrance to pipeline processing, by adding an id of a flow table for traffic processing by one.

In step 320, the controller may configure the first flow table (flow table 0) of pipeline processing of all switches as a flow rule for traffic analysis. More specifically, the controller records Goto table 1 in the instructions of all flow entries, records traffic information to be tracked in the match field, generates flow table 0, and applies it to each switch.

In particular, flow table 0 according to an embodiment of the present invention has a feature of applying * to a match field and goto table 1 to an instruction as a flow entry of priority 0. This is to allow traffic not to be tracked according to a flow table for processing traffic applied from table-id 1.

On the other hand, the traffic to be tracked is recorded in the counter according to another flow entry in the flow table 0, and will be processed according to pipeline processing starting from flow table 1.

For example, according to the OpenFlow protocol, the controller can match the source IP address, destination IP address, VLAN id, VLAN priority, MPLS label, MPLS traffic class, source MAC address, destination MAC address, inport, and export in the match field. You can track the traffic you want by recording such information.

In step 330, the controller may collect counter information of Table id 0 of all switches. According to an embodiment of the present invention, since all instructions of table id 0 constituting pipeline processing of all switches are goto table 1, traffic matching the match field of table-id 0 is only recorded in the counter of table-id 0. Since it is processed according to pipeline processing starting from table-id 1, it is possible to track the traffic of the entire network in step 340 by combining the record and topology information of the counter of table-id 0.

For example, the controller can recover the end-to-end full path of any traffic with a combination of table-id 0 counter record and topology information. As another example, if the packet count information for an arbitrary path is different from the calculation, it may be estimated that a packet drop occurs in the corresponding path. Furthermore, it is possible to detect the possibility of looping in a specific path. As another example, the controller may check the delivery status of a broadcast packet by using a combination of table-id 0 counter record and topology information.

According to this embodiment of the present invention, traffic can be simultaneously tracked while processing traffic only with a controller and an open flow switch that form software-defined networking. That is, it is possible to track traffic for the entire network by simply adding the traffic analysis table 0, which is a flow table, to the switch, so there is no need to add additional equipment to the network, and it does not affect the traffic processing of the switch. .

The embodiments of the present invention disclosed in the present specification and drawings are merely to provide a specific example to easily explain the technical content of the present invention and to understand the present invention, and are not intended to limit the scope of the present invention. It is obvious to those of ordinary skill in the art to which the present invention pertains that other modifications based on the technical spirit of the present invention can be implemented in addition to the embodiments disclosed herein.

Claims (1)

In a software-defined network, how to prevent a DDoS attack from a controller,
A first switch, a second switch, and a third switch are connected, and the controller collects information on the network layer (L3) of traffic from the first switch;
Collecting, by the controller, information on a transport layer (L4) of the traffic from the second switch;
And collecting information on the presentation layer (L6) and the application layer (L7) of the traffic from the third switch at the controller.

Images