A network target platform construction method for relieving DDoS attack

Abstract

The application discloses a network target platform construction method for relieving DDoS attack, takes OpenStack as a core technology, replaces the original storage system of OpenStack by Ceph distributed storage technology, and proposes a super-converged network target design scheme based on OpenStack and Ceph, and a data storage optimization algorithm based on the degree of favor, the storage position of data is constrained by the degree of favor factor, and the balance of all OSD nodes in the cluster to store data is improved. The network target platform constructed by the application has the advantages of simple storage system maintenance, difficulty in single point failure, simple architecture, low cost and load balancing.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a method for constructing a network range platform to mitigate DDoS attacks. Background Technology

[0002] Currently, cyberspace has become a new arena for international competition. It is evident that security boundaries are no longer limited to geographical space but are evolving towards informatization. Countries worldwide are deploying cybersecurity strategies to seize the high ground. In particular, the current cyberspace competition is exhibiting a new trend of increasing practicality and complexity, sounding the alarm for maintaining cybersecurity. To systematically study cyberspace activities, deploy cybersecurity strategies, cultivate cybersecurity talent, and enhance the ability to respond to cyberattacks, cyber ranges have emerged as a core infrastructure for cybersecurity learning, training, drills, and research, possessing broad application prospects and significant social value.

[0003] In recent years, cyberattacks have become more frequent and destructive. According to relevant data, economic losses caused by cyberattacks in 2020 alone reached one trillion US dollars, roughly double the figure in 2018. Among the many types of cyberattacks facing cyberspace, Distributed Denial of Service (DDoS) attacks are one of the major security threats. This attack method can unleash a flood of malicious traffic onto network devices, violently exhausting the resources of target devices and rendering them unable to respond to legitimate traffic requests. It causes enormous losses with simple attack methods and low costs, posing a significant threat to the stability of the network environment, and is therefore highly concerned by cybersecurity organizations. Although some traditional solutions exist, these solutions often suffer from high resource consumption and high implementation costs.

[0004] Cyber ​​ranges, as a whole, revolve around a core concept: providing virtual environments that simulate various infrastructures to serve cybersecurity exercises or training. Currently, my country is designing and researching cyber ranges from multiple perspectives, including large-scale network behavior simulation, network traffic and user behavior simulation, and visualization technologies. The main methods used in constructing cyber ranges are traditional technologies, simulation technologies, and virtualization technologies. Although a large amount of experimental research has been conducted on cyber ranges in China, these platforms generally suffer from complex architectures, high operating costs, poor load balancing, and lack methods for mitigating DDoS attacks in specific scenarios. Summary of the Invention

[0005] To address the shortcomings of existing technologies and achieve the goals of enhancing network range storage performance and operational stability, as well as detecting and mitigating DDoS attacks, this invention adopts the following technical solution:

[0006] A method for constructing a network test range platform includes the following steps:

[0007] Step 1: Based on the network range platform, set up control nodes and computing nodes;

[0008] Specifically, the key technologies of the OpenStack network range platform are used, and the deployment is carried out manually. The node planning is adjusted according to the needs, which can promote users' overall understanding and mastery of the OpenStack cloud platform. The control nodes and computing nodes of the network range are set up.

[0009] Step 2: Build a virtual environment and control the storage of the distributed file system through virtualization management tools;

[0010] Specifically, KVM is loaded using the Linux kernel, and KVM is used to schedule and manage virtual machine vCPUs and virtual memory. Then, QEMU is used to interact with virtual external devices. The Libvirt virtualization management tool provides management of virtual machines and virtual devices. At the same time, Libvirt is used to manage RBD (RADOS Block Device). The OpenStack cloud platform, which provides virtualization services using KVM / QEMU technology, uses Ceph RBD, that is, it uses Ceph distributed storage technology to replace the OpenStack native storage system.

[0011] Step 3: The distributed file system utilizes a preference factor to constrain data storage locations, improving the data balance across all OSD nodes in the cluster. The CRUSH algorithm is built into the Ceph distributed storage system. During data storage optimization, it first obtains the file size allocation from the configuration file, then determines whether a preference factor needs to be added during the initialization phase based on the configuration information. By obtaining the heartbeat cycle detected by the Ceph distributed file system, it adjusts the preference values ​​of the cluster storage nodes. The optimization algorithm is organized in modules and dynamically loaded according to actual needs, ensuring the isolation between technology and business, thereby adjusting the data distribution in the cluster storage. The preference-based data storage optimization algorithm mainly consists of a preference module and a calculation module. The preference module runs on Ceph's RADOS, with the Paxos algorithm maintaining consistency during message passing. The calculation module determines whether to call the preference module and add a preference factor based on the configuration file, thereby adjusting the data distribution in the cluster.

[0012] Furthermore, step one includes the following steps:

[0013] Step 1.1: Deploy the network range platform;

[0014] Specifically, the core technologies of OpenStack are deployed manually.

[0015] Step 1.2: Design the control node, integrating the functions of the network nodes onto the control node to provide management support services for the underlying services, outgoing management services, and extended management services;

[0016] Specifically, a control node is designed and installed on the control node through the Neutron service, integrating the functions of the network node into the control node; management support services for the installation of related components such as databases and message queues are provided, as well as basic management services related to user management and control such as Keystone, Glance, Nova, and Dashboard, and extended management services for the installation of optional components such as Cinder.

[0017] Step 1.3: Design the computing nodes, install the Cinder service component on the computing nodes, integrate the storage nodes on the computing nodes, and provide computing, networking and monitoring services for the network range.

