HTTP2 protocol anomaly detection method, system, medium and device

Abstract

The present invention belongs to the technical field of communication anomaly detection, and provides an HTTP2 protocol anomaly detection method, system, medium and device. The method includes obtaining an HTTP2 feature hash table formed after each preset interval duration in a test phase; wherein the HTTP2 feature hash table is a multidimensional vector, and each component is a traffic feature received in a corresponding time interval in the test phase; according to the hash value difference between a pre-constructed standard feature hash table and an HTTP2 feature hash table, detecting whether the corresponding interval duration contains an abnormal flow: if the hash value difference is less than a preset hash difference threshold, the corresponding interval duration does not contain an abnormal flow; otherwise, the corresponding interval duration contains an abnormal flow; wherein the standard feature hash table is created by the average value of each traffic feature in the legal HTTP2 traffic received in different time intervals in a training phase.

Description

Technical Field

[0001] The present invention belongs to the technical field of communication anomaly detection, and in particular relates to an HTTP2 protocol anomaly detection method, system, medium and equipment. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] With the development of efficient network infrastructure, research on network applications has gradually focused on developing robust application layer protocols to fully utilize the potential and capabilities of the underlying infrastructure. For example, HTTP1.1 uses TCP as the transport layer protocol for reliable data transmission. In a sense, HTTP1.1 is inefficient in using TCP because it cannot transmit at full rate, which has a certain negative impact on the performance of the application to a certain extent. Problems such as HoL (Head of Line, an HTTP request that results in a large number of responses, thereby hindering other small requests) limit HTTP1.1 from effectively using TCP services. This prompted the emergence of the HTTP2 version. HTTP2 not only supports all the basic features of HTTP1.1, but is also very effective in utilizing TCP transmission capabilities.

[0004] The current HTTP2 protocol has poor detection accuracy for current DoS / DDoS attacks, such as application-specific, low-speed DoS attacks. To launch an attack, a malicious client establishes multiple connections with the victim and sends an incomplete request from each connection. Since the incomplete requests belonging to these connections interact very slowly with the server, the server stores them in the connection queue space until these requests are fully serviced. Once all available space in this queue is occupied, the server will not process any legitimate connections, resulting in a DoS attack. These DoS attacks require minimal bandwidth and can easily shut down high-end servers even with minimal computing resources. These attacks are highly invisible because the traffic they generate is very small and mimics normal traffic behavior. Summary of the invention

[0005] In order to solve the technical problems existing in the above-mentioned background technology, the present invention provides an HTTP2 protocol anomaly detection method, system, medium and device, which can detect abnormal events of the HTTP2 protocol using hash table statistics.

[0006] In order to achieve the above object, the present invention adopts the following technical solution:

[0007] A first aspect of the present invention provides an anomaly detection method for HTTP2 protocol.

[0008] In one or more embodiments, a method for detecting anomalies in HTTP2 protocol includes:

[0009] Obtaining an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, each component of which is a traffic feature received in a corresponding time interval in the test phase;

[0010] Based on the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table, detect whether the corresponding interval duration contains abnormal flow:

[0011] If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow;

[0012] The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

[0013] As an implementation method, the average value of each traffic feature is:

[0014] The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

[0015] As an implementation method, the flow characteristics include:

[0016] Set the SETTINGS frame with the SETTINGS_INITIAL_WINDOW_SIZE information to 0;

[0017] Restart the header frame with END_STREAM_FLAG information;

[0018] Streams with only a concatenated predecessor;

[0019] Restart the header frame with END_HEADERS_FLAG information;

[0020] Unacknowledged server settings frame.

[0021] As an implementation mode, the hash difference threshold is corrected periodically by retraining.

[0022] The advantage of the above scheme is that the hash difference threshold is used to correct the deviation regularly through retraining, so as to realize the self-learning and continuous improvement of the hash difference threshold and improve the detection accuracy of abnormal events of the HTTP2 protocol.

[0023] As an implementation manner, the interval duration is set according to corresponding matching of different time periods.

