Techniques for generating application layer signatures characterizing advanced application layer flood attack tools

Abstract

Various disclosed embodiments include methods and systems for generating application layer signatures that characterize advanced application layer attacks. The method includes determining a baseline distribution of applicability of attributes included in a transaction for a protected entity during a peace period; determining an attack distribution of applicability attributes included in the transactions for the protected entity during the ongoing application layer attack; based on the application baseline distribution and the attack distribution of the application attributes, determining a probability that an attacker executes an ongoing application layer attack to generate an attack using at least one attribute; and generating an application layer signature specifying an applicability attribute determined to be qualified based on their respective probabilities, where the application layer signature characterizes a behavior of an attacker performing the ongoing application layer attack.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 477,522, filed December 28, 2022, the contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to techniques for characterizing application-layer denial-of-service (DoS)-based attacks, and more particularly, to techniques for generating application-layer signatures that characterize advanced application-layer flood attack tools. Background Art

[0004] Today, online businesses and organizations are vulnerable to malicious attacks. Recent cyberattacks have employed a wide range of attack techniques and tools to target the information maintained by online businesses, their IT infrastructure, and actual service availability. Hackers and attackers are constantly evolving their attack strategies to cause irreparable damage and overcome currently deployed protection mechanisms.

[0005] A popular network attack is a denial of service ("DoS") / distributed denial of service ("DDoS") attack, which is an attack that attempts to render a computer or network resource unavailable or idle. Common techniques for executing DoS / DDoS attacks include saturating a target victim resource (e.g., a computer, web server, API server, web application, other type of application server, etc.) with a large number of external application requests or traffic. As a result, the target victim becomes overloaded and is unable to allocate resources and properly respond to legitimate traffic or legitimate service requests. When an attacker sends many application requests or other requests to its victim services or applications, each victim resource is affected by the DoS attack. A DoS attack is executed by an attacker using a single machine, while a DDoS attack is executed by an attacker controlling many machines and other entities and directing them to collectively attack.

[0006] One type of DDoS attack is called an "application-layer DDoS attack." This is a form of DDoS attack in which attackers target application-layer processes, resources, or entire applications. This attack overuses specific functions or features of an application, disabling them and rendering the application unresponsive to legitimate requests or even terminating or crashing. A major subcategory of application-layer DDoS attacks is HTTP flooding.

[0007] In an HTTP flood attack, an attacker sends numerous manipulated HTTP GET and / or POST and / or other unwanted HTTP requests to attack or overload victim server, service, or application resources. These attacks are typically carried out by an attack tool or tools designed to generate and send a large number of "legitimate-looking" HTTP requests to the victim server. The content of these requests may be random or pseudo-random to simulate legitimate web client behavior and circumvent anti-DoS mitigation components. Examples of such tools include Challenge Collapsar (CC), Shaphyra, the Mirai botnet, the Meris botnet, Blood, MHDDoS, DDOSIA, Akira, Xerxes, web stressers, and DDoSers.

[0008] Recently, hackers have developed a plethora of new, sophisticated tools that are now being used in a variety of deadly and high-volume HTTP flood attacks. The need for simple and accurate solutions to mitigate HTTP flood attacks has become both real and urgent. Modern online services require application-based anti-DoS solutions that can characterize incoming HTTP requests generated by attackers or legitimate clients in real time with very low false positive and false negative rates. Attackers are constantly improving their attack tools by generating legitimate-looking HTTP requests, making mitigation very challenging and enabling more specific characterization of application-based attacks.

[0009] Accurately characterizing the HTTP flood attacks performed by these tools is a complex problem that is not yet achieved by currently available DDoS attack mitigation solutions. Distinguishing legitimate HTTP requests from malicious ones is a complex and arcane task. The complexity of the problem stems from the fact that there are dozens of attack tools that behave differently and produce different attack patterns. In addition, the HTTP requests sent by the attack tools have a truly legitimate structure (e.g., headers and payloads defined in the corresponding HTTP standards and following industry conventions), and some parts of their request content are complexly randomized.

[0010] For example, HTTP header values, query parameter keys and values, web cookies, etc. can all be randomly selected. In addition, due to the extremely large request volume (e.g., thousands or tens of thousands of requests per second) and the constant changes in request content, coupled with the extensive use of randomization, existing DDoS mitigation solutions are unable to effectively and accurately characterize HTTP flood application layer DDoS attacks.

[0011] Existing detection solutions rely on calculating a normal baseline during peacetime (when no attacks are active or detected), and then detecting any deviation from the baseline as an attack. A baseline is a statistical model calculated or learned based on received HTTP requests that represents the normal behavior of legitimate clients accessing protected servers. After detecting an HTTP flood attack, the normal baseline can potentially be used for practical attacker characterization tasks.

[0012] HTTP flood mitigation solutions based on legitimate baselines present significant challenges in attack characterization. One challenge lies in achieving accurate baselines for legitimate, non-stationary applications or those with low-rate, bursty traffic. Furthermore, during an attack, it's challenging to quickly and accurately learn attacker behavior and understand the attacker patterns required to generate accurate and effective application-layer signatures. These challenges are even greater when developing application-layer signatures for attacks that generate an extremely large number of random requests. In such cases, the probability of detecting and mitigating a specific attacker's pattern is relatively low.

[0013] Furthermore, since HTTPS flood attacks use legitimate-looking requests with or without large amounts of traffic and with many random patterns, it is difficult to distinguish such requests from valid legitimate traffic. Therefore, this type of DDoS attack is one of the most advanced and vulnerable security challenges facing web server and application owners today.

[0014] Therefore, to accurately and effectively characterize application-based attack tools, it is imperative to compute a unique baseline that accurately simulates the legitimate behavior of legitimate clients accessing protected servers or applications. Furthermore, during an attack, this characterization is required to accurately distinguish between various types of legitimate requests (or transactions) and a wide range of malicious requests. In all cases, the time to mitigate ("TTM") should be in the order of seconds.

[0015] Therefore, it would be beneficial to baseline and characterize HTTPS flood attacks to provide effective security solutions. Summary of the Invention

[0016] The following is an overview of several example embodiments of the present disclosure. This overview is provided for the convenience of providing the reader with a basic understanding of these embodiments and does not fully limit the breadth of the present disclosure. This overview is not an extensive overview of all contemplated embodiments and is neither intended to identify key or important elements of all embodiments nor to describe 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 a more detailed description that will be presented later. For convenience, the terms "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or more embodiments of the present disclosure.

[0017] Some embodiments disclosed herein include a method for generating an application layer signature that characterizes an advanced application layer attack. The method includes determining an application baseline distribution of attributes included in transactions against a protected entity during peacetime; determining an attack distribution of application attributes included in transactions against the protected entity during an ongoing application layer attack; determining a probability that an attacker is executing the ongoing application layer attack to generate an attack using at least one attribute based on the application baseline distribution and the attack distribution of the application attributes; and generating an application layer signature that specifies application attributes that are determined to be qualified based on their respective probabilities, wherein the application layer signature characterizes the attacker's behavior in executing the ongoing application layer attack.

[0018] Some embodiments disclosed herein include a system for generating dynamic applicability signatures using an application layer flood attack tool. The system includes processing circuitry and a memory containing instructions that, when executed by the processing circuitry, configure the system to: determine an applicability baseline distribution of attributes included in transactions against a protected entity during peacetime; determine an attack distribution of the applicability attributes included in transactions against the protected entity during an ongoing application layer attack; determine a probability that an attacker is performing an ongoing application layer flood attack to generate an attack using at least one attribute based on the applicability baseline distribution and the attack distribution of the applicability attributes; and generate an application layer signature that specifies the applicability attributes that are determined to be qualified based on their respective probabilities, wherein the application layer signature characterizes the attacker's behavior in performing the ongoing application layer attack. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims of the specification.The above and other objects, features and advantages of the invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings.

