In an implementation, all components of the infrastructure 200 may be co-located in a same installation, for example being part of a same datacenter. In another implementation, some of the components of the infrastructure 200 may be distant from other components of the infrastructure 200, geographically separated components of the infrastructure communicating via the Internet or via a private network. In an illustrative but non-limiting example, servers providing services to customers of the infrastructure may be installed in large numbers in many locations while, in the same example, components of the system for defending against DoS attacks may be installed in a limited number of locations.

In some non-limiting implementations of the present technology, the communication network 50 may be implemented as the Internet. In other implementations of the present technology, the communication network 50 can be implemented differently, such as any wide-area communication network, local-area communication network, a private communication network and the like. How the communication links between the devices 20 and the infrastructure 200 are implemented will depend inter alia on how the devices 20 and the infrastructure 200 are implemented. The infrastructure 200 includes one or more data processing entity 210 (e.g. servers) to provide a given service to the devices 20. In some non-limiting implementations, the infrastructure 200 is a datacenter.

In use, each device 20 may transmit, over the communication network 50, a connection request 22 to the infrastructure 200 to establish a communication session therewith. The ensemble of the connection requests for the infrastructure 200 may be referred to as a “traffic” for that service provide 200. However, in some instances, one or more malicious devices 20 may transmit malicious connection requests 22′ that are part of a DoS attack. For example, a given malicious device 20 or a group of malicious devices 20 may transmit a substantially high number of concurrent connection requests to make the infrastructure 200, a given data processing entity 210 thereof or a group of data processing entities 210, unavailable to other devices 20 by temporarily or indefinitely disrupting services of the infrastructure 200.

In the context of the present disclosure, a given data processing entity 210 or a group of data processing entities 210, physical and/or virtual, to which a device 20 desires to establish a communication session with is referred to as a “destination device” for that device 20. For example, a data processing entity 210 may be hardware equipment (e.g. a server) or a service (e.g. a website or a database) provided by hardware equipment.

In order to mitigate attacks on the infrastructure 200, the communication environment 1000 includes a detection service 100 communicably connected to the infrastructure 200. An implementation of the detection service 100 is described in greater details herein after (see FIG. 6). For example and without limitation, the detection service 100 may be operated by one or more servers. In alternative non-limiting implementations of the present technology, the functionality of the detection service 100 may be distributed and may be implemented via multiple servers.

Even though the detection service 100 is depicted separately from the service provider, functions of the detection service 100 described herein may be performed by the infrastructure 200.

As will be described in greater details herein below, the detection service 100 may execute an authentication protocol pipeline that may leverage different computational resources at different stages of the authentication protocol pipeline, and may effectively prevent DoS attacks and recognize them before they can cause considerable damages to the service provider and/or legitimate devices 20. The detection service 100 receives the connection requests 22 before a communication session is established between the devices 20 that transmitted connection requests 22 and the infrastructure 200. The detection service 100 may thus prevent a communication session to be established in response to a malicious network event being identified. As it will be described in greater details herein after, the detection service 100 may execute a mitigation execution module 164 (see FIG. 2) in response to a DoS attack being detected.

FIG. 2 is a block diagram of an authentication protocol pipeline 150 that may be executed by the detection service 100 in response to receiving a new connection request 22. In this implementation, each connection request 22 transmitted by a given device 20 desiring to establish a communication session with a target device includes a communication dataset including:

- information about a source IP address of the given device 20;
- information about a source port of the given device 20;
- information about a destination IP address of a corresponding destination device;
- information about a destination port of the corresponding destination device; and
- information about a protocol used for communication between the given device 20 and the corresponding destination device.

Execution of the authentication protocol pipeline 150 will now be described with reference to FIGS. 2, 4A and 4B. It should be noted that the authentication protocol pipeline 150 is a modular pipeline, and that some modules thereof may be executed in different orders and/or omitted in alternative implementations.

Event Merging Module

The authentication protocol pipeline 150 includes an event merging module 152 that receives the connection request 22, or “network events”, and extract the above information therefrom. The event merging module 152 may cluster connection requests based on the source IP address, the destination IP address, the destination port and/or the destination port of each of the connection requests 22. For example, connection requests 22 having a first destination IP address are clustered by the event merging module 152 as a first connection cluster, and connection requests 22 having a second destination IP address are clustered by the event merging module 152 as a second connection cluster. Sub-clusters may also be identified by the event merging module 152. For example, connection requests 22 having the first destination IP address and a first source IP address are identified by the event merging module 152 as a first sub-cluster of the first connection cluster, and connection requests 22 having the first destination IP address and a second source IP address are identified by the event merging module 152 as a second sub-cluster of the first connection cluster.

Broadly speaking, the event merging module 152 may deserialize network events and merge them into a given data format used by the detection service 100 for statistical analysis thereof. This module handles different input formats as they can vary depending on the type of equipment from which the connection requests are received. For example, the network events may have a NetFlow data format, a sFlow data format or a kFlow data format.

