A blockchain-based lfa dynamic mitigation method

Abstract

The application designs a LFA dynamic mitigation method based on a block chain, relates to the technical field of flooding link attack mitigation, and first proposes an LFA inter-domain cooperation mitigation architecture; the mitigation architecture is from bottom to top, and respectively is a parameter calculation layer, a data integration layer and a data storage layer; the traffic arriving at the firewall is monitored in time, behavior exploration and discarding are carried out, then the domain controller in the data integration layer applies the mitigation parameter corresponding to the network state to the data storage layer, if not, the mitigation parameter calculated by the calculation node is directly used, the corresponding parameter is used on the corresponding firewall, the domain controller integrates the mitigation parameter and the reputation value in the domain, finally, the effective data is stored and shared through the data storage layer, and the parameter calculation amount is reduced.

Description

Technical Field

[0001] This invention relates to the field of flooding link attack mitigation technology, and in particular to a blockchain-based LFA dynamic mitigation method. Background Technology

[0002] With the increasing number of IoT devices and network infrastructure, attackers are now shifting from traditional Distributed Denial-of-Service (DDoS) attacks to sophisticated DDoS attacks, which in turn target critical internet infrastructure. DDoS attacks generate massive amounts of attack traffic by forming large-scale botnets, overloading attacked servers and network links, exhausting system resources, and preventing them from responding to normal service requests. Once attackers have established an attack network, they can launch coordinated large-scale attacks against one or more targets.

[0003] DDoS attacks specifically targeting network backbone links are known as link flooding attacks (LFA). Attackers control bots to direct low-intensity traffic to a large number of publicly accessible servers. This traffic is concentrated on a small number of backbone links, causing them to become congested without directly contacting the target. By actively switching links multiple times, attackers can disconnect servers in the target area from the Internet for extended periods. The result of link congestion is no different from ordinary network congestion, and the congested links and the disconnected areas may not even be in the same autonomous system. Therefore, identifying the ultimate target and source of the attack flow is more difficult and time-consuming. Thus, there is an urgent need for a new mitigation method that can adapt to constantly changing rolling attacks and achieve adaptive, long-term cross-domain mitigation of link flooding attacks. This places higher demands on the speed and cost of adaptive adjustments in mitigation methods. Due to the adversarial and strategic nature of the attack and defense processes, many researchers have used game theory to model LFA. In 2016, Wang Yichuan et al. proposed a dynamic game theory defense method against DDoS attacks to achieve variable attack and defense decisions. They argued that the behavioral history of game participants is a significant influencing factor in the dynamic process and shifted the focus of game interests from the endgame to the present. In 2020, Chen et al. proposed a Bayesian game theory protection method based on LFA under incomplete information, utilizing the Stackelberg security game model to select specific links for protection.

[0004] Currently, mitigation methods for link flooding attacks mainly fall into the following two categories:

[0005] (1) Mitigation techniques based on routing mechanisms reduce the pressure on congested links by changing or adding routing paths or migrating traffic. Examples include ISP dynamic load balancing and congested ASs gradually initiating reconstruction requests to the source AS. These techniques can achieve good mitigation results in a short time without losing normal traffic sent by legitimate users. In 2018, Jared M. Smith proposed using Autonomous Systems (ASes) to handle route advertisements in the existing Border Gateway Protocol (BGP), enabling AS deployment to isolate traffic from critical upstream ASs from attacked links and backup, non-congested paths. However, due to high costs and the problem of frequent traffic clearing causing BGP route oscillations that could paralyze the entire Internet, this approach is not suitable for mitigating rolling flood link attacks.

[0006] Routing-based mitigation alleviates congestion on links by changing or adding routing paths or migrating traffic. However, its characteristics are not suitable for rolling flooding attacks (LFA). Firstly, routing-based traffic migration requires redirecting traffic to other autonomous systems (ASs) for mitigation. In multi-level network structures, other ISPs will not adjust routes for congested ASs for free, resulting in significant costs. Furthermore, inter-domain cooperation requires further research. Secondly, because LFA selects multiple links for rolling attacks and actively changes the target links within three minutes, it is difficult to achieve long-term defense by changing or adding links. In fact, frequent traffic clearing can cause BGP routing oscillations, paralyzing the entire internet, making it unsuitable for mitigating rolling flooding attacks.

[0007] (2) Firewall-based mitigation techniques reduce link load and alleviate resource bottlenecks by managing bandwidth, cutting off abnormal sessions, or dropping excessive packets. Since LFA attackers actively switch links within three minutes to launch rolling attacks, the timeliness of mitigation parameters becomes increasingly important, requiring computationally lightweight and fast parameters. Therefore, to balance computational speed and parameter applicability, researchers often use game theory methods for parameter selection or calculation. T. Spyridopoulos et al. used a single-round non-cooperative zero-sum game to automatically calculate traffic thresholds in firewalls; Guanhua Yan et al. used incomplete information non-cooperative dynamic games to calculate session number thresholds, session speed upper and lower limits, etc., under firewall mechanisms.

[0008] Firewall-based mitigation methods alleviate resource bottlenecks through session management, bandwidth management, and IP packet limiting. Firewalls, as a widely deployed defense method, offer significant cost reduction through direct improvements. Furthermore, their deployment at network boundaries, directly interacting with attack traffic, makes them well-suited for mitigating flood attacks on network links. However, LFA attackers control bots to send normal traffic, unlike the explosive traffic of traditional DDoS attacks. This traffic gradually increases until it congests the target link, making it highly stealthy and difficult for ISPs to detect and accurately extract attack characteristics. Both normal and attack flows are indiscriminately restricted; moreover, mitigation parameters are manually set empirical values ​​and cannot be dynamically adjusted based on the attack status. Therefore, choosing the appropriate time, reasonable strategy, and suitable parameters to reduce the indirect damage caused by firewalls becomes a critical issue.

