WO2025002535A1

WO2025002535A1 - Method of protecting against reflection distributed denial of service, ddos, attacks, network node, and server

Info

Publication number: WO2025002535A1
Application number: PCT/EP2023/067392
Authority: WO
Inventors: Oleg Pogorelik; Evyatar MUNK
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2023-06-27
Filing date: 2023-06-27
Publication date: 2025-01-02
Anticipated expiration: 2025-12-27
Also published as: CN121399891A

Abstract

In order to achieve protecting against reflection distributed denial of service, DDoS, attacks, a reflection DDoS attack is detected and an attack vector information of DDoS attack is obtained by a network node through receiving unexpected reply packets from a server. A reflection attack complain request with the attack vector information is then sent to the server to initiate analyzing adversarial requests to obtain an attack specific information. An attacker feature differentiating the adversarial requests from benign requests is determined based on comparison of the attack vector information and the attack specific information. If no attacker feature is determined, the server shares a secret with the network node for implementing traffic differentiation in a protection mode with providing a target difference of the benign requests from the adversarial requests.

Description

METHOD OF PROTECTING AGAINST REFLECTION DISTRIBUTED DENIAL OF SERVICE, DDOS, ATTACKS, NETWORK NODE, AND SERVER

TECHNICAL FIELD

This disclosure generally relates to a network security, and in particular to a method of protecting against reflection distributed denial of service, DDoS, attacks, a network node, and a server for implementing corresponding aspects of the method.

BACKGROUND

Generally, a reflection attack is a type of distributed denial-of-service, DDoS, attacks that exploits inherent trust in certain protocols to amplify and intensify a volume of malicious traffic directed towards a system of a victim. In such attacks, an attacker uses a computer system to transmit a carefully crafted request to a vulnerable server (e.g., DNS, NTP, SNMP, servers, and the like). The vulnerable server further responds to the request by transmitting a larger response to the victim's system, amplifying the traffic, and overwhelming the victim's system or a network. The reflection attack causes significant damage by overwhelming the victim's system or the network with a flood of traffic, causing a denial-of-service, downtime, or even complete unavailability of services.

Conventionally, certain attempts have been made to mitigate the reflection attacks, such as by application of mitigation techniques. Such mitigation techniques can be divided into techniques of hardening a server infrastructure in order to prevent the server infrastructure from being used as reflectors and techniques of configuring the network infrastructure to filter out packets with suspicious IPs. The conventional mitigation techniques of hardening the server infrastructure implement the following approaches and are characterized by the following disadvantages: (1) limiting a response rate - lacks an accuracy and impacts negatively on the quality of service of legitimate services; (2) limiting a request rate - is expensive, lacks scaling and imposes a heavy negative impact on the performance; (3) detecting attack signatures - is applicable to attacks with known behavior patterns only; (4) source attestation - is applicable to a small number of applications and services only; and (5) blocking known vulnerable servers - is impractical due to a large number of vulnerable servers and requires heavy maintenance of threat intelligence databases. For the described reasons, the known mitigation techniques of hardening the server infrastructure are not able to efficiently mitigate the reflection DDoS attacks in real-world scenarios.

The mitigation techniques of configuring the network infrastructure implement the following approaches and are characterized by the following disadvantages: (1) blocking inaccessible IPs that do not appear in routing tables, for example, as described in the Request for Comments No. 2827 of the Network Working Group (RFC2827, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing) - the approach relies on edge routers and hence, is not widely supported by the network infrastructure; (2) filtering asymmetric transactions as per the unicast Reverse Path Forwarding (uRPF) technique described in the Request for Comments No. 8707 of the Internet Engineering Task Force (IETF) (RFC 8707, Resource Indicators for OAuth 2.0) - the approach is based on assumptions of traffic symmetry and consistent routing and thereby fails to serve content delivery networks (CDNs) and optimized re-routes; and (3) IP validation by Internet Service Providers (ISPs) on demand, using tracking of a return path - not supported by most ISPs. For the described reasons, the mitigation techniques related to configuring the network infrastructure are also not able to efficiently mitigate the reflection DDoS attacks in real-world scenarios.

In general, the prior art reflector protection techniques are inaccurate, complicated, have inacceptable performance implications, require additional costs and heavy maintenance. The known network infrastructure-based solutions to mitigate the reflection attacks have installation and configuration-specific issues and multiparty dependencies, and for these reasons are barely or only partially supported in wide-area networks and service providers. Therefore, there exists a technical problem to provide a lightweight and accurate solution to protect the servers and /networks against the reflection DDoS attacks.

Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with the conventional approaches of protection against the reflection DDoS attacks.

SUMMARY

The present disclosure provides a method of protecting against reflection distributed denial of service, DDoS, attacks, a network node, and a server. The present disclosure provides a solution to the existing problem of how to filter out malicious requests of an attacker and how to accurately protect a network node, a server and a network against reflection DDoS attacks. An aim of the present disclosure is to provide a solution that overcomes at least partially the problem encountered in the prior art and provides an improved method for protecting against reflection DDoS attacks, an improved network node, and an improved server.

