Detecting and mitigating DDoS attacks performed over a QUIC communication protocol

Abstract

A method and system for preventing a denial of service (DDoS) attack based on a quick UDP internet connections (QUIC). The system includes: extracting traffic features from at least traffic directed to a protected entity, wherein the traffic features represent behavior of QUIC user datagram protocol (UDP) traffic directed to the protected entity, wherein the extracted traffic features include at least one rate-based feature and at least one rate-invariant feature, and wherein the at least traffic includes QUIC packets; computing at least one baseline for each of the at least one rate-based feature and the at least one rate-invariant feature; and analyzing real-time samples of traffic directed to the protected entity to detect a deviation from each of the at least one computed baseline, wherein the deviation indicates a detected QUIC DDoS attack; and performing at least one mitigation action when the indication of the detected QUIC DDoS attack is determined.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Patent Application No. 16 / 731,441, filed December 31, 2019, which is currently pending, and U.S. Provisional Application No. 62 / 906,432, filed September 26, 2019, the contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates generally to network security, and more specifically to the detection and mitigation of denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks carried out on the Quick UDP Internet Connection (QUIC) communication transport layer protocol. Background Technology

[0004] The Quick UDP Internet Connection (QUIC) protocol is an improved UDP-based Internet transport protocol. Similar to the Transmission Control Protocol (TCP), QUIC serves as a transport layer for connecting computers over the Internet. QUIC offers several advantages over TCP, primarily in enhanced performance, such as reduced latency and reliability, persistent encryption security, and deployability with user-space capacity and UDP usage. Because QUIC is relatively new, its implementations are not as widespread as TCP implementations, and its corresponding security features remain fewer and less defined. However, growth in the use of QUIC as a lower-latency, higher-reliability alternative to TCP is expected in the coming years, particularly among enterprises, service providers, and cloud providers. The QUIC protocol standard is currently defined by the IETF in the QUIC working group; the current definition can be found in the Internet draft working document "IEFT QUICTRANSPORT," published by the IEFT in November 2019.

[0005] Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) attacks are types of network attacks where an attacker overloads a target computer, network infrastructure, server, or system with access requests until the target computer becomes unable to achieve its intended purpose. DoS / DDoS attacks (hereinafter collectively referred to as DDoS attacks) can potentially execute at the network layer, such as using the TCP / UDP / Internet Protocol (IP) layer, or at various application layers, such as using the HTTP / S layer. Common types of DDoS attacks include SYN flooding, abuse of the TCP protocol, protocol-dependent "handshake" routines, allowing attackers to flood the target with synchronous requests, receive acknowledgments from the target, and refuse to send the second acknowledgment expected by the target, thus leaving an incomplete pattern, exhausting the target's resources, and blocking legitimate users.

[0006] As the implementation of the QUIC protocol grows, system administrators, network designers, and individual and business users may expect to see similar attack patterns arising from the abuse of QUIC communication. DDoS attacks executed via TCP connections are relatively more difficult to detect than those executed via TCP connections.

[0007] Furthermore, the UDP library on which the QUIC protocol communicates lacks rate-invariant properties, which can be derived from TCP connections. Therefore, detecting malicious QUIC traffic and distinguishing it from legitimate flooding (e.g., fast-crowding scenarios) is significantly more difficult for QUIC connections than for TCP connections. Prior to the adoption of the QUIC protocol, mitigating DDoS attacks, particularly those against TCP-based services (web), included blocking all UDP traffic. Solutions involving blanket blocking of UDP traffic could cause unacceptable service disruptions and might be considered unacceptable mitigation measures for attacks on QUIC connections.

[0008] Furthermore, the QUIC protocol is designed to avoid the rigidity of middleware devices (e.g., security devices such as firewalls, attack mitigators, NAT devices, and others). Another challenge in analyzing QUIC traffic is that most QUIC traffic can be encrypted. Therefore, security solutions via QUIC, especially attack detection and mitigation, are more complex and challenging to implement compared to TCP-based solutions.

[0009] Furthermore, due to the relative evolution of the protocol, there is limited development and optimization of techniques for identifying, characterizing, and mitigating attacks on QUIC connections. Therefore, computers and servers communicating via QUIC are at higher risk of cyberattacks.

[0010] Therefore, it is advantageous to provide a network security solution that overcomes the aforementioned shortcomings. Summary of the Invention

[0011] The following is an overview of several exemplary embodiments of this disclosure. This overview is provided to facilitate the reader in providing a basic understanding of these embodiments, and not to completely limit the scope of this disclosure. This overview is not an extensive summary of all contemplated embodiments, and is neither intended to identify key or essential elements of all embodiments, nor to depict the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that follows. For convenience, the term "some embodiments" may be used herein to refer to a single embodiment or multiple embodiments of this disclosure.

[0012] Certain embodiments disclosed herein include methods, systems, and computer-readable media for protecting against denial-of-service (DDoS) attacks based on Fast UDP Internet Connections (QUIC). The method includes: extracting traffic features from at least traffic destined for a protected entity, wherein the traffic features represent the behavior of QUIC User Datagram Protocol (UDP) traffic destined for the protected entity, wherein the extracted traffic features include at least one rate-based feature and at least one rate-invariant feature, and wherein the at least traffic includes QUIC packets; calculating at least one baseline for each of the at least one rate-based feature and the at least one rate-invariant feature; analyzing real-time samples of traffic destined for the protected entity to detect deviations from each of the at least one calculated baseline, wherein the deviations indicate a detected QUIC DDoS attack; and performing at least one mitigation action when an indication of a detected QUIC DDoS attack is determined.

[0013] Certain embodiments disclosed herein include methods, systems, and computer-readable medium methods for protecting against Fast Denial-of-Service (DDoS) attacks based on UDP Internet Connections (QUIC). The method includes: extracting at least one rate-based feature from at least traffic directed to a protected entity, wherein the at least one rate-based feature represents the behavior of QUIC User Datagram Protocol (UDP) traffic directed to the protected entity, and wherein the at least one traffic includes QUIC packets; calculating at least one baseline for each of the at least one rate-based feature; analyzing real-time samples of traffic directed to the protected entity to detect deviations from each of the at least one calculated baseline, wherein the deviations indicate a detected QUIC DDoS attack; and performing at least one mitigation action when an indication of a detected QUIC DDoS attack is determined. Attached Figure Description

[0014] The subject matter disclosed herein is specifically pointed out and explicitly claimed in the claims at the end of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0015] Figure 1 This is a network diagram used to describe various embodiments of a detector for detecting and mitigating QUIC DDoS attacks according to embodiments.

[0016] Figure 2 This is a network diagram showing the off-path deployment of a detector according to another embodiment.

[0017] Figure 3 This is a diagram illustrating the operation of the detector according to an embodiment.

[0018] Figure 4 This is an example flowchart illustrating a method for detecting QUIC DDoS attacks according to an embodiment.

[0019] Figure 5 This is an example block diagram of a detector implemented according to an embodiment. Detailed Implementation

[0020] It is very important and noteworthy that the embodiments disclosed herein are merely examples of the many advantageous uses of the inventive teachings herein. Generally, the statements made in the specification of this application do not necessarily limit any of the various claimed embodiments. Furthermore, some statements may apply to some inventive features but not others. Generally, unless otherwise indicated, singular elements may be plural, and vice versa, without loss of generality. In the drawings, the same reference numerals refer to the same parts in several views.