[0009] As scholars from various countries have studied methods to mitigate link flooding attacks, firewall-based link flooding attack mitigation methods have been widely used due to their direct contact with attack traffic. Since the botnets controlled by LFA attackers send legitimate and normal traffic to the decoy servers, it is difficult to distinguish them through a single flow. In order to achieve the goal of congesting the same area for a long time, attackers will actively switch links and roll attacks. At the same time, in order to reduce the cost of the attack, the botnets controlled by attackers will be used multiple times. Router firewalls are stateful firewalls, so multi-wall linkage will accelerate the exposure of bot nodes. However, current firewall-based link flooding attack mitigation methods still have the following problems: 1) Lack of incentive mechanisms, making it difficult to achieve linkage defense between different autonomous systems; 2) Firewall mitigation parameters are manually set empirical values, making it difficult to adaptively adjust mitigation parameters according to the link attack status. Summary of the Invention

[0010] To address the difficulty of cross-domain collaborative mitigation of Low-Level Attacks (LFAs), existing mitigation mechanisms cannot utilize multi-autonomous domain (Autonomous Domain) link information for LFA mitigation. This invention designs a blockchain-based dynamic LFA mitigation method. Through in-depth analysis of the characteristics of LFA rolling attacks, an inter-domain collaborative mitigation architecture for LFA is proposed. This architecture utilizes blockchain as an inter-domain trust mechanism, enabling firewalls within multiple Autonomous Domains to cooperate and coordinate defenses, accelerating the exposure of botnet attack behavior. Based on the characteristics of LFA, an adaptive firewall parameter adjustment algorithm is designed to achieve dynamic LFA mitigation. Simultaneously, the blockchain-based mitigation architecture allows for inter-domain sharing of LFA mitigation parameters, reducing the computational load.

[0011] A blockchain-based dynamic mitigation method for LFA (Local Fractional Amount) includes the following:

[0012] First, an LFA inter-domain collaborative mitigation architecture is proposed. This mitigation architecture is bottom-up, consisting of a parameter calculation layer, a data integration layer, and a data storage layer. In the parameter calculation layer, traffic arriving at the firewall is monitored in a timely manner, and behavior probing and dropping are performed. Then, the domain controller in the data integration layer requests mitigation parameters corresponding to the network state from the data storage layer. If no mitigation parameters are available, the mitigation parameters calculated by the compute nodes are used directly. The corresponding parameters are then applied to the appropriate firewalls, and the domain controller integrates the intra-domain mitigation parameters and reputation values. Finally, the data storage layer stores and shares the effective data.

[0013] The parameter calculation layer consists of all router firewalls and computing nodes within the autonomous system. It is responsible for real-time monitoring of network links and traffic shaping. Based on the detected network status, it uses Bayesian networks to calculate firewall mitigation parameters and performs congestion control at the data flow and session levels. It also defines a network status difference degree to represent the difference between the network status detected at different times or on different links. When the network status difference degree reaches a specific proportion specified by the user, it begins to adaptively adjust the mitigation parameters.

[0014] The data integration layer, composed of domain controllers from various autonomous systems (AS), is responsible for integrating defense data and reputation values ​​within each AS. After mitigation parameters are uploaded by the AS with link congestion, the qualified interactive ASs collaboratively evaluate this data and use a consortium blockchain to record all defense data requests and calculation data upload service fee transfer information in an "accounting" manner. The decentralized and tamper-proof advantages of blockchain make the mitigation parameter sharing process public. Since the mitigation parameters uploaded by the domain controllers are defense information for links within the domain, without disclosing which specific link it is for other ASs, the privacy of the link's defense information is guaranteed.

[0015] The data storage layer is used to store LFA mitigation parameters and the blockchain application network status of the data. Defense information approved by the data integration layer will be stored in the data storage layer. In order to adapt to dynamic LFA attacks, a time decay function is introduced to punish continuous abnormal behavior of the autonomous system, which has a time forgetting effect. The punishment decreases as the time distance from the last attack increases. The specific mitigation data is stored in the form of a binary tree.

[0016] A blockchain-based dynamic LFA mitigation method, implemented based on the aforementioned LFA inter-domain collaborative mitigation architecture, specifically includes the following steps:

[0017] Step 1: Monitor the link network status in real time through the firewalls of each autonomous system router in the parameter calculation layer, and obtain the link network status S = <S[1], S[2], S[3], S[4]>, where S[1] represents the average number of sessions, S[2] represents the average session rate, S[3] represents the total amount of traffic blocking the firewall, and S[4] represents the available bandwidth. The historical link network status is represented by M = <M[1], M[2], M[3], M[4]>. Normalize the distance between the current traffic and the historical traffic to calculate the network status difference. Then the link network status difference cS = |S[1]-M[1]| / M[1]+|S[2]-M[2]| / M[2]+|S[3]-M[3]| / M[3]+|S[4]-M[4]| / M[4];

[0018] Step 2: The domain controller searches for mitigation parameters based on the current network state S detected by the firewall. If found, the parameters are used directly; otherwise, they need to be calculated. To ensure the efficiency of mitigation parameter calculation, an LFA dynamic game model is established, and the computing nodes within the domain are used to calculate the congestion link front-end firewall mitigation parameters, which include: bandwidth weighting queue, session speed limit threshold, session number threshold, and whether to enable traffic dropping.