[0018] Specifically, based on the overall design of the network testbed platform, the control nodes and compute nodes of the network testbed are designed first. The control node primarily provides three types of services: management support services providing underlying services for the installation of related components such as databases and message queues; basic management services related to user management and control of Keystone, Glance, Nova, and Dashboard; and extended management services for the installation of optional components such as Cinder. The network node provides network services, with the Neutron component managing communication between private and public network segments, communication between virtual networks, firewalls, etc., and communication with other nodes is achieved by configuring two or more ports. When the network node functionality is integrated into the control node, the Neutron service is installed on the control node, and its related services are basic management services. The "openstack catalog list" command is executed on the control node terminal to view the currently deployed OpenStack service components. The compute nodes primarily provide three types of services: compute, network, and monitoring. Compute and network services are the basic services of the compute nodes. Storage nodes are integrated on the compute nodes, requiring the Cinder service component to be installed on the compute nodes. Storage nodes can perform block storage and object storage. Block storage is equivalent to virtualizing a disk mounted on the corresponding virtual machine, unaffected by the file system, and can be expanded when virtual machine space is insufficient. The deployment of compute nodes begins with cloning a template machine, modifying the hostname of the cloned virtual machine, and configuring the relevant network settings. Next, chrony is installed, making the compute node an NTP client to keep its time synchronized with the control node, preventing malfunctions caused by time discrepancies between nodes. Then, the OpenStack base package is installed. Next, the Neutron component is installed and configured to provide network services to the compute node. Finally, the Nova component is installed and configured to provide compute services to the compute node while utilizing the Neutron network. Finally, the Cinder service is installed and configured to provide virtual disks for specific instances.

[0019] Furthermore, in step two, during the integration of OpenStack and Ceph, the Ceph software package is installed on the OpenStack control node and compute node, making the control node and compute node Ceph clients. After installing the Ceph software package, to implement the OpenStack and Ceph hyperconverged architecture, firstly, the Glance image service component of the OpenStack network testbed platform is configured to store the Image files in the OpenStack network testbed platform into the distributed file system Ceph object storage node OSD; then, virtual machines are booted or mounted through Volumes, based on the block storage Cinder service, to support the storage of volumes on the OpenStack network testbed platform into the distributed file system Ceph object storage node OSD, including the following steps:

[0020] Step 2.1: First, execute the command "ceph osd pool create [pool-name][pool-size]" to create the storage pool required for storing the files. After data addressing operations, write the objects to the distributed file system Ceph to achieve the storage purpose.

[0021] Step 2.2: Execute the command "ceph osd pool application enable[pool-name]rbd" to activate the authorization of each storage pool, so that the distributed file system Ceph cannot provide storage services for the network testbed platform OpenStack;

[0022] Step 2.3: When merging the distributed file system Ceph with the image service component Glance, the instance creation component Nova, and the block storage component Cinder, create keys for component users to grant access to the distributed file system Ceph storage pool; when Ceph and Cinder are integrated, change the original logical volume storage method to "ceph", and at this time, a new record will be added to the volume_type table in the database corresponding to the Cinder service component.

[0023] In step two, the Ceph distributed file system uses Straw-type buckets by default, selecting suitable items using a lottery-like approach. Specifically, each item is assigned a weight, and these weights are combined into a Straw array. During each item traversal, the Straw with the highest weight is selected first. From a macro perspective, items with higher weights have larger storage spaces and a higher probability of being selected, thus containing the most data. During each traversal, the system finds the largest draw value, which corresponds to the weight in the Straw array, and returns the corresponding item result.

[0024]

[0025]

[0026] draw=crush(x,r,item_id)*straw[i].

[0027] Furthermore, in step 2.1, the storage pool in Ceph is an abstract concept. To simplify the organization process during storage and reduce maintenance costs, each storage pool includes multiple Placement Groups (PGs). The addressing process in the Ceph distributed file system includes three mapping operations:

[0028] The first mapping involves striping the stored file into a set of small-granular objects, establishing a mapping relationship between file IDs and object IDs. Here, INO is the unique ID of the file, ONO is the sequence number of a specific object after stripping, and the OID formed by concatenating the two is the object ID. The formula for the mapping relationship between file IDs and object IDs is as follows:

[0029] (INO,ONO)→OID

[0030] The second mapping involves independently mapping each object to a placement group (PG). A static hash function maps the OID to an approximately uniformly distributed pseudo-random value, which is then bitwise ANDed with the mask to obtain the PGID. The mask value is the total number of placement groups (PG) minus 1. The mapping formula is as follows:

[0031] Hash(OID) & mask → PGID

[0032] The third mapping uses the CRUSH algorithm to map placement groups (PGs) to actual storage units (OSDs). In a production environment, a group of actual storage units (OSDs) consists of three objects, which jointly store and maintain all objects in a placement group (PG). The specific formula is as follows:

[0033] CRUSH(PGID)→(OSD.0,OSD.1,...,OSD.n).

[0034] Furthermore, in step three, the favorability rating represents the degree of preference of a storage object for the cluster. It is used to indicate the frequency of access to storage nodes by the storage object. Whenever a storage node receives a write request, the favorability rating of the storage object for that storage node is increased, reducing the likelihood of that storage node being allocated as a storage location, thus balancing the probability of all storage nodes in the cluster receiving write requests. If two accesses to a storage node occur within the same heartbeat cycle of the Ceph distributed file system, the second access will accelerate the increase in favorability, thereby reducing the probability of that storage node being accessed. If a storage node is not accessed during multiple object storage operations, the favorability rating of the storage node is decreased. Once the favorability rating of a storage node drops to zero, the storage node has a greater chance of being accessed in subsequent object storage processes.

[0035] Furthermore, in the CRUSH algorithm of the distributed file system Ceph, a preference variable is incorporated as a constraint to record and adjust the access frequency of storage nodes, as shown in the following formula:

[0036]

[0037]