One or more objectives of the present disclosure are achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

In one aspect, the present disclosure provides a method of protecting against reflection distributed denial of service, DDoS, attacks. The method includes detecting a reflection DDoS attack by a network node through receiving unexpected reply packets from a server, obtaining an attack vector information of the detected reflection DDoS attack by the network node, sending a reflection attack complain request with the attack vector information to the server from the network node, analyzing by the server adversarial requests where the network node is indicated as a destination during a first period of time after receiving the reflection attack complain request to obtain an attack specific information, determining an attacker feature of the adversarial requests differentiating them from benign requests of the network node by the server based on comparison of the attack vector information from the reflection attack complain request and the attack specific information, sharing a secret with the network node by the server, to be used for implementing traffic differentiation in a protection mode if no attacker feature is determined, and in response thereto, using the secret by the network node to operate in the protection mode with providing a target difference of the benign requests from the adversarial requests if the secret is shared by the server with the network node, and operating the server in the protection mode by filtering out any requests where the network node is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined.

The method of protecting against reflection DDoS attacks improves network security and performance by using information specific to the reflection DDoS attack to create a filter. The method is beneficial to make the filter more accurate and less likely to block legitimate requests as compared to traditional methods. Such traditional methods may be inaccurate, especially when an attacker is using a new or sophisticated attack. Beneficially as compared to conventional methods, the method of protecting against reflection DDoS attacks is efficient, reliable, cost-effective, and easier to deploy as the method does not require complex software and hardware configurations for implementation of the method. Conventionally, zero-day attacks are attacks that exploit vulnerabilities that are not known to the defender. The method of the present disclosure does not rely on signatures created for known vulnerabilities, and the method depends on the use of information that is specific to the attack to create the filter. Thus, the method is resilient against the zero-day attacks.

In an implementation form, the method further includes switching the server into a normal operation mode after a pre-defined period of time or when an end-of-attack is detected and switching the network node into a normal operation mode after the pre-defined period of time or in response to receiving an end of attack instruction from the server.

The server and the network node, while in the protection mode, are configured to use more resources to protect itself from the reflection DDoS attack as compared to the normal operation mode. Hence, by switching the server and the network node back to the normal operation mode, the performance of the server and the network node is improved.

In a further implementation form, the attack vector information and/or the attack specific information include one or more of a communication protocol type, an identification data of an internet protocol, IP, packet, a destination IP address, a source IP address, a destination port, a source port, a time to live, TTL, and a request sequence number as specified in the adversarial request.

Advantageously, the method is easier to detect, respond to, and prevent attacks. Moreover, the attack vector information and/or the attack specific information improves the overall protection against DDoS attacks by configuring firewalls, intrusion detection systems, honeypots, and the like.

In a further implementation form, the method further includes preventing the network node from initiating requests to the server during the first period of time after sending the reflection attack complain request to the server.

Advantageously, by preventing the network node from initiating requests to the server for a period of time after sending the reflection attack complain request, the method supports and enhances the server’s analysis of adversarial requests where the network node is indicated as a destination to obtain the attack specific information. In a further implementation form, the determining of the attacker feature includes analyzing fields of a Layer 3 header and/or Layer 4 header of IP packets of the adversarial and benign requests.

By virtue of the determination of the attacker feature by analyzing the Layer 3 header and/or the Layer 4 header of IP packets of the adversarial and benign requests, the method reduces the number of false positives as compared with the ones generated by intrusion detection systems. This is because the headers are used to identify requests that are likely to be from attackers, such as the requests that come from a known malicious IP address or that use a known malicious communication protocol.

In a further implementation form, the attacker feature includes one or more differences of the adversarial requests from the benign requests related to a packet routing path, a lack of a network node specific information in the adversarial requests, and parameters of the adversarial requests including a time to live, TTL, a source IP address, a source port, and a request sequence number.

Attackers often use different routing paths, do not include network node specific information, and use different parameters in the adversarial requests than a benign user. However, by virtue of using differences in the routing path, lack of network node specific information, and parameters of the requests, the method is beneficial to accurately identify if a request originates from the attacker or the benign network node.

In a further implementation form, the secret includes a change of one or more of communication settings and parameters of requests of the network node, or a specific piece of content to be added to requests of the network node as the target difference in the protection mode.

By virtue of changing the communication settings of the network node and the parameters of benign requests of the network node, or by adding a specific piece of content to the benign requests, the method is beneficial to clearly differentiate between the adversarial and benign requests and implement efficient protection.

In another aspect, the present disclosure provides a network node. The network node is configured for detecting a reflection DDoS attack through receiving unexpected reply packets from a server. The network node is further configured for obtaining an attack vector information of the detected reflection DDoS attack. The network node is further configured for sending a reflection attack complain request with the attack vector information to the server. In response thereto, using a secret to operate in a protection mode with providing a target difference of benign requests of the network node to the server from adversarial requests of an attacker if the secret is shared by the server with the network node.

The network node achieves all the advantages and technical effects of the method of the present disclosure.