[0020] Figure 1 is a diagram for describing various embodiments for characterizing an application layer flood attack according to some embodiments.

[0021] Figure 2A is a flow chart illustrating characterization of an HTTP flood attack according to an embodiment.

[0022] Figure 2B is a flow diagram illustrating the creation of a window interpretation buffer according to an embodiment.

[0023] Figure 3 is an example structural interpretation vector generated according to an embodiment.

[0024] Figure 4 is a flowchart illustrating a process of generating a paraphrase vector according to an embodiment.

[0025] Figure 5 is an array of interpretation buffers generated according to an embodiment.

[0026] Figure 6 is a flow chart illustrating a process for generating an application layer signature characterizing an advanced application layer flood attack tool, according to an embodiment.

[0027] Figure 7 is a graph showing the transformation from a histogram to a distribution of interpretations.

[0028] Figure 8 is a block diagram of an apparatus for performing the disclosed embodiments. Specific embodiments

[0029] The embodiments disclosed herein are merely examples of the many possible advantageous uses and implementations of the innovative teachings presented herein. In general, statements in this application specification do not necessarily limit any claimed invention. Furthermore, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be plural, and vice versa, without loss of generality. In the accompanying drawings, like numbers represent like parts across multiple views.

[0030] Various disclosed embodiments include a method for baseline and characterization of HTTP flood DDoS attacks. The disclosed method characterizes malicious requests and legitimate requests to dynamically generate signatures of attack tools. The generated signatures can effectively mitigate HTTP flood attacks. In embodiments, the disclosed method can be performed by devices in an out-of-path deployment or an in-line always-on deployment. Various disclosed embodiments will be described with reference to HTTP flood DDoS attacks, but the technology disclosed herein can be used to characterize flood DDoS attacks generated by other types of application layer protocols.

[0031] According to an embodiment of the present disclosure, the signature of an attack tool is an attack interpretation distribution subtracted from a baseline interpretation distribution. This distribution is determined or otherwise calculated using an interpretation buffer. For the purposes of this disclosure and without limiting the scope of the embodiments of the present disclosure, the following terms (singular or plural) are used: interpretation; interpretation vector; interpretation buffer, which is a set of interpretation values; multiple interpretation buffers, which are a set of interpretation buffers; baseline interpretation distribution; multiple baseline interpretation distributions, which are a set of baseline interpretation distributions; attack interpretation distribution; multiple attack interpretation distributions, which are a set of attack interpretation distributions. Interpretations characterize the structure of a Layer 7 transaction (e.g., an HTTP request). That is, interpretations maintain the properties of an incoming transaction. Each interpretation contains one or more interpretation values. An interpretation vector includes a set of interpretations. Interpretations are used to generate the required application (Layer 7) signature that characterizes the application properties of the attacker to mitigate the attack.

[0032] Figure 1 1 is a diagram 100 for describing various embodiments for characterizing and mitigating HTTP flood attacks according to some embodiments. In diagram 100, client devices 120 and 125 communicate with a victim server (or simply server) 130 via a network 140. For the purposes of illustrating embodiments of the present disclosure, client device 120 is a legitimate client (operated by a real legitimate user or other type of legitimate WEB client entity), client device 125 is an attack tool (e.g., operated as a bot by a bot network), and server 130 is a "victim server," i.e., protected server 130 is under attack.

[0033] The legitimate client device 120 can be a web browser or other type of legitimate web application client or user agent executed on a computing device (such as a server, mobile device, IoT device, laptop, PC, connected device, smart TV system, etc.).

[0034] Attack tool 125 performs a malicious attack on victim server 130, specifically an HTTP flood attack. The attacker's attack tool 125 generates and sends "legitimate-looking" HTTP requests to the victim server. The attacker-generated HTTP requests have the correct structure and content required by the HTTP protocol, so these requests appear "legitimate" even though they are malicious requests generated by an attacker with malicious intent. To make attack mitigation a very complex task, the attacker makes extensive use of randomization or pseudo-randomization. In some cases, the attacker generates a large number of different "legitimate" requests while randomly selecting the requests to transmit. It should be noted that the attacker generates a large number of different HTTP requests in order to evade fingerprinting and mitigation by simple web filtering or other attack mitigation measures.

[0035] Attack tool 125 can be HTTP flood attack tool, it can use WEB proxy to deploy as bot network, also can not use WEB proxy but deploy as HTTP flood attack means. Attack tool 125 can also be deployed as WEBstresser, DDoS and other "employment DDoS (DDoS for hire)" form of attack.

[0036] The attack tool 125 generates requests with legitimate structure and content. To achieve a "legitimate structure," the attacker-generated HTTP request may include a legitimate URL in the protected application, a set of standard and non-standard HTTP headers, web cookies, and one or more query parameters. The attack tool 125 may consistently include specific HTTP headers or query parameters in the HTTP requests it generates, or randomly decide to include or exclude them in each request or set of requests it generates. The attack tool may also randomly select the attacked URL to address in each request it generates.

[0037] The request generated by the attack tool 125 may also contain legitimate and different content or values. In order to make the request "look" legitimate, the HTTP request generated by the attack tool may have an HTTP header with a legitimate value (for example, the UserAgent may be randomly selected from a predefined list of legitimate UserAgents, and a reference may be randomly selected from predefined legitimate and common WEB sites (e.g., facebook.com, google.com)).

[0038] These overall operations of attack tool 125 result in the attacker potentially sending tens of thousands or even millions of different HTTP requests to victim server 130. The attacker uses randomization to select the actual HTTP request to send to the victim in each request transmission. Therefore, simply or manually identifying millions of different attacker requests "as is" by a human operations team would be an extremely tedious task, if not impossible. It is worth noting that these tools have many mutations and variants, but still follow similar operations, generating HTTP requests as described above. Advanced attack tools are designed to bypass simple Layer 7 filtering mitigations by generating a large number of diverse and "legitimate-looking" HTTP requests. Therefore, it is impossible to characterize a dominant or frequent set of HTTP requests as being issued by attack tool 125.

[0039] Compared to attacker requests, legitimate client-generated requests are more diverse in structure. Legitimate client HTTP requests may have more HTTP headers, standard and non-standard headers, redirect to multiple URLs within the protected entity (potentially including victim server 130), have more key-value pairs in cookies, use more query parameters, and so on. Based on the higher diversity and content distribution of legitimate requests, a normal baseline for legitimate traffic applicability can be calculated, and legitimate request behavior can be accurately learned.

[0040] It should be noted that the embodiments disclosed herein are applicable when multiple attack tools are simultaneously executing attacks against the victim server 130. Similarly, a large number of legitimate client devices 120 may be operating simultaneously to receive services provided by the server 130. Both client devices 120 and 125 may reach the victim server 130 simultaneously. The network 140 may be, but is not limited to, a local area network (LAN), a wide area network (WAN), the Internet, a public or private cloud network, a cellular network and a metropolitan area network (MAN), a wireless network, an IoT network, a corporate network, a data center network, or any combination thereof.