[0021] Figure 1 Example network diagram 100 is shown to illustrate various embodiments for detecting and mitigating DDoS network attacks (hereinafter referred to as QUIC DDoS attacks) carried out via the QUIC communication protocol.

[0022] exist Figure 1 In the example, network 110 establishes a connection between QUIC-enabled server 120 and protected entities 130 and 135. In yet another embodiment, only one of protected entities 130 or 135 is deployed. Each protected entity may include a server, web server, media server, etc. Each such server may be implemented as a physical server or a virtual entity (e.g., a function, software container, microserver, etc.).

[0023] In the example deployment, Figure 1The diagram also shows an End-User Device (EUD) 140, which can be any user device, such as a desktop computer, laptop, mobile device, handheld device, etc. Client device 155 and attack tool 150 are also connected to network 110 and can send QUIC traffic to protected entities 130 and / or 135. For the purpose of illustrating the disclosed embodiments, client device 155 is a legitimate client (operated by a real user and a QUIC-enabled browser), and the attack tool is operated, for example, by a bot. Furthermore, protected entity 130 is a QUIC-enabled server, and protected entity 135 is a server that communicates using the TCP protocol instead of the QUIC transport protocol.

[0024] EUD 140 can communicate with QUIC enable server 120 via the network (110 and 115) using the QUIC protocol.

[0025] Typically, network 110 can be any type of communication network, such as wireless, cellular, local area network (LAN), wide area network (WAN), the Internet, or any combination thereof. Figure 1 The diagram also shows network 115. Network 115 can be an edge network and can include enterprise data centers, enterprise systems, mobile networks, broadband networks, etc.

[0026] Detection of QUIC DDoS attacks is performed by defense system 101, which is configured to perform various disclosed embodiments. Defense system 101 includes detector 160 and mitigator 170. In one embodiment, defense system 101 is embedded between protected entities 130, 135 and network 110, and is configured to inspect inbound and outbound traffic to and from entities 130, 135 and EUD 140. In another example embodiment, defense system 101 is configured to inspect only inbound traffic.

[0027] In another embodiment, such as Figure 2 As shown, defense system 101 is deployed outside the path and configured to receive traffic signatures from the protected entity and networks 110 and 115. The embodiments used to analyze traffic to detect and mitigate attacks are similar in both deployments. It should be noted that when receiving various traffic signatures from network 110, Figure 2 The deployment in [the system / platform] also enables protection of Network 110 from QUIC-based DDoS attacks. See [reference / reference / etc.] for details. Figure 1 The embodiments are discussed to facilitate understanding of the examples based on the embodiments.

[0028] Mitigator 170 can be used to mitigate detected DDoS attacks. Mitigator 170 may include traffic cleanup functions (to remove malicious traffic and return clean traffic to the protected entity), resources configured to generate web and other challenges, alerting systems, and any combination thereof. Detection and mitigation of QUIC DDoS attacks may include mechanisms for handling and preventing various types of such attacks, including but not limited to QUIC UDP flooding, QUIC connection flooding, and QUIC HTTP flooding, where all attacks are executed in various ways via the QUIC communication protocol. In an example embodiment, attack tool 150 may use each of the above methods individually for a period of time, or a combination of these attack types simultaneously.

[0029] Defense system 101 continuously inspects inbound traffic, and in this embodiment, continuously inspects QUIC traffic entering and exiting protected entities 130, 135, network 110, network 115, and EUD 140. In a typical deployment, traffic entering and exiting protected entities 130 and 135 exhibits relatively high capacity and consistency. However, QUIC traffic entering and exiting EUD 140 (as an endpoint) exhibits "bursting" characteristics, with relatively low capacity and sparse traffic cycles.

[0030] To launch various strategies for QUIC flood attacks, attack tool 150 uses QUIC UDP traffic to generate a malicious and meticulously planned flood of UDP traffic destined for a victim. Attackers who abuse the QUIC protocol to generate DDoS flood attacks may employ several methods to execute QUIC-based DDoS attacks. Attacks can be executed using a single method or as a multi-vector attack consisting of combinations of possible methods.

[0031] Attack tool 150 can generate attacks in the form of QUIC UDP floods, specifically using QUIC UDP traffic (ports 443 or 80) to generate a flood of unstructured QUIC UDP traffic directed to the protected entity. In this case, the traffic generated by attack tool 150 does not need to conform to the QUIC protocol standard. The attack is performed by simply sending a very large stream of QUIC traffic consisting of QUIC long header and / or QUIC short header packets. In another example, attack tool 150 can use a network layer DDoS flooding attack tool (e.g., HPING with or without spoofing its IP address) instead of the full QUIC stack to achieve its goal by flooding the victim's network infrastructure. Here, attack tool 150 abuses the fact that UDP traffic cannot be blocked to mitigate UDP-based flooding.

[0032] In yet another example, attack tool 150 is used to perform a QUIC HTTP flooding attack by simulating legitimate QUIC traffic using QUIC traffic itself, in order to generate a large amount of UDP traffic that overwhelms network infrastructure and potentially overwhelms the resources of the protected entity. The attack traffic is fully compliant with the QUIC standard and therefore consists of a flood of “legitimate” QUIC connections. In yet another example, attack tool 150 uses an HTTP / 3-based flooding tool or similar tool that uses QUIC as the transport layer.

[0033] In yet another example, attack tool 150 performs a QUIC connection flooding attack by sending a large number of QUIC connection initiation requests to a designated destination victim 130 or 135 over a short period of time—that is, a flooding of QUIC long headers or initial packets with requests to initiate QUIC connections. The number of such requests can range from thousands to hundreds of thousands or even millions per second. The requests are then accepted by the protected entity (e.g., entity 130), and a new connection is initiated. Attack tool 150 can continue sending QUIC connection initiation requests regardless of whether the protected entity 130 (or even an embodiment of 135) responds to such requests.

[0034] QUIC connection flooding can also be a form of flooding "stateful" QUIC connections. In this case, the attack tool 150 is fully compliant with the QUIC standard and is able to complete the connection setup and use these established QUIC connections to overwhelm the QUIC-enabled protected entity 130 with a large number of parallel QUIC connections, including combinations of large numbers of bytes and packets, long durations, short durations, and such strategies.

[0035] QUIC DDoS attacks can originate from the internet or within a service provider's network. QUIC attacks can target the IP addresses of an organization's "online" services. Furthermore, some QUIC attack traffic may target the organization's NAT address instead of the address of the organization's connection service. This example primarily occurs when the target is EUD140.

[0036] In summary, the main types of QUIC DDoS attacks include QUIC UDP flooding, QUIC HTTP flooding, and QUIC connection flooding. QUIC UDP flooding attacks are characterized by a massive influx of UDP traffic overwhelming network infrastructure, or by a large number of QUIC connection requests overwhelming server resources. QUIC HTTP flooding attacks are characterized by a massive influx of QUIC connection traffic overwhelming network infrastructure, and a large number of concurrent QUIC connections overwhelming server resources. QUIC connection flooding attacks are characterized by a massive influx of QUIC connection ingress traffic overwhelming network infrastructure, and / or a large number of QUIC connection requests overwhelming server resources, and / or a large number of concurrent QUIC connections overwhelming server resources.