In some implementation, the event merging module 152 converts a data format of the received connection requests into a same given data format. This may further case a clustering of the connection requests. For example, a first connection request received at the event merging module 152 may have a NetFlow data format, and a second connection request received at the event merging module 152 may have a sFlow data format. The event merging module 152 may converts the data formats of the first and second connection requests into the kFlow data format (or any other data format) prior determining whether or not the first and second connection requests belong to a same connection cluster.

The event merging module 152 may further forward information about the connection clusters to a high-rate DoS attack coarse detection module 154. In some non-limiting implementations, the event merging module 152 forwards information about the connection clusters to a high-rate DoS attack coarse detection module 154 only for the groups that include at least a pre-determined number of connection requests 22.

High-Rate DoS Attack Coarse Detection Module

In this implementation, the high-rate DoS attack coarse detection module 154 executes a high-rate DoS attack coarse detection algorithm that determines, for each connection cluster, a first confidence score based on the communication datasets extracted from the connection requests 22 of the connection cluster. The first confidence score is indicative of a first probability that the connection cluster is associated with a high-rate DoS attack. The high-rate DoS attack coarse detection algorithm may include statistical tests to determine the first confidence score, as described in “A New Detection Method for Distributed Denial-of-Service Attack Traffic based on Statistical Test”, by Chin-Ling Chen and published in January 2009 by The Journal of Universal Computer Science. Alternatively, the high-rate DoS attack coarse detection algorithm may be implemented as described in “Real-time DoS attack detection using FPGA”, by N. Hoquea, H. Kashyapb and D. K. Bhattacharyya, and published in September 2017 in Computer Communications, the entirety of which is incorporated by reference for jurisdictions allowing such incorporation. Yet alternatively, the high-rate DoS attack coarse detection algorithm may be implemented as described in “Detecting Distributed Denial of Service Attacks by Sharing Distributed Beliefs” by Tao Peng, Christopher Leckie and Kotagiri Ramamohanarao, and published as a conference paper in January 2003, the entirety of which is also incorporated by reference for jurisdictions allowing such incorporation.

Broadly speaking, in some implementations, DoS detection algorithms described in the present disclosure may implement threshold algorithms in which a threshold value, or set of threshold values, is used to distinguish ranges of values in which what is predicted by the model varies significantly. In use, a threshold algorithm may define a threshold value for acceptable traffic and detect a DoS attack when this threshold value is exceeded. Threshold algorithms are relatively easy to implement and inexpensive in resources, but can lead to false alarms or fail to detect low rate attacks.

In addition or alternatively, the DoS detection algorithms described in the present disclosure may implement packet distribution analysing algorithms. The DoS detection algorithms parse through the statistical distribution of packets of the traffic (e.g., connection requests) to detect anomalies in the traffic data. DoS detection algorithms may be suitable for detection of low rate attacks, but may require a large amount of data for reliable statistical analysis. DoS detection algorithms may also be affected by background noise.

In addition or alternatively, the DoS detection algorithms described in the present disclosure may implement behavior analysing algorithms that learn normal traffic patterns to detect anomalies and abnormal behavior. The behavior analysing algorithms may detect low-rate attacks with high accuracy, but at the expense of a large amount of training data which therefore and can therefore be resource intensive to implement.

In addition or alternatively, the DoS detection algorithms described in the present disclosure may implement sequence analysing algorithms that parse through packet sequences to detect anomalies such as repeated sequences of similar packets. The algorithms are effective in detecting low rate attacks, but may require a significant amount of memory to store the packet sequences.

In addition or alternatively, the DoS detection algorithms described in the present disclosure may implement Machine Learning Algorithms (MLA) such as deep learning algorithms, clustering algorithms, neural networks, logistic regression algorithms, decision trees, principal component analysis, and/or Support Vector Machine (SVM)-based algorithms. More specifically, neural networks are deep learning algorithms that can be used to detect DoS attacks by learning from network traffic data. Neural networks can be used to detect anomalies in network traffic and distinguish legitimate from malicious traffic. Decision tree-based algorithms are classification algorithms that can be used to detect DoS attacks by classifying network traffic into different categories. Decision tree-based algorithms may be trained on network traffic data to identify the characteristics of DoS attacks and use them to detect future attacks. SVM-based algorithms are classification algorithms that can also be used to detect DDoS attacks. SVMs can be trained on network traffic data to find decision boundaries that distinguish legitimate from malicious traffic. These illustrative implementations of machine learning algorithms may detect complex attacks that cannot be detected by signature-based methods.

The MLAs may have been trained to detect anomalies in the traffic data using historical data. They can detect low and high-rate attacks with high accuracy, but require a significant amount of training data and can be resource intensive to implement. These algorithms can be used independently or in combination for more accurate detection of low and high-rate DoS attacks. In addition, higher-performance DoS detection algorithms require more resources to implement, but can also provide more accurate and reliable detection of DoS attacks.