In yet another aspect, the present disclosure provides a server. The server is configured for receiving a reflection attack complain request with an attack vector information from a network node. The server is further configured for analyzing adversarial requests where the network node is indicated as a destination during a first period of time after receiving the reflection attack complain request to obtain an attack specific information. The server is further configured for determining an attacker feature of the adversarial requests differentiating them from benign requests of the network node based on comparison of the attack vector information from the reflection attack complain request and the attack specific information. The server is further configured for sharing a secret with the network node to be used for implementing traffic differentiation in a protection mode if no attacker feature is determined. The server is further configured for operating in the protection mode by filtering out any requests where the network node is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined.

The server achieves all the advantages and technical effects of the method of the present disclosure.

It is to be appreciated that all the aforementioned implementation forms can be combined.

It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

Additional aspects, advantages, features, and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. 1 is a flowchart illustrating a method of protecting against reflection distributed denial of service, DDoS, attacks, in accordance with an embodiment of the present disclosure;

FIGs. 2A and 2B are block diagrams illustrating a network node and a server respectively, in accordance with different embodiments of the present disclosure;

FIG. 3 is a diagram illustrating a communication protocol between the network node, an attacker, and the server, in accordance with another embodiment of the present disclosure; and

FIG. 4 is a diagram illustrating a negotiation protocol between the network node, the server, and the attacker, in accordance with another embodiment of the present disclosure.

In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the nonunderlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

FIG. 1 is a flowchart of a method of protecting against reflection distributed denial of service, DDoS, attacks, in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a flowchart of method 100 to be implemented for protecting a network node and a server against reflection DDoS attacks. The method 100 includes steps 102 to 116.

The method 100 is used for protecting against reflection distributed denial of service, DDoS, attacks. The method 100 is beneficial for implementing a new communication protocol between attacked machine/system (e.g., the network node) and a reflector (e.g., the server) to support adjustments of the server-side protection system and legitimate traffic parameters helping in accurate differentiation between adversarial and legitimate requests. At step 102, the method 100 includes detecting a reflection DDoS attack by a network node through receiving unexpected reply packets from a server. In other words, the network node is configured to receive the unexpected reply packets from the server and detect the reflection DDoS attack. In an implementation, the unexpected reply packets correspond to the packets that are received in response to a sequence of adversarial requests sent to the server from an unexpected source. In such an implementation, the unexpected source may be an attacker that is trying to launch the reflection DDoS attack through the server. Therefore, the server is utilized by the attacker as a reflector for sending the unexpected reply packets to the network node. In an example, the attacker generates the sequence of adversarial requests specifying internet protocol, IP, of the network node as a source IP. The server sends the unexpected reply packets to the network node that is a victim machine, and in response, the network node detects the reflection DDoS attack. Furthermore, at step 104, the method 100 includes obtaining an attack vector information of the detected reflection DDoS attack by the network node. In an implementation, the network node is configured to detect the reflection DDoS attack by an attack targeted machine (ATTM). Further, on successful detection of the reflection DDoS attack, the ATTM collects the attack vector information. As a result, the network node is configured to obtain the attack vector information from the ATTM. In an implementation, the attack vector information and/or attack specific information includes one or more of a communication protocol type, an identification data of an internet protocol, IP, packet, a destination IP address, a source IP address, a destination port, a source port, a time to live, TTL, and a request sequence number as specified in the adversarial request.

Furthermore, at step 106, the method 100 includes sending a reflection attack complain request with the attack vector information to the server from the network node. In an implementation, the network node complements the attack vector information by authentic details of the ATTM and provides a complimented attack vector information to the server as the reflection attack complain request.

Furthermore, at step 108, the method 100 includes analyzing, by, the server adversarial requests where the network node is indicated as a destination during a first period of time after receiving the reflection attack complain request to obtain an attack specific information. In an implementation, after receiving the reflection attack complain request, the server is configured to analyze each of the adversarial requests in the sequence of adversarial requests for obtaining the attack specific information.