[0037] To protect protected entities and network infrastructure, Defense System 101 provides a variety of protections. These protections include: QUIC “flooding” protection to prevent the malicious increase of UDP bytes and / or packets; QUIC “connection initiation” protection to prevent the malicious increase of QUIC long header packets; and QUIC “connection restriction” protection to prevent the malicious increase of the number of existing / new QUIC connections.

[0038] Examples of QUIC connection transports can include QUIC packets, QUIC streams, and QUIC frames. After a QUIC connection is established or set up, a client node connects to its peer node (e.g., a server or host node). The established connection has a specified UDP communication port, typically, but not exclusively, port 443 or port 80, and a unique QUIC connection ID.

[0039] QUIC connections support transport features traditionally supported by both TCP and TLS protocols, including but not limited to transport handshake, congestion control and avoidance, flow control, TLS 1.3 encrypted handshake, and other security features. Each QUIC connection is identified based on source and destination connection IDs. Connection IDs do not uniquely identify individual QUIC connections, and because connection IDs can be updated during a QUIC connection, several connection IDs can be identified for the same single QUIC connection. It should also be noted that the actual definition of QUIC protocol behavior is an ongoing effort by the IETF QUIC WG.

[0040] In examples illustrating the content of QUIC packets as defined by the IETF QUIC WG, a QUIC packet can consist of an unencrypted header and an encrypted payload. Therefore, two types of QUIC packets are defined as long-header QUIC packets and short-header QUIC packets.

[0041] Long header QUIC packets are sent together with a plaintext long header and a QUIC packet encrypted payload, and are used during the QUIC connection handshake process to establish a QUIC connection and exchange various attributes (primarily transport and cryptographic attributes) about the peer system. Long header plaintext QUIC packets can be identified by "header format bits," which appear in plaintext within the QUIC header. The long header also includes a destination connection ID and a source connection ID, as plaintext attributes, simply identifying the QUIC connection to which the long header QUIC packet belongs. In embodiments, the actual QUIC connection initiation request is executed by a specific type of long header QUIC packet, the "initial packet."

[0042] Short header QUIC packets are sent using a plaintext short header and are used once the QUIC handshake is established to transmit data over the QUIC connection. Short header QUIC packets can also be easily identified by the plaintext "header format bits". Short header QUIC packets may also include a plaintext destination connection ID, allowing for simple identification of the QUIC connection to which the packet belongs.

[0043] According to the disclosed embodiments, by continuously inspecting the plaintext information in the plaintext long header and short header of the QUIC packets, the defense system 101 is configured to detect and mitigate abnormal traffic and the various situations described above, as well as other DDoS attacks.

[0044] In an embodiment, the number of long header packets per second directed to the protected entity is proportional to the number of QUIC connections that its client (e.g., client device 155 or attack tool 150) attempts to establish. Therefore, anomalies detected in this property can be used as an indicator of a flood of QUIC connections in the form of a large number of requests to initiate QUIC connections.

[0045] In another example, the number of QUIC long header packets of type "Initial Packet" can also provide a more granular assessment of the number of QUIC connections, clients, or attack tools that a connected user might attempt to establish. This feature is extracted by counting the number of long header packets of type "Initial Packet" received during a predefined time period.

[0046] In another embodiment, the number of obviously active Connection IDs (defined as the number of unique connection IDs of packets sent over a predetermined time period) appearing in the short header and in the long header, packets, and packets pointing to the protected entity can be proportional to the number of concurrent active QUIC connections. Therefore, anomalies detected on this attribute can be used as indicators of QUIC connection flooding in the form of legitimate connections initiated by an attacker and involving a large number of concurrent QUIC connections. Similarly, counting the number of obviously new active Connection IDs appearing in the short and long header packets sent to the protected entity can be proportional to the rate of new active QUIC connections over a period of time. Anomalies can be detected on this attribute to further serve as indicators of QUIC connection flooding QUIC DDoS attack types.

[0047] In the example embodiment, the number of bytes and packets exceeding the active connection ID appearing in the short and long header packets sent to the protected entity can be proportional to the average size of the QUIC connection. Anomalies detected on this property can be used as indicators of QUIC HTTP flooding and QUIC connection flooding. Here, anomalies can be detected based on an increase or decrease in the average QUIC connection size.

[0048] The aforementioned attributes are primarily measured in the inbound direction, i.e., from network 110 to the protected entity. It should be understood that these flow attributes can also be measured in the opposite outbound direction.

[0049] Therefore, to detect and mitigate anomalous traffic patterns, defense system 101 can be configured to evaluate certain rate-based attributes and certain rate-invariant attributes, continuously using these attributes as baselines and searching for anomalies in these attributes over time. Rate-based attributes are needed to detect increases in traffic rate or flooding across various QUIC traffic components, while rate-invariant attributes are used to distinguish between malicious flooding or attacks and legitimate flooding, such as in fast-moving crowds.

[0050] According to the disclosed embodiments, detector 160 performs detection of various types of QUIC DDoS attacks. To this end, detector 160 is configured to extract traffic features including rate-based and constant-rate traffic characteristics. Each type of QUIC DDoS attack can be detected using a suitable set of traffic features. Traffic features are extracted from inspected traffic or received telemetry. The extracted features are baselined, and any anomalies are then detected based on their respective baselines and comparisons of these baselines with corresponding real-time values. In yet another embodiment, detector 160 is configured to extract and analyze only rate-based features.

[0051] exist Figure 3 The operation of detector 160 is further illustrated. When deployed in-line, detector 160 is configured to receive inbound / outbound traffic to and from protected entities 130 and 135, and extract traffic features from the received traffic. In an example implementation, feature extraction engine 310 is configured to extract or otherwise compute traffic features. Various example embodiments for feature extraction are discussed herein. In yet another implementation, where outbound traffic may be unavailable because detector deployment may be asymmetric, feature extraction is performed only on inbound traffic.

[0052] According to the disclosed embodiments, in order to provide QUIC flood protection, it is necessary to first detect QUIC flooding. To this end, the following rate-based traffic characteristics are extracted: the number of long header packets per second; the total number of QUIC packets per second; and the total number of QUIC bytes per second (i.e., the bandwidth or total cumulative bytes contained in QUIC packets in the last second). In addition, the following rate-invariant traffic characteristics are extracted: the average size of QUIC packets with long and short headers; the long header ratio, i.e., the ratio between QUIC long header packets (and bytes) and total QUIC packets (and bytes), and the ratio between QUIC long header packets (and bytes) and short header packets (and bytes); and the number of bytes and packets per active connection ID for both long and short headers.

[0053] To provide QUIC "connection initiation" protection, it is required to first detect anomalous conditions on request groups of QUIC connections initiated to protected entities 130 and 135. For this purpose, the following rate-based traffic characteristics are extracted: the number of long header packets per second; and the number of long header packets per second set to "initial packet". Additionally, the following rate-invariant traffic characteristics are extracted: the ratio between the number of packets with long headers set to "initial packet" and the total number of packets with long headers; the ratio between packets with long headers and packets with long headers set to "initial packet"; the ratio between packets with long headers and client greeting packets; the ratio between client greeting packets and long header packets; and the ratio between packets with long headers and all traffic (in bytes and packets). These characteristics can generally be referred to as the long header ratio.