Summarily, the DoS detection algorithms described in the present disclosure may implement, one or more of the following algorithms, alone or in collaboration: threshold algorithms, packet distribution analysing algorithms, behavior analysing algorithms, sequence analysing algorithms and MLAs.

In response to the first confidence score being below a first threshold (i.e. the first probability being indicative that the connection cluster does not constitute a high-rate DoS attack), the connection cluster is not considered as a high-rate DoS attack by the high-rate DoS attack coarse detection module 154, and the detection service 100 and may execute a low-rate DoS attack coarse detection module 160 that is described in greater details herein after. In an implementation, the first threshold is 15%.

In the context of the present disclosure, thresholds associated with confidence scores of DoS algorithms may be defined based on a plurality of parameters including:

- Data Distribution parameter: the threshold for anomaly detection may be at least partly based on a statistical distribution of traffic data;
- Detection Objective parameter: the threshold for anomaly detection may be at least partly based on a desired alert rate and/or a tolerable false positive rate;
- Traffic history parameter: the threshold for anomaly detection may be at least partly based on a traffic history used to determine normal and abnormal traffic variations;
- Desired accuracy: the threshold for anomaly detection may be at least partly based on a desired balance between accuracy and false positives; and/or
- Type of attack: the threshold for anomaly detection may be at least partly based on a type of attack, as some attacks may be more difficult to detect than others.

Broadly speaking, in the context of the present disclosure, for a given data processing entity 210 adapted for receiving, at most, a maximum traffic data rate (e.g. a maximum number of connection requests per second that can be handled), a high-rate DoS attack has a rate of more than about one percent of the maximum traffic data rate, and a low-rate DoS attack (e.g. a Economic Denial of Sustainability (EDoS) attack) has a rate of less than about one percent of the maximum traffic data rate. For a given service (e.g. a client of the infrastructure 200 providing a service hosted by the data processing entities 210), a DoS attack is considered to be a high-rate DoS attack when it constitutes more than 50% of the traffic for The service, while it is considered to be a low-rate DoS attack when it constitutes less than 50% of the traffic for The service.

In response to the first confidence score being above a second threshold (i.e. the first probability being indicative that the connection cluster constitutes a high-rate DoS attack), the connection cluster is considered as a high-rate DoS attack by the high-rate DoS attack coarse detection module 154. The detection service 100 thus executes a mitigation execution module 164. Execution of the mitigation execution module 164 may include generation of a mitigation order and/or transmission of information about the connection cluster to an anti-DoS attack dedicated system (not shown). The anti-DoS attack dedicated system may perform additional analysis on the connection clusters received from modules of the authentication protocol pipeline 150. For example, the anti-DoS attack dedicated system may implement mitigation measures consisting of filtering illegitimate connection requests while letting legitimate connection requests access the infrastructure 200. The anti-DoS attack dedicated system may be implemented as described in the European Patent Application No. 3618355, titled “SYSTEMS AND METHODS FOR OPERATING A NETWORKING DEVICE” and filed on Aug. 27, 2018, the entirety of which is also incorporated by reference herein. In an implementation, the second threshold is 85%.

In response to the first confidence score being above the first threshold and below the second threshold, the detection service 100 executes a flash-crowd detection module 156 adapted to detect flash-crowd events. In the context of the present disclosure, a flash-crowd event occurs when a substantially high number of legitimate connection requests 22 are received to establish communication sessions with the same destination device. Broadly speaking, a flash-crowd event happens when the destination device is unable to handle the volume of legitimate connection requests. In opposition to malicious connection requests, connection requests that form a flash-crowd event are legitimate.

Broadly speaking, the high-rate DoS attack coarse detection module 154 identifies high-rate DoS attacks and uses limited computational resources and processing resource allocation such as, for example and without limitation, power processing resource allocation and/or memory allocation, to separate possibly suspicious traffic from legitimate traffic. In some implementations, the high-rate DoS attack coarse detection module 154 may use known heuristics. In use, the high-rate DoS attack coarse detection module 154 may detect egress and ingress DoS attacks as well as outgoing DoS attacks. If the confidence of the high-rate DoS attack coarse detection module 154 is above a predefined threshold, a mitigation event is directly issued. Otherwise, the detection service 100 proceeds with the execution of the authentication protocol pipeline 150.

Flash-Crowd Detection Module