In accordance with an embodiment, the attack vector information and/or attack specific information includes one or more of the communication protocol type, the identification data of the internet protocol, IP, packet, the destination IP address, the source IP address, the destination port, the source port, the time to live, TTL, and the request sequence number as specified in the adversarial request. In an implementation, the attack specific information includes the one or more of a communication protocol type, the identification data of the internet protocol, IP, packet, the destination IP address, the source IP address, the destination port, the source port, the time to live, TTL, and the request sequence number as specified in the adversarial request. In such an implementation, each of the adversarial requests corresponds to the destination IP address during the first period of time. In an implementation, the communication protocol type refers to the type of communication protocol used in the reflection DDoS attack, such as a hypertext transfer protocol (HTTP), a file transfer protocol (FTP), or a secure shell (SSH) protocol. Furthermore, the communication protocol type may be used to identify the type of attack that is used in the reflection DDoS attack. For example, if the attack is using the HTTP protocol, then the attack is likely a web-based attack. In addition, the identification data of the IP packet refers to a unique number that is assigned to each IP packet when the corresponding IP packet is created. Such a unique number may be used to track the IP packet, which travels through the network. Therefore, the information obtained by tracking the IP packet may be used to identify the source of the reflection DDoS attack and to block future reflection DDoS attacks. Moreover, the destination IP address refers to an address of the network node that corresponds to a target of the reflection DDoS attack. Similarly, the source IP address refers to an address of the attacker that is sending the reflection DDoS attack. The source IP address is used to identify the attacker and to take steps to stop the reflection DDoS attack. Furthermore, the destination port is a number of a port on the network node that is the target of the reflection DDoS attack. The destination port may be used to identify a service that is being attacked and to take steps to protect the network node. Similarly, the source port is a number of a port on the attacker that is sending the reflection DDoS attack. The source port may be used to identify an application that is being used to send the reflection DDoS attack and to take steps to block future reflection DDoS attacks. In addition, the TTL is a value that is set in each IP packet, such as the TTL informs the network about a duration for which the network can retain the IP packet in the network routing tables before the IP packet needs to be discarded. The TTL may be used to identify the sources that are being used to send the reflection DDoS attacks and to take steps to block the future reflection DDoS attacks. The request sequence number is a number that is assigned to each adversarial request in the sequence of the adversarial requests sent to the server. The request sequence number is used to keep track of an order of the adversarial requests and to prevent data corruption. The request sequence number may be used to identify the order of the requests that are sent to the server. The request sequence number may be used to prevent data corruption and to detect reflection DDoS attacks that are trying to modify data. In particular, the attack vector information and/or the attack specific information improves the overall protection against reflection DDoS attacks by configuring firewalls, intrusion detection systems, honeypots, and the like.

In accordance with an embodiment, the first period of time is a time in which the network node is prevented from initiating requests to the server after sending the reflection attack complain request to the server. In an implementation, the ATTM configured in the network node is prevented from initiating the requests to the server during the first period of time, so that all the requests with the destination IP address are considered coming from the attacker as adversarial requests. Conventionally, such requests cause a conventional server to become overloaded, that lead to performance degradation of the conventional server. Beneficially as compared to conventional approaches, the method 100 is used to improve the performance of the server, such as by virtue of preventing the network node from initiating requests to the server for a period of time after sending the reflection attack complain request.

Furthermore, at step 110, the method 100 further includes determining an attacker feature of the adversarial requests differentiating them from benign requests of the network node by the server based on comparison of the attack vector information from the reflection attack complain request and the attack specific information. In an implementation, the server is configured to compare the attack vector information as obtained from the network node and the attack specific information as obtained by the server from the attacker. For example, the server is configured to communicate with the network node to verify authenticity of the network node’s IP address, collect traffic details and compare various requests in order to differentiate between the adversarial requests and the benign requests. The server is further configured to determine the attacker feature of each of the adversarial requests based on the comparison of the attack vector information and the attack specific information. In accordance with an embodiment, the attacker feature includes one or more differences of the adversarial requests from the benign requests related to a packet routing path, a lack of a network node specific information in the adversarial requests, and parameters of the adversarial requests including a time to live, TTL, a source IP address, a source port, and a request sequence number. In other words, considering lack of specific information about the ATTM in the attackers, the adversarial requests are expected to have different parameters, such as the TTL, the source port, the request sequence number, and the like. Furthermore, the attacker feature is determined for preparing filters to differentiate between the adversarial requests and the benign requests. In such embodiment, the determination of the attacker feature includes analyzing fields of a Layer 3 header and/or Layer 4 header of the IP packets of the adversarial requests and the benign requests. The attacker features are specifically determined based on protocol type and functionality. The protocol type may include but is not limited to, DNS and SNMP. The difference in the attacker features may be found immediately while selecting the attacker features, such as the TTL, the source Address, the destination address, the source port, the destination port, and the like. Furthermore, at step 112, the method 100 includes sharing a secret with the network node by the server, to be used for implementing traffic differentiation in a protection mode if no attacker feature is determined. Examples of the secret may include but are not limited to a specified value 0 to 3 in a Layer 3 header (or unused Layer 3) and/or a Layer 4 header (or Layer 4 SDDS field) of the IP packets of the adversarial requests and the benign requests. This will help the server to create a filter. Therefore, the sharing of the secret will also prevent from adversary to block the server from handling legitimate requests from the ATTM. In accordance with an embodiment, the secret includes a change of one or more of communication settings and parameters of requests of the network node, or a specific piece of content to be added to the requests of the network node as the target difference in the protection mode. As the attacker is not aware about the sharing of the secret between the server and the network node, thus the server easily distinguishes between the benign request and the adversarial requests coming from the same IP address and the server accurately drops the adversarial requests leaving benign requests intact.

Furthermore, at step 114, the method 100 includes using the secret by the network node to operate in the protection mode by providing a target difference of the benign requests from the adversarial requests if the secret is shared by the server with the network node. In an implementation, the server may share the secret (e.g., specify value 0 to 3 in unused Layer 3 and/or Layer 4 SDDS field) with the ATTM configured in the network node to apply the secret in the further requests. For example, the server may require the network node to provide the target difference by specifying the appropriate TTL, switch to the appropriate source port, and the like. In such an implementation, guidelines, and request attributes of the traffic difference may vary per service type. The traffic difference may help the server to prepare the filters. In an implementation, sharing the secret prevents the attacker from blocking the server from handling the benign requests from the ATTM. Once the filter is prepared, the server ignores all the requests coming from the attacker and the reflection DDoS attack is blocked.