[0054] To provide QUIC “connection restriction” protection, it is required to first detect anomalies in the number of existing and new QUIC connections managed by protected entities 130 and 135. To this end, the following rate-based traffic characteristics are extracted: the number of active connection IDs per second; and the number of new active connection IDs per second. Additionally, the following rate-invariant traffic characteristics are extracted: an increase in the average number of bytes per active connection ID for both long and short headers; and a decrease in the average number of bytes per active connection ID for both long and short headers.

[0055] Extracting the aforementioned traffic characteristics involves monitoring UDP ports (e.g., port 443 or port 80) and examining the clear headers of the QUIC protocol. The headers are plaintext headers (i.e., unencrypted). There are two types of headers: long and short, specified using "header format bits," set to the value "1" (long header) or "0" (short header).

[0056] In order to extract the number of long header packets per second, detector 160 is configured to count all packets received on the UDP port for each time frame (e.g., 1 second), where the "header format bit" is set to "1" (i.e., long header).

[0057] To extract the number of QUIC packets per second, detector 160 is configured to count all packets received on the UDP port for each time frame (e.g., 1 second). To extract the number of bytes per second, detector 160 is configured to count all bytes on all data packets received on the UDP port for each time frame (e.g., 1 second). To extract the average QUIC packet size feature, detector 160 is configured to divide the number of QUIC packets per second by the number of bytes per second. To extract the long header portion feature, detector 160 is configured to divide the number of long header packets per second by the number of QUIC packets per second. To extract the long header with the initial packet portion feature, detector 160 is configured to divide the number of long header packets per second by the number of QUIC long header packets with the initial packet type per second.

[0058] To extract the average number of bytes and packets per active connection ID, detector 160 is configured to count all traffic received on a QUIC UDP port belonging to each active connection ID. This includes the bytes and packets of traffic with both short and long headers. Detector 160 is then configured to sum all counts and divide by the number of active connection IDs. The connection ID is specified in the header. It should be noted that each QUIC connection is identified based on the source and destination connection IDs. The connection ID does not uniquely identify a single QUIC connection, and since the connection ID can be updated during a QUIC connection, several connection IDs can be identified for the same single QUIC connection.

[0059] like Figure 3 As further demonstrated, the extracted features are fed into baseline engines 320-1, 320-2, and 320-3, each configured to run on a set of features exhibiting the behavior of different types of QUIC DDoS attacks, such as... Figure 3The example is marked. It should be noted that a baseline can be calculated for each traffic characteristic (rate-based and rate-invariant).

[0060] Each baseline engine 320 can employ various techniques to compute the baseline for each traffic characteristic. However, since QUIC traffic can exhibit “bursting” characteristics (such as addressing to EUD 140), the baseline is computed by factoring such bursting behavior (i.e., high bursts followed by periods of no traffic on UDP with high levels of traffic (legitimate or attacking)).

[0061] A baseline based on rate or rate-invariant characteristics is calculated during the learning period, which can be set to a predefined time window or until sufficient data is loaded and collected. The baseline is established during normal times or data is loaded during normal times, i.e., when no attack traffic is detected. The baseline for each characteristic can be calculated continuously based on samples of various traffic characteristics of the inspected traffic. In embodiments, the baseline is primarily determined during “burst” (active traffic) periods and rarely during “down” periods.

[0062] In one embodiment, two types of baselines are calculated for each traffic characteristic: a short-term baseline and a long-term baseline. The short-term baseline is calculated for short-term changes, i.e., changes over a relatively short period. A short-term period could be, for example, one hour. The short-term baseline is used to track hourly changes in QUIC traffic, thus detecting anomalies caused by relatively rapid changes in QUIC traffic behavior, such as those observable during an attack. It is valuable to track hourly changes in traffic to eliminate high attack thresholds during both high and low time periods, and also to track changes in legitimate traffic during busy or similar periods.

[0063] Long-term baselines are calculated over a long period, reflecting changes in traffic over a long-term cycle. A long-term cycle could be, for example, one week. Long-term baselines are used to detect anomalies caused by slow changes in traffic behavior. Long-term baselines complement short-term baselines because they eliminate the possibility of attackers "slowly" altering attack loads, in which case the attack load could be calculated as a legitimate baseline.

[0064] Long-term baselines can be calculated using IIR LP filters configured with low-frequency defined passbands and stopbands (e.g., on the order of approximately 1 / week), while short-term baselines can be calculated using IIR LP filters with higher passband and stopband filters (e.g., on the order of 1 / hour and 1 / minute, respectively). Two baselines are maintained for each flow characteristic. It should be noted that each baseline is continuously updated.

[0065] To account for the bursty behavior of the monitored traffic, particularly for EUD 140 traffic, a baseline is calculated based on the following assumptions: A high-traffic UDP burst followed by a period of zero traffic is expected to be either legitimate traffic or an attack. Furthermore, during the learning period, a portion of the legitimate traffic X needs to be continuously calculated, where X can be user-defined and may range from 30% to 50%. Additionally, during continuous baseline calculation, any calculated baseline values ​​below the percentage X need to be eliminated. The percentage X should be updated promptly.

[0066] Similarly, only when the real-time traffic value is higher than X percent of the traffic, the counting of burst characteristics of the monitored rate-constant traffic attributes is actively performed, especially for traffic addressed to EUD 140.

[0067] The baselines calculated by baseline engines 320-1, 320-3, and 320-3 are fed into the corresponding anomaly detection engines 330-1, 330-3, and 330-3. Each of engines 330-1, 330-3, and 330-3 is configured to detect various deviations from the determined baseline to detect flow anomalies.

[0068] In this embodiment, anomaly detection is performed by dynamically learning the typical maximum deviation of various traffic features from their instantaneous computational baselines during normal periods. A real-time sample of each traffic feature is considered an anomaly if it exceeds the baseline by an amount equal to or greater than / more than the maximum deviation over a period of time.

[0069] As an example, the abnormal baseline threshold can be determined as follows:

[0070] U(t) = Y(t) + maxDev(t)

[0071] Where U(t) is the anomaly threshold, Y(t) is the baseline, and maxDev(t) is the maximum deviation of the traffic characteristic observed during normal time, which corresponds to the desired false alarm detection rate for the observed traffic characteristic. For a given false alarm rate, maxDev(t) is considered the maximum “legitimate” deviation from the instantaneous baseline; it is also updated with each new sample.

[0072] The maxDev value is calculated during the learning period and normal time, serving as a measure of the actual legitimate deviation of various traffic characteristics from the instantaneous baseline. The maxDev value allows for anomaly detection because it compares legitimate deviations in traffic (due to legitimate traffic statistics) with deviations caused by malicious activity. maxDev is calculated separately for short-term and long-term baselines.

[0073] In this embodiment, maxDev is calculated by multiplying the standard deviation of the measurement σ by a constant multiplier ρ, i.e.:

[0074] maxDev=ρσ

[0075] Since the standard deviation is measured for various relevant flow characteristics and other features, it is calculated over a normal time period against the corresponding baseline for each of the aforementioned flow characteristics. The value of the multiplier ρ can be correlated with the expected false alarm detection for the observed feature. The multiplier ρ is a pre-configured parameter that defines the sensitivity.