[0019] The process of calculating the mitigation parameters is as follows: The LFA attack and defense process is modeled using the theory of dynamic game theory with incomplete information. The attacker and the defender are two players. The attacker's decision space is A = <A[1], A[2], A[3], A[4]>, where A[1] represents the number of bots used by the attacker, A[2] represents the decoy server selected for the attack, and A[3] represents the flow rate allocated to the bot. The defender's decision space is D = <D[1], D[2], D[3], D[4]>, also known as the mitigation parameters. D[1] represents the bandwidth distribution queue scheme that the firewall decides to enable, D[2] represents the session speed limit threshold, D[3] represents the session number threshold of the firewall, and D[4] represents whether the firewall starts the traffic dropping scheme. If the defender increases the bandwidth during congestion, the higher the bandwidth used, the higher the cost will be.

[0020] For session queues that are about to enter the bottleneck link, the defender will set three policies according to the firewall function: bandwidth allocation, session rate limiting, and session quantity limit;

[0021] Step S1: Bandwidth weighting;

[0022] At the initial moment of the game, both the attacker and the defender believe that the other has not changed in any particular way. In each round after LFA occurs, both sides, guided by the Bayesian decision network, compare the current utility and choose the decision space with the largest utility function to complete the operation. The network state will then change according to the specific decisions of both sides.

[0023] Set up different queues to record different IP addresses:

[0024] The first queue is allocated to very important users or servers, with the highest priority. Service requests from these users will not be rejected in case of congestion. Users requiring the highest priority special services can pay a fee to obtain a higher priority allocation. Let f be the total traffic reaching the firewall from the first queue. 1B Let the payment fees for each IP be Q1, Q2, ..., Qn1, then their weights are: W11:W12:...:W1n1 = Q1:Q2:...:Qn1

[0025] The second queue is assigned to n2 users who pose no threat and have a high access frequency. It is set as a whitelist. Safe users who do not pay the fee will be recorded in this queue. By default, the second queue has the same weight. When congestion occurs, all bandwidth except that used by the first queue will be allocated to the second queue.

[0026] The third queue consists of users with low access frequency. Their weights will be distributed evenly, and they will be allocated bandwidth last. In case of congestion, they will be the first to be denied service.

[0027] Step S2: Session rate limiting;

[0028] Iterate through the n historical session rates in the first and second queues, sort the session rates in ascending order, and calculate the average of the first r (0 < r < 1) as the lower limit V of the rate. min The average value of r is used as the upper limit of the rate V. max :

[0029] n = n1 + n2

[0030]

[0031]

[0032] The value of r needs to be set based on factors such as the network environment, and it is necessary to find the r value with high defender effectiveness through enumeration; V i Let i be the i-th session rate out of n session rates;

[0033] Step S3: Session quantity limit;

[0034] At this point, all three queues have been established. When the paid users in the first queue send too much traffic, f 1B When the bandwidth is ≥B (where B is the link-limited bandwidth), the firewall will not allow traffic from the second and third queues to enter, and will focus its services on the first queue users. At this time, the traffic that each IP address in the first queue can pass through is f. 1 i, the discarded traffic is f 1D :

[0035] f 1D =f 1B -B

[0036]

[0037] Since paying users are long-term users of this link, their regular use generally does not clog the link, i.e., f 1B <B, At this point, there is no bandwidth pressure, so the firewall will not perform weight distribution on the first queue. It will directly allow all traffic in the first queue to pass through, and then allocate the remaining bandwidth to the traffic f sent by the source IP in the second queue. 2B Let n2 be the number of source IPs in the second queue, and let B' be the remaining bandwidth.

[0038] When the second queue reaches flow f 2B When >B', since the second queue consists of ordinary security users, the firewall will treat each source IP fairly. If it detects that a source IP is sending too much traffic, causing insufficient bandwidth, it will drop traffic sent by source IPs in the second queue proportionally. Because the second queue currently has f... 2B Due to bandwidth restrictions, data usage needs to be discarded. 2D flow:

[0039] B'=Bf 1B

[0040] f 2D =f 2B -B'

[0041] The firewall will inspect the traffic sent by the source IP in the second queue, and if its traffic is less than the average bandwidth it should be allocated, it will not drop the packets.

[0042]

[0043] flag i =0, the traffic sent by the i-th IP is less than or equal to the average bandwidth allocated to it.

[0044] f 2D i=0

[0045] If traffic from certain source IPs exceeds the allocated bandwidth, it will be dropped according to the size of the traffic being sent.

[0046] flag i >0, the traffic sent by the i-th IP is greater than the average bandwidth allocated.

[0047] f 2D 1:f 2D :…:f 2D i = f 2 1:f 2 2:…:f 2 i

[0048]

[0049] f 2D i≥0

[0050] If f 2B When the bandwidth is less than or equal to B', no traffic is dropped, and the remaining bandwidth is not weighted. The remaining bandwidth is directly allocated to the third queue. For the source IP addresses of the second queue, since no payment has been made in advance, their weights are all the same by default.

[0051] If a source IP initiates too many sessions, its new session request packets are dropped. If, after being dropped, the IP reduces its packet sending for a period of time to mitigate packet loss, the LFA dynamic game model considers it a safe user, and its weight remains unchanged. If a large amount of traffic is still injected despite link congestion, the user is considered malicious and their weight is reduced. The second reduction to Each time, the weight is reduced to half of its original value. If the IP is in the whitelist, it will be removed from the whitelist after the third weight reduction. Since the link bandwidth is already used up at this point, f 2 i will be completely discarded and recorded in Discard;

[0052] The third queue adopts the same allocation method as the second queue;