[0024] The advantage of the above scheme is that since the traffic density and characteristics in different time periods vary greatly, the scheme sets different interval durations for different time periods, avoiding false detection and improving the detection accuracy of abnormal events in the HTTP2 protocol.

[0025] A second aspect of the present invention provides an anomaly detection system for the HTTP2 protocol.

[0026] In one or more embodiments, an HTTP2 protocol anomaly detection system includes:

[0027] An HTTP2 feature hash table acquisition module, which is used to obtain an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, each component of which is a traffic feature received in a corresponding time interval in the test phase;

[0028] The hash value difference judgment module is used to detect whether the corresponding interval duration contains abnormal flow according to the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table:

[0029] If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow;

[0030] The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

[0031] As an implementation manner, in the hash value difference judgment module, the average value of each traffic feature is:

[0032] The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

[0033] As an implementation method, the flow characteristics include:

[0034] Set the SETTINGS frame with the SETTINGS_INITIAL_WINDOW_SIZE information to 0;

[0035] Restart the header frame with END_STREAM_FLAG information;

[0036] Streams with only a concatenated predecessor;

[0037] Restart the header frame with END_HEADERS_FLAG information;

[0038] Unacknowledged server settings frame.

[0039] As an implementation mode, the hash difference threshold is corrected periodically by retraining.

[0040] As an implementation manner, the interval duration is set according to corresponding matching of different time periods.

[0041] A third aspect of the present invention provides a computer-readable storage medium.

[0042] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps in the HTTP2 protocol anomaly detection method as described above.

[0043] A fourth aspect of the present invention provides a computer device.

[0044] A computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps in the above-mentioned HTTP2 protocol anomaly detection method are implemented.

[0045] Compared with the prior art, the present invention has the following beneficial effects:

[0046] (1) The present invention innovatively proposes a feature hash table traffic anomaly measurement technology, which uses hash table statistics to detect the use of normal HTTP2 traffic to create a standard feature hash table, and compares it with the HTTP2 feature hash table formed in the test phase. It can identify deviations in network traffic patterns caused by abnormal connections caused by these attacks, thereby improving the detection efficiency of HTTP2 protocol abnormal events.

[0047] (2) The present invention proposes a self-learning detection mechanism to detect these abnormal attacks. The hash difference threshold is corrected by retraining, and the interval duration is set according to the corresponding matching of different time periods. The attack characteristics of the new HTTP2 protocol are analyzed and the normal event range and intrusion event characteristics are defined. The abnormal events are detected and the detection method is continuously self-learned to improve, thereby forming an abnormal detection scheme for the HTTP2 protocol and improving the accuracy of HTTP2 protocol anomaly detection.

[0048] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0050] Figure 1 is a schematic diagram of frame exchange involved in normal operation of the HTTP2 protocol according to an embodiment of the present invention;

[0051] Figure 2 It is an abnormal attack scenario using a complete GET_Header and SETTINGS_INITIAL_WINDOW_SIZE is 0;

[0052] Figure 3 It uses the complete POST Header for abnormal attack scenarios;

[0053] Figure 4 It is an abnormal attack scenario using the connection preamble;

[0054] Figure 5 It is an abnormal attack scenario using incomplete GET / POST headers;

[0055] Figure 6 is a self-learning correction flow chart of an embodiment of the present invention;

[0056] Figure 7 This is a flowchart of anomaly detection of the HTTP2 protocol according to an embodiment of the present invention. DETAILED DESCRIPTION

[0057] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0058] It should be noted that the following detailed descriptions are all illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0059] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof.

[0060] The following describes the limitations and stealth of DoS / DDoS attacks in terms of bandwidth requirements and highlights some limitations of transport and application-level DoS / DDoS attacks from the perspective of a malicious client.