[0076] In yet another exemplary embodiment, maxDev is calculated based on the value of the difference "Δ" between the current sample and the calculated short-term, and in a separate calculation, maxDev is also calculated based on the indices of the last highest FP×N samples from the long-term, baseline, and the virtual set phantom from the last N samples, where FP is the allowed false alarm rate. "Δ" n The samples in the set are sorted in descending order, and the entire virtual set is updated continuously. That is, the maxDev value can be calculated as follows:

[0077]

[0078] To detect anomalies, for each traffic feature, its real-time value (e.g., the real-time average packet size value) is compared to a threshold of its corresponding baseline. Illegal deviations from the corresponding baseline threshold are identified as anomalies. In this embodiment, an anomaly indication is issued only after multiple predefined consecutive anomalies with the same features or characteristics associated with the same type of attack are detected.

[0079] To detect various QUIC DDoS attacks, engines 340-1, 340-3, and 340-4 are each configured to analyze rate-based and rate-invariant detected anomalies and determine when to launch an actual DDoS attack. In one embodiment, a DDoS attack indication is triggered when an anomaly is detected on at least one rate-invariant traffic feature and at least one traffic-invariant feature. In yet another embodiment, fuzzy logic can be implemented between these various features to generate attack indication logic. In yet another example implementation, only rate-based features are analyzed, such that a DDoS attack indication is triggered when an anomaly is detected on at least one rate-based traffic feature.

[0080] return Figure 1According to the example embodiment, one or more mitigation actions performed by the mitigator 170 can be used to mitigate a detected attack. Such actions include sending alerts, blocking traffic from a source suspected to be the attack tool 150, limiting traffic rates, applying one or more web challenges or QUIC-based challenges, etc. Mitigation actions can include combinations of mitigation actions, and such combinations can be in an ascending order. The mitigation action to be applied can be selected based on the type of detected QUIC DDoS attack, the profile of the protected resource, or any combination thereof. For example, a QUIC-based challenge can be used to mitigate a QUIC flooding attack. However, this action cannot be used to provide QUIC connection restriction protection.

[0081] Similarly, for Figure 2 In another example embodiment, a detected attack can be mitigated using one or more mitigation actions deployed off-path and performed by mitigator 170. When an attack is detected on protected entities 130 and / or 135, attack traffic is directed to mitigator 170 to perform one or more of the aforementioned mitigation actions.

[0082] In this embodiment, the QUIC-based challenge is based on a mechanism defined by the IETF QUIC WG in the QUIC communication protocol standard. This mechanism is the QUIC address verification process, which aims to provide protection against amplified DDoS attacks by enabling QUIC servers to verify client IP addresses as “real IPs” rather than spoofed, deceptive IP addresses. Here, mitigator 170 is configured to inspect source traffic with valid IPs, rather than stateless bot traffic. Upon detecting an attack, mitigator 170 is configured to initiate its own address verification process on each new client source IP address detected by mitigator 170. In this embodiment, the address verification process is implemented for a partial list of new source IPs, and mitigator 170 is also configured to identify a list of IP addresses suspected of being those of attack tool 150 launching a malicious QUIC UDP flood attack. Traffic from entities that fail the address verification process can be blocked or rate-limited by mitigator 170.

[0083] Network challenges can also be used to distinguish between legitimate sources and stateless bots. In an embodiment, the mitigator 170 is configured to challenge suspicious sources using encrypted client-side network challenges, such as, but not limited to, 302 HTTP redirect messages, redirect scripts, CAPTCHA challenges, etc.

[0084] In this embodiment, mitigation measures can be based on signature generation, such as a 1000-byte QUIC UDP packet (port 443) with a long header, or a QUIC UDP packet (DEST port 443) with source port "123456" and TTL=50. This mitigation measure can effectively combat QUIC UDP flooding attacks that do not conform to the QUIC standard.

[0085] According to an embodiment, detector 160 is configured to detect attacks targeting protected entities 130 and 135. Protected entities 130 and 135 may also be affected if network 115 becomes congested due to a flood attack on EUD 140. In other cases, a burst of legitimate traffic from QUIC-enabled server 120 to EUD 140 is not expected to indicate an attack, as baseline calculation eliminates the "silent" period and expects high periods to introduce legitimate rate-constant behavior.

[0086] When directly attacking protected entity 130, attack tool 150 can abuse QUIC to open UDP ports, launching QUIC DDoS floods of various types and quantities towards protected entity 130 and its QUIC-enabled services. Attack patterns can include UDP packet flooding and QUIC connections. This pattern can be generated by attack tool 150 to conform to or not conform to the QUIC protocol standard. It should be noted that traffic between protected entity 130 and attack tool 150 can be considered and act as legitimate traffic when not detected.

[0087] It should be noted that TCP-based DDoS detection technology will detect legitimate QUIC traffic (on the connection marked 103) between EUD 140 and QUIC-enabled server 120 as an attack, thus generating false alarms.

[0088] It should be understood that implementing a QUIC attack detection and mitigation solution can prove useful because it is applied to QUIC traffic originating within an organization or from service providers and the global Internet (WWW) and directed to external targets. In this case, malicious traffic should be distinguished from legitimate inbound and outbound QUIC traffic. As QUIC DoS / DDoS attacks targeting outside the organization's network can still consume valuable network resources, thereby reducing the organization's capacity, such attacks are well-suited for rapid detection and mitigation.

[0089] In this embodiment, the defense system 101 can be deployed on a cloud computing platform and / or on-premises, working together. The cloud computing platform can be, but is not limited to, a public cloud, a private cloud, or a hybrid cloud. When installed in the cloud, the defense system can operate like a SaaS.

[0090] In further embodiments, multiple detectors and mitigators can be used to perform various disclosed embodiments. The detectors and mitigators can be configured with different capacities and / or resources and can be further deployed in various locations within the network, such as embedded or out-of-path deployments, to provide multi-layered defense. Example arrangements, configurations, and orchestrations of multi-layered mitigation systems are disclosed in U.S. Patent No. 9,769,201, assigned to a common assignee, which is incorporated herein by reference.

[0091] It should be noted that, although in Figure 1 and Figure 2 This document describes only one attacker device, a QUIC-enabled protection entity, a non-QUIC-enabled protection entity, an EUD, and a QUIC-enabled server for simplicity; however, the embodiments disclosed herein can be applied to multiple such components. These components can be located in different geographical locations.

[0092] It should also be noted that, for reference Figure 3 All or some of the engines discussed can be implemented in software, firmware, hardware, or any combination thereof. Hardware can be implemented to include at least processing circuitry and memory, examples of which are provided below. In an embodiment, defense system 101 may include all or even a partial list of the detection and mitigation mechanisms described herein.

[0093] Figure 4 An exemplary flowchart 400 according to an embodiment is shown, illustrating a method for detecting and mitigating QUIC DDoS attacks. Detected QUIC DDoS attacks may include, for example, QUIC UDP flooding, QUIC HTTP flooding, QUIC connection flooding, etc. The method may be performed by detector 160.