[0053] If congestion persists after the above three steps, data streams are dropped according to the bandwidth weighting scheme. Session information about to enter the bottleneck link is classified by destination IP, and the session bandwidth for each destination IP is accumulated. If the accumulated bandwidth is within the purchased bandwidth of the destination IP, it is allocated according to the accumulated bandwidth; if it exceeds the purchased bandwidth, it is allocated according to its weight ratio to ensure that the resources obtained by the server do not exceed the weight ratio. When dropping data streams, weighting is performed based on the source IP's autonomous system reputation score, and dropping tasks are assigned to each server until the link is no longer overloaded, at which point dropping stops.

[0054] Step 3: Perform utility calculations for attackers and defenders;

[0055] In the LFA dynamic game model, the attacker launches a flooding link attack. Since this attack targets the bottleneck link, it believes that the greater the proportion of illegal flow and the greater the loss of legal flow on the target link, the more the attacker benefits. However, since the attacker cannot know the loss ratio of legal flow, it cannot be used in utility optimization. The attacker can only treat the loss ratio of the flow he sends as the loss ratio of legal flow.

[0056] Since the attacker manipulates bots to carry out the attack, the LFA dynamic game model assumes that the attacker's attack cost is only related to the size of the botnet they use. For any link li ∈ L, the average cost of flooding link li with one unit of botnet traffic is denoted by Cost. a express;

[0057] If the total traffic does not reach the traffic threshold, the attacker gains nothing and incurs the cost of using a botnet of a certain size.

[0058] If the total traffic reaches the traffic threshold, the attacker's utility function is defined as follows:

[0059]

[0060] The above formula The illegal flow loss ratio, i.e., the attacker's gain, f aD For illegal traffic, f a For the total flow, t a The duration of this attack is σ, which is the benefit adjustment parameter; A[1]×cost a In the middle, A[1] represents the size of the botnet, and cost is... a The price required per unit of botnet; when attackers are rational, they will try to disrupt the most legitimate services with the fewest bots.

[0061] An attacker's benefit from blocking a unit of benign network traffic is income. a Defenders need to consider the external communication capabilities of the protected links as well as their own service costs and revenues. As a rational player, a defender should retain as much legitimate traffic as possible. All legitimate traffic that cannot reach the server is detrimental to the defender's interests. Therefore, every time a legitimate flow is dropped, it reduces the defender's decision utility.

[0062] The prerequisite for a defender to generate revenue is that some source IPs provide special protection services and block more illegal flows; its costs include the cost of maintaining the link and the additional defense costs required to activate specific defense functions. The profit that a defender gains from benign traffic load is Cv per unit of traffic.

[0063] Therefore, the utility of a single firewall is defined as:

[0064]

[0065] U D Used to measure the benefits that the defender can gain from this decision; This is the additional revenue brought by the payment of the source IP in the first queue. It is the weighted sum of traffic that the defender discards as illegitimate and traffic that passes through whitelisted IPs, c 白名单 c is the weight given to the impact of whitelisted traffic on firewall effectiveness. d c1 and c2 are the weights of the impact of discarding illegal traffic on the effectiveness of the firewall, and Discard is the total amount of illegal traffic discarded; c1 and c2 are the weights of the impact of the first and second queues of legal traffic that are forced to be discarded to alleviate congestion on the firewall effect; Δt is the time difference between the current calculation and the previous calculation, and D[3] is the additional defense cost brought to the defender by the flooding link attack; that is to say, the lower the weighted cost of protecting a unit of legal traffic, the better the effectiveness of the defender.

[0066] Step 4: In the data integration layer, the domain control integrates the defense data of each backbone link within the autonomous system and the calculated LFA reputation scores of other autonomous systems, and uploads them;

[0067] Because LFA deliberately avoids front-end congestion, in the reputation assessment of the data integration layer, only the congested autonomous region (AGN) evaluates the AGN from which the congested traffic originates, while other AGNs verify the "authenticity" of the scores. This serves to prevent malicious scoring by the congested AGN. A consortium blockchain is used to record all defense data requests and calculation data upload service fee transfer information in an "accounting" manner. The decentralized and tamper-proof advantages of blockchain are used to make the mitigation parameter sharing process public. Since the mitigation parameters uploaded by the domain controller are defense information for links within the domain, without informing other AGNs which specific link it is, the privacy of the defense information for that link is guaranteed.

[0068] After the congested autonomous region data is uploaded, the LFA collaborative mitigation reputation assessment algorithm is used to perform data review and scoring review on adjacent autonomous regions with interaction, specifically as follows:

[0069] The undirected graph G = (A, E) formed by the participating autonomous systems (AS) is defined, where A represents the set of nodes in the participating AS and E represents the logical connections between the nodes. Let v ∈ A be the AS being evaluated, and d ∈ A be the AS being evaluated. When the firewall front-end link is congested, defense data and reputation scores are calculated. d needs to quantify and evaluate the reputation of v's behavior in this stage based on the update message data received locally from v ∈ R, i.e., the reputation evaluation table E(d, v ∈ R). AS nodes dequeued from the interactive AS queue R are considered AS v for reputation evaluation. Nodes that have interacted with both the congested AS and the AS being evaluated enter the collaborative evaluation AS queue Q and are given voting rights. Nodes with evaluation rights confirm whether the traffic described by node f has passed through. If all nodes in the collaborative evaluation AS queue Q pass, the defense data is considered true. If the collaborative evaluation AS does not approve, the initiating AS is evaluated. If the review is passed, the data is stored on the chain. If the review is not passed, the AS is evaluated to prevent it from uploading false data.