[0041] According to an embodiment of the present disclosure, a defense system 110 (hereinafter referred to as "system 110") is deployed between a client device 120, an attack tool 125, and a victim server 130. The system 110 is connected to a characterization device 170 (hereinafter referred to as "device 170") configured to perform an embodiment of the present disclosure. Specifically, in peacetime, the device 170 is configured to analyze requests received from the system 110 and learn legitimate traffic applicability baselines. During an attack period, the device 170 uses the calculated applicability baseline to build one or more dynamic applicability signatures to characterize the HTTP requests of the attack tool 125 (or attacker). The signatures generated by the device 170 can allow mitigation measures or policy selection. Mitigation measures can be executed by the system 110. In other embodiments, mitigation measures are implemented in the device 170.

[0042] System 110 provides an indication of an ongoing attack to device 170. Techniques for detecting an ongoing attack are outside the scope of the embodiments of the present disclosure. Example techniques for detecting an ongoing Layer 7 DDoS attack can be found in U.S. Patent Application No. 18 / 058,482, entitled “TECHNIQUES FOR DETECTING ADVANCED APPLICATION LAYER FLOODATTACK TOOLS,” assigned to a common assignee and hereby incorporated by reference.

[0043] The system 110 may be deployed in serial or continuous run modes, or other types of deployments that allow for peacetime baselining of incoming application transactions.

[0044] The system 110, the device 170, and the victim server 130 may be deployed in a cloud computing platform and / or a local deployment such that they are combined or combined together. The cloud computing platform may be, but is not limited to, a public cloud, a private cloud, or a hybrid cloud. Examples of cloud computing platforms include Web Services (AWS), Metacloud, Cloud Platform, etc. In an embodiment, when the device 170 is installed in the cloud, it can be run as SaaS or as a managed security service provided as a cloud service. In an embodiment, when the device 170 is installed locally, it can be run as a managed security service.

[0045] In an example configuration, system 110 includes a detector 111 and a mitigation resource 112. Detector 111 in system 110 is configured to provide an indication of an ongoing attack. Mitigation resource 112 is configured to execute one or more mitigation measures triggered by detector 111 to mitigate the detected attack. Mitigation resources may be, but are not limited to, a scrubbing center or a DDoS mitigation appliance. In an embodiment, system 110 and / or appliance 170 are integrated into a DDoS mitigation appliance. In another embodiment, system 110 and / or appliance 170 is a multi-layer mitigation system. The arrangement, configuration, and orchestration of a multi-layer mitigation system are disclosed in U.S. Patent No. 9,769,201, assigned to a common assignee, which is incorporated herein by reference.

[0046] In an embodiment, system 110 and / or device 170 are integrated into a WAF (Web Application Firewall) device. In another embodiment, system 110 and / or device 170 are integrated into any form of web proxy or web server. In another embodiment, system 110 and / or device 170 can be integrated into a web cache system such as a CDN.

[0047] Victim server 130 is the entity to be protected from malicious threats. Server 130 can be a physical or virtual entity (e.g., a virtual machine, a software container, a serverless function, etc.). Victim server 130 can be a web server (e.g., a compromised server, a compromised online web server, a compromised web application, an API server, a mobile application, etc.).

[0048] According to an embodiment of the present disclosure, device 170 is configured to inspect application transactions received from system 110 throughout peacetime and during active attacks. These transactions are application requests, such as HTTP requests sent by legitimate client devices 120 and attack tools 125 to victim servers 130. Transactions are received at device 170 during peacetime to learn and baseline normal application behavior required for attack characterization and application signature generation, thereby accurately and effectively mitigating attacks. After detector 111 detects an active attack, device 170 continues to receive incoming transactions throughout the duration of the attack. During an active attack, device 170 is configured to analyze the received transactions and determine whether the structure of the HTTP request is that of the attack tool (125) that performed the detected attack, or a legitimate HTTP request sent by client device 120. Device 170 reports its decision on each received request to system 110. The decision can be to mitigate the request or to securely pass the request to victim server 130.

[0049] In another embodiment, to improve the efficiency and cost structure of device 170, device 170 is fed and updated by a sample of incoming HTTP transactions. The sample can be 1 out of N received transactions, the first of N transactions received in a time window, etc. In another embodiment, the sampling rate N can be different for peacetime conditions and attack time conditions to better adapt to the number of HTTP requests transmitted to the protected entity.

[0050] In order to improve efficiency and cost, other embodiments can be proposed. In this article, during active attack, device 170 is only responsible for dynamically building the required accurate signature. In addition, system 110 is responsible for the mitigation activities of each actual transaction. Device 170 is configured to continuously pass the signature to system 110, and system 110 uses the signature to mitigate the attack. During active attack, system 110 is configured to analyze each incoming request, compare the request with the signature provided by device 170, and decide on the basis of each transaction whether the transaction is generated by client device 120 (i.e., the transaction is legal and should be safely transmitted), or generated by attack tool 125 (i.e., the transaction is an attack and should be mitigated). In this embodiment, device 170 can also run by analyzing all transactions without any sampling (peace and attack periods).

[0051] Specifically, the system 110 is configured to sample incoming traffic (i.e., HTTP requests) and generate signatures. Specifically, the signature of the attack tool can be generated, modified, or updated in each time window. The time window is a preconfigured time period (e.g., 10 seconds). Three (3) interpretation buffers can be updated within each time window: window, baseline, and attack. A window interpretation buffer is provided in each time window, each time window updates a baseline interpretation buffer during peacetime (no active attack), and each time window provides an attack interpretation buffer during an attack.

[0052] Device 170 is configured to identify and differentiate between paraphrase values ​​presented in requests sent by attack tool 125 and legitimate clients. To this end, device 170 is configured to compare the application's normal, peacetime paraphrase behavior with its attack-time paraphrase behavior. This is achieved by comparing the peacetime paraphrase distribution with the attack-time paraphrase distribution. The signatures generated by device 170 can be configured at mitigation resource 112 to allow for effective attack mitigation. That is, legitimate traffic is securely transmitted to protected server 130, and the desired mitigation measures are taken against the attacker's malicious traffic based on the generated signatures.

[0053] In an example embodiment, the mitigation resource 112 can selectively perform mitigation measures only on attacker traffic. The mitigation measure can be a simple block of the request, a response with a dedicated block page on behalf of the server 130, or the like. In another embodiment, the mitigation measure can include rate limiting the attacker traffic, or only reporting and logging the mitigation results without actually blocking the incoming request. In another embodiment, the mitigation measure can be issuing various types of challenges (e.g., CAPTCHAs) to better identify the client as coming from a legitimate user or an attack tool running as a bot. In addition, the generated signature can be used to update the mitigation policy defined in the mitigation resource 112.

[0054] exist Figure 1 In the example deployment shown, system 110 is connected in series with traffic from client device 120 and attack tool 125 to victim server 130. In this deployment, system 110 is configured to sample and process intrusion traffic from client device 120 and attack tool 125.

[0055] In some configurations, system 110 is also connected to the outside of the traffic, where the traffic is transferred to the system 110 for processing by a switch / router, a web proxy (not shown), or a protected server. In this configuration, device 170 is also connected to the outside of the path.

[0056] In another configuration, the system 110 can be in a continuous operation deployment state. In this deployment, the system 110 and the device 170 can be part of a cloud protection platform (not shown).

[0057] In another embodiment, device 170 is integrated with system 110. In such an embodiment, regardless of the deployment of the integrated system, device 170 processes requests both during peacetime and during attack. The integrated system may be a DDoS mitigation device, a web application firewall, or the like.