[0094] In S410, traffic features are extracted from inbound and outbound traffic to or from the protected entity. In an embodiment, traffic features are extracted from, for example, telemetry collected by the protected entity. Traffic features include rate-based features and rate-invariant features, and represent the behavior of UDP traffic to the protected entity. Different sets of traffic features can be used to detect each type of QUIC DoS attack. Examples of rate-based traffic features include: the number of long header packets per second, the number of QUIC packets per second, and the number of QUIC bytes per second, the number of long header packets set as "initial packets" per second, the number of active connection IDs per second, and the number of new active connection IDs per second. Examples of rate-invariant traffic features include: average QUIC packet size, long header ratio, bytes per active connection ID, and the average number of packets, the long header ratio, and increases and decreases in the average number of bytes per active connection ID. Various example embodiments for traffic feature extraction have been discussed above.

[0095] In S420, at least one baseline is calculated for each extracted traffic feature. Baselines can be calculated during a learning period, which can be set to a predefined time window or configured to end when sufficient data is loaded and collected. Baselines can also be established during normal times or data can be loaded during normal times, i.e., when no attack traffic is detected.

[0096] According to the disclosed embodiments, at least one baseline is continuously calculated based on samples of flow characteristics to determine the normal activity of the detected flow based on rate-based and constant-rate characteristics. As described above, two types of baselines, short-term and long-term baselines, can be calculated for each flow characteristic.

[0097] In S430, after baselineization of the rate-based flow characteristics and the rate-invariant flow characteristics, various deviations from the calculated baseline are detected as flow anomalies. In this embodiment, anomaly detection is performed by dynamically learning the typical maximum deviation of the flow from its instantaneously calculated baseline during normal time. A state where a real-time sample of each flow characteristic continuously equals or exceeds the maximum deviation / the amount of the maximum deviation exceeds the baseline for a period of time is considered an anomaly.

[0098] In this embodiment, the baseline threshold can be determined as follows:

[0099] U(t)=Y(t)+maxDev

[0100] Where U(t) is the anomaly threshold, Y(t) is the baseline, and maxDev is the maximum deviation of the traffic characteristics observed during the normal time period, corresponding to the desired false alarm detection rate of the observed traffic characteristics. maxDev is considered the “legitimate” deviation from the instantaneous baseline.

[0101] maxDev is continuously calculated during the learning period and normal time, serving as a measure of the actual legal deviation of various flow characteristics from the instantaneous baseline. maxDev is calculated separately for short-term and long-term baselines. An example of calculating the maxDev value is discussed above.

[0102] In S440, once baselines for various flow characteristics have been calculated, estimated flow telemetry or instantaneous real-time flow characteristic values ​​are compared to these baselines to determine if anomalies exist. Each flow telemetry is established for its corresponding baseline (short and long, or short or long alone). Anomalies are detected as deviations from one of the short or long baselines. When maxDev is used as the baseline threshold, each sample is compared to the baseline threshold U(t). When a sample exceeds the threshold consecutively a certain number of times, an alarm is generated and triggered.

[0103] In one embodiment, the anomaly can be calculated as the deviation from one of two rate-based baselines as follows:

[0104] Y[t]>Y baseline +ρ*σ

[0105] In the embodiment, Y[t] is the current sample, Y baseline Here, σ is the short-term or long-term baseline, ρ is the corresponding variance, and ρ is a pre-configured parameter defining the sensitivity. An anomaly alarm is only issued after a configurable series of consecutive detections that satisfy the above equation. In an embodiment, a predefined number (e.g., 5 or 10) of consecutive detections can be considered an alarm.

[0106] In S450, based on the anomaly indication (detected anomaly), it is determined whether any type of QUIC DDoS attack is currently underway. If so, proceed to S460; otherwise, return to S410. For each attack type, an attack is detected when anomalies are measured on at least one rate-based traffic characteristic and at least one rate-invariant traffic characteristic.

[0107] For example, a QUIC UDP flood attack is detected when anomalies are detected in the characteristics of the number of long header packets per second and the average number of bytes per second. Any of the characteristics described above for detecting QUIC UDP flood attacks can be utilized.

[0108] At S460, upon detecting a QUIC DDoS attack, at least one mitigation action is triggered. In an embodiment, triggering a mitigation action at S460 may include providing instructions to a mitigator to perform the mitigation action. Such actions may include generating an alert, automatically finding an attack signature and using that signature to block additional packets, causing clients to perform web challenges or QUIC challenges, redirecting traffic to a cleanup center, blocking traffic, limiting traffic rates, and combinations thereof. As mentioned above, mitigation actions can be selected based on the type of attack detected.

[0109] Figure 5 This is an example block diagram of a detector 160 implemented according to an embodiment. Detector 160 includes processing circuitry 510 coupled to memory 515, storage device 520, and network interface 540. In another embodiment, components of detector 160 may be communicatively connected via bus 550.

[0110] The processing circuit 510 can be implemented as one or more hardware logic components and circuits. For example, but not limited to, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), or any other hardware logic component that can perform computation or other information manipulation.

[0111] Memory 515 may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof. In one configuration, computer-readable instructions for implementing one or more embodiments disclosed herein may be stored in memory 520.

[0112] In another embodiment, memory 515 is configured to store software. Software should be interpreted broadly to mean any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or others. Instructions may comprise code (e.g., in source code format, binary code format, executable code format, or any other suitable code format). When executed by one or more processors, the instructions cause processing circuitry 510 to perform the various processes described herein. Specifically, when executed, the instructions cause processing circuitry 510 to perform the embodiments described herein.

[0113] The memory 520 may be a magnetic storage device, an optical storage device, etc., and may be implemented, for example, as flash memory or other storage technologies, a CD-ROM, a Digital Versatile Disk (DVD), or any other medium that can be used to store the desired information. The memory 520 may include the workflow scheme described herein.

[0114] Processing circuitry 510 is configured to detect and mitigate HTTPS flooding attacks and any encrypted DDoS attacks as described herein. Network interface 540 allows detector 160 to communicate with protected entities and networks 110 ( Figure 1 ) communication.

[0115] It should be understood that the embodiments described herein are not limited to those described herein. Figure 5 The specific architecture shown is illustrated, and other architectures can be used equivalently without departing from the scope of the disclosed embodiments. It should also be noted that detector 170 can be adapted to... Figure 5 The architecture shown is used for construction.

[0116] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Furthermore, the software is preferably implemented as an application tangibly embodied in a program storage unit or a computer-readable medium including components, or as certain devices and / or combinations of devices. The application can be uploaded to and executed by a machine including any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPU”), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code or an application, or any combination thereof, which can be executed by the CPU, whether or not such a computer or processor is explicitly shown. Furthermore, various other peripheral units may be connected to the computer platform, such as additional data storage units and printing units. Additionally, a non-transitory computer-readable medium is any computer-readable medium other than volatile propagating signals.

[0117] All examples and conditional language listed herein are intended for educational purposes to help the reader understand the principles of the disclosed embodiments and the inventors' concepts for contributing to the prior art, and should be interpreted as not being limited to such specifically listed examples and conditions. Furthermore, all statements herein listing the principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to include equivalents of their structure and function. Additionally, such equivalents are intended to include both currently known equivalents and those developed in the future, i.e., any element developed that performs the same function, regardless of its structure.