[0070] Newly registered domain controllers, as blockchain nodes, need to publish a series of declaration transactions when joining the consortium blockchain, including address declarations, public key declarations, and identity tag declarations. The blockchain, as a distributed ledger, records these transactions, which are categorized into six types: declaration transactions, data request transactions, data confirmation transactions, transfer transactions, reputation assessment transactions, and collaborative assessment transactions. The transaction type is an explanation of the transaction content. Transactions are ultimately processed by the accounting nodes, packaged into blocks, published, and finally verified before being uploaded to the blockchain. Verifying nodes need to verify whether the reputation assessment has been collaboratively approved; if any node indicates the reputation assessment is false, the verification fails. Because reputation assessment is affected by topology location and routing policies, only congested links will have their reputation scores calculated, and these traffic flows through different autonomous systems (ASAs). Therefore, within each time period T, the domain controller integrates and broadcasts the reputation score table of the ASAs being assessed from the interactive ASA queue R within the ASA. ASAs with assessment eligibility then conduct collaborative verification. The approved mitigation data will be stored in the form of a blockchain.

[0071] Beneficial technical effects of the present invention:

[0072] (1) This invention utilizes the coordinated defense of LFA by firewalls in various autonomous domains to directly contact attack traffic, and has the advantage of rapid response.

[0073] (2) This invention utilizes blockchain to design a collaborative mitigation architecture, which has an inter-domain trust mechanism, can ensure the openness and sharing of inter-domain mitigation data, integrate attack and defense information of congestion links in various autonomous domains, and coordinate multiple firewalls to mitigate the congestion and accelerate the exposure of botnets.

[0074] (3) The parameter calculation method based on the firewall mechanism of this invention, by studying the application scenarios of game theory, uses incomplete information dynamic non-cooperative game suitable for LFA defense for modeling, can dynamically adapt to the changes of flooding link attacks and adaptively adjust the mitigation parameters in a short time.

[0075] (4) This invention optimizes the firewall parameter setting method, uses a weighted queue for block weighting, and limits session speed and number of sessions. If congestion persists after Layer 3, a weighted discard data stream algorithm will be used to discard data streams to ensure immediate mitigation. As zombie machines are exposed, the mitigation effect will gradually increase. Attached Figure Description

[0076] Figure 1 This is a diagram of the LFA inter-domain cooperation mitigation architecture of the present invention;

[0077] Figure 2 This is a flowchart of the parameter calculation layer of the LFA inter-domain collaboration mitigation architecture of the present invention;

[0078] Figure 3 This is a schematic diagram of the hierarchical function of the LFA inter-domain collaboration mitigation architecture of the present invention;

[0079] Figure 4 This invention relates to a Bayesian network based on firewall functionality. Detailed Implementation

[0080] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0081] A blockchain-based dynamic mitigation method for LFA (Local Fractional Amount) includes the following:

[0082] First, an LFA inter-domain cooperation mitigation architecture is proposed, as shown in the appendix. Figure 1 As shown, the mitigation architecture, from bottom to top, consists of a parameter calculation layer, a data integration layer, and a data storage layer. In the parameter calculation layer, traffic arriving at the firewall is monitored in a timely manner, and behavior probing and dropping are performed. Then, the domain controller in the data integration layer requests mitigation data corresponding to the network status from the data storage layer. If there is no directly usable mitigation data, the compute nodes perform the calculation and use the corresponding data on the appropriate firewall. The domain controller integrates the mitigation data and reputation values ​​within the domain, and finally, the data storage layer stores and shares the effective data.

[0083] The parameter calculation layer, composed of all router firewalls and computing nodes within the autonomous system, is responsible for real-time monitoring of network links and traffic shaping. Based on the detected network state, it uses Bayesian networking to calculate firewall mitigation parameters, performing congestion control at both the data flow and session levels. It also defines a network state difference degree to represent the difference in network state detected at different times or on different links. When the network state difference degree reaches a user-defined specific proportion, it begins adaptively adjusting mitigation parameters, as shown in the appendix. Figure 2 As shown;

[0084] The data integration layer, composed of domain controllers from various autonomous systems (AS), is responsible for integrating defense data and reputation values ​​within each AS. After mitigation data is uploaded to the congested AS, qualified interactive ASs collaboratively evaluate this data and use a consortium blockchain to record all defense data requests and calculate data upload service fee transfer information in an "accounting" manner. Leveraging the decentralized and tamper-proof advantages of blockchain, the mitigation parameter sharing process is made public. Because the mitigation parameters uploaded by the domain controllers are defense information for links within the domain, without disclosing which specific link it is for other ASs, the privacy of the link's defense information is guaranteed.

[0085] The data storage layer is used to store LFA mitigation data and the blockchain that applies the data to the network state. Defense information that has been approved in the data integration layer will be stored in the data storage layer. In order to adapt to dynamic LFA attacks, a time decay function is introduced to punish continuous abnormal behavior of the autonomous system, which has a time forgetting effect. The punishment decreases as the time since the last attack increases. The specific mitigation data is stored in the form of a binary tree.

[0086] A blockchain-based LFA dynamic mitigation method is implemented based on the aforementioned LFA inter-domain collaborative mitigation architecture. The overall functionality is shown in the attached figure. Figure 3 As shown, the specific steps include:

[0087] Step 1: Monitor the link network status in real time through the firewalls of each autonomous system router in the parameter calculation layer, and obtain the link network status S = <S[1], S[2], S[3], S[4]>, where S[1] represents the average number of sessions, S[2] represents the average session rate, S[3] represents the total amount of traffic blocking the firewall, and S[4] represents the available bandwidth. The historical link network status is represented by M = <M[1], M[2], M[3], M[4]>. Normalize the distance between the current traffic and the historical traffic to calculate the network status difference. Then the link network status difference cS = |S[1]-M[1]| / M[1]+|S[2]-M[2]| / M[2]+S[3]-M[3]| / M[3]+|S[4]-M[4]| / M[4];