Furthermore, at step 116, the method 100 includes operating the server in the protection mode by filtering out any requests where the network node is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined. In other words, the server is configured to operate in the protection mode in two of the following conditions, such as when the attacker feature is determined or when there is no target difference. In an implementation, the server filters out any requests while operating in the protection mode.

Henceforth, the server is configured to be operated in the protection mode while filtering out any when the reflection DDoS attack is identified. In accordance with an embodiment, the method 100 further includes switching the server into a normal operation mode after a predefined period of time or when an end of the attack is detected and switching the network node into a normal operation mode after the pre-defined period of time or in response to receiving an end of attack instruction from the server. The normal operation mode refers to a mode in which the server and network node operate when there is no attack. In normal operation mode, the server and network node are not filtering out any requests and are operating as they normally would. The method includes switching the server and the network node from the protection mode to the normal operation mode to ensure that the server and the network node are not unnecessarily filtering out requests when there is no attack. It is appreciated that the server and the network node, while in the protection mode, are using more resources to protect themselves from the reflection DDoS attack as compared to the normal operation mode. Hence, by switching the server and the network node back to the normal operation mode, the performance of the server and the network node is improved.

The method 100 is used for protecting against reflection distributed denial of service, DDoS, attacks, such as for preparing the filter using information specific to the reflection DDoS attacks in order to make the filter more accurate and less likely to block the benign requests. The method 100 does not rely on signatures created for known vulnerabilities, however, the method 100 uses information that is specific to the reflection DDoS attacks to prepare the filter. Thus, the method 100 is resilient against zero-day attacks. The method 100 is cost-effective and easier to deploy and does not require complex software and hardware configurations for implementation of the method 100.

The steps 102 to 116 are only illustrative, and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

FIG. 2A is a block diagram illustrating a network node, in accordance with an embodiment of the present disclosure. With reference to FIG. 2A, there is shown a diagram 200A illustrating implementation of a network node 202 configured for protection against reflection DDoS attacks. The network node 202 is connected to a server 204 through a network 206.

The network node 202 corresponds to a system comprising a computer or device that is protected against the reflection DDoS attack by the implementation of the method 100. The network node 202 is configured to detect the reflection DDoS attack through receiving the unexpected reply packets from the server 204. In an implementation, the unexpected reply packets correspond to the packets that are received in response to a sequence of adversarial requests sent to the server 204 from an unexpected source. The network node 202 is further configured to obtain the attack vector information of the detected reflection DDoS attack. In an implementation, the network node 202 is configured to detect the reflection DDoS attack by the attack targeted machine (ATTM). Further, on successful detection of the reflection DDoS attack, the ATTM collects the attack vector information. As a result, the network node 202 is configured to obtain the attack vector information from the ATTM. The network node 202 is further configured to send the reflection attack complain request with the attack vector information to the server 204. In an implementation, the network node 202 complements the attack vector information by authentic details of the ATTM and provides a complimented attack vector information to the server 204 as the reflection attack complain request. The network node 202 is further configured for using a secret to operate in a protection mode by providing a target difference of benign requests of the network node 202 to the server 204 from adversarial requests of the attacker 302 if the secret is shared by the server 204 with the network node 202. In an implementation, sharing the secret prevents the attacker from blocking the server 204 from handling the benign requests from the ATTM. Once the filter is prepared, the server 204 ignores all the requests coming from the attacker and the reflection DDoS attack is blocked.

The network node 202 includes a first processor 202A, a first memory 202B, and a first interface card 202C. The first processor 202A is configured to perform program instructions of the network node 202. The Examples of implementation of the first processor 202A may include but are not limited to a central data processing device, a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a state machine, and other processors or control circuitry.

The first interface card 202C is configured to enable the network node 202 to connect to the network 206 for communicating with the server 204. Examples of implementation of the first interface card 202C, may include but are not limited to, Network Interface Cards (NICs) and Wireless Network Cards.

In accordance with an embodiment, the network node 202 is further configured to initiate no requests to the server 204 during the first period of time after sending the reflection attack complain request to the server 204, and switch into the normal operation mode after a second period of time or in the response to receiving an end of attack instruction from the server 204. In an implementation, the ATTM configured in the network node 202 is prevented from initiating the requests to the server during the first period of time, so that all the requests with the destination IP address are considered coming from the attacker as adversarial requests. Further, the ATTM configured in the network node 202 is configured to receive an end of the attack instruction from the server 204 after the second period of time for switching the network node 202 into the normal operation mode.

In accordance with an embodiment, the secret received by the network node 202 includes the change of one or more of communication settings and parameters of requests of the network node 202, or a specific piece of content to be added to requests of the network node 202 as the target difference in the protection mode. Examples of the secret may include but are not limited to a specified value 0 to 3 in a Layer 3 header (or unused Layer 3) and/or a Layer 4 header (or Layer 4 SDDS field) of the IP packets of the adversarial requests and the benign requests. This will help the server to create such a filter.