[0061] Transport-level DDoS flooding attack: Transport-level DoS attacks are mainly launched using TCP and UDP packets. Malicious clients interrupt the victim's connection by exhausting its network bandwidth (e.g., forged / non-forged UDP floods), or exploit implementation vulnerabilities of transport layer protocols to consume the victim's excess resources (e.g., TCP SYN floods, ACK & PSH ACK floods, etc.). In addition, malicious clients may use reflection and amplification to launch attacks, such as ICMP Echo-Request-Flood attacks and Smurf attacks. Another type of DoS attack, known as low-rate TCP targeted DoS attacks, exploits TCP's retransmission timeout mechanism. Malicious clients stimulate TCP flows to repeatedly enter the retransmission timeout state by sending burst messages at a high rate but with a short duration. These DDoS attacks exploit network and transport layer operations, so compared to low-rate application layer DoS attacks, a large amount of malicious client bandwidth is required to overwhelm the victim. In addition, since transport-level DDoS attacks generate too much traffic, these attacks are easy to detect.

[0062] Application-level DDoS flood attacks: These attacks also aim to disrupt victim clients by exhausting their resources, but they require less bandwidth, so they are stealthier than transport-level DDoS attacks. To launch these attacks, malicious clients use either reflection (like VoIP flooding) and amplification techniques (like DNS amplification attacks) or just protocol-specific request flooding (like HTTP flooding attacks, DHCP starvation attacks, etc.). These attacks consist of sending complete requests at a very high rate to overwhelm the victim client.

[0063] Application-specific low-rate DoS attacks: Application-specific low-rate DoS attacks (such as Slowloris HTTP1.1 and FTP DoS attacks) require a very small number of incomplete requests to create a DoS scenario. To launch the attack, the malicious client establishes multiple connections with the victim and sends an incomplete request from each connection. Since the incomplete requests belonging to these connections interact very slowly with the server, the server stores them in the connection queue space until these requests are fully served. Once all the available space in this queue is occupied, the server will not process any legitimate connections, resulting in a DoS attack. These DoS attacks require minimal bandwidth and can easily shut down high-end servers even with minimal computing resources. These attacks are highly invisible because they generate very small amounts of traffic and mimic normal traffic behavior. The low-rate HTTP2 DoS attacks mentioned in this invention belong only to this category, and they also target the number of free connection slots available in the web server connection pool.

[0064] Application layer protocol-independent low-rate DoS attacks: Along with HTTP, these attacks can also create DoS scenarios for protocols such as FTP and SMTP. The SlowReq and Slowcomm attacks have some similarities with the Slowloris attack, as all of these attacks involve sending incomplete and hanging requests. However, both attacks are also able to detect the connection closure within a reasonable time and reestablish the connection as soon as it is closed. This makes SlowReq and Slowcomm more effective than simple Slowloris attacks. On the other hand, Slow Next involves sending valid and legitimate requests to the server. This attack exploits the persistent connection feature of the HTTP1.1 protocol, which keeps an established connection open even after receiving a response from the server to a specific request that was previously sent. Before the waiting time for the connection to be open expires, another legitimate and valid request is sent on the same established connection in order to reset the timer. Once a sufficient number of such connections are established with the server, it becomes unusable for real users. Since there are complete requests, the server successfully parses them and sends back responses. Therefore, this attack is more covert than the previously mentioned low-rate DoS attacks.

[0065] The operation of HTTP2 is very different from HTTP1.1. Although the semantics of the original protocol remain the same, HTTP2 improves the ability of applications to effectively utilize transmission bandwidth. The limitation of having only one outstanding request at a time per connection makes HTTP1.1 inefficient given the capacity of modern Internet infrastructure. To overcome these limitations, HTTP2 provides features such as message multiplexing, anticipating the client's resource requirements, and compressing header information into serialized header blocks. These new control features significantly increase the speed of communication between clients and web servers. With the help of message multiplexing, each connection can have multiple concurrent streams, which allow multiple outstanding requests at a time in a connection. A stream is a bidirectional sequence of frames exchanged between the client and the server in an HTTP2 connection. Since multiple streams are multiplexed on a single connection, an HTTP client can send multiple concurrent HTTP requests, thereby maximizing bandwidth utilization. Streams also solve the HoL (Head-of-Line) blocking problem, which is a major limitation in HTTP1.1. Each stream is uniquely identified by an unsigned 31-bit integer. Furthermore, HTTP2 messages are divided into separate binary frames of different types, each type serving a different purpose.