[0038] In the formula: F new F represents the favorability value that a cluster node has before processing write operations from an external system. last This represents the affinity value possessed upon completing the write operation in the previous stage, serving as a description of the node's state; F now This represents the favorability value of the storage node during this write operation, e. up e represents the increase in favorability value. down t represents the decrease in favorability value. interval N represents the unit period, which is the same as the heartbeat detection interval. osd c represents the number of storage nodes in the cluster. io Indicates throughput, s obj This represents the object with the highest favorability value and the largest capacity.

[0039] Furthermore, the calculation of the favorability factor includes the following stages:

[0040] Phase 1: The favorability values ​​of the storage nodes in the cluster are set, typically initialized to 0. To control the favorability of nodes within a specified period, the internal clock and heartbeat monitoring intervals are unified. Simultaneously, it is stipulated that at the end of the previous period, the favorability value of the target storage node will be incremented by e. down The size gradually decreases;

[0041] Phase Two: When a user is in a network testbed and the storage method is the distributed file system Ceph, that is, under the condition of requesting a write operation on the target storage node, if F now =0, meaning it's the first write operation request or there hasn't been a write operation for a long time, then it follows the rule e. up Size can increase favorability;

[0042] Phase 3: When the target storage node is continuously requested for write operations, i.e., F now ≠0 and F last -F now When the value is 0, increase the size of the corresponding storage node;

[0043] Phase 4: Under the condition that the target storage node does not have too many write operation requests, i.e., F now ≠0 and F last -F now =0, reduce the size of the storage node.

[0044] Furthermore, step three includes the following steps:

[0045] Step 3.1: Split and encapsulate the request message;

[0046] Step 3.2: Obtain the cluster heartbeat detection through Monitor, obtain the storage location of data objects based on the data distribution map CRUSHMap information of the request node, and calculate the allocatable nodes by the cluster map Cluster Map. The cluster map includes the data distribution map CRUSH Map, the detection map, the object storage map OSD Map, and the storage pool placement group map PG Map.

[0047] Step 3.3: Configure the replica backup method, number of replicas, and bucket type;

[0048] Step 3.4: If the size of the current stored object meets the conditions for calling the favorability module, then calculate the favorability factor; otherwise, use the default strategy of the CRUSH algorithm to allocate storage locations.

[0049] Step 3.5: Based on the object identifier (OID) of the stored object and the bucket number, generate pseudo-random numbers using the JenkinsHash algorithm. Finally, select the final object storage OSD node based on the weight and favorability factor, and store the data on the corresponding node.

[0050] A network range platform includes a control node, a computing node, a network node, and a storage node, constructed according to a network range platform construction method. The control node is used to manage and control the other nodes; the computing node is used for communication between the platform and internal and external networks; the network node is used to control the entire lifecycle of virtual machines from creation to destruction; and the storage node is used to store the additional resources of the virtual machines.

[0051] A network range platform for DDoS attack mitigation, which utilizes the aforementioned network range platform for DDoS attack detection and mitigation.

[0052] The advantages and beneficial effects of this invention are as follows:

[0053] This invention, based on OpenStack and Ceph technologies and grounded in research on virtualization, proposes a hyperconverged network range platform design. It replaces the native OpenStack storage system with Ceph distributed storage technology, resolving issues such as maintenance difficulties and susceptibility to single points of failure. Furthermore, addressing the uneven data distribution across OSDs in Ceph cluster storage, it proposes a data storage optimization algorithm based on affinity, improving the data balance across all OSD nodes in the cluster, thereby enhancing the storage performance and operational stability of the network range. Simultaneously, leveraging the programmability of software-defined networks, it proposes a DDoS attack detection and mitigation method, providing a fundamental approach for analyzing cybersecurity behaviors. Attached Figure Description

[0054] Figure 1 This is a flowchart of the method of the present invention.

[0055] Figure 2 This is a schematic diagram of the platform structure of the present invention.

[0056] Figure 3 This is an architecture diagram of the DDoS attack detection and mitigation method in this embodiment of the invention.

[0057] Figure 4 This is a virtual network topology diagram in this embodiment of the invention.

[0058] Figure 5 This is a pie chart showing the flow rate percentage in an embodiment of the present invention.

[0059] Figure 6 This is a structural diagram of the attack detection model in an embodiment of the present invention.

[0060] Figure 7 This is a structural diagram of a stacked sparse autoencoder in an embodiment of the present invention.

[0061] Figure 8This is a network topology diagram created in an embodiment of the present invention.

[0062] Figure 9 This is a topology diagram of a DDoS attack instance in an embodiment of the present invention.

[0063] Figure 10 This is a benign flow detection diagram in an embodiment of the present invention.

[0064] Figure 11 This is a statistical chart showing the number of data packets from h1 to eth0 during normal communication between h3 and h1 in an embodiment of the present invention.

[0065] Figure 12 This is a statistical chart showing the number of data packets from h1 to eth0 during normal communication between multiple devices and h1 in this embodiment of the invention.

[0066] Figure 13 This is a schematic diagram of Wireshark capturing data packets on port h1-eth0 during SYN-Flood in an embodiment of the present invention.

[0067] Figure 14 This is a schematic diagram illustrating an abnormal communication between h6 and h1 in an embodiment of the present invention.

[0068] Figure 15 This is a statistical chart showing the number of h1-eth0 data packets during the SYN-Flood event in this embodiment of the invention.

[0069] Figure 16 This is a statistical chart showing the number of h1-eth0 packets after implementing the mitigation method in this embodiment of the invention.

[0070] Figure 17 This is a schematic diagram illustrating h1 restoring normal communication with other devices in an embodiment of the present invention. Detailed Implementation