[0058] It should be noted that although Figure 1 For simplicity, only one client device 120, one attack tool 125, and one victim server 130 are depicted in the figure, but the embodiments disclosed herein can be applied to multiple clients and servers. The clients may be located in different geographical locations. The server can be part of one or more data centers, server frameworks, private clouds, public clouds, hybrid clouds, or a combination thereof. In some configurations, the victim server 130 can be deployed in a data center, a cloud computing platform, or within an organization. The cloud computing platform can be a private cloud, a public cloud, a hybrid cloud, or any combination thereof. In addition, Figure 1 The deployment shown may include a content delivery network (CDN) connected between client device 120 , attack tool 125 , and server 130 .

[0059] System 110 and device 170 may be implemented in software, hardware, or any combination thereof. System 110 and device 170 may be physical entities (example block diagrams discussed below) or virtual entities (e.g., virtual machines, software containers, micro-entities, functions, etc.).

[0060] Figure 2A An example flow chart 200 illustrating HTTP flood attack characterization according to an embodiment is shown, the purpose of which is to generate accurate application-layer attack signatures based on a baseline of application normality learned during peacetime. During an active attack, the method aims to characterize requests generated by an attacker using HTTP flooding tools (such as the tools described above) and distinguish legitimate requests from the attacker's requests.

[0061] This representation is based on the application baseline structure of legitimate traffic learned during peacetime, distinguishing the structure of legitimate HTTP requests from that of malicious requests. The signature generation process discussed in this paper is adaptive and can learn a large number of different attack tools. A new signature can be generated at the end of each time window. Therefore, Figure 2AThe illustrated method runs within each time window. It should be emphasized that new signatures are only generated or updated during active attacks; accordingly, the baseline of legitimate application behavior is learned only during peacetime. It should be noted that signatures are accurate and valid application-layer signatures of attack tools, as described above. Generated signatures can be leveraged by mitigation resources to effectively execute mitigation measures. Specifically, mitigation resources can check each incoming request for a match against the generated signature and apply mitigation measures based on the match. For simplicity, we will refer to application-layer signatures as "signatures."