The flash-crowd detection module 156 may execute a flash-crowd detection algorithm to establish whether the connection cluster is associated with a flash-crowd event. The flash-crowd detection algorithm may be implemented as described in “Detection of spoofed and non-spoofed DoS attacks and discriminating them from flash crowds”, by Jaideep Gera and Bhanu Prakash Battula, and published in July 2018 in EURASIP Journal on Information Security. Alternatively, the flash-crowd detection algorithm may be implemented as described in “Modeling Human Behavior for Defense Against Flash-Crowd Attacks”, by G. Oikonomou and J. Mirkovic, and published in June 2009 in 2009 IEEE International Conference on Communications, the entirety of which is also incorporated by reference for jurisdictions allowing such incorporation. Yet alternatively, the flash-crowd detection algorithm may be implemented as described in “Flash Crowd Detection Using Decoy Hyperlinks”, by Dimitris Gavrilis, Ioannis Chatzis and Evangelos Dermatas, and published in April 2007 in 2007 IEEE International Conference on Networking, Sensing and Control, the entirety of which is incorporated by reference herein.

In this implementation, the flash-crowd detection algorithm determines, for each connection cluster received from the high-rate DoS attack coarse detection module 154, a second confidence score based on the communication dataset extracted from the connection requests 22 of the connection cluster. The second confidence score is indicative of an estimation of the flash-crowd detection module 156 about whether the connection cluster is associated with a flash-crowd event.

In response to the second confidence score being below a third threshold, the connection cluster is not considered as a flash-crowd event by the flash-crowd detection module 156, and the detection service 100 executes a high-rate DoS attack fine detection module 158 that is described in greater details herein after. In response to the second confidence score being above the third threshold, the connection cluster is considered as being associated with a flash-crowd event by the detection service 100. The detection service 100 thus executes the low-rate DoS attack coarse detection module 160. In an implementation, the third threshold is 50%.

Broadly speaking, the flash-crowd detection module 156 indicates whether the suspected traffic is associated with a flash-crowd event or not. If a flash crowd is not detected, the connection requests continue to be analyzed by the detection service 100. Otherwise, the connection requests are considered legitimate. In some implementations, in response to the connection requests being deemed legitimate by the flash-crowd detection module 156 (i.e. occurrence of a flash-crowd event), the detection service 100 issues a message to the infrastructure 200 indicating that the suspicious traffic is a flash crowd event.

High-Rate DoS Attack Fine Detection Module

In this implementation, the high-rate DoS attack fine detection module 158 executes a high-rate DoS attack fine detection algorithm that generates a second confidence score indicative of a second probability that the connection cluster is associated with a DoS attack. More specifically, in some implementations, the high-rate DoS attack fine detection algorithm determines, for each connection cluster received from the flash-crowd detection module 154, a third confidence score based on the communication dataset extracted from the connection requests 22 of the connection cluster. The third confidence score is indicative of an estimation of the high-rate DoS attack fine detection module 158 about whether or not the connection cluster constitutes a high-rate DoS attack. The high-rate DoS attack fine detection algorithm may be implemented as described in “DoS Detection Method Based on Chaos Analysis of Network Traffic Entropy”, by Xinlei Ma and Yonghong Chen and published in December 2013 in IEEE Communications Letters, the entirety of which is incorporated by reference herein. Alternatively, the high-rate DoS attack fine detection algorithm may be implemented as described in “DoS Attack Detection Using Fast Entropy Approach on Flow-Based Network Traffic”, by Jisa David and Ciza Thomas, and published in May 2015 in Procedia Computer Science, the entirety of which is also incorporated by reference herein.

Broadly speaking, the high-rate DoS attack fine detection module 158 differs from the high-rate DoS attack coarse detection module 154 in the following aspects. In an implementation, connection clusters used by the high-rate DoS attack coarse detection module 154 are based on first communication datasets extracted from connection requests received at the network during a first collection time having a first time span. Upon being transmitted to the high-rate DoS attack fine detection module 158, the connection clusters are adjusted by extracting second communication datasets from connection requests received at the network during a second collection time having a second time span longer than the first time span. Therefore, the high-rate DoS attack fine detection module 158 may be more accurate in detecting attacks, but may be slower to provide a response to an attack.

In some implementations, adjusting a given connection cluster may include identifying pairs of device 20/destination device based on the communication datasets, and/or collecting additional information from the traffic data about the pairs.

Indeed, the connection cluster, after having been adjusted with additional information, may include more recognizable pattern, provide more data usable by the high-rate DoS attack fine detection module 158 compared to the input of the high-rate DoS attack coarse detection module 154. It can be said that the high-rate DoS attack coarse detection module 154 acts as a filter for the high-rate DoS attack fine detection module 158. In use, the high-rate DoS attack coarse detection module 154 may handle Terabytes of connection requests, while the high-rate DoS attack fine detection module 158 may handle Gigabytes of connection requests. The high-rate DoS attack fine detection module 158 is thus less likely to analyse a relative high amount of connection cluster and connection requests. It can thus use more time and provide more detailed analysis compared to the high-rate DoS attack coarse detection module 154.

In some implementations, an implementation complexity of the high-rate DoS attack fine detection module 158 may be greater than that of the high-rate DoS attack coarse detection module 154. For example, the execution of the high-rate DoS attack coarse detection module 154 may be constrained, for a given connection cluster, within a first processing resource allocation. In this example, the execution of the high-rate DoS attack fine detection module 158 may be constrained, for the given connection cluster adjusted during the second collection time, within a second processing resource allocation being greater than the first processing resource allocation.