[0071] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0072] A scalable, easy-to-operate network range platform for researching DDoS attack mitigation methods is proposed. Based on OpenStack, the platform replaces the native OpenStack storage system with Ceph distributed storage technology. A hyperconverged network range design scheme based on OpenStack and Ceph is proposed, and a data storage optimization algorithm based on favorability is used to constrain the storage location of data by favorability factor, thereby improving the balance of data storage across all OSD nodes in the cluster.

[0073] like Figure 1 As shown, the steps for building a network test range platform are as follows:

[0074] Step 1: Utilize the key technologies designed for the OpenStack network range platform and deploy it manually, adjusting node planning according to requirements. This process also promotes users' overall understanding and mastery of the OpenStack cloud platform, and sets up the control and compute nodes of the network range.

[0075] The specific steps for designing a network range platform using OpenStack are as follows:

[0076] Step 1.1: Deploy the OpenStack core technologies manually.

[0077] Step 1.2: Design the control node and install it on the control node using the Neutron service to integrate the functions of the network node onto the control node.

[0078] Step 1.3: Design the computing node, install the Cinder service component on the computing node, and integrate the storage node on the computing node.

[0079] In this embodiment of the invention, OpenStack is first used as the core technology to build a network testbed. After authentication via the Keystone service, users are authorized to access the cloud platform and perform specific operations using the Dashboard's web page. The core steps can be divided into creating virtual machines, allocating IP addresses, mounting and using the machines, and monitoring. In the virtual machine creation step, the Nova and Glance services are mainly used. Nova is responsible for creating instances, while Glance provides the image and stores it in Swift. In the IP address allocation step, the Neutron service is responsible for providing the new virtual machine obtained in the previous steps with an address belonging to the virtual network. It is also responsible for managing communication between the private and public networks, communication between virtual machines, firewall functions, etc. In the mounting and using step, Cinder's block storage function is mainly used to generate volumes, utilizing Swift to store the volumes.

[0080] like Figure 2 As shown, OpenStack has four types of nodes at the physical hardware layer: control nodes, compute nodes, network nodes, and storage nodes, corresponding to the four servers or virtual machines deployed in an OpenStack environment. The control node acts as the "administrator," managing resource scheduling, allocation, and network partitioning for the other nodes; the network node acts as the "communicator," responsible for communication between the platform and the network; the compute node controls the entire lifecycle of the virtual machine from creation to destruction; and the storage node is responsible for storing the additional resources of the virtual machine.

[0081] The control node primarily provides three types of services: management support services that provide underlying services for the installation of components such as databases and message queues; basic management services related to user management and control of Keystone, Glance, Nova, and Dashboard; and extended management services for the installation of optional components such as Cinder. The network node only provides network services. The Neutron component manages communication between private and public network segments, communication between virtual networks, firewalls, etc., and communication with other nodes is achieved by configuring two or more ports. When network node functionality is integrated into the control node, the Neutron service needs to be installed on the control node, and the related service is the basic management service. You can view the currently deployed OpenStack service components by executing the command "openstack catalog list" in the control node terminal.

[0082] Compute nodes primarily provide three types of services: computing, networking, and monitoring. Compute and networking services are fundamental and essential for the implementation of compute nodes. If storage nodes are integrated onto compute nodes, the Cinder service component needs to be installed on the compute nodes. Typically, storage nodes can perform block storage and object storage. Block storage is essentially a virtual disk mounted on the corresponding virtual machine, unaffected by the file system. It is generally used to expand virtual machine space when it is insufficient, and this is the storage method chosen in this invention.

[0083] The first step in deploying a compute node is to clone the template machine, modify the hostname of the cloned virtual machine, and perform relevant network configurations. The second step is to install chrony, which acts as an NTP client for the compute node, keeping its time synchronized with the control node to prevent malfunctions caused by time discrepancies between nodes. The third step is to install the OpenStack base package; if the installed base package version is incompatible with the OpenStack version used, the installation will fail and affect the deployment of subsequent service components. The fourth step is to install and configure the Neutron component to provide network services to the compute node. The fifth step is to install and configure the Nova component to provide compute services to the compute node while using the Neutron network. Finally, the Cinder service is installed and configured to provide virtual disks for the specific instance.

[0084] Step 2: First, load KVM using the Linux kernel. Use KVM to schedule and manage virtual machine vCPUs and virtual memory. Then, interact with virtual external devices through QEMU. QEMU and Linux kernel version 2.6.37 and above provide support for RBD. At the same time, use Libvirt to manage RBD. On the OpenStack cloud platform where KVM / QEMU technology provides virtualization services, Ceph RBD is used.

[0085] The specific steps for using Ceph to provide compute and storage management capabilities for the platform are as follows:

[0086] Step 2.1: First, execute the command "ceph osd pool create [pool-name][pool-size]" to create the storage pool required for storing files. After data addressing operations, write the objects to Ceph to achieve the storage purpose.

[0087] Step 2.2: Execute the command "ceph osd pool application enable[pool-name]rbd" to enable the authorization of each storage pool, so that Ceph cannot provide storage services for OpenStack.

[0088] Step 2.3: When integrating Ceph with Glance, Nova, and Cinder, create keys for component users to grant them access to Ceph storage pools.

[0089] In this embodiment of the invention, Ceph defaults to using a Straw type Bucket and selects suitable items using a lottery-like approach. Specifically, according to its rules, each item corresponds to a weight, and these weights are combined to form a Straw array. During each item traversal, the Straw with the highest weight is selected first. From a macro perspective, items with higher weights have larger storage spaces and a higher probability of being selected than other items, thus containing the most data. During each traversal, the largest draw value, i.e., the weight corresponding to the Straw array, is found, and the corresponding item result is returned.

[0090]

[0091]

[0092] draw=crush(x,r,item_id)*straw[i]