[0088] Step 2: The domain controller searches for mitigation parameters based on the current network status detected by the firewall. If found, the parameters are used directly; otherwise, they need to be calculated. To ensure the efficiency of mitigation parameter calculation, an LFA dynamic game model is established, using in-domain computing nodes to calculate the congestion link front-end firewall mitigation parameters, which include: bandwidth weighting queue, session speed limit threshold, session number threshold, and whether to enable traffic dropping.

[0089] The process of calculating the mitigation parameters is as follows: The LFA attack and defense process is modeled using the theory of dynamic game theory with incomplete information. The attacker and the defender are two players. The attacker's decision space is A = <A[1], A[2], A[3], A[4]>, where A[1] represents the number of bots used by the attacker, A[2] represents the decoy server selected for the attack, and A[3] represents the flow rate allocated to the bot. The defender's decision space is D = <D[1], D[2], D[3], D[4]>, also known as the mitigation parameters. D[1] represents the bandwidth distribution queue scheme that the firewall decides to enable, D[2] represents the session speed limit threshold, D[3] represents the session number threshold of the firewall, and D[4] represents whether the firewall starts the traffic dropping scheme. If the defender increases the bandwidth during congestion, the higher the bandwidth used, the higher the cost will be.

[0090] For session queues that are about to enter the bottleneck link, the defender will set three policies according to the firewall function: bandwidth allocation, session rate limiting, and session quantity limit;

[0091] Step S1: Bandwidth weighting;

[0092] At the initial moment of the game, both the attacker and the defender believe that the other has not changed in any particular way. In each round after LFA occurs, both sides, guided by the Bayesian decision network, compare the current utility and choose the decision space with the largest utility function to complete the operation. The network state will then change according to the specific decisions of both sides.

[0093] Set up different queues to record different IP addresses:

[0094] The first queue is allocated to very important users or servers, with the highest priority. Service requests from these users will not be rejected in case of congestion. Users requiring the highest priority special services can pay a fee to obtain a higher priority allocation. Let f be the total traffic reaching the firewall from the first queue. 1B Let the payment fees for each IP be Q1, Q2, ..., Qn1, then their weights are: W11:W12:...:W1n1=Q1:Q2:...:Qn1

[0095] The second queue is assigned to n2 users who pose no threat and have a high access frequency. It is set as a whitelist. Safe users who do not pay the fee will be recorded in this queue. By default, the second queue has the same weight. When congestion occurs, all bandwidth except that used by the first queue will be allocated to the second queue.

[0096] The third queue consists of users with low access frequency. Their weights will be distributed evenly, and they will be allocated bandwidth last. In case of congestion, they will be the first to be denied service.

[0097] Step S2: Session rate limiting;

[0098] High-speed sessions consume more resources, and a large number of such sessions can lead to server service interruption. Conversely, while low-speed sessions consume fewer resources, a large number of these sessions clustering on the same link can also cause server service interruption due to a clustering effect—a phenomenon known as a slow attack. Therefore, a reasonable session rate threshold needs to be designed to filter out excessively fast or slow sessions, ensuring that normal sessions receive server responses.

[0099] Iterate through the n historical session rates in the first and second queues, sort the session rates in ascending order, and calculate the average of the first r (0 < r < 1) as the lower limit V of the rate. min The average value of r is used as the upper limit of the rate V. max :

[0100] n = n1 + n2

[0101]

[0102]

[0103] The value of r needs to be set according to factors such as the network environment, and the value of r with high defender effectiveness needs to be found by enumeration.

[0104] Step S3: Session quantity limit;

[0105] At this point, all three queues have been established. When the paid users in the first queue send too much traffic, f 1B When the bandwidth is ≥B (where B is the link-limited bandwidth), the firewall will not allow traffic from the second and third queues to enter, and will focus its services on the first queue users. At this time, the traffic that each IP address in the first queue can pass through is f. 1 i, the discarded traffic is f 1D :

[0106] f 1D =f 1B -B

[0107]

[0108] Since paying users are long-term users of this link, their regular use generally does not clog the link, i.e., f 1B <B, At this point, there is no bandwidth pressure, so the firewall will not perform weight distribution on the first queue. It will directly allow all traffic in the first queue to pass through, and then allocate the remaining bandwidth to the traffic sent by the source IP in the second queue. 2B Let n2 be the number of source IPs in the second queue, and let B' be the remaining bandwidth.

[0109] When the second queue reaches flow f 2B When >B', since the second queue consists of ordinary security users, the firewall will treat each source IP fairly. If it detects that a source IP is sending too much traffic, causing insufficient bandwidth, it will drop traffic sent by source IPs in the second queue proportionally. Because the second queue currently has f... 2B Due to bandwidth restrictions, data usage needs to be discarded. 2D flow:

[0110] B'=Bf 1B

[0111] f 2D =f 2B -B'

[0112] The firewall will inspect the traffic sent by the source IP in the second queue, and if its traffic is less than the average bandwidth it should be allocated, it will not drop the packets.

[0113]

[0114] flag i =0, the traffic sent by the i-th IP is less than or equal to the average bandwidth allocated to it.

[0115] f 2D i=0

[0116] If traffic from certain source IPs exceeds their allocated bandwidth, it will be dropped according to the size of the traffic being sent.

[0117] flag i >0, the traffic sent by the i-th IP is greater than the average bandwidth allocated.

[0118] f 2D 1:f 2D :…:f 2D i = f 2 1:f 2 2:…:f 2 i

[0119]

[0120] f2D i≥0