[0066] Connection preamble: The connection preamble (containing a magic string PRI*HT TP / 2.0\r\n\r\nSM\r\n\r\n) is used to establish the initial setup of the HTTP2 connection and the final confirmation of the protocol being used.

[0067] Header frame and continuation frame: Header frame is used to carry header block. If a header block is large enough to not fit in one header frame, continuation frame is used to transmit the rest of the header block.

[0068] Data frame: This frame is used to carry the message body sent by the endpoint. For example, the client uses the data frame to carry the message body of a POST request, and the server uses the data frame to carry the response to the client's GET request.

[0069] Setup frame: Endpoints use this frame to negotiate connection parameters such as initial window size, maximum concurrent streams, etc.

[0070] WINDOW_UPDATE frame: The WINDOW_UPDATE frame is used to indicate the number of bytes that the sender is willing to accept in addition to the existing HTTP flow control window.

[0071] GOAWAY frame: This frame is used to disconnect an established connection between endpoints or indicate some serious error conditions. rfc7540 defines various error codes carried by the GOAWAY frame to convey the reasons behind the connection or stream errors.

[0072] Figure 1 Shows the frame exchanges involved in normal operation of the HTTP2 protocol.

[0073] The order is as follows:

[0074] First payload from client to server: Once the TCP connection is established, the client sends the connection preface, setup frames, and window update frames on stream 0, while header frames are sent on another stream multiplexed over the same connection. Both streams are part of one HTTP2 payload.

[0075] Second payload from server to client: Once the server receives the previous HTTP2 payload, it acknowledges receipt of the setup frame by sending an empty setup frame with identification number 0 on stream. Along with this frame, the server also sends a window update frame and a non-empty setup frame. In response to the GET request, the server also sends header and data frames back to the client on another stream.

[0076] Third payload from client to server: Once the client receives the second HTTP2 payload, it acknowledges the SETUP frame sent by the server and successfully closes the connection by sending a GOAWAY frame.

[0077] The specific scheme of the HTTP2 protocol anomaly detection method of the present invention is explained below in conjunction with specific embodiments.

[0078] Embodiment 1

[0079] Reference Figure 7 This embodiment provides an HTTP2 protocol anomaly detection method, which includes:

[0080] Step 1: Obtain an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, and each component is a traffic feature received in a corresponding time interval in the test phase.

[0081] The low-rate HTTP2 DOS attack mentioned in the present invention focuses on exhausting all available free connection slots in the web server connection pool. In order to consume all free slots, the malicious client establishes a sufficient number of connections and sends deliberately constructed requests from each connection. Since these special requests block the established connections for a long time, the server cannot receive requests sent by real HTTP clients during this time, which will lead to a DoS scenario. This embodiment proposes a detection method for evaluating the effectiveness of the mentioned attack to create a test bench setting for a denial of service scenario.

[0082] Testbed Setup: The attacks were tested on four popular HTTP2-enabled web servers, namely Apache 2.4.23, Nginx 1.10.1, H2O 2.0.4, and NgHTTP2 1.14.0. All four servers were tested in their default configurations. All these servers were configured on a computer with 4GB of physical memory and a quad-core processor. This computer was running Kali 2.0 operating system. A sample website was hosted in the home directory of each server. This website contained a homepage with 50 images embedded in it. Two other computers were also set up in the network and designated as malicious and real clients respectively. Each client had 4GB of physical memory and a dual-core processor and was running Ubuntu 16.04 LTS operating system. The malicious clients were used to launch the proposed attacks, while the real clients were used to check the availability of the servers during the attack scenarios. Since there is no mature tool that can flexibly modify some parameters of HTTP2 frames while testing the protocol, these attacks were implemented using Python, while the h2load benchmark tool was used to create and send legitimate requests from genuine clients to check the availability of the servers during the attacks.