In use, the high-rate DoS attack fine detection module 158 may require a significant amount of computing resources, such as memory, storage, and processing power, while the high-rate DoS attack coarse detection module 154 may require fewer resources.

Broadly speaking, an increase of the collecting time for the connection clusters used as inputs of the high-rate DoS attack coarse detection module 154 and the high-rate DoS attack fine detection module 158 may result in the following aspects. With a longer collection time, the high-rate DoS attack fine detection module 158 may analyze a larger amount of traffic data for improved attack detection. For example, by collecting data (i.e. a number of connection requests) over a longer period of time, the high-rate DoS attack fine detection module 158 may refine analyses of normal traffic patterns and thus provide a more accurate detection of anomalies indicative of a DoS attack.

In response to the third confidence score being below a fourth threshold, the connection cluster is not considered as a high-rate DoS attack by the high-rate DoS attack fine detection module 158, and the detection service 100 may execute the low-rate DoS attack coarse detection module 160. In an implementation, the fourth threshold is 50%. In response to the third confidence score being above the fourth threshold, the connection cluster is considered as a high-rate DoS attack by the detection service 100. The detection service 100 thus executes the mitigation execution module 164.

It should be note that the execution of the high-rate DoS attack coarse detection algorithm executed by the high-rate DoS attack coarse detection module 154 is constrained, for a given connection cluster, within a first processing resource allocation. The execution of the high-rate DoS attack fine detection algorithm executed by the high-rate DoS attack fine detection module 158 is constrained, for the given connection cluster, within a second processing resource allocation that is greater than the first processing resource allocation. In other words, the high-rate DoS attack fine detection module 158 may provide more accurate identification of malicious connection attempts. In use, the authentication protocol pipeline 150 causes execution of the high-rate DoS attack fine detection module 158, and involves associated relatively great processing resource allocation, in response to the high-rate DoS attack coarse detection module 154 being uncertain about an occurrence of a DoS attack. This may provide efficient and accurate detection of the DoS attacks with low computational latency.

Broadly speaking, the high-rate DoS attack fine detection module 158 is executed in response to the confidence in the decisions of the previous modules (i.e. the high-rate DoS attack coarse detection module 154 and the flash-crowd detection module 156) being below associated thresholds. In some implementations, since a smaller part of the traffic is analyzed at the high-rate DoS attack fine detection module 158, developers of the present technology have devised more resource-intensive calculations to be executed by the high-rate DoS attack fine detection module 158 in comparison to the high-rate DoS attack coarse detection module 154. This may increase an accuracy of the decision of the DoS attack detection.

In the context of the present disclosure, distinction between high-rate and low-rate attacks may be relied upon to increase an efficiency of the detection of the attack. For example, in the case of a high-rate attack, it is easier to identify the attack using methods such as Wilson's Continuity Corrected Score method. In case a low-rate attack, the identification of the attack includes discriminating malicious traffic from legitimate since the two are statistically very close. Here, statistical pattern identification methods can be used. Broadly speaking, it can be said that high-rate DoS attacks are volumetric attacks aimed at saturating a communication link, while low rate DoS attacks such as “Slowloris” attacks send attack packets to a target device at a sufficiently low-rate to try to elude detection. Low rate DoS attacks may imitate a behavior of legitimate users to exploit a flaw by requiring connection requests to a server or a device without ever establishing said connections, solely to consume computing resources of the server or device.

FIG. 3 illustrates a DoS pipeline 300 for detecting DoS attacks in accordance with some non-limiting implementations of the present technology. The pipeline 300 includes a DoS attack coarse detection module 310 and a DoS attack fine detection module 320. The DoS attack coarse detection module 310 and the DoS attack fine detection module 320 may be for example and without limitation, the high-rate DoS attack coarse detection module 154 and the high-rate DoS attack fine detection module 158 respectively, or the low-rate DoS attack coarse detection module 160 and the low-rate DoS attack fine detection module 162 respectively that are described in greater details hereinafter.

In an implementation, the DoS attack coarse detection module 310 receives communication datasets 305 about communication requests between devices 20A, 20B and 20c, and data processing entities 210A and 210B. Arrows in the representation of the communication datasets 305 in FIG. 3 are representative of communication requests and form connection clusters. It can be seen that the device 20B transmits a relatively high number of communication requests to the data processing entity 210A and that the data processing entity 210g transmits a relatively high number of communication requests to the device 20c.