[0093] Integrating Ceph into OpenStack as a backend storage device involves three service components: Nova, Glance, and Cinder. When merging OpenStack and Ceph, the Glance component needs to be configured to store OpenStack images in Ceph OSDs. Meanwhile, Volumes, used to boot virtual machines or mount them to currently running virtual machines, leverage the Cinder service to support the storage of OpenStack volumes in Ceph OSDs. Disks are stored using Nova's RBD driver, and both Images and Volumes provide services to Nova.

[0094] Install the Ceph package on the OpenStack control and compute nodes, making the control and compute nodes Ceph clients.

[0095] After installing the Ceph package, the specific process of implementing the OpenStack and Ceph hyperconverged architecture is as follows:

[0096] First, the command "ceph osd pool create [pool-name][pool-size]" must be executed to create the storage pool required for storing the files. After data addressing operations, the objects are written to Ceph to achieve the storage purpose. However, a storage pool is an abstract concept in Ceph. To simplify the organization process during storage and reduce maintenance costs, each storage pool consists of multiple Placement Groups (PGs). The addressing process in Ceph is implemented through three mapping operations. The first step is to stripe the stored file into many smaller, uniformly sized objects, establishing a mapping relationship between file IDs and object IDs. Here, INO is the unique ID of the file, and ONO is the sequence number of a specific object after stripping. The two are concatenated to form the OID. The formula for the mapping relationship between file IDs and object IDs is as follows:

[0097] (INO,ONO)→OID

[0098] The second step involves independently mapping each object to a PG (Program Group). This mapping is done using a static hash function to convert the objects into approximately uniformly distributed pseudo-random values, which are then ANDed using a bitwise AND operation. The value of is the total number of PGs minus 1. The mapping formula is as follows:

[0099] Hash(OID) & mask → PGID

[0100] The third method uses the CRUSH algorithm to map a PG to an actual storage unit OSD. In a production environment, there are three OSDs in a group, which jointly store and maintain all objects in a PG

[60] . The specific formula is as follows:

[0101] CRUSH(PGID)→(OSD.0,OSD.1,...,OSD.n)

[0102] After the convergence configuration is complete, execute the command "ceph osd pool application enable[pool-name]rbd" to enable the authorization of each storage pool.

[0103] Secondly, when integrating Ceph with Glance, Nova, and Cinder, keys are created for component users to grant them access to the Ceph storage pool. When Ceph is integrated with Cinder, the original logical volume storage method is changed to "ceph," at which point a new record is added to the volume_type table in the database corresponding to the Cinder service component.

[0104] Step 3: Read the configuration file to obtain the partitioning of storage file size. Based on the configuration information, determine whether to add a favorability factor during the algorithm initialization phase. Adjust the favorability value of cluster nodes by obtaining the heartbeat cycle detected by Ceph, and adjust the distribution of data in the cluster.

[0105] The specific steps for using the favorability-based storage optimization algorithm are as follows:

[0106] Step 3.1: First, the request message needs to be split and encapsulated.

[0107] Step 3.2: Obtain the cluster heartbeat detection through Monitor, obtain the storage location of the data object based on the CRUSH Map information of the requesting node, and calculate the allocatable nodes using Cluster Map.

[0108] Step 3.3: Set the replica backup method, number, and Bucket type.

[0109] Step 3.4: If the size of the current stored object meets the conditions for calling the favorability module, then the favorability factor needs to be calculated; otherwise, the CRUSH algorithm default strategy is used to allocate storage locations.

[0110] Step 3.5: Based on the OID of the stored object and the Bucket number, generate pseudo-random numbers using the Jenkins Hash algorithm, and finally select the final OSD node based on the weight and favorability factor, and store the data on the corresponding node.

[0111] In this embodiment of the invention, the CRUSH algorithm is built into the Ceph distributed storage system. During data storage optimization, the configuration file is read to obtain the allocation of storage file sizes, and this configuration information determines whether a preference factor needs to be added during the algorithm's initialization phase. Preference represents the degree of preference a storage object has for the cluster, indicating the frequency of access to storage nodes. Whenever a node receives a write request, the preference of the storage object for that node is increased, reducing the likelihood of that node being allocated as a storage location, thus balancing the probability of all nodes in the cluster receiving write requests. If two accesses to a node occur within the same Ceph heartbeat cycle, the second access will accelerate the increase in preference, thereby reducing the probability of that node being accessed. If a node is not accessed during multiple object storage operations, its preference is decreased. Once a node's preference drops to zero, the node has a greater chance of being accessed in subsequent object storage processes. The preference variable is incorporated into Ceph's CRUSH algorithm as a constraint to record and adjust the access frequency of storage nodes, as shown in the following formula:

[0112]

[0113]

[0114] In the formula: F represents the favorability value that cluster nodes have before processing write operations from external systems. new This indicates that the favorability value obtained when completing the write operation in the previous stage is expressed as F. last This represents a description of the node's state. During this write operation, the node's favorability value is expressed as F. now This indicates the increase in favorability value, e. up To indicate the degree to which favorability rating decreases, express an e-value. down This indicates that the unit period is expressed in t. interval This indicates that the value is the same as the heartbeat detection interval. The number of storage nodes in the cluster is in N... osd This indicates that throughput is expressed in terms of c. io This indicates that the object with the highest favorability value and the largest capacity is represented by s. obj express.

[0115] The calculation method for the favorability factor will be described in the following four stages:

[0116] Phase 1: Assign favorability values ​​to the nodes in the cluster, typically initializing them to 0. To control the favorability of nodes within a specified period, the internal clock and heartbeat monitoring interval are unified. Simultaneously, it is stipulated that at the end of the previous period, the favorability value of the target node will be incremented by e. down The size gradually decreases.