[0083] In view of the different low-rate DoS attacks described in the above experiments, this embodiment proposes an anomaly detection scheme to detect low-rate HTTP2 DoS attacks. The detection scheme is divided into a training phase and a testing phase. In the training phase, a normal HTTP2 profile is created by collecting legitimate web traffic in and out of the server within x observation intervals. In the testing phase, the detection system compares the current traffic distribution map with the traffic distribution map generated in the training phase. For comparison, a hash table statistical method is used to perform distance measurement of the test feature statistics.

[0084] In the specific implementation process, the abnormal attack scenarios include the following four types:

[0085] (1) Abnormal attack using complete GET_Header and SETTINGS_INITIAL_WINDOW_SIZE is 0, such as Figure 2 shown.

[0086] To generate the attack, the malicious client sends an HTTP2 payload with a settings frame with the SETTINGS_INITIAL_WINDOW_SIZE field set to zero and a complete GET request, as shown in the following figure. After receiving this payload, the server assumes that the client is now unable to receive any data. Therefore, the server waits to receive a WINDOW_UPDATE frame from the malicious client. On the other hand, the malicious client does not send a WINDOW_UPDATE frame to the server, which makes the server wait for a specific amount of time, depending on the software implementation of the network server.

[0087] (2) Use the complete POST Header to perform abnormal attacks, such as Figure 3 shown.

[0088] There are four types of flags in the header frame, two of which are the END_STREAM and END_HEADERS flags. When reset, the END_STREAM flag indicates that the sender's data stream contains data frames. When the END_HEADERS flag is set, it indicates that the header frame contains a complete header block and there will be no continuation frames behind it.

[0089] To launch the attack, the malicious client sets and resets the END_HEADERS and END_STREAM flags of the header frame, respectively, and sends a complete POST request wrapped in this frame, as shown in the figure below. Once the server receives this header frame, it assumes that although it has received the complete POST-request header (due to the END_HEADERS flag being set), it has not yet received one or more data frames (due to the END_STREAM flag being reset). Depending on the server's software implementation, it will wait for a specific amount of time to receive the data frame before closing the connection.

[0090] (3) Using abnormal attacks before the connection, such as Figure 4 shown.

[0091] After the connection is established successfully, the malicious client will send a connection preamble to the server, as shown in the figure below. The server accepts this message and starts waiting to receive GET / POST HTTP requests. On the other hand, the malicious client will not send any more HTTP requests. In turn, this forces the server to wait for a specific time to receive HTTP requests. This allows the malicious client to get enough waiting time on the server to create a DoS scheme.

[0092] (4) Using incomplete GET / POST headers to carry out abnormal attacks, such as Figure 5 shown.

[0093] A malicious client can launch this attack using either a GET or POST request. To launch the attack using a GET request, the malicious client sends a header frame that sets and resets the END_HEADERS and END_STREAM flags, respectively, as shown in the following figure. The END_HEADERS flag, when reset, indicates that the header frame must be followed by one or more continuation frames. The last continuation frame must have the END_HEADERS flag set. When the server receives such a header frame, the server assumes that it has received an incomplete header and should therefore wait to receive a complete header block. To launch the attack using a POST request, the malicious client sends a header frame that contains a POST request with both the END_STREAM and END_HEADERS flags reset. Therefore, there are two types of such attacks, depending on the type of header frame request included.

[0094] Among them, the detection technology proposed in this embodiment is used to detect a set of characteristics of the proposed attack. It should be emphasized that these characteristics are the sum of the number of such events that occur when an attack occurs. For example, an event corresponding to the value 0 in the SETTINGS_INITIAL_WINDOW_SIZE field in the SETTINGS frame occurs due to an attack. Similarly, some other functions are defined to detect whether there are other types of attacks, as shown in Table 1.

[0095] Table 1 Candidate feature table

[0096]