In use, identification of DoS attacks by the DoS attack coarse detection module 310 is made per source IP address and per destination IP address. More specifically, the DoS attack coarse detection module 310 may identify communication requests of the traffic that involves a same source IP address. For a given source IP address, the DoS attack coarse detection module 310 further executes detection algorithms as disclosed herein to flag DoS attacks. In addition, for a given destination IP address, the DoS attack coarse detection module 310 further executes detection algorithms as disclosed herein to flag DoS attacks. It can be said that the DoS attack coarse detection module 310 aggregates connection requests per IP address (source or destination) to form the connection clusters that are further analyzed. In this implementation, the DoS attack coarse detection module 310 determines a first confidence score indicative of a first probability that a connection cluster is associated with a DoS attack. The DoS attack coarse detection module 310 may further compare the first confidence score with a first threshold, to determine whether a mitigation order is to be generated. Thresholds used by the DoS attack coarse detection module 310 to flag IP addresses may be pre-determined to reduce computation time of said identification.

Otherwise, the DoS attack coarse detection module 310 may transmit the corresponding source IP addresses and the corresponding destination IP addresses to the DoS attack fine detection module 320. In other words, the DoS attack coarse detection module 310 transmit indication of the IP addresses for which there is uncertainties about whether or not the connection requests thereto and/or therefrom are illegitimate. In some implementations, the DoS attack coarse detection module 310 may remove connection requests from the pipeline 300 in response to the confidence score being below a second threshold (i.e. the DoS attack coarse detection module 310 is confident that these connection requests are not part of a DoS attack).

Said transmission of connection clusters from the DoS attack coarse detection module 310 to the DoS attack fine detection module 320 is depicted as adjusted communication datasets 307 in FIG. 3. In this implementation, information about the devices 20 and the data processing entities 210, as well as other devices 20 and other data processing entities 210 communication therewith, involved in a communication with an IP address flagged by the DoS attack coarse detection module 310 are included in the adjusted communication datasets 307.

It can be said that an execution of the DoS attack coarse detection module 310 is a “broad detection phase” of the detection pipeline 300. For example and without limitation, the DoS attack coarse detection module 310 may receive information about between approximately 4 and 5 millions of communication requests per second.

The DoS attack fine detection module 320 further executes detection algorithm for IP addresses flagged by the DoS attack coarse detection module 310 included in the adjusted communication datasets 307. More specifically, for each IP address, the DoS attack fine detection module 320 parses through (i) the devices 20 and/or the data processing entities from which the communication requests are received, (ii) an amount of data that is exchanged therewith, (iii) the devices 20 and/or the data processing entities to which communication requests are sent and (iv) an amount of data that is exchanged therewith. As such, the DoS attack fine detection module 320 relies on pairs of IP addresses (source and destination) to identify DoS attacks.

For example and without limitation, the DoS attack fine detection module 320 may receive information about between approximately 400,000 and 500,000 communication requests per second. It should also be noted that the collection time for collecting information about the IP addresses flagged by the DoS attack coarse detection module 310 is increased upon execution of the DoS attack fine detection module 320. Indeed, given that the DoS attack fine detection module 320 has less communication requests to analyze, the collection time thereof may be increased and still provide computing times suitable to detect DoS attacks and protect the infrastructure 200 therefrom. It can be said that the connection clusters are adjusted by extracting second communication datasets from connection requests received at the network during the second collection time having a second time span longer than a first time span of the first collection time.

In this implementation, the DoS attack fine detection module 320 determines a second confidence score indicative of a second probability that a connection cluster is associated with a DoS attack. In response to the second confidence score being higher than a threshold, a mitigation order may be executed. Otherwise, the connection cluster is consider as legitimate by the DoS attack fine detection module 320. In the same or other implementations, the thresholds used by the DoS attack fine detection module 320 to flag IP addresses may be determined based on dynamic heuristics such as a current bandwidth of a flagged data processing entity, a current flow rate of the traffic received at the infrastructure 200, a reputation score of the data processing entity assigned by an operator of the infrastructure 200 and/or other dynamic heuristic to increase accuracy of the DoS attack fine detection module 320.

Broadly speaking, the DoS attack coarse detection module 310 flags IP addresses using data gathered during a first collection time, while the DoS attack fine detection module 320 flags pairs of IP addresses among the ones flagged by the DoS attack coarse detection module 310 and using data gathered during a second collection time that is greater than the first collection time. Usage of computing resources is thus substantially reduced (e.g. ten times less).

It can thus be said that the DoS attack coarse detection module 310 acts as a filter for the DoS attack fine detection module 320 by eliminating connection cluster that are most likely (i.e. relative high confidence score) to be a DoS attack and causing execution of a mitigation order in response. The DoS attack fine detection module 320 thus analyses with greater computing resources, and thus an increased accuracy, the connection clusters for which the DoS attack coarse detection module 310 was unable to make a decision about whether or not a mitigation order should be executed. The “two-stage” structure of the detection pipeline 300 may thus reduce requirement in terms of computing resources, costs and latency for detecting DoS attacks compared to known detection pipelines.