[0117] Phase Two: When a user selects "ceph" as the storage type in the network testbed, i.e., requests a write operation on the target node, if F now =0, meaning it's the first write operation request or there hasn't been a write operation for a long time, then it follows the rule e. up The size of the object increases its favorability.

[0118] Phase 3: When the target node is continuously requested for write operations, i.e., F now ≠0 and F last -F now When the value is 0, the size of the corresponding node will be increased.

[0119] Phase 4: Under the condition that the target node does not have too many write operation requests, i.e., F now ≠0 and F last -F now If the value is 0, the size of the corresponding node will be reduced.

[0120] In addition, the favorability values ​​of cluster nodes need to be adjusted by obtaining the heartbeat cycle detected by Ceph. Therefore, organizing the optimization algorithm in the form of modules and dynamically loading it according to actual needs can ensure the isolation between technology and business.

[0121] The favorability-based data storage optimization algorithm mainly consists of a favorability module and a computation module. The favorability module runs on Ceph's RADOS, and the Paxos algorithm maintains consistency during message passing. The computation module determines whether to call the favorability module and add a favorability factor based on the configuration file, thereby adjusting the distribution of data in the cluster.

[0122] When a client sends a request, the request message is first split and encapsulated. Next, the heartbeat detection of the cluster is obtained through the Monitor, and the storage location of the data object is determined based on the CRUSH Map information of the requesting node. The ClusterMap then calculates the allocatable nodes. Next, the replica backup method, number, and Bucket type are set. If the current size of the stored object meets the conditions for calling the affinity module, an affinity factor is calculated; otherwise, the default CRUSH algorithm strategy is used to allocate storage locations. Subsequently, based on the OID of the stored object and the Bucket number, a pseudo-random number is generated using the Jenkins Hash algorithm. Finally, the final OSD node is selected based on the weight and affinity factor, and the data is stored on the corresponding node.

[0123] Example 1:

[0124] The DDoS attack detection and mitigation method was verified using a hardware platform configured with an Intel(R) Core(TM) i5-1032G 1 CPU@1.00GHz processor and 16GB RAM, and VMware Workstation 16PRO virtualization software installed on the Windows 10 operating system.

[0125] 1. Simulation and Analysis of DDoS Flood Attacks

[0126] The DDoS flood attack was simulated using a network range platform. DDoS attack traffic was generated using the hping3 tool. Intrusion detection rules were set by writing the / etc / snort / rules / local.rules file under Snort.

[0127] This is the equipment used for simulating DDoS attacks. When the attacking machine sends an attack to the target machine, the target machine successfully detects the intrusion and alerts the user via its terminal. To reduce the hardware requirements of the network range, this invention, in its research on DDoS flood attack detection and mitigation methods, migrates the network topology and DDoS flood attack behavior from the aforementioned network range platform to a software-defined network.

[0128] 2. DDoS Attack Detection and Mitigation Architecture

[0129] This invention designs a DDoS attack detection and mitigation method that uses SDN to simulate the working process of actual terminal devices and switches, collecting benign and malicious traffic generated during the simulation. This data is then combined with an attack detection model to learn traffic characteristics. The trained model is applied to the detection of DDoS attack behavior, and the programmability of the SDN controller is used to design a mitigation method to address DDoS attacks. The DDoS attack detection and mitigation method is as follows: Figure 3 As shown, the DDoS attack detection and mitigation architecture can be divided into five modules: traffic generation module, feature extraction module, information collection module, attack detection module, and attack mitigation module. The virtual network topology is as follows: Figure 4 As shown, ensure that the virtual network topology is consistent with the actual network testbed topology. Twenty-one features are selected from the switch flow tables and used as the basis for traffic behavior analysis in normal network communication and DDoS flood attack scenarios. An additional "label" feature field is added to distinguish between benign and malicious traffic. The final statistical results are as follows: Figure 5 As shown.

[0130] 3. Analysis of Machine Learning Attack Detection Models

[0131] DDoS attack detection is a binary classification problem, and machine learning algorithms can be used to effectively detect traffic types. In an SDN environment, machine learning code is typically installed and run, dividing the entire dataset into training and test sets in a 7:3 or 8:2 ratio. The training set continuously learns from the characteristics of the data, analyzes the inherent relationships between data points, and summarizes learning experiences. The test set is then used for evaluation, employing scientific metrics such as precision (Equation 1), recall (Equation 2), and the balanced F-score (Equation 3) to assess the learning effectiveness of the machine learning model. Parameter adjustments or algorithm optimizations are then used to improve the model's learning ability on the current dataset.

[0132]

[0133]

[0134]

[0135] 4. Mitigation methods for DDoS attacks targeting imbalanced data

[0136] To effectively combat DDoS attacks in complex network environments, this invention proposes an attack detection model, SSAE-EL, which combines Stacked Sparse Autoencoders (SSAEs) with Ensemble Learning (EL). The model structure is as follows: Figure 6 As shown, the attack detection process consists of three stages: data undersampling, feature extraction, and ensemble learning. The data undersampling and ensemble learning stages focus on malicious traffic to enhance its detection capabilities. The feature extraction stage reduces the dimensionality of the original traffic features to obtain semantically rich information, which is then used as an abstract table of the original network traffic information. Feature extraction utilizes a stacked sparse autoencoder, an unsupervised learning model based on a neural network structure. The stacked sparse autoencoder structure is shown below. Figure 7 As shown, ensemble learning trains several weak classifiers by inputting the same dataset in batches, exchanging high learning costs for diverse feature information. The classification results of each weak classifier are then aggregated to compensate for the errors caused by those weak classifiers that misclassify the data.

[0137] 5. Validation of DDoS attack detection and mitigation methods