[0097] Feature 1 is related to the number of SETTINGS frames with SETTINGS_INITIAL_WINDOW_SIZE information set to zero. Feature 2 and feature 4 are related to the number of header frames restarted with END_STREAM_FLAG or END_HEADERS_FLAG, respectively. Feature 3 corresponds to the number of stream 2 with only a connection order, while feature 5 is related to the number of server SETTINGS frames that were not acknowledged. In the absence of a stable HTTP2 parsing library, a program was written to extract the required features using the jnetpcapjava library.

[0098] Step 2: Based on the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table, detect whether the corresponding interval duration contains abnormal flow:

[0099] If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow;

[0100] The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

[0101] For the purpose of detection, the null hypothesis and the alternative hypothesis are HN (time interval ΔT does not contain abnormal flow) and HA (time interval ΔT contains abnormal flow). A hash table is generated every time interval ΔT to record the number and frequency of feature i. The information recorded in the hash table includes: time interval, the number of feature occurrences in a certain time interval, and the frequency of feature occurrences in a certain time interval. Among them, the frequency of feature occurrences in a certain time interval is the ratio of the number of feature occurrences in a certain time interval to the time interval.

[0102] In order to make the detection system learn normal HTTP2 behavior, legitimate HTTP2 traffic to and from the web server is collected in x time intervals (each time interval is ΔT). Then, a standard feature hash table E is created by taking the average value of each feature received in different time intervals during the training phase.

[0103] Among them, the average value of each traffic feature is:

[0104] The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

[0105] Specifically, the standard feature hash table E is an n-dimensional vector, and each component Ei of the vector represents feature i.

[0106]

[0107] where e it Corresponding to the feature i received in the tth time interval of the training phase, x is the total number of time intervals in the training phase.

[0108] Once the detection system is trained with a normal HTTP2 profile, it can be used to detect the presence of attacks from (x+1) intervals. A feature hash table O is generated after each ΔT duration. Similar to E, O is also an n-dimensional vector, where each component Oi of the vector O represents the feature i received in a specific time interval during the test phase. The hash values ​​of E and O are calculated and compared. If the hash value difference is less than a pre-defined threshold, the detector accepts HN; if the hash value is greater than or equal to the pre-defined threshold, the detector accepts HA. For each time interval, the detector accepts HN or HA.

[0109] like Figure 6 As shown, the hash difference threshold is corrected by retraining regularly. In this way, the hash difference threshold is corrected by retraining regularly, which realizes the self-learning and continuous improvement of the hash difference threshold and improves the detection accuracy of abnormal events of the HTTP2 protocol.

[0110] In other embodiments, the interval duration is set according to corresponding matching of different time periods.

[0111] Since the traffic density and characteristics of different time periods vary greatly, this solution sets different interval durations for different time periods to avoid false detection and improve the detection accuracy of abnormal events in the HTTP2 protocol. For example, in different time periods such as system busy time (such as working hours) and rest time (such as night), or the difference between working days and rest days, the detection system should construct different standard feature hash tables and set corresponding thresholds and time intervals.

[0112] Embodiment 2

[0113] This embodiment provides an HTTP2 protocol anomaly detection system, which specifically includes the following modules:

[0114] (1) an HTTP2 feature hash table acquisition module, which is used to acquire an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, each component of which is a traffic feature received in a corresponding time interval in the test phase;

[0115] The flow characteristics include:

[0116] Set the SETTINGS frame with the SETTINGS_INITIAL_WINDOW_SIZE information to 0;

[0117] Restart the header frame with END_STREAM_FLAG information;

[0118] Streams with only a concatenated predecessor;

[0119] Restart the header frame with END_HEADERS_FLAG information;

[0120] Unacknowledged server settings frame.

[0121] (2) A hash value difference judgment module, which is used to detect whether the corresponding interval duration contains an abnormal flow based on the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table:

[0122] If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow;

[0123] The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

[0124] In the specific implementation process, in the hash value difference judgment module, the average value of each traffic feature is:

[0125] The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

[0126] In one or more embodiments, the hash difference threshold is corrected periodically by retraining.