[0062] At S210, for a protected object (eg, Figure 1 S210 may include sampling HTTP requests from a server 130 in the example. Requests are sampled and processed within the time window regardless of whether a DDoS attack is in progress. Alternatively, S210 may include receiving a sample of requests. In another embodiment, S210 may include receiving and analyzing all transactions without any sampling.

[0063] At S220, a window interpretation buffer (WPBF) is constructed for the current time window. The WPBF represents the behavior of the current window interpretation in peacetime and attack time. In an embodiment, S220 includes vectorizing HTTP requests (whether sampled or not) into interpretation vectors and updating the window interpretation buffer with their respective interpretation values. The WPBF provides a histogram of the request structure received in the current time window. Figure 2B The operation of S220 is discussed in more detail.

[0064] Now refer to Figure 2B At step S221, the incoming request is processed and placed into or represented as a corresponding paraphrase vector. The representation and signature generation are based on an understanding of the request structure, rather than the request content. This structural representation is referred to herein as a paraphrase. A paraphrase vector is a data structure that represents the properties of the incoming HTTP request structure based on the symbols of the corresponding paraphrase.

[0065] In an example embodiment, the following HTTP request attributes are included in the "interpretation vector" of an HTTP request: HTTP VERB (GET, POST, PUT, etc.); multiple path elements in the request URL path; multiple query parameters in the request URL; multiple key:values ​​cookie elements in the cookie; the length of the UserAgent header value; the actual value of the UserAgent; the total length of the request in bytes; the total number of "known HTTP headers" (standard HTTP headers); and the total number of "unknown headers", i.e., all HTTP headers that are non-standard HTTP headers defined according to any existing standard or alternatively. The presence or absence of a set of predefined HTTP headers is also included as an interpretation in the system interpretation vector. A specific set of HTTP headers can be composed of standard or non-standard HTTP headers. In another embodiment, the interpretation vector entities are dynamically learned to adapt to the incoming traffic of a specific application.

[0066] In one embodiment, the definition of standard or non-standard headers can be dynamically defined. In another embodiment, to accommodate various types of protected applications, the actual HTTP request attributes are treated as interpretations and included in an interpretation vector, which can be dynamically defined, learned over time, etc. In another embodiment, the interpretation vector entity is dynamically defined by the user of the operating system to accommodate the operation or other needs of the protected application.

[0067] Figure 3 An example paraphrase vector 300 is shown in FIG, where row 320 represents the paraphrase value for the corresponding paraphrase (attribute) in row 310. The paraphrase value can be an integer (e.g., the number of cookie elements in a Cookie HTTP header, a request size range), a string (e.g., the HTTP method type), or a binary (presence or absence for a specific HTTP header from a predefined list).

[0068] Converts or places the value received in the HTTP request into the interpretation vector depending on the corresponding attribute. Figure 4 The process of generating paraphrase vectors is discussed further.

[0069] Since paraphrases represent HTTP request structures, and there are substantial differences between attacker and legitimate client request structures, it is assumed that paraphrase vectors of received HTTP requests should be used to characterize attackers with reference to normal legitimate client application baseline structural behavior. Requests sent by one or more attackers can be represented using relatively few paraphrases, and therefore also using relatively few paraphrase vectors. That is, the paraphrase vector represents the structure of the request. However, multiple different requests can share the same paraphrase, because the actual content of the request is not part of its paraphrase vector. It should be understood that using this approach, a large number (e.g., tens, thousands, or millions) of different HTTP requests from attackers are represented as a small set of paraphrases. This small set represents the number of requests sent by one or more attackers (e.g., Figure 1 HTTP requests generated by attack tools such as

[125] (e.g.,

[125] ) are more diverse than those generated by most legitimate clients because their paraphrase vectors are more diverse, less repetitive, and more numerous. Attacker traffic is represented as a set of paraphrases, and the differences in their behavior from legitimate paraphrases form the basis for constructing application-specific signatures.

[0070] Now refer to Figure 2B At S222, the interpretation vectors corresponding to the incoming sampled (or unsampled) HTTP requests are buffered into an interpretation buffer array to provide WPBF. WPBF can be referred to as a set of interpretation buffers that represent the interpretation behavior of the current window. The array is a data structure used to maintain the total number of occurrences of each interpretation value in the incoming traffic within the current peacetime window and within the attack time window during an active attack. The array contains the same interpretations as those defined for the interpretation vector (e.g., HTTP VERB, number of path elements in the request URL path, and presence / absence of headers), so each interpretation has its own interpretation buffer. The interpretation buffer is a data structure constructed to include a single interpretation value. For each possible interpretation value, the buffer has an actual "value" field and an "occurrence count" field. The occurrence count represents the total number of HTTP requests with a specific value that appear in a specific interpretation. For each protected entity (e.g., Figure 1 The victim server 130 in maintains a single dedicated WPBF array.

[0071] An example array 500 of interpretation buffers is shown as Figure 55. Array 500 includes a list of paraphrase buffers 510. Each buffer holds a list of corresponding paraphrase values ​​and a count of the number of occurrences of the same value. Each paraphrase can have a different number of paraphrase values. For example, if the incoming vectors are aggregated (representing 10 different HTTP requests) and there are 5 vectors using the GET method, 4 vectors using the POST method, and 1 vector using the HEAD method, then the paraphrase values ​​GET, POST, and HEAD would have 5, 4, and 1 occurrences, respectively. In an example embodiment, possible paraphrase values ​​are predefined for each type of paraphrase. In an embodiment, array 500 can be used for WPBF, attack paraphrase buffers, and baseline paraphrase buffers.

[0072] Return Reference Figure 2B In an embodiment, S222 includes updating a corresponding paraphrase buffer in the array with each sampled HTTP request. In this embodiment, the vector generated or updated in response to the received HTTP request is scanned, regardless of whether sampling is performed, and for each corresponding paraphrase value in the scanned vector, the occurrence count in the paraphrase buffer is incremented by 1. At the beginning of each time window, the occurrence count is set to zero; for the first paraphrase value seen, the occurrence count is set to 1.

[0073] In S223, it is checked whether the time window has passed. If it has passed, the process continues with S230 ( Figure 2A ); otherwise, execution returns to S221 where the WPBF construction continues. In some embodiments, a check is performed to see if the number of requests being processed exceeds a predefined threshold. In this case, all occurrence count values ​​in all interpretation buffers are multiplied by, for example, 0.5 or another predefined number less than 1 to avoid distortion.

[0074] Back to Figure 2A At S230, it is checked whether an attack indication is received during or before the time window. Such indication may be received from a detection system (e.g., Figure 1 If no attack indication is received, execution continues to S240; otherwise, execution continues to S250.

[0075] At S240, a baseline paraphrase buffer (BPBF) is constructed based on the WPBF. The BPBF represents paraphrased peacetime normal application behavior or legitimate paraphrased behavior. In an embodiment, S240 may include updating the BPBF with the aggregated paraphrase value occurrence counts from the WPBF for the most recent time window. Execution then continues to S270, where all event count values ​​in the WPBF are cleared and a new time window begins. Execution then returns to S210 to process the new time window. It should be noted that the structure of the BPBF is identical to that of the WPBF buffer. It should also be noted that the BPBF is updated in any time window if no attack indication is received.

[0076] In an embodiment, during the peacetime period at the end of each time window, an alpha filter is used to calculate the average number of occurrences of the paraphrase value in the BPBF within the current time window, thereby updating the BPBF with the aggregated value in the WPBF. In an embodiment, the average number of occurrences of the paraphrase value is calculated as follows:

[0077] ParaValueOccMean i,j [n+1]=ParaValueOccMean i,j [n]·(1-α)+WinParaValueOcc i,j [n+1]·α

[0078] Equation 1

[0079] Among them, ParaValueOccMean i,j [n] is the average number of occurrences of paraphrase value i belonging to paraphrase j for time window n. WinParaValueOcc i,j [n+1] is the total number of windowed occurrences of paraphrase value i belonging to paraphrase j, calculated in time window n+1. α is the alpha coefficient, which defines the "integration" period of the alpha filter. The "integration period" refers to the length of time required for integration. The integration period is the time over which the alpha filter performs averaging. In the exemplary embodiment, the alpha coefficient is chosen to be 0.001 to achieve an approximate five-hour integration period.

[0080] At S250, when an ongoing attack occurs, an attack interpretation buffer (APBF) is constructed. The APBF represents interpreted attack-period behavior within a time window, starting from the first window in which the attack was detected and continuing throughout the ongoing attack. During an ongoing attack, the APBF is updated based on the number of occurrences of interpretation values ​​aggregated from the most recent time window in the WPBF. This update is performed for each time window during the indication of an ongoing attack. It should be noted that updating the APBF does not require updating the BPBF, so the contents of the BPBF remain unchanged during the attack.

[0081] In an embodiment, during an active attack, at the end of each time window, the APBF is updated with the value aggregated in the WPBF using a simple sum of the current window occurrence count and the attack aggregate sum.

[0082] In another embodiment, the generated signature can quickly adapt to the structure of the attacker's request. To this end, during an active attack, at the end of each time window, an alpha filter with a short integration period is used to update the APBF with the values ​​aggregated from the WPBF. After the update, the average number of occurrences of the paraphrase value in the APBF is calculated as follows:

[0083] AtatckParaValueOcc i,j [n]+1]=AtatckParaValueOcc i,j [n]·(1-α)+WinParaValueOcc i,j [n+1]·α

[0084] Equation 1.1

[0085] Among them, AttackParaValueOcc i,j [n] is the average number of occurrences of paraphrase value i belonging to paraphrase j in time window n in APBF. WinParaValueOcc i,j [n+1] is the total windowed number of occurrences of paraphrase value i belonging to paraphrase j computed in time window n+1. α is the alpha coefficient that defines the "integration" period of the alpha filter. In the example embodiment, α is chosen to be 0.75 to achieve the fast integration time (e.g., tens of seconds) required to quickly adapt to the attacker's request structure.

[0086] At S260, a signature of the attack tool (attacker) that is initiating the ongoing DDoS attack is generated based on BPBF and APBF. The signature includes a set of optimal interpretation values ​​that can effectively prevent the HTTP request generated by the attacker from executing the application layer DDoS attack. Figure 6 is discussed in more detail in .

[0087] In an embodiment, the generated signature is provided to a mitigation resource to perform mitigation measures on the attack traffic. To this end, the mitigation resource can be configured to compare each request with the generated signature and, if a match is found, apply mitigation measures to the request. It should be noted that S250 and S260 are performed as long as the attack is an ongoing DDoS attack. An indication that the attack has ended can be received from the detector. Such an indication will prevent the generation of new signatures and any mitigation measures. After the attack ends, detection measures are indicated and an attack mitigation grace period can be initiated. In an embodiment, the APBF is not updated during the entire grace period. Signatures can be retained or deleted during the grace period, which is predefined as part of the system configuration. The grace period is a preconfigured timeline.

[0088] Mitigation measures can include blocking attack tools at the source when the tool is repeatedly characterized as matching a dynamic applicability signature. If a client, identified by its IP address or X-Forwarded-For HTTP header, issues a large number of HTTP requests that match a dynamic applicability signature, the client can be considered an attacker (or attack tool). After the client is identified as an attacker, all future HTTP requests received from the identified attacker will be blocked without performing any matching operations on the signature.

[0089] In some configurations, matching a request to a signature can include matching each interpretation of the request's interpretation vector to the signature. The matching strictness can be configured to determine the sensitivity of the method. This sensitivity may affect the false positive rate of legitimate requests being detected as malicious. The range of matches can be determined as a percentage, with a range of 100% matching when all incoming interpretation vector values ​​are the same as the corresponding signature. This strict matching strategy can eliminate false positives, but may increase false negatives in some cases. To simplify the matching requirements, the percentage of matching interpretation vector values ​​will be, for example, between 80% and 90% (or all interpretations except 2 or 3 interpretations will match). The matching percentage is a configurable parameter. The matching strictness is defined in terms of the number of unmatched interpretations allowed.

[0090] Figure 4 is an example flow chart illustrating a process for generating a paraphrase vector according to an embodiment.

[0091] At S410, the sampled HTTP request is parsed. Specifically, the HTTP request's header fields and other components are parsed and processed. At S420, the information in the HTTP method field is copied from the request to the corresponding "HTTP method" interpretation value element in the vector. This value can be "GET," "POST," "HEAD," or any other HTTP method.

[0092] At S420 , the number of path elements is counted starting from the URL path specified in the request. Each "\" is counted. For example, the path "\pictures\images\2021\July" has a value of 4. The root "\" is interpreted as 0.

[0093] At S430, known HTTP headers are identified in the parsed request. This can be performed by first finding (e.g., using regular expressions) all strings that are designated as known headers. For example, an Accept* interpretation is constructed by finding the presence of all HTTP headers (e.g., Accept, Accept-Encoding, Accept-Language, etc.) that begin with "Accept-*." If at least one Accept* header is found in the request, the interpretation value is EXIST. Otherwise, the interpretation value will be NOT-EXIST. In an embodiment, known headers include, but are not limited to, the following headers: Referrer, User-Agent, Host, Authorization, Connection, Cache-Control, Date, Pragma, Expect, Forwarded, From, Max Forwards, Origin, Prefer, ProxyAuthorization, Range, Transfer-Encoding, Upgrade, Via, Accept* (all HTTP headers beginning with Accept), Content* (all HTTP headers beginning with Content), Sec- (all HTTP Headers beginning with Sec-), and If-* (all HTTP Headers beginning with If-), as well as similar HTTP headers, both standard and non-standard. In an embodiment, the known headers are defined using a static list of standard HTTP headers. In another embodiment, the known headers can be defined dynamically and learned as they appear in incoming HTTP transactions.

[0094] At S440, all identified known headers are counted and the corresponding values ​​are set as the interpreted values ​​of the total number of "known HTTP headers". Each occurrence of a known header is counted as 1 and the total number of all headers "known HTTP headers" is set accordingly.

[0095] At S450, any unrecognized headers (e.g., by the above regular expression) are counted and added to the corresponding interpretation, i.e., the total number of unknown headers. If no unknown headers are found, the corresponding interpretation value is set to zero.

[0096] At S460, any cookie header in the received HTTP request is identified, and the number of key:value pairs in the cookie is calculated and added to the corresponding interpretation, i.e., the total number of key:value pairs in the cookie. If no cookie header is found, the corresponding interpretation value is set to zero.

[0097] At S470, any query parameters in the URL of the received HTTP request are identified and parsed, and the total number of query parameter URLs is counted and set to the corresponding interpretation, that is, the number of query parameters in the request URL. If no query parameter is found, the corresponding interpretation value is set to zero.

[0098] At S480, the UserAgent and the total length of the received HTTP request are identified and parsed. In addition, the length of the UserAgent header is counted and set to the corresponding interpretation, i.e., the length of the UserAgent header. If the UserAgent HTTP header is not found, the corresponding interpretation value is set to zero. The same applies to the actual value of UserAgent. In addition, the total length (in bytes) of the received HTTP request is counted and set to the corresponding interpretation, i.e., the total length HTTP request. In an embodiment, the total length of the HTTP request is defined by a range (e.g., 0-99, 100-199, up to 390-3999 bytes). In another embodiment, the initial count of the source IP (GEO IP) that generated the request is identified and set, and the source IP can be defined by a layer 3 IP header or an X-Forwarded FOR HTTP header.

[0099] The process described herein is performed on sample HTTP requests sent by the client device 120 and / or the attack tool 125 to the victim server 130 (e.g. Figure 1 ). A request can be converted into one or more paraphrases, each with a corresponding paraphrase vector.

[0100] Figure 6 An example flow chart S260 illustrating a process of generating an attack tool (attacker) signature during an active attack according to an embodiment is shown. This process is implemented at the end of each time window during the active attack.

[0101] At S610, a baseline paraphrase distribution is calculated using the BPBF. This may include converting the baseline paraphrase histogram (represented by the BPBF) into a probability distribution function. In an embodiment, the baseline paraphrase distribution is calculated as follows

[0102]

[0103] Among them, BaselineParaValueProb i,j [n] is the probability of occurrence of paraphrase value i belonging to paraphrase j in time window n. i,j [n] is the average (baseline) number of occurrences of paraphrase value i belonging to paraphrase j in time window n, recorded in the baseline paraphrase buffer. Figure 1 shown.

[0104] At S620, the attack interpretation distribution is calculated using the APBF. This may include converting the attack interpretation histogram (represented by the APBF) into a probability distribution function. In an embodiment, the attack interpretation distribution is calculated as follows:

[0105]

[0106] Among them, AttackParaValueProb i,j [n] is the probability that paraphrase value i belonging to paraphrase j appears in the time window n of the active attack. i,j [n] is the aggregated number of occurrences of paraphrase value i belonging to paraphrase j in time window n recorded in the attack paraphrase buffer.

[0107] Figure 7 An example of the conversion from a histogram to a distribution of interpretations (for both attack and baseline) is shown. In this example, the interpretation is "the number of key:val in the cookie." The corresponding interpretation is labeled 710 and the distribution is labeled 710.

[0108] At S630, the attacker generates the probability P of attack using a specific interpretation (j) j attack[n], calculate each specific value. In the embodiment, P j attack[n] is calculated as follows:

[0109]

[0110] Among them, P j attack[n] and P j The baseline is derived from the calculated attack interpretation distribution and baseline interpretation distribution. The function AF[n] is the attack factor, which is the RPS generated by the attacker divided by the RPS generated by the legitimate client:

[0111]

[0112] And it can be done as follows:

[0113]

[0114] Where "adt" is the actual attack detection time, and "n" is the current time window. AttackRPS[n] is the true average RPS measured during time window n of the attack activity. BaselineRSP represents the average legitimate RPS measured before the attack began. In one embodiment, BaselineRSP is calculated as the average value over the hour before the attack began. In another embodiment, BaselineRSP is calculated as the sum of the average value over the hour before the attack began and a predefined number of corresponding standard deviations.

[0115] Where the average interpretation of the APBF is calculated using Equation 1.1, AF[n] is averaged by the alpha filter using the following equation:

[0116]

[0117] In an example embodiment, corresponding to Equation 1.1, α is chosen to be 0.75 to achieve a fast convergence time (eg, tens of seconds) required to quickly adapt to the attacker request structure.

[0118] It should be noted that S630 is performed for each paraphrase.

[0119] At S640, the attacker probability P of each interpretation j and each value thereof is j attacker[n] is compared with a predefined attacker threshold. The probability of an attacker exceeding the threshold is P j All corresponding paraphrased values ​​for attacker[n] are added to the attacker buffer, and the remaining paraphrased values ​​are added to the legitimate buffer. The paraphrased values ​​in the attacker buffer are candidates for inclusion in the adaptive signature. That is, such paraphrased values ​​are likely executed by the attacker and are continuously generated by the attack tools the attacker is using. In an embodiment, the attacker threshold is preconfigured and defines the mitigation or sensitivity.

[0120] At S650, the signature eligibility of each interpretation is determined. That is, the signature eligibility determines whether the corresponding interpretation value of each interpretation in the attacker buffer is included or not included in the signature. The eligibility is determined by summing the baseline (peacetime) distribution of all interpretation values ​​in the legitimate buffer and comparing the sum to a predefined legitimate threshold. If the sum of the distribution exceeds the legitimate threshold, the interpretation value in the attacker buffer is considered signature qualified because legitimate traffic with a required level of certain values ​​in the legitimate buffer is expected to be excluded from the signature. If the sum of the distribution exceeds the legitimate threshold, the interpretation value in the APBF is deleted from the signature and the interpretation is not part of the signature. This activity ensures the efficiency of the generated signature. In an embodiment, the legitimate threshold is preconfigured and defines the mitigation or sensitivity.

[0121] At S660, all the interpretation values ​​that meet the signature criteria are added to a data structure representing the signature of the attacker performing the ongoing attack. The signature characterizes the attacker and is further used for actual attack mitigation in the next time window.

[0122] Here are two examples showing qualified and unqualified definitions. In the first example, the definition is the number of keys in the cookie. The definition values ​​are "0", "1", "2", "3", "4", "5", and "6". j The attacler is calculated as follows:

[0123] P j attacker(paraValue=0)=0.495;P j attacker(paraValue=1)=0.098;P j attacker(paraValue=2)=0.098;P j attacker(paraValue=3)=0.101;P j attacker(paraValue=4)=0.104;P j attacker(paraValue=5)=0.102; and P j attacker(paraValue=6)=0.

[0124] The attacker threshold is set to 0.1, so all values ​​except "paraValue=6" will be included in the attacker's buffer. The legal threshold is 0.01, and the total legal probability is 23%, so the interpretation (the number of keys in the cookie) is qualified and will be included in the attacker's signature. This ensures that the signature is accurate and valid.

[0125] In the second example, the interpretation is the HTTP method. The interpretation values ​​are "GET", "POST", "DELETE", "HEAD", and "PUT". The calculated P j The values ​​are: Pjattacker(paraValue=GET)=0.498; Pjattacker(paraValue=POST)=0.501; Pjattacker(paraValue=DELETE)=0; Pjattacker(paraValue=HEAD)=0; and Pjattacker(paraValue=PUT)=0.

[0126] The attacker threshold is set to 0.2, so all 2 values ​​"GET" and "POST" will be included in the attacker buffer. The total legitimacy probability is about 0%, so the interpretation (HTTP method) is not qualified and will not be included in the attacker's signature.

[0127] Figure 8 8 is an example block diagram of device 170 implemented according to an embodiment. Device 170 includes processing circuitry 810 coupled to memory 815, storage 820, and network interface 840. In another embodiment, the components of device 170 may be communicatively coupled via bus 850.

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

[0129] The memory 815 may be volatile (eg, RAM), non-volatile (eg, ROM, flash memory), or a combination thereof. In one configuration, computer-readable instructions for implementing one or more embodiments disclosed herein may be stored in the storage device 820 .

[0130] In another embodiment, the memory 815 is configured to store software. Software should be broadly interpreted as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include 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 the processing circuit 810 to perform the various processes described herein. Specifically, when executed, the instructions cause the processing circuit 810 to perform the embodiments described herein.

[0131] Storage device 820 may be magnetic storage, optical storage, etc., and may be implemented as, for example, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD), or any other medium that can be used to store the desired information.

[0132] The network interface 840 allows the device to communicate with at least a server and a client. Figure 8 The particular architecture shown, other architectures may also be used without departing from the scope of the disclosed embodiments. In addition, the system 110 may use Figure 8 The arrangement shown is constructed.

[0133] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. In addition, the software is preferably implemented as an application program tangibly embodied in a program storage unit or computer-readable medium consisting of components or certain devices and / or combinations of devices. The application program can be uploaded to and executed by a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware (e.g., 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 part of the application program, or any combination thereof, which may be executed by the CPU, regardless of whether such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform, such as an additional data storage unit and a printing unit. In addition, a non-transient computer-readable medium is any computer-readable medium other than a transient propagation signal.

[0134] All examples and conditional language described herein are intended for didactic purposes to help the reader understand the principles of the disclosed embodiments and the concepts contributed by the inventors to advance the art, and should be interpreted as not being limited to these specifically cited examples and conditions. In addition, all statements describing the principles, aspects, and embodiments of the disclosed embodiments herein, as well as specific examples thereof, are intended to encompass structural and functional equivalents thereof. Furthermore, such equivalents include currently known equivalents as well as equivalents developed in the future, i.e., any element developed to perform the same function, regardless of its structure.

[0135] As used herein, the phrase "at least one of" followed by a list of items means that any one of the listed items may be used alone, or any combination of two or more of the listed items may be used. For example, if a system is described as including "at least one of A, B, and C," the system may include only A; only B; only C; 2A; 2B; 2C; 3A; a combination of A and B; a combination of B and C; a combination of A 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.

[0136] It should be understood that any reference to an element using names such as "first" or "second" herein does not typically limit the quantity or order of these elements. On the contrary, these names are typically used as a convenient way to distinguish two or more elements or element instances in this article. Therefore, mentioning a first and a second element does not mean that only two elements can be used there, nor does it mean that the first element must precede the second element in some way. In addition, unless otherwise indicated, an element set includes one or more elements.

Claims

1. A method for generating an application layer signature characterizing an advanced application layer attack, comprising: Determine the applicable baseline distribution of attributes included in peacetime transactions against protected entities; determining an attack distribution of application attributes included in transactions against the protected entity during an ongoing application layer attack; determining, based on the applicability baseline distribution and the attack distribution of the applicability attributes, a probability that an attacker will execute the ongoing application layer attack to generate an attack using at least one attribute; as well as An application layer signature is generated that specifies application attributes determined to be eligible based on their respective probabilities, wherein the application layer signature characterizes behavior of the attacker performing the ongoing application layer attack.

2. The method according to claim 1, further comprising: Attributes of transactions for protected entities are maintained in paraphrases, wherein each paraphrase includes at least one paraphrase value, wherein the paraphrase value represents an applicability attribute in the transaction.

3. The method according to claim 2, wherein: The interpreted value is any one of the following: HTTP VERB; multiple path elements in the request URL path; multiple query parameters in the request URL; UserAgent actual value, multiple key:values ​​cookie elements in the cookie; The length of the UserAgent header; The total length of the request in bytes; the total number of known HTTP headers; the total number of unknown headers; and whether there is a predefined set of HTTP headers, a dynamically defined set of HTTP headers, and the geographic origin of the attacker.

4. The method according to claim 2, further comprising: Sampling transactions received during a time window; For each time window, Construct a set of window interpretation buffers (WPBFs); A set of baseline buffers for interpretation (BPBFs) is constructed based on transactions for the protected entity during peacetime, wherein the BPBFs represent interpreted normal behaviors.

5. The method according to claim 4, further comprising: Sampling transactions received during a time window; For each time window, Construct a set of window interpretation buffers (WPBFs); For each time window, a set of attack interpretation buffers (APBFs) are constructed based on transactions received during the ongoing application layer attack, wherein the APBFs represent interpreted attack period behaviors during the duration of the ongoing application layer attack.

6. The method according to claim 5, wherein: Constructing the set of WPBFs further includes: vectorizing a set of paraphrases derived from the received transactions during a time window; and Interpretation vectors are buffered to provide the WPBF.

7. The method according to claim 4, wherein: Constructing the set of BPBFs further includes: Update the value from the WPBF into the BPBF.

8. The method according to claim 7, further comprising: The average occurrence of paraphrase values ​​in the BPBF of the current time window is calculated based on the average of the occurrences of paraphrase values ​​in the BPBF calculated for the previous time window, the total occurrences of paraphrase values ​​in the WPBF of the current time window, and an alpha filter.

9. The method according to claim 4, wherein: Building the APBF also includes: updating the value from the WPBF into the APBF; and During an ongoing application layer attack, the paraphrase value occurrence count is updated based on transactions against the protected entity.

10. The method according to claim 9, wherein: Updating the APBF also includes: An average occurrence of paraphrase values ​​in the APBF of a current time window, an average occurrence of paraphrase values ​​in the APBF calculated in a previous time window, a total occurrence of paraphrase values ​​in the WPBF, and an alpha filter are calculated, wherein the alpha filter is configured to shorten adaptation to changes.

11. The method according to claim 4, wherein Generating the application layer signature further includes: using a first probability distribution function, calculating a baseline distribution based on the values ​​in the BPBF; Calculating an attack distribution based on the values ​​in the APBF using a second probability distribution function; and For each paraphrase value in the baseline distribution and the attack distribution, a probability that the attacker is performing the attack is calculated using at least one paraphrase value, wherein the application layer signature includes a set of paraphrase values ​​for mitigating an attacker performing an ongoing application layer attack.

12. The method according to claim 11, further comprising: Compare the attacker probability calculated for each paraphrase value with a predefined attacker threshold; as well as Interpretation values ​​having an attacker probability higher than the predefined attacker threshold are included in the application layer signature.

13. The method according to claim 11, further comprising: The eligibility of the generated application layer signature is determined.

14. The method according to claim 1, further comprising: The application layer signature determined to be qualified is used to cause mitigation resources to mitigate the ongoing application layer attack.

15. The method according to claim 14, further comprising: Convert incoming transactions into paraphrase vectors; comparing the interpretation vector to the qualified application layer signature; determining that the incoming transaction is a legitimate request when the interpretation vector does not match the qualified application layer signature; as well as When the interpretation vector matches the qualified application layer signature, the incoming transaction is determined to be generated by the attacker.

16. The method according to claim 15, wherein The match is determined based on a plurality of predefined matching interpretations between the received interpretation vector of the incoming transaction and the qualified application layer signature.

17. The method according to claim 14, further comprising: generating an attacker mitigation strategy based on the qualified application layer signature; as well as The policy is provided to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attack tool.

18. The method according to claim 17, wherein The at least one mitigation measure includes blocking the attacker.

19. The method of claim 1, further comprising: After receiving the indication of the application layer attack against the protected entity, the attack distribution of application attributes is determined.

20. The method according to claim 21, wherein The ongoing application layer attack is a DDoS attack implemented as an HTTP flood application layer attack.

21. The method according to claim 20, further comprising: The transaction is sampled, wherein the transaction is an HTTP request.

22. The method according to claim 1, wherein The method is performed by any one of the following: a DDoS mitigation device, a WAF device, a WEB server, a WEB cache (CDN), and a WEB proxy.

23. A non-transitory computer-readable medium having stored thereon instructions for causing a processing circuit to perform a process comprising: Determine the applicable baseline distribution of attributes included in peacetime transactions against protected entities; determining an attack distribution of application attributes included in transactions against a protected entity during an ongoing application layer attack; determining, based on the applicability baseline distribution and the attack distribution of the applicability attributes, a probability that an attacker will execute the ongoing application layer attack to generate an attack using at least one attribute; as well as An application layer signature is generated that specifies application attributes determined to be qualified based on their respective probabilities, wherein the application layer signature characterizes behavior of the attacker performing the ongoing application layer attack.

24. A system for generating dynamic application signatures using an application layer flood attack tool, comprising: processing circuits; as well as a memory containing instructions that, when executed by the processing circuit, configure the system to: Determine the applicable baseline distribution of attributes included in peacetime transactions against protected entities; determining an attack distribution of application attributes included in transactions against a protected entity during an ongoing application layer attack; determining, based on the applicability baseline distribution and the attack distribution of the applicability attributes, a probability that an attacker will execute the ongoing application layer attack to generate an attack using at least one attribute; as well as An application layer signature is generated that specifies application attributes determined to be qualified based on their respective probabilities, wherein the application layer signature characterizes behavior of the attacker performing the ongoing application layer attack.

25. The system of claim 24, wherein: The system is further configured to: Attributes of the transaction are maintained in paraphrases, wherein each paraphrase includes at least one paraphrase value, wherein the paraphrase value represents an applicability attribute in the transaction.

26. The system of claim 25, wherein: The interpreted value is any one of the following: HTTP VERB; multiple path elements in the request URL path; multiple query parameters in the request URL; multiple key:values ​​cookie elements in the cookie; The length of the UserAgent header; The total length of the request in bytes; the total number of known HTTP headers; the total number of unknown headers; and whether a set of predefined HTTP headers are present.

27. The system of claim 25, wherein: The system is further configured to: Sampling transactions received during a time window; For each time window, Construct a set of window interpretation buffers (WPBFs); A set of baseline buffers for interpretation (BPBFs) is constructed based on transactions for the protected entity during peacetime, wherein the BPBFs represent interpreted normal behaviors.

28. The system of claim 27, wherein: The system is further configured to: Sampling transactions received within the time window and attack period; For each time window, Construct a set of window interpretation buffers (WPBFs); as well as For each time window, a set of attack interpretation buffers (APBFs) are constructed based on transactions received during the ongoing application layer attack, wherein the APBFs represent interpreted attack period behaviors during the duration of the ongoing application layer attack.

29. The system of claim 27, wherein: The system is further configured to: vectorizing a set of paraphrases derived from the received transactions during a time window; and Interpretation vectors are buffered to provide the WPBF.

30. The system of claim 27, wherein: The system is further configured to: Update the value from the WPBF into the BPBF.

31. The system of claim 30, wherein: The system is further configured to: The average occurrence of paraphrase values ​​in the BPBF of the current time window is calculated based on the average of the occurrences of paraphrase values ​​in the BPBF calculated for the previous time window, the total occurrences of paraphrase values ​​in the WPBF of the current time window, and an alpha filter.

32. The system of claim 27, wherein: The system is further configured to: updating the value from the WPBF into the APBF; and During an ongoing application layer attack, the paraphrase value occurrence count is updated based on transactions against the protected entity.

33. The system of claim 32, wherein: The system is further configured to: An average occurrence of paraphrase values ​​in the APBF of a current time window, an average occurrence of paraphrase values ​​in the APBF calculated in a previous time window, a total occurrence of paraphrase values ​​in the WPBF, and an alpha filter are calculated, wherein the alpha filter is configured to shorten adaptation to changes.

34. The system of claim 27, wherein: The system is further configured to: using a first probability distribution function, calculating a baseline distribution based on the values ​​in the BPBF; Calculating an attack distribution based on the values ​​in the APBF using a second probability distribution function; as well as For each paraphrase value in the baseline distribution and the attack distribution, a probability of an attacker performing an attack is calculated using at least one paraphrase value, wherein the application layer signature includes a set of paraphrase values ​​for mitigating an attacker from performing the ongoing application layer attack.

35. The system of claim 34, wherein: The system is further configured to: Comparing the attacker probability calculated for each interpretation value to a predefined attacker threshold; and Interpretation values ​​having an attacker probability higher than the predefined attacker threshold are included in the application layer signature.

36. The system of claim 34, wherein: The system is further configured to: The eligibility of the generated application layer signature is determined.

37. The system of claim 24, wherein: The system is further configured to: The application layer signature determined to be qualified is used to cause mitigation resources to mitigate the ongoing application layer attack.

38. The system of claim 37, wherein: The system is further configured to: Convert incoming transactions into paraphrase vectors; comparing the interpretation vector to the qualified application layer signature; determining that the incoming transaction is a legitimate request when the interpretation vector does not match the qualified application layer signature; as well as When the interpretation vector matches the qualified application layer signature, the incoming transaction is determined to be generated by the attack tool.

39. The system of claim 38, wherein: The match is determined based on a plurality of predefined matching interpretations between the received interpretation vector of the incoming transaction and the qualified application layer signature.

40. The system of claim 37, wherein: The system is further configured to: generating an attacker mitigation policy based on the qualified application layer signature; and The policy is provided to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attack tool.

41. The system of claim 40, wherein: The at least one mitigation measure includes blocking the attack tool.

42. The system of claim 24, wherein: The system is further configured to: After receiving the indication of the application layer attack against the protected entity, the attack distribution of application attributes is determined.

43. The system of claim 24, wherein: The ongoing application layer attack is a DDoS attack implemented as an HTTP flood application layer attack.

44. The system of claim 43, wherein: The system is further configured to: The transaction is sampled, wherein the transaction is an HTTP request.

45. The system of claim 24, wherein: The method is performed by any one of the following: a DDoS mitigation device, a WAF device, a WEB server, a WEB cache (CDN), and a WEB proxy.

Images