FIG. 2B is a block diagram illustrating a server, in accordance with an embodiment of the present disclosure. With reference to FIG. 2B, there is shown a diagram 200B illustrating implementation of the server 204 for protection against reflection DDoS attacks. The server 204 is connected to the network node 202 through the network 206.

The server 204 corresponds to a system including a computer or device that is prevented to be used as a reflector by the attacker 302 for launching the reflection DDoS attack. The server 204 is configured for receiving the reflection attack complain request with the attack vector information from the network node 202. In an implementation, the network node 202 complements the attack vector information by authentic details of the ATTM and provides a complimented attack vector information to the server 204 as the reflection attack complain request. The server 204 is further configured for analyzing the adversarial requests where the network node 202 is indicated as a destination during the first period of time after receiving the reflection attack complain request to obtain the attack specific information. In an implementation, after receiving the reflection attack complain request, the server 204 is configured to analyze each of the adversarial requests in the sequence of adversarial requests for obtaining the attack specific information. The server 204 is further configured for determining the attacker feature of the adversarial requests differentiating them from the benign requests of the network node 202 based on comparison of the attack vector information from the reflection attack complain request and the attack specific information. In an implementation, the server 204 is configured to compare the attack vector information that is obtained from the network node 202 and the attack specific information that is obtained by the server 204. For example, the server is configured to communicate with the network node 202 to verify the authenticity of the network node’s IP address, collect traffic details and compare various requests in order to differentiate between the adversarial requests and the benign requests. The server 204 is further configured for sharing the secret with the network node 202 to be used for implementing the traffic differentiation in the protection mode if no attacker feature is determined. This will help the server 204 to create the filter. Therefore, the sharing of the secret will only prevent requests from adversary to be blocked the server 204 and does not prevent the server 204 from handling legitimate requests from the ATTM. The server 204 is further configured for operating in the protection mode by filtering out any requests where the network node 202 is indicated as the destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined. In other words, the server 204 is configured to operate in the protection mode in two of the following conditions, such as when the attacker feature is determined or when there is no target difference. In an implementation, the server filters out any requests while operating in the protection mode.

The server 204 includes a second processor 204A, a second memory 204B, and a second interface card 204C. The second processor 204A is configured to perform program instructions of the server 204. The Examples of implementation of the second processor 204A may include but are not limited to a central data processing device, a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a state machine, and other processors or control circuitry.

The second interface card 204C is configured to enable the server 204 to connect to the network 206 for communicating with the network node 202. Examples of implementation of the second interface card 204C, but are not limited to, Network Interface Cards (NICs) and Wireless Network Cards.

In accordance with an embodiment, the server 204 is further configured for switching into the normal operation mode after the second period of time or when the end of attack is detected. Thus, either after the second period of time or an end of the attack instruction, the server 204 is not filtering out any requests and operates as the server 204 normally would.

In accordance with an embodiment, the attack vector information and/or the attack specific information includes the one or more of a communication protocol type, the identification data of the Internet Protocol, IP, packet, the destination IP address, the source IP address, the destination port, the source port, the time to live, TTL, and the request sequence number as specified in the adversarial request. The attack vector information is obtained from the ATTM configured in the network node 202 and the attack specific information is obtained from the attacker.

In accordance with an embodiment, the server 204 is further configured for analyzing fields of the Layer 3 header and/or the Layer 4 header of the IP packets of the adversarial and the benign requests for determining the attacker feature. The attacker feature includes the one or more differences between the adversarial requests from the benign requests related to the packet routing path, the lack of the network node specific information in the adversarial requests, and the parameters of the adversarial requests including the time to live, the TTL, the source IP address, the source port, and the request sequence number.

In accordance with an embodiment, the secret shared by the server 204 includes the change of the one or more of communication settings and the parameters of requests of the network node 202, or a specific piece of content to be added to requests of the network node 202 as the target difference in the protection mode. Examples of the secret may include but are not limited to a specified value 0 to 3 in the Layer 3 header (or unused Layer 3) and/or the Layer 4 header (or Layer 4 SDDS field) of the IP packets of the adversarial requests and the benign requests. This will help the server 204 to create the filter. Therefore, the sharing of the secret will only prevent requests from adversary to be blocked the server 204 and does not prevent the server 204 from handling legitimate requests from the ATTM.

FIG. 3 is a diagram that depicts a communication protocol between a network node, an attacker, and a server, in accordance with an embodiment of the present disclosure. With reference to FIG. 3, there is shown a diagram 300 that depicts an implementation of a communication protocol between the network node 202, an attacker 302, and the server 204. The communication protocol includes operations 304A to 304D.