[0121] If f 2B When the bandwidth is less than or equal to B', no traffic is dropped, and the remaining bandwidth is not weighted. The remaining bandwidth is directly allocated to the third queue. For the source IP addresses of the second queue, since no payment has been made in advance, their weights are all the same by default.

[0122] If a source IP initiates too many sessions, its new session request packets are dropped. If, after being dropped, the IP reduces its packet sending for a period of time to mitigate packet loss, the LFA dynamic game model considers it a safe user, and its weight remains unchanged. If a large amount of traffic is still injected despite link congestion, the user is considered malicious and their weight is reduced. The second reduction to Each time, the weight is reduced to half of its original value. If the IP is in the whitelist, it will be removed from the whitelist after the third weight reduction. Since the link bandwidth is already used up at this point, f 2 i will be completely discarded and recorded in Discard;

[0123] The third queue adopts the same allocation method as the second queue;

[0124] If congestion persists after the above three steps, data streams are dropped according to a bandwidth weighting scheme, as shown in Algorithm 1. Session information about to enter the bottleneck link is categorized by destination IP. The session bandwidth for each destination IP is accumulated. If the accumulated bandwidth is within the purchased bandwidth of the destination IP, it is allocated according to the accumulated bandwidth; otherwise, it is allocated according to its weight ratio, ensuring that the resources allocated to the server do not exceed the weight ratio. When dropping data streams, weighting is applied based on the source IP's autonomous system reputation score, and dropping tasks are assigned to each server until the link is no longer overloaded, at which point dropping stops.

[0125]

[0126] Step 3: Perform utility calculations for attackers and defenders;

[0127] Based on the specific functions of the firewall described in the above steps, a dynamic game model of LFA between the attacker and the defender is established using Bayesian networks, as shown in the appendix. Figure 4 In the LFA dynamic game model shown, the attacker launches a flooding link attack. Since this attack targets the bottleneck link, it believes that the greater the proportion of illegal flow and the greater the loss of legal flow on the target link, the greater the attacker's benefit. However, since the attacker cannot know the loss ratio of legal flow, it cannot be used in utility optimization. The attacker can only treat the loss ratio of the flow it sends as the loss ratio of legal flow.

[0128] Since the attacker manipulates bots to carry out the attack, the LFA dynamic game model assumes that the attacker's attack cost is only related to the size of the botnet they use. For any link li ∈ L, the average cost of flooding link li with one unit of botnet traffic (e.g., per Gbps) is denoted by Cost. a express;

[0129] If the total traffic does not reach the traffic threshold, the attacker gains nothing and incurs the cost of using a botnet of a certain size.

[0130] If the total traffic reaches the traffic threshold, the attacker's utility function is defined as follows:

[0131]

[0132] The above formula The illegal flow loss ratio, i.e., the attacker's gain, f aD For illegal traffic, f a For the total flow, t a The duration of this attack is σ, which is the benefit adjustment parameter; A[1]×cost a In the middle, A[1] represents the size of the botnet, and cost is... a The price required per unit of botnet; when attackers are rational, they will try to disrupt the most legitimate services with the fewest bots.

[0133] An attacker's benefit from blocking a unit of benign network traffic is income. a Defenders need to consider the external communication capabilities of the protected links as well as their own service costs and revenues. As a rational player, a defender should retain as much legitimate traffic as possible. All legitimate traffic that cannot reach the server is detrimental to the defender's interests. Therefore, every time a legitimate flow is dropped, it reduces the defender's decision utility.

[0134] The prerequisite for a defender to generate revenue is that some source IPs provide special protection services and block more illegal flows; its costs include the cost of maintaining the link and the additional defense costs required to activate specific defense functions. The profit that a defender gains from benign traffic load is Cv per unit of traffic.

[0135] Therefore, the utility of a single firewall is defined as:

[0136]

[0137] U D Used to measure the benefits that the defender can gain from this decision; This is the additional revenue brought by the payment of the source IP in the first queue. It is the weighted sum of traffic that the defender discards as illegitimate and traffic that passes through whitelisted IPs, c 白名单 c is the weight given to the impact of whitelisted traffic on firewall effectiveness. d c1 and c2 are the weights of the impact of discarding illegal traffic on the effectiveness of the firewall, and Discard is the total amount of illegal traffic discarded; c1 and c2 are the weights of the impact of the first and second queues of legal traffic that are forced to be discarded to alleviate congestion on the firewall effect; Δt is the time difference between the current calculation and the previous calculation, and D[3] is the additional defense cost brought to the defender by the flooding link attack; that is to say, the lower the weighted cost of protecting a unit of legal traffic, the better the effectiveness of the defender.

[0138] Step 4: At the data integration layer, the domain controller integrates the defense data of each backbone link within the autonomous system and the calculated LFA reputation scores of other autonomous systems, and uploads them. Since LFA deliberately avoids front-end congestion and only blocks specific links, its malicious behavior is difficult to detect in other autonomous systems simultaneously. Such collaborative evaluation results in no significant decrease in the malicious node score, failing to achieve a punitive effect. Therefore, in the reputation evaluation at the data integration layer, only the congested autonomous system evaluates the autonomous system from which the congested traffic originates, while other autonomous systems verify the "authenticity" of its score, thus preventing malicious scoring by the congested autonomous system. A consortium blockchain is used to record all defense data requests and calculation data upload service fee transfer information in an "accounting" manner; the decentralized and tamper-proof advantages of blockchain make the mitigation parameter sharing process public; and since the mitigation parameters uploaded by the domain controller are defense information of links within the domain, without informing other autonomous systems which specific link it is, the privacy of the link's defense information is guaranteed.

[0139] After the congested autonomous region uploads its data, neighboring autonomous regions with interaction perform data review, including calculation review and scoring review.