[0118] As used herein, the phrase "at least one" followed by a list of items means that any one of the listed items can be used alone, or any combination of two or more of the listed items can be used. For example, if the system is described as including "at least one of A, B, and C", then the system may include A alone; B alone; C alone; 2A; 2B; 2C; 3A; a combination of A and B; a combination of B and C; a combination of A, B, and C; a combination of 2A and C; a combination of A, 3B, and 2C; and so on.

[0119] It should be understood that any reference to elements using designations such as "first," "second," etc., herein does not generally limit the number or order of those elements. Rather, these designations are generally used herein as a convenient way to distinguish two or more elements or instances of elements. Therefore, references to first and second elements do not imply that only two elements may be used there or that the first element must somehow precede the second element. Moreover, unless otherwise stated, a set of elements includes one or more elements.

Claims

1. A method for preventing denial-of-service (DoS) attacks based on Fast User Datagram Protocol (UDP) Internet connections (QUIC), comprising: Extracting traffic features from QUIC traffic directed to a protected entity, wherein the traffic features specifically indicate the behavior of the QUIC traffic directed to the protected entity, wherein the extracted traffic features include at least one rate-based feature of the QUIC traffic and at least one rate-invariant feature of the QUIC traffic, and wherein the QUIC traffic includes QUIC packets. For each of at least one rate-based feature of the QUIC traffic and at least one rate-invariant feature of the QUIC traffic, calculate at least one baseline; as well as After calculating at least one baseline for each of at least one rate-based feature and at least one rate-invariant feature, real-time samples of traffic directed to the protected entity are analyzed to detect deviations from each of the at least one calculated baseline, wherein the deviations indicate a detected QUIC DoS attack. as well as When an indication of a detected QUIC DoS attack is determined, at least one mitigation action is performed.

2. The method according to claim 1, further comprising: Extract traffic characteristics from traffic directed to the protected entity.

3. The method according to claim 1, wherein extracting the flow characteristics further comprises: Monitor at least one UDP port at the protected entity to analyze the QUIC packets received through the UDP port, thereby determining at least the type of each packet, wherein the packet type includes any one of the following: QUIC short header packet, QUIC long header packet, and QUIC long header packet designated as the initial packet type.

4. The method of claim 1, wherein extracting at least one rate-based feature of the QUIC traffic further comprises any one of the following: Count the number of QUIC packets and bytes designated as short header packets received during a predefined time frame; as well as Count the number of QUIC packets and bytes designated as long header packets received during a predefined time frame; as well as Count the number of QUIC packets and bytes that are long header packets of the initial packet type received during a predefined time frame.

5. The method of claim 1, wherein extracting the flow characteristics further comprises: Count the number of QUIC packets with short headers and QUIC packets with long headers received on the UDP port, as well as the number of bytes received. as well as Divide the number of bytes and QUIC packets by the number of active connection IDs.

6. The method according to claim 1, wherein, Based on the type of QUIC DoS attack and the protection required under the corresponding attack type, determine at least one extracted rate-based feature and the at least one rate-invariant feature, wherein the attack type is any of the following: QUIC UDP flooding, QUIC HTTP flooding, and QUIC connection flooding, and wherein the required protection includes any of the following: QUIC flooding, QUIC connection initiation; and QUIC connection restriction.

7. The method of claim 6, wherein at least the rate-based features providing QUIC flood protection include the number of long header packets per second; the number of QUIC packets per second; and the number of QUIC bytes per second, and wherein, At least one rate-invariant flow characteristic providing the QUIC flood protection includes the average QUIC packet size with long and short headers; and the long header ratio. And the number of bytes for each active connection ID in the long and short headers and the number of QUIC packets.

8. The method according to claim 6, wherein, The at least rate-based traffic characteristics used to provide QUIC connection initiation protection include the number of long header packets per second; and the number of long header packets per second set as "initial packet", wherein the at least one rate-invariant characteristic used to provide the QUIC connection initiation protection includes a long header ratio.

9. The method according to claim 6, wherein, The at least rate-based traffic characteristics providing QUIC connection limit protection include the number of active connection IDs per second and the number of new active connection IDs per second, and wherein the at least rate-constant characteristics providing the QUIC connection limit protection include an increase in the average number of bytes per active connection ID and a decrease in the average number of bytes per active connection ID.

10. The method of claim 1, wherein analyzing real-time samples of traffic directed to the protected entity to detect deviations further comprises: The real-time samples of the at least one rate-based feature and at least one rate-invariant feature are compared with at least one corresponding baseline; as well as An anomaly is detected when at least one of the following occurs: the at least one rate-based feature and the at least one rate-invariant feature deviate from the at least one corresponding baseline by reaching a threshold.

11. The method of claim 10, wherein calculating at least one baseline further comprises: A short-term baseline and a long-term baseline are calculated based on the real-time samples, wherein the short-term baseline is adapted to relatively rapid changes in the QUIC UDP traffic, and the long-term baseline is adapted to relatively slow changes in the QUIC UDP traffic.

12. The method of claim 11, wherein calculating at least one baseline further comprises: The breakdown is characterized by periods of no traffic followed by periods of high bursts of traffic, including QUIC UDP packets.

13. The method according to claim 10, wherein, The threshold is dynamically updated as follows: U(t) = Y(t) + maxDev; Where U(t) is the anomaly threshold, Y(t) is the baseline, and maxDev is the maximum deviation of the traffic characteristics observed during the normal time period corresponding to the desired value of the false alarm detection rate of the observed traffic characteristics.

14. The method according to claim 1, wherein, When at least one anomaly is detected in each of at least one rate-based feature and at least one rate-invariant feature, at least one mitigation action is performed.

15. The method according to claim 1, wherein, The mitigation actions include at least one of the following: web challenge, QUIC challenge, traffic blocking, rate limiting, attack signature generation, and alarm generation, wherein one or more mitigation actions can be executed in an ascending order.

16. The method of claim 1, wherein the method is performed by a defense system, wherein the defense system is embedded in the traffic between client devices accessing the protected entity, wherein the protected entity is deployed as at least one of: a QUIC-enabled server and a non-QUIC-enabled server, and a network.

17. The method of claim 1, wherein the method is performed by a defense system deployed outside the path between client devices accessing the protected entity, wherein the protected entity is deployed as at least one of: a QUIC-enabled server and a non-QUIC-enabled server, and a network.

18. The method of claim 1, wherein the method is performed by a defense system, wherein the defense system is installed as a permanently online deployment in a cloud defense platform, wherein the cloud defense platform is deployed on the path between the client device and the protected entity.

19. A non-transitory computer-readable medium storing instructions for causing processing circuitry to perform the method of claim 1.

20. A system for preventing denial-of-service (DoS) attacks based on Fast User Datagram Protocol (UDP) Internet connections (QUIC), comprising: Processing circuitry; as well as The memory contains instructions that, when executed by the processing circuitry, configure the system to: Extracting traffic features from traffic directed to a protected entity, wherein the traffic features specifically indicate the behavior of QUIC traffic directed to the protected entity, wherein the extracted traffic features include at least one rate-based feature of the QUIC traffic and at least one rate-invariant feature of the QUIC traffic, and wherein the QUIC traffic includes QUIC packets; For each of at least one rate-based feature of the QUIC traffic and at least one rate-invariant feature of the QUIC traffic, calculate at least one baseline; as well as After calculating at least one baseline for each of at least one rate-based feature and at least one rate-invariant feature, real-time samples of traffic directed to the protected entity are analyzed to detect deviations from each of the at least one calculated baseline, wherein the deviations indicate a detected QUIC DoS attack. as well as When an indication of a detected QUIC DoS attack is determined, at least one mitigation action is performed.