At operation 304A, the attacker 302 is configured to generate a sequence of spoofed requests (i.e., adversary requests) specifying a destination IP of the network node 202 as the source IP. Thereafter, the server 204 is configured to send an unexpected reply packet to the network node 202. Furthermore, the network node 202 detects the reflection DDoS attack. In addition, at operation 304B, the network node 202 is configured to send the reflection attack complain request along with the attack vector information to the server 204. In an example, the reflection attack complain includes unexpected responses and corresponding details. Thereafter, the server 204 verifies the destination IP of the network node 202. The server 204 analyzes the adversarial requests and determines the attacker features of the adversarial requests. In addition, at operation 304C, the server 204 is configured to share the secret with the network node 202, to be used for implementing traffic differentiation in the protection mode if no attacker feature is determined. Optionally, the server 204 is configured to verify IP address, nonce, and the like. In an example, the server 204 is configured to adjust the server-side protection system and legitimate traffic parameters that are used in accurate differentiation between adversarial and legitimate requests. Finally, at operation 304D, the network node 202 is configured to use the secret by the network node 202 to operate in the protection mode while providing the target difference of the authentic requests (i.e., benign requests) from the spoofed requests (i.e., adversarial requests). The server 204 is configured to operate in the protection mode by filtering out any requests where the network node 202 is indicated as the destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined. In an example, the server 204 is configured to filter out any requests and determine if a marker is ok to delete the spoofed requests (i.e., adversarial requests) and allow the authentic requests (i.e., benign requests).

FIG. 4 is a diagram that depicts an implementation of a negotiation protocol between a network node, an attacker, and a server, in accordance with an embodiment of the present disclosure. With reference to FIG. 4, there is shown a diagram 400 that depicts an implementation of a negotiation protocol between the network node 202, the attacker 302, and the server 204. The negotiation protocol includes operations 404A to 4040. At operation 404A, the attacker 302 is configured to generate a sequence of adversary requests specifying the destination IP (i.e., target IP) of the network node 202 as the source IP. Thereafter, at operation 404B, the server 204 is configured to prepare an unexpected reply packet and sends the unexpected reply packets to the network node 202, such as at operation 404C. In an example, the unexpected reply packets correspond to an out of context response. Furthermore, at operation 404D, the network node 202 is configured to detect the reflection DDoS attack. Optionally, the network node 202 is configured to detect the reflection DDoS attack by using the unexpected reply packets sent by the server 204. Moreover, at operation 404E, the network node 202 is configured to prepare the attack vector information and sends the reflection attack complain request along with the attack vector information to the server 204, such as at operation 404F. After that, at operation 404G, the server 204 is configured to collect the attack specific information from the attacker 302. Moreover, at operation 404H, the server 204 is configured to compare the attack vector information and the attack specific information and determines the attacker feature based on a difference between the attack vector information and the attack specific information. At operation 4041, the server 204 is configured to share the secret with the network node 202, to be used for implementing traffic differentiation in the protection mode if no attacker feature is determined. In an implementation, the secret includes a change of one or more of communication settings and parameters of requests of the network node 202, or a specific piece of content to be added to requests of the network node 202 as the target difference in the protection mode. Therefore, at operation 404J, the network node 202 is configured to use the secret, such as to adjust communication settings.

At operation 404K, the network node 202 is configured to apply the secret. As a result, the network node 202 is configured to use the secret to operate in the protection mode with providing a target difference of the benign requests from the adversarial requests if the secret is shared by the server 204 with the network node 202. Thereafter, at operation 404L, the server 204 started operating in the protection mode by filtering out any requests where the network node 202 is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined. Moreover, at operation 404M, the server 204 is configured to determine the difference between secrets. However, if the secret is not ok or a wrong secret is obtained, then the server 204 is configured to drop the packet, such as at operation 404N. Finally, at operation 4040, the server 204 is configured to operate in normal mode. In other words, the server 204 switches into a normal operation mode after a predefined period of time or when an end of attack is detected and the network node 202 switches into a normal operation mode after the pre-defined period of time or in response to receiving an end of attack instruction from the server 204.

In an implementation, the difference in the attacker features is analyzed by comparing the attack vector information received from the network node 202 and the attack specific information received from the attacker 302. The difference in the attacker features is found in the appropriate fields of the Layer 3 header and/or the Layer 4 header of the attack vector information and/or the attack specific information. The attacker features are specifically selected based on protocol type and functionality. Optionally, the protocol type may include, but is not limited to, DNS and SNMP. Moreover, the difference in the attacker features may be found immediately while selecting the attacker features, such as the TTL, the source address, the destination address, the source port, the destination port, and the like. Hence, negotiation and adjustment are not required. In addition, when the difference in the attacker features is not found, then some of the attacker features in the benign requests are changed to create a base for the reliable traffic differentiation. In an example, the identification field may be set to a specific value for User Datagram Protocol, UDP, as well as for transmission control protocol, TCP, packets where fragmentation isn’t expected (e.g., TCP ACK messages), TTL, could be increased to create distance between adversarial TTL values and benign TTL values at the end of the network node 202. Moreover, source ports and/or the destination ports may also be changed for an appropriate period of time. In an implementation, additional attacker features may be created in a higher- level payload. In an example, several traffic differentiators may also be used in combination with the attacker features.

Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including", "comprising", "incorporating", "have", "is" used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.

Claims