[0127] This embodiment uses the hash difference threshold to perform corrections through regular retraining, thereby achieving self-learning and continuous improvement of the hash difference threshold and improving the detection accuracy of abnormal events of the HTTP2 protocol.

[0128] In one or more embodiments, the interval duration is set according to corresponding matching of different time periods.

[0129] Since the traffic density and characteristics in different time periods vary greatly, this solution sets different interval durations for different time periods, avoiding false detection and improving the detection accuracy of abnormal events in the HTTP2 protocol.

[0130] It should be noted here that each module in this embodiment corresponds to each step in Example 1 one by one, and the specific implementation process is the same, which will not be repeated here.

[0131] Embodiment 3

[0132] This embodiment provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the steps in the HTTP2 protocol anomaly detection method as described above are implemented.

[0133] Embodiment 4

[0134] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the steps in the HTTP2 protocol anomaly detection method described above are implemented.

[0135] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram and the combination of processes and / or blocks in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the flowchart. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0136] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for detecting anomalies in HTTP2 protocol, characterized in that: include: Obtaining an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, each component of which is a traffic feature received in a corresponding time interval in the test phase; The flow characteristics include: Set the SETTINGS frame with the SETTINGS_INITIAL_WINDOW_SIZE information to 0; Restart the header frame with END_STREAM_FLAG information; Streams with only a concatenated predecessor; Restart the header frame with END_HEADERS_FLAG information; Unacknowledged server setup frame; The information recorded in the hash table includes: time interval, the number of occurrences of features in a certain time interval, and the frequency of occurrence of features in a certain time interval; Based on the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table, detect whether the corresponding interval duration contains abnormal flow: If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow; The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

2. The HTTP2 protocol anomaly detection method according to claim 1, characterized in that: The average value of each traffic feature is: The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

3. The HTTP2 protocol anomaly detection method according to claim 1, characterized in that: The hash difference threshold is corrected periodically by retraining.

4. The HTTP2 protocol anomaly detection method according to claim 1, characterized in that: The interval duration is set according to the corresponding matching of different time periods.

5. An HTTP2 protocol anomaly detection system, characterized in that: include: An HTTP2 feature hash table acquisition module, which is used to obtain an HTTP2 feature hash table formed after each preset interval duration in the test phase; wherein the HTTP2 feature hash table is a multidimensional vector, each component of which is a traffic feature received in a corresponding time interval in the test phase; The flow characteristics include: Set the SETTINGS frame with the SETTINGS_INITIAL_WINDOW_SIZE information to 0; Restart the header frame with END_STREAM_FLAG information; Streams with only a concatenated predecessor; Restart the header frame with END_HEADERS_FLAG information; Unacknowledged server setup frame; The information recorded in the hash table includes: time interval, the number of occurrences of features in a certain time interval, and the frequency of occurrence of features in a certain time interval; The hash value difference judgment module is used to detect whether the corresponding interval duration contains abnormal flow according to the hash value difference between the pre-built standard feature hash table and the HTTP2 feature hash table: If the hash value difference is less than the preset hash value difference threshold, the corresponding interval duration does not contain abnormal flow; otherwise, the corresponding interval duration contains abnormal flow; The standard feature hash table is created by the average value of each traffic feature in the legitimate HTTP2 traffic received at different time intervals in the training phase.

6. The HTTP2 protocol anomaly detection system as claimed in claim 5, characterized in that: In the hash value difference judgment module, the average value of each traffic feature is: The ratio of the cumulative sum of the corresponding traffic features received in all time intervals during the training phase to the total number of time intervals during the training phase.

7. The HTTP2 protocol anomaly detection system as claimed in claim 5, characterized in that: The hash difference threshold is corrected regularly by retraining; or The interval duration is set according to the corresponding matching of different time periods.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps in the HTTP2 protocol anomaly detection method as described in any one of claims 1 to 4 are implemented.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps in the HTTP2 protocol anomaly detection method as described in any one of claims 1 to 4 are implemented.

Images