As described herein, one of the distinctions between DoS attack detection algorithms (equally referred to as “DoS attack “coarse” detection algorithms”) and DoS attack “fine” detection algorithms includes adjustment of the collection time. On the other hand, a larger number of samples is used for executing the DoS attack “fine” detection algorithms which increase the collection time and provide significantly less false positives that coarse detection algorithm.

Low-Rate DoS Attack Coarse Detection Module

In this implementation, the low-rate DoS attack coarse detection module 160 executes a low-rate DoS attack coarse detection algorithm that determines, for each connection cluster received from the high-rate DoS attack coarse detection module 154, the flash-crowd detection module 154 or the high-rate DoS attack fine detection module 158, a fourth confidence score based on the communication dataset extracted from the connection request 22 of The connection cluster.

The fourth confidence score is indicative of a third probability that the connection cluster is associated with a DoS attack. The low-rate DoS attack coarse detection algorithm may be implemented as described in “An empirical evaluation of information metrics for low-rate and high-rate DoS attack detection”, by Monowar H. Bhuyan, D. K. Bhattacharyya and J. K. Kalita and published in January 2015 in Pattern Recognition Letters, the entirety of which is incorporated by reference for jurisdictions allowing such incorporation. Alternatively, the low-rate DoS attack coarse detection algorithm may be implemented as described in “Detection of the botnets' low-rate DoS attacks based on self-similarity”, by Sergii Lysenko, Kira Bobrovnikova, Serhii Matiukh, Ivan Hurman and Olch Savenko, and published in August 2020 in International Journal of Electrical and Computer Engineering, the entirety of which is also incorporated by reference for jurisdictions allowing such incorporation.

In response to the fourth confidence score being below a fifth threshold, the connection cluster is not considered as a low-rate DoS attack by the low-rate DoS attack coarse detection algorithm, and the detection service 100 and may execute an access granting module 166 for generating a network access granting order, granting an establishment of the communication sessions and/or causing execution of additional authentication algorithms. In an implementation, the fifth threshold is 15%.

In response to the fourth confidence score being above a sixth threshold, the connection cluster is considered as a low-rate DoS attack by the low-rate DoS attack coarse detection algorithm. The detection service 100 thus executes the mitigation execution module 164. In an implementation, the sixth threshold is 85%.

In response to the first confidence score being above the fifth threshold and below the sixth threshold, the detection service 100 executes a low-rate fine detection module 162.

Broadly speaking, typical heuristics on which the low-rate fine detection module 162 is based cannot make decisions when there is a substantially high amount of traffic to analyze. As such, according to an implementation of the authentication protocol pipeline 150, the low-rate fine detection module 162 is executed when no high-rate attacks have been found or considered legitimate by the previous modules of the authentication protocol pipeline 150.

Low-Rate DoS Attack Fine Detection Module

In this implementation, the low-rate fine detection module 162 executes a low-rate fine detection algorithm that determines, for each connection cluster received from the low-rate DoS attack coarse detection module 160, a fifth confidence score based on the communication dataset extracted from the connection request 22 of the connection cluster. The fifth confidence score is indicative of indicative of a fourth probability that the connection cluster is associated with a DoS attack.

Broadly speaking, the fifth confidence score is indicative an estimation of the low-rate fine detection module 162 about whether or not the connection cluster is associated with a low-rate DoS attack. The low-rate fine detection algorithm may be implemented as described in “DoS Detection Method Based on Chaos Analysis of Network Traffic Entropy”, by Xinlei Ma and Yonghong Chen and published in December 2013 in IEEE Communications Letters, the entirety of which is also incorporated by reference for jurisdictions allowing such incorporation. Alternatively, the low-rate fine detection algorithm may be implemented as described in “An empirical evaluation of information metrics for low-rate and high-rate DoS attack detection”, by Monowar H. Bhuyana, D. K. Bhattacharyya and J. K. Kalita, and published in January 2015 in Pattern Recognition Letters, the entirety of which is also incorporated by reference for jurisdictions allowing such incorporation.

In response to the fifth confidence score being below a seventh threshold, the connection cluster is not considered as a low-rate DoS attack by the low-rate fine detection algorithm, and the detection service 100 may execute the access granting module 166. In an implementation, the seventh threshold is 50%. In response to the fifth confidence score being above the seventh threshold, the connection cluster is considered as a low-rate DoS attack by the low-rate DoS fine detection module 162. The detection service 100 thus executes the mitigation execution module 164. It can be said that the low-rate fine detection module 162 is executed when the confidence scores relative to the decisions of the previous modules of the authentication protocol pipeline 150 are below associated thresholds.

Broadly speaking, the low-rate DoS attack fine detection module 162 differs from the low-rate DoS attack coarse detection module 160 in the following aspects. In an implementation, connection clusters used by the low-rate DoS attack coarse detection module 160 are based on first communication datasets extracted from connection requests received at the network during a first collection time having a first time span. The first collection time may be the same collection time than the collection time of the high-rate DoS attack coarse detection module 154, or a different one with another time span. In some implementations, the collection time of the low-rate DoS attack coarse detection module 160 may have a higher time span than that of the high-rate DoS attack coarse detection module 154 to provide an improved detection of low-rate DoS attacks.