21. The system of claim 20, wherein the system is further configured to: Extract traffic characteristics from traffic directed to the protected entity.

22. The system of claim 20, wherein the system is further configured to: Monitor at least one UDP port at the protected entity to analyze the QUIC packets received through the UDP port, thereby determining at least the type of each packet, wherein the packet type includes any one of the following: QUIC short header packet, QUIC long header packet, and QUIC long header packet designated as the initial packet type.

23. The system according to claim 20, wherein, To extract at least one rate-based feature of the QUIC traffic, the system is also configured to perform any of the following: Count the number of QUIC packets and bytes designated as short header packets received during a predefined time frame; as well as Count the number of QUIC packets and bytes designated as long header packets received during a predefined time frame; as well as Count the number of QUIC packets and bytes that are long header packets of the initial packet type received during a predefined time frame.

24. The system of claim 20, wherein the system is further configured to: Count the number of QUIC packets with short headers and QUIC packets with long headers received at the UDP port, and the number of bytes received. Divide the number of bytes and QUIC packets by the number of active connection IDs.

25. The system according to claim 20, wherein, The at least one extracted rate-based feature and the at least one rate-invariant feature are determined based on the type of the QUIC DoS attack and the protection required under the corresponding attack type, wherein the attack type is any of the following: QUIC UDP flooding, QUIC HTTP flooding, and QUIC connection flooding, and wherein the required protection includes any of the following: QUIC flooding, QUIC connection initiation; and QUIC connection restriction.

26. The system of claim 25, wherein at least rate-based features providing the QUIC flood protection include the number of long header packets per second; the number of QUIC packets per second; and the number of QUIC bytes per second, and wherein, At least one rate-invariant flow characteristic providing the QUIC flood protection includes the average QUIC packet size with long and short headers; and the long header ratio. The number of packets per active connection ID in the long and short headers.

27. The system according to claim 25, wherein, The at least rate-based features used to provide the QUIC connection-initiated protection include the number of long header packets per second; and the number of long header packets per second set as "initial packets", wherein the at least one rate-invariant feature used to provide the QUIC connection-initiated protection includes a long header ratio.

28. The system according to claim 25, wherein, The at least rate-based features for providing the QUIC connection limit protection include the number of active connection IDs per second; and the number of new active connection IDs per second, wherein the at least rate-constant features for providing QUIC connection limit protection include an increase in the average number of bytes per active connection ID; and a decrease in the average number of bytes per active connection ID.

29. The system of claim 25, wherein the system is further configured to: Compare real-time samples of the at least one rate-based feature and at least one rate-invariant feature with at least one corresponding baseline; and An anomaly is detected when at least one of the following occurs: the at least one rate-based feature and the at least one rate-invariant feature deviate from the at least one corresponding baseline by reaching a threshold.

30. The system of claim 25, wherein the system is further configured to: A short-term baseline and a long-term baseline are calculated based on the real-time samples, wherein the short-term baseline is adapted to relatively rapid changes in the QUIC UDP traffic, and the long-term baseline is adapted to relatively slow changes in the QUIC UDP traffic.

31. The system of claim 25, wherein the system is further configured to: The breakdown is characterized by periods of no traffic followed by periods of high bursts of traffic, including QUIC UDP packets.

32. The system according to claim 24, wherein, The threshold is dynamically updated as follows: U(t) = Y(t) + maxDev; Where U(t) is the anomaly threshold, Y(t) is the baseline, and maxDev is the maximum deviation of the traffic characteristics observed during the normal time period corresponding to the desired value of the false alarm detection rate of the observed traffic characteristics.

33. The system of claim 20, wherein the system is further configured to: When at least one anomaly is detected in each of at least one rate-based feature and at least one rate-invariant feature, at least one mitigation action is performed.

34. The system according to claim 20, wherein, The mitigation actions include at least one of the following: web challenge, QUIC challenge, traffic blocking, rate limiting, attack signature generation, and alarm generation, wherein one or more mitigation actions can be executed in an ascending order.

35. The system of claim 20, wherein the system is embedded in traffic between client devices accessing the protected entity, wherein the protected entity is deployed as at least one of: a QUIC-enabled server and a non-QUIC-enabled server, and a network.

36. The system of claim 20, wherein the system is deployed outside the path between client devices accessing the protected entity, wherein the protected entity is deployed as at least one of: a QUIC-enabled server and a non-QUIC-enabled server, and a network.

37. The system of claim 20, wherein the system is installed as a permanently online deployment in a cloud defense platform, wherein the cloud defense platform is deployed on the path between the client device and the protected entity.

38. A method for preventing denial-of-service (DoS) attacks based on Fast User Datagram Protocol (UDP) Internet connections (QUIC), comprising: Extract at least one rate-based feature from QUIC traffic directed to the protected entity, wherein the at least one rate-based feature specifically indicates the behavior of the QUIC traffic directed to the protected entity, and wherein the QUIC traffic includes QUIC packets; Calculate at least one baseline for each of at least one rate-based feature of the QUIC traffic; After calculating at least one baseline, real-time samples of traffic directed to the protected entity are analyzed to detect deviations from each of the at least one calculated baseline, wherein the deviations indicate detected QUIC DoS attacks. as well as When an indication of a detected QUIC DoS attack is determined, at least one mitigation action is performed.

39. The method of claim 38, wherein extracting the at least one rate-based feature further comprises: Count the number of QUIC packets designated as short header packets received during a predefined time frame; as well as Count the number of packets designated as long header packets received during a predefined time frame; as well as Count the number of packets with long headers that are designated as the initial packet type and received during a predetermined time frame.

40. The method of claim 38, wherein at least one extracted rate-based feature is determined based on the type of the QUIC DoS attack and the protection required under the corresponding attack type, wherein the attack type is any one of: QUIC UDP flooding, QUIC HTTP flooding, and QUIC connection flooding, and wherein, The required protections include any of the following: QUIC flooding, QUIC connection initiation; And QUIC connection limitations.

41. The method of claim 40, wherein at least rate-based features providing the QUIC flood protection include the number of long header packets per second; the number of QUIC packets per second; and the number of QUIC bytes per second.

42. The method according to claim 40, wherein, The at least rate-based features providing protection for the QUIC connection include the number of long header packets per second; and the number of long header packets per second set to "initial packet".

43. The method according to claim 40, wherein, The at least rate-based features used for QUIC connection initiation protection include the number of active connection IDs per second; and the number of new active connection IDs per second.

44. A non-transitory computer-readable medium storing instructions for causing processing circuitry to perform the method of claim 38.

45. A system for preventing denial-of-service (DoS) attacks based on Fast User Datagram Protocol (UDP) Internet connections (QUIC), comprising: Processing circuitry; And a memory containing instructions that, when executed by the processing circuitry, configure the system to perform the method according to claim 38.

Images