1. A method (100) of protecting against reflection distributed denial of service, DDoS, attacks, the method (100) comprising: detecting a reflection DDoS attack by a network node (202) through receiving unexpected reply packets from a server (204), obtaining an attack vector information of the detected reflection DDoS attack by the network node (202), sending a reflection attack complain request with the attack vector information to the server (204) from the network node (202), analyzing by the server (204) adversarial requests where the network node (202) is indicated as a destination during a first period of time after receiving the reflection attack complain request to obtain an attack specific information, determining an attacker feature of the adversarial requests differentiating them from benign requests of the network node (202) by the server (204) based on comparison of the attack vector information from the reflection attack complain request and the attack specific information, sharing a secret with the network node (202) by the server (204), to be used for implementing traffic differentiation in a protection mode if no attacker feature is determined, using the secret by the network node (202) to operate in the protection mode with providing a target difference of the benign requests from the adversarial requests if the secret is shared by the server (204) with the network node (202), and operating the server (204) in the protection mode by filtering out any requests where the network node (202) is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined.

2. The method (100) of claim 1, further comprising: switching the server (204) into a normal operation mode after a pre-defined period of time or when an end of attack is detected, and switching the network node (202) into a normal operation mode after the pre-defined period of time or in response to receiving an end of attack instruction from the server (204).

3. The method (100) of claim 1 or 2, wherein the attack vector information and/or the attack specific information comprise one or more of a communication protocol type, an identification data of an Internet Protocol, IP, packet, a destination IP address, a source IP address, a destination port, a source port, a time to live, TTL, and a request sequence number as specified in the adversarial request.

4. The method (100) of any of claims 1 to 3, further comprising preventing the network node (202) from initiating requests to the server (204) during the first period of time after sending the reflection attack complain request to the server (204).

5. The method (100) of any of claims 1 to 4, wherein the determining of the attacker feature comprises analyzing fields of a Layer 3 header and/or Layer 4 header of IP packets of the adversarial and benign requests.

6. The method (100) of any of claims 1 to 5, wherein the attacker feature comprises one or more differences of the adversarial requests from the benign requests related to a packet routing path, a lack of a network node specific information in the adversarial requests, and parameters of the adversarial requests including a time to live, TTL, a source IP address, a source port, and a request sequence number.

7. The method (100) of any of claims 1 to 6, wherein the secret comprises a change of one or more of communication settings and parameters of requests of the network node (202), or a specific piece of content to be added to requests of the network node (202) as the target difference in the protection mode.

8. A network node (202), being configured for: detecting a reflection DDoS attack through receiving unexpected reply packets from a server (204), obtaining an attack vector information of the detected reflection DDoS attack, sending a reflection attack complain request with the attack vector information to the server (204), and using a secret to operate in a protection mode with providing a target difference of benign requests of the network node (202) to the server (204) from adversarial requests of an attacker (302) if the secret is shared by the server (204) with the network node (202).

9. The network node (202) of claim 8, being further configured for: initiating no requests to the server (204) during a first period of time after sending the reflection attack complain request to the server (204), and switching into a normal operation mode after a second period of time or in response to receiving an end of attack instruction from the server (204).

10. The network node (202) of claims 8 or 9, wherein the secret comprises a change of one or more of communication settings and parameters of requests of the network node (202), or a specific piece of content to be added to requests of the network node (202) as the target difference in the protection mode.

11. A server (204), being configured for: receiving a reflection attack complain request with an attack vector information from a network node (202), analyzing adversarial requests where the network node (202) is indicated as a destination during a first period of time after receiving the reflection attack complain request to obtain an attack specific information, determining an attacker feature of the adversarial requests differentiating them from benign requests of the network node (202) based on comparison of the attack vector information from the reflection attack complain request and the attack specific information, sharing a secret with the network node (202) to be used for implementing traffic differentiation in a protection mode, if no attacker feature is determined, and operating in the protection mode by filtering out any requests where the network node (202) is indicated as a destination that have the determined attacker feature or do not have the target difference if no attacker feature is determined.

12. The server (204) of claim 11, being further configured for switching into a normal operation mode after a second period of time or when an end of attack is detected.

13. The server (204) of claim 11 or 12, wherein the attack vector information and/or the attack specific information comprise one or more of a communication protocol type, an identification data of an Internet Protocol, IP, packet, a destination IP address, a source IP address, a destination port, a source port, a time to live, TTL, and a request sequence number as specified in the adversarial request.

14. The server (204) of any of claims 10 to 12, being configured for analyzing fields of a Layer 3 header and/or Layer 4 header of IP packets of the adversarial and benign requests for determining the attacker feature, wherein the attacker feature comprises one or more differences of the adversarial requests from the benign requests related to a packet routing path, a lack of a network node specific information in the adversarial requests, and parameters of the adversarial requests including a time to live, TTL, a source IP address, a source port, and a request sequence number.

15. The server (204) of any of claims 10 to 13, wherein the secret comprises a change of one or more of communication settings and parameters of requests of the network node (202), or a specific piece of content to be added to requests of the network node (202) as the target difference in the protection mode.