[0138] First, start the remote Ryu controller using the command "ryu-manager mitigation-controller.py". The Ryu controller will automatically load the trained SSAE-EL model to detect DDoS attacks in the current network in real time, and simultaneously start the OFPHandler application to send, receive, and parse OpenFlow message data. Create the network topology as follows: Figure 8 As shown, a network topology containing 6 switches and 18 terminal devices is established in the Mininet virtual machine. The DDoS attack instance topology is as follows. Figure 9 As shown.

[0139] The HTTP server identity is verified by executing the command "python -m SimpleHTTPServer 80&", and benign traffic detection is performed as follows. Figure 10 As shown, the number of h1-eth0 data packets during normal communication between the two terminal devices is as follows: Figure 11 As shown. Figure 12 The data shows that all devices in the current network are communicating normally.

[0140] Source: Wireshark capture of data packets on ports h1-eth0 during SYN-Flood, such as Figure 13 As shown in the figure, the address column displays fake IP addresses and does not reveal any H.18 information. During DDoS flood attack detection, once the attack detection module detects malicious traffic in the network, it will indicate the presence of a DDoS attack, specifying the type of DDoS flood attack and identifying the victim device name or IP address. The detection results of the attack detection module when a SYN-Flood occurs during normal network communication are shown below. Figure 14 As shown.

[0141] like Figure 15 As shown, when h1 is in normal network communication, the number of data packets passing through the switch per second is strictly less than 50. However, when h1 is subjected to a SYN-Flood attack, the number of data packets on the h1-eth0 interface increases sharply, and the image used to observe the number of network data packets suddenly increases, with the number of data packets per unit time approaching 250, which is significantly different from the normal communication.

[0142] To reduce resource consumption caused by DDoS attacks in the current network environment, the attack detection module automatically calls the attack mitigation module to achieve mitigation after detecting malicious traffic. For example... Figure 16 The study demonstrates that after implementing the mitigation method, the number of packets entering the h1-eth0 interface was significantly reduced.

[0143] When evaluating the effectiveness of DDoS mitigation methods using the blocking rate formula shown below, the numerator represents the difference between the malicious traffic packet rate during a DDoS flood attack and the benign traffic packet rate after the mitigation method is implemented, and the denominator is the malicious traffic packet rate. The effectiveness of the automatic DDoS flood attack mitigation method is evaluated by calculating the packet blocking rate. Where, time... m' -time m This indicates the time taken from the start of a malicious attack to its mitigation. Indicates the total number of malicious data packets, time b' -time b This represents the normal communication duration equal to the duration of a malicious traffic attack after the mitigation method has been applied. This represents the total number of benign data packets. Calculations show that the DDoS attack mitigation method achieved a 99.55% blocking effect on the number of data packets within the 153-184 second time period, demonstrating the effectiveness of the DDoS mitigation method proposed in this invention.

[0144]

[0145] like Figure 17 As shown, after applying the mitigation method, the data packets sent from the attacking machine to the target machine were blocked, so other devices were able to communicate normally with the target machine. The data packets captured by Wireshark on the switch port where the target device h1 is located showed that it had returned to normal.

[0146] 6. Comparison of OpenStack+Ceph with other related methods in DDoS attack detection and mitigation.

[0147] Table 1 compares this invention with related works from five perspectives: dataset selection, feature selection, DDoS attack types, evaluation metrics, and performance. This invention, like other related works, uses a self-built dataset, without replacing SDN environment data with traditional traffic datasets. Regarding feature selection, SSAE-SVM uses 19 features as the basis for DDoS flood attack detection, while this invention is more comprehensive, employing 21 switch flow table features. Except for KNN, this invention detects the same DDoS attack types as related works. However, in comparing detection performance, SVC-RF and SSAE-SVM use Accuracy as the evaluation metric, resulting in a somewhat limited reference value. The literature DDAML, KNN, and this invention all use F1-Score as the evaluation metric, providing a more comprehensive assessment of detection performance. Although the literature DDAML performs well in DDoS attack detection, it only considers four features, which cannot meet the detection needs in complex network environments. Both SSAE-SVM and this invention use SSAE as part of the DDoS traffic detection model, but this invention selects more comprehensive features, which can not only detect more types of DDoS attacks, but also achieve better detection results.

[0148] Table 1 Comparison of the detection method of this invention with related work.

[0149]

[0150] Table 1 compares this invention with related works from the perspective of DDoS attack mitigation methods. First, this invention implements mitigation methods automatically; it executes automatically once a DDoS attack is detected in the network. Unlike methods that extract the attacker's IP and apply rules to switches to block packets, the method proposed in this invention requires no additional manual operation. Second, the method proposed in this invention does not require time to trace the attacker's IP; it utilizes the programmability of SDN to add flow tables and block the switch ports where the attacked device resides, making this method more efficient. Furthermore, unlike methods that add flow tables without providing a verification process for the mitigation method, or extract the attacker's IP and perform a "drop" operation that only provides a table showing the packet blocking rate of the mitigation method, this invention clearly provides evaluation indicators for calculating the application effect of the mitigation method and their calculation methods, providing a scientific basis for evaluating the method proposed in this invention. Overall, the mitigation method proposed in this invention is more effective than other related works and has certain value for practical applications.

[0151] Table 2 Comparison of the mitigation method of the present invention with related work

[0152]

[0153]