[0140] The undirected graph G = (A, E) formed by the participating autonomous systems (AS) is defined, where A represents the set of nodes in the participating AS and E represents the logical connections between the nodes. Let v ∈ A be the AS being evaluated, and d ∈ A be the AS being evaluated. When the firewall front-end link is congested, defense data and reputation scores are calculated. d needs to quantify and evaluate the reputation of v in this stage based on the update message data received locally from v ∈ R, i.e., the reputation evaluation table E(d, v ∈ R). The LFA collaborative mitigation reputation evaluation algorithm is shown in Algorithm 2. The AS nodes dequeued from the interactive AS queue R are the AS being evaluated for reputation evaluation. Nodes that have interacted with both the congested AS and the AS being evaluated enter the collaborative evaluation AS queue Q and are given voting rights. The nodes with evaluation rights confirm whether the traffic described by node f has passed through. If all nodes in the collaborative evaluation AS queue Q pass, the defense data is considered true. If the collaborative evaluation AS does not approve, the initiating AS is evaluated. If the review is passed, the data is stored on the chain. If the review is not passed, the AS is evaluated to prevent it from uploading false data.

[0141]

[0142]

[0143] Newly registered domain controllers, as blockchain nodes, need to publish a series of declaration transactions when joining the consortium blockchain, including address declarations, public key declarations, and identity tag declarations. The blockchain, as a distributed ledger, records these transactions, which can be categorized into six types: declaration transactions, data request transactions, data confirmation transactions, transfer transactions, reputation assessment transactions, and collaborative assessment transactions. The transaction type is an explanation of the transaction content. Transactions are ultimately processed by the accounting nodes, packaged into blocks, published, and finally verified before being uploaded to the blockchain. Verifying nodes need to verify whether the reputation assessment has been collaboratively approved; if any node indicates the reputation assessment is false, the verification fails. Because reputation assessment is affected by topology location and routing policies, only congested links will have their reputation scores calculated, and these traffic flows through different autonomous systems (AS). Therefore, within each time period T, the domain controller integrates and broadcasts the reputation score table of the AS being assessed from the interactive AS queue R within the AS. ASs with assessment eligibility then conduct collaborative verification. The approved mitigation data will be stored in the form of a blockchain.

Claims

1. A blockchain-based LFA dynamic mitigation method, characterized in that, The method is based on an LFA inter-domain cooperative mitigation architecture, which is bottom-up, respectively, parameter calculation layer, data integration layer, data storage layer; the method comprises: in the parameter calculation layer, the traffic arriving at the firewall will be monitored, and the behavior will be explored and discarded, then the data integration layer domain controller applies to the data storage layer for mitigation parameters corresponding to the network state, if not, the mitigation parameters are calculated by the computing nodes, the corresponding parameters are used on the corresponding firewall, and the domain controller integrates the mitigation parameters and the reputation value in the domain, finally the effective data is stored and shared through the data storage layer; wherein The parameter calculation layer is composed of all routers and computing nodes in the autonomous domain, responsible for real-time monitoring of network links and traffic shaping, and calculating firewall mitigation parameters using Bayesian networks according to the detected network state, from the data flow level and the session level, respectively, for congestion control, and defining the network state difference degree to represent the difference between the network states detected at different times or different links, when the network state difference degree reaches the user specified proportion, start adaptive adjustment of mitigation parameters; The data integration layer is composed of domain controllers of each autonomous domain, and after the link congestion autonomous domain uploads the mitigation parameters, the interactive autonomous domains with evaluation qualifications cooperatively evaluate the data, and use the alliance chain to record all defense data requests and computing data upload service charge transfer information in the form of accounting; Since the mitigation parameters uploaded by the domain controller are defense information for the links within the domain, and will not inform other autonomous domains of the specific link, while ensuring the privacy of the link defense information; The data storage layer is used to store the LFA mitigation parameters and the corresponding network state block chain, in order to adapt to dynamic LFA attacks, a time decay function is introduced to punish the continuous abnormal behavior of the autonomous domain, with time forgetting effect, the punishment decreases with the increase of the distance from the last attack time point, and the mitigation data is stored in the form of binary tree; In the reputation evaluation of the data integration layer, only the congestion autonomous domain evaluates the congestion traffic source autonomous domain, and other autonomous domains verify the authenticity of the score; in each time period T, the domain controller integrates the reputation score table of the evaluated autonomous domain in the interactive autonomous domain queue R in the autonomous domain and broadcasts it, and the autonomous domains with evaluation qualifications cooperatively audit; the mitigation data that passes the audit will be stored in the form of block chain; after the congestion autonomous domain uploads data, the LFA cooperative mitigation reputation evaluation algorithm is used to calculate and audit the data of the adjacent interactive autonomous domains, which is specific to The undirected graph G=(A, E) is constituted by the participating autonomous domains, A represents the node set of the participating autonomous domains, and E represents the logical connection relationship between the nodes of the participating autonomous domains; v∈A is an evaluated autonomous domain, and d∈A is an evaluating autonomous domain; when the front-end link of the firewall is congested, the calculation of the defense data and the reputation score is performed, d needs to quantitatively evaluate the behavior reputation of v in the current stage according to the update message data received from v∈R, that is, the reputation score table E(d, v∈R); the autonomous domain node dequeued from the interactive autonomous domain queue R is taken as the evaluated autonomous domain v of the reputation evaluation, the nodes interacting with the congested autonomous domain f and the evaluated autonomous domain enter the cooperative evaluation autonomous domain queue Q, are given the voting right, and the nodes with the evaluation right confirm whether the traffic described by the f node passes; if all the nodes in the cooperative evaluation autonomous domain queue Q pass, it is considered that the defense data is true.

Images