Upon being transmitted to the low-rate DoS fine detection module 162, the connection clusters are adjusted by extracting second communication datasets from connection requests received at the network during a second collection time having a second time span longer than the first time span. Therefore, the low-rate DoS fine detection module 162 may be more accurate in detecting attacks, but may be slower to provide a response to an attack.

Indeed, the connection cluster, after having been adjusted with additional information, may include more recognizable pattern, provide more data usable by the low-rate DoS fine detection module 162 compared to the input of the low-rate DoS attack coarse detection module 160. It can be said that the low-rate DoS attack coarse detection module 160 acts as a filter for the low-rate DoS fine detection module 162. In use, the low-rate DoS attack coarse detection module 160 may handle Terabytes of connection requests, while the low-rate DoS attack fine detection module 162 may handle Gigabytes of connection requests. The low-rate DoS fine detection module 162 is thus less likely to analyse a relative high amount of connection cluster and connection requests. It can thus use more time and provide more detailed analysis compared to the low-rate DoS attack coarse detection module 160.

In some implementations, an implementation complexity of the low-rate DoS fine detection module 162 may be greater than that of the low-rate DoS attack coarse detection module 160. For example, the execution of the low-rate DoS attack coarse detection module 160 may be constrained, for a given connection cluster, within a first processing resource allocation. In this example, the execution of the low-rate DoS fine detection module 162 may be constrained, for the given connection cluster adjusted during the second collection time, within a second processing resource allocation being greater than the first processing resource allocation.

In use, the low-rate DoS fine detection module 162 may require a significant amount of computing resources, such as memory, storage, and processing power, while the low-rate DoS attack coarse detection module 160 may require fewer resources.

Broadly speaking, an increase of the collecting time for the connection clusters used as inputs of the low-rate DoS attack coarse detection module 160 and the low-rate DoS fine detection module 162 may result in the following aspects. With a longer collection time, the low-rate DoS fine detection module 162 may analyze a larger amount of traffic data for improved attack detection. For example, by collecting data (i.e. a number of connection requests) over a longer period of time, the low-rate DoS fine detection module 162 may refine analyses of normal traffic patterns and thus provide a more accurate detection of anomalies indicative of a DoS attack. In addition, by increasing the collection time, the low-rate DoS fine detection module 162 may better detect low-rate attacks, which may be difficult to detect using a relatively short collecting time.

Summarily, the detection service 100 may, by executing the authentication protocol pipeline 150, detect low-rate and high-rate attacks with high confidence, differentiate between flash-crowd events and malicious attacks, and adapt an amount of running computational resources to determine occurrence of an attack to reduce computational latency. As can be seen, the authentication protocol pipeline 150 is a modular pipeline including a plurality of modules that may be changed in order and/or enriched from other algorithms.

FIG. 5 is a flow diagram of a method 400 for detecting Denial of Service (DoS) attacks on a network, such as the communication network 50, according to some implementations of the present technology. In one or more aspects, the method 400 or one or more steps thereof may be performed by a processor or a computer system, such as the detection service 100. The method 400 or one or more steps thereof may be embodied in computer-executable instructions that are stored in a computer-readable medium, such as a non-transitory mass storage device, load-ed into memory and executed by a CPU. Some steps or portions of steps in the flow diagram may be omitted or changed in order.

The method 400 starts with extracting, at operation 410, communication datasets from connection requests received at the network. Each communication dataset comprising a corresponding connection request and an indication of a corresponding destination device.

For example and without limitations, the communication dataset of a given connection request may include information about a source IP address of a corresponding device, information about a source port of the corresponding device, information about a destination IP address of a corresponding destination device, information about a destination port of the corresponding destination device and information about a protocol used for communication between the corresponding device and the corresponding destination device.

In some implementations, a data format of a given connection request may be a NetFlow data format, a SFlow data format or a kFlow data format.

The method 400 continues with clustering, at operation 420, connection requests based on the communication datasets to form a plurality of connection clusters. For example, the connection requests may be clustered by identifying a corresponding destination device for each of the connection request and partitioning the connection requests into connection clusters based on their corresponding destination device. The connection requests associated to a same destination device may thus be grouped in a same connection cluster.

The method 400 continues with executing, at operation 430 and for at least one connection cluster, a first DoS attack detection algorithm (e.g. the high-rate DoS attack coarse detection module 154), to generate, based on the communication datasets corresponding to the given connection cluster, a first confidence score indicative of a first probability that the connection cluster is associated with a DoS attack. In some implementations, the execution of the first DoS attack detection algorithm is constrained, for the given connection cluster, within a first processing resource allocation.

The method 400 continues with comparing, at operation 440, the first confidence score with a first threshold, to determine whether a mitigation order is to be generated