[0154] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for constructing a network target range platform, characterized in that... Includes the following steps: Step 1: Based on the network range platform, set up control nodes and computing nodes; Step 2: Build a virtual environment and control the storage of the distributed file system through virtualization management tools; Step 3: The distributed file system uses a preference factor to constrain the storage location of data. First, the partitioning of storage file size is obtained through the configuration file. Then, based on the configuration information, it is determined whether a preference factor needs to be added during the initialization phase. By obtaining the heartbeat cycle detected by the distributed file system, the preference value of the cluster storage nodes is adjusted, thereby adjusting the distribution of data in the cluster storage. The favorability rating represents the degree of preference of a storage object for the cluster. It is used to indicate the frequency of access to storage nodes by the storage object. Whenever a storage node is requested to write, the favorability rating of the storage object to that storage node is increased, reducing the possibility that the storage node will be allocated as a storage location, thus balancing the probability of all storage nodes in the cluster receiving write requests. If two accesses to a storage node occur within the same heartbeat cycle of the distributed file system, the second access will accelerate the increase in favorability, thereby reducing the probability of that storage node being accessed. If a storage node is not accessed during multiple object storage operations, its favorability is reduced. Once a storage node's favorability drops to zero, that storage node has a greater chance of being accessed in subsequent object storage processes.

2. The method for constructing a network range platform according to claim 1, characterized in that: Step one includes the following steps: Step 1.1: Deploy the network range platform; Step 1.2: Design the control node, integrating the functions of the network nodes onto the control node to provide management support services for the underlying services, outgoing management services, and extended management services; Step 1.3: Design computing nodes, integrating storage nodes onto computing nodes to provide computing, networking, and monitoring services for the network range.

3. The method for constructing a network range platform according to claim 2, characterized in that: In step two, the image service component of the network range platform is first configured, and the image files in the network range platform are stored in the object storage node of the distributed file system. Then, the virtual machine is booted or mounted via volume bootstrap, providing support for storing volumes on the network range platform into the object storage node of the distributed file system, based on block storage services, including the following steps: Step 2.1: Create the storage pool required for storing the files, and write the objects to the distributed file system through data addressing operations; Step 2.2: Activate the authorization for each storage pool to prevent the distributed file system from providing storage services to the network test range platform; Step 2.3: When merging the distributed file system with the image service component, instance creation component, and block storage component, create keys for component users to grant access to the distributed file system storage pool.

4. The method for constructing a network range platform according to claim 3, characterized in that: In step 2.1, each storage pool includes multiple placement groups; the addressing process in the distributed file system includes three mapping operations: The first mapping involves striping the stored file into a set of small-granular objects, establishing a mapping relationship between file IDs and object IDs. Here, INO is the unique ID of the file, ONO is the sequence number of a specific object after stripping, and the OID formed by concatenating the two is the object ID. The formula for the mapping relationship between file IDs and object IDs is as follows: The second mapping involves independently mapping each object to a placement group. A static hash function maps the OID to an approximately uniformly distributed pseudo-random value, which is then bitwise ANDed with the mask to obtain the PGID. The mask value is the total number of placement groups minus 1. The mapping formula is as follows: The third mapping uses the CRUSH algorithm to map placement groups to actual storage units. A group of actual storage units jointly stores and maintains all objects in a placement group. The specific formula is as follows: 。 5. The method for constructing a network range platform according to claim 1, characterized in that: In the algorithm of the distributed file system, a preference variable is incorporated as a constraint to record and adjust the access frequency of storage nodes, as shown in the following formula: In the formula: This represents the favorability value that cluster nodes have before processing write operations from external systems. This represents the affinity value possessed when the write operation was completed in the previous stage, serving as a description of the node's state. This indicates the favorability value of the storage node during this write operation. This indicates the increase in favorability rating. This indicates the degree of decrease in favorability rating. This represents the unit period, and this value is the same as the heartbeat detection interval. Indicates the number of storage nodes in the cluster. Indicates throughput. This represents the object with the highest favorability value and the largest capacity.

6. The method for constructing a network range platform according to claim 5, characterized in that: The calculation of the favorability factor includes the following stages: Phase 1: Set favorability values ​​for the storage nodes in the cluster, unify the internal clock and heartbeat monitoring intervals, and stipulate that at the end of the previous cycle, the favorability value corresponding to the target storage node will be set as follows. The size gradually decreases; Phase Two: When the storage method in the network test range is a distributed file system, i.e., under the condition of requesting write operations on the target storage node, if That is, whether it is the first write operation request or there has been no write operation for a long period of time, then according to Size can increase favorability; The third stage: when the target storage node is continuously requested for write operations, i.e. and When necessary, increase the size of the corresponding storage node; Phase 4: Under the condition that the target storage node does not have too many write operation requests, i.e. and Reduce the size of the storage node.

7. The method for constructing a network range platform according to claim 1, characterized in that: Step three includes the following steps: Step 3.1: Split and encapsulate the request message; Step 3.2: By obtaining the heartbeat detection of the cluster, the storage location of the data object is obtained according to the data distribution map information of the request node. The allocatable nodes are calculated by the clustering graph, which includes the data distribution map, detection map, object storage map, and storage pool placement group map. Step 3.3: Set the backup method, quantity, and bucket type; Step 3.4: If the size of the current stored object meets the conditions for calling the favorability module, then calculate the favorability factor; otherwise, use the default strategy to allocate storage locations. Step 3.5: Generate pseudo-random numbers based on the object identifier and bucket number of the stored object. Finally, select the final object storage node based on the weight and favorability factor, and store the data on the corresponding node.

8. A network range platform, comprising a control node, a computing node, a network node, and a storage node, characterized in that: The network range platform is constructed according to any one of claims 1 to 7, wherein the control node is used to manage and control the other nodes; and the computing node is used for communication between the platform and the network inside and outside the platform. The network node is used to control the entire lifecycle of a virtual machine from creation to destruction; The storage node is used to store additional resources for the virtual machine.

9. A network range platform for DDoS attack mitigation, characterized in that: The network range platform described in claim 8 is used for DDoS attack detection and mitigation.

Images