Defense method and defense device for malicious client, electronic equipment and storage medium

Abstract

The invention discloses a malicious client defense method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to a received transport layer security / secure socket layer protocol handshake request from a client, recording a receiving moment, and adding 1 to the cumulative number of handshake requests of the client to obtain an updated cumulative number of times; according to the updated cumulative number of times and the receiving time of each handshake request in the updated cumulative number of times, acquiring the handshake request frequency of the client, and judging whether the client is a malicious client; if the client is not the malicious client, subtracting 1 from the accumulated number of times of updating; and if the client is the malicious client, blocking the Internet protocol address of the client in the handshake request. Therefore, a refined management and control mode of distinguishing attacks and normal handshake requests based on a posterior mode can be realized.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a defense method, defense device, electronic device and storage medium for malicious clients. Background Art

[0002] SSL / TLS is an encryption protocol located between the transport layer and the application layer (implemented at the socket layer). SSL is the abbreviation of Secure Sockets Layer, and TLS is the abbreviation of Transport Layer Security. In actual applications, the application layer data is encrypted based on the SSL / TLS protocol and the SSL header is added to obtain the encrypted application layer data, which is then passed to the transport layer.

[0003] During the SSL handshake process, the server CPU overhead is much greater than the client CPU overhead during the encryption algorithm negotiation phase. Malicious clients take advantage of this feature and continuously perform rapid renegotiations in a TCP connection (this behavior is allowed by the SSL protocol), thereby exhausting the server CPU resources and launching a handshake attack on the server.

[0004] In order to defend against this attack method, in the related art, the server counts the number of handshake requests in the TLS handshake phase at the presentation layer of the open system interconnection reference model. If the number of TLS handshake requests within a preset time reaches a preset threshold, the client IP address that issued these TLS handshake requests is blocked. Since the statistical result of the number of requests in the related art is only increasing but not decreasing, that is, regardless of whether the TLS / SSL handshake request is a handshake attack or a normal request (because the request content has not been issued in the handshake phase, it is impossible to determine whether the request is a handshake attack or a normal request), as long as a TLS / SSL handshake request is received, the number of requests corresponding to the client IP address that issued the TLS / SSL handshake request will be increased by 1, so it will lead to a high misjudgment rate of whether the handshake request is an attack, and it is easy to mistakenly block the client IP address of normal users, especially during peak customer traffic periods, it is easier to cause the client IP address to be mistakenly blocked. For example, during the promotion of a large e-commerce website, the server may mistakenly identify normal users as attackers due to processing a large number of TLS handshake requests, resulting in mistaken IP addresses. In addition, in high-concurrency application scenarios such as stock trading platforms, it is also easy to mistakenly block normal users, affecting the availability of services.

[0005] Therefore, in order to reduce the number of false blockings, the server needs to adopt more advanced algorithms and mechanisms to distinguish between normal requests and attack behaviors.

[0006] The above statements are only used to provide background information related to the present application and do not necessarily constitute prior art. Summary of the invention

[0007] The purpose of this application is to provide a malicious client defense method, defense device, electronic device and storage medium. In order to have a basic understanding of some aspects of the disclosed embodiments, a simple summary is given below. This summary is not a general review, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its only purpose is to present some concepts in a simple form as a preface to the detailed description that follows.

[0008] According to one aspect of an embodiment of the present application, a method for defending against a malicious client is provided, including:

[0009] In response to receiving a transport layer security / secure socket layer protocol handshake request from a client, recording a receiving time, adding 1 to a cumulative number of handshake requests from the client to obtain an updated cumulative number;

[0010] According to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates, the handshake request frequency of the client is obtained to determine whether the client is a malicious client;

[0011] If the client is not a malicious client, the cumulative number of updates is reduced by 1;

[0012] If the client is a malicious client, the client Internet Protocol address in the handshake request is blocked.

[0013] In some embodiments of the present application, the determining whether the client is a malicious client includes:

[0014] If the handshake request frequency is greater than or equal to a preset value, the client is determined to be a malicious client;

[0015] If the handshake request frequency is less than a preset value, a handshake operation is performed with the client according to the handshake request, and in response to receiving an encrypted Hypertext Transfer Protocol HTTP request from the client, whether the client is a malicious client is determined according to the encrypted HTTP request; the encrypted HTTP request is generated by the client based on the handshake operation.

[0016] In some embodiments of the present application, performing a handshake operation with the client according to the handshake request includes:

[0017] Generate a reply message corresponding to the handshake request;

[0018] Sending the reply message and the server certificate, so that the client performs a transport layer security / secure socket layer protocol connection establishment operation based on the reply message and the server certificate;

[0019] In response to receiving a connection establishment operation completion message from the client within a preset time period, sending encrypted parameter data to the client, so that the client encrypts the HTTP request based on the encrypted parameter data to obtain an encrypted HTTP request.

[0020] In some embodiments of the present application, determining whether the client is a malicious client according to the encrypted HTTP request includes:

[0021] Parsing the encrypted HTTP request at the application layer of the open system interconnection reference model to obtain parsing information; the encrypted HTTP request is obtained by the client encrypting the HTTP request based on the handshake operation;

[0022] Determining whether the handshake request is a malicious request according to the parsed information;

[0023] If the handshake request is a malicious request, determining that the client is a malicious client;

[0024] If the handshake request is not a malicious request, it is determined that the client is not a malicious client.

[0025] In some embodiments of the present application, the parsing of the encrypted HTTP request to obtain parsing information includes:

[0026] Parsing the ciphertext in the encrypted HTTP request according to the server private key and the encryption suite in the encrypted parameter data to obtain the first information;

[0027] The plain text in the encrypted HTTP request is parsed according to the HTTP protocol to obtain the second information; the parsed information includes the first information and the second information.

[0028] In some embodiments of the present application, determining whether the handshake request is a malicious request according to the parsed information includes:

[0029] Determining whether the encrypted HTTP request is a malicious request according to the parsed information;

[0030] If the encrypted HTTP request is a malicious request, determining the handshake request is a malicious request;

[0031] If the encrypted HTTP request is not a malicious request, it is determined that the handshake request is not a malicious request.

[0032] In some embodiments of the present application, determining whether the encrypted HTTP request is a malicious request according to the parsed information includes:

[0033] Detecting whether there is malicious request data in the parsed information;

[0034] If it exists, the encrypted HTTP request is determined to be a malicious request.

[0035] In some embodiments of the present application, the defense method further includes:

[0036] If the handshake request is a malicious request, the handshake request and the encrypted HTTP request are discarded.

[0037] In some embodiments of the present application, the recording receiving time, adding 1 to the cumulative number of handshake requests from the client to obtain an updated cumulative number, includes:

[0038] The receiving time is recorded at the application layer and the presentation layer of the open system interconnection reference model, and the cumulative number of handshake requests of the client is increased by 1 to obtain an updated cumulative number.

[0039] In some embodiments of the present application, said reducing the cumulative number of updates by 1 includes: reducing the cumulative number of updates by 1 at the application layer and the presentation layer of the open systems interconnection reference model.

[0040] In some embodiments of the present application, obtaining the handshake request frequency of the client according to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates includes:

[0041] According to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates, the total number of receptions within a preset time period is obtained;

[0042] The ratio of the total number of reception times to the preset time period is calculated to obtain the handshake request frequency.

[0043] According to another aspect of an embodiment of the present application, a defense device for malicious clients is provided, including:

[0044] an accumulation module, configured to, in response to receiving a transport layer security / secure socket layer protocol handshake request from a client, record a receiving time, add 1 to the accumulated number of handshake requests from the client, and obtain an updated accumulated number;

[0045] An acquisition module, used for acquiring the handshake request frequency of the client according to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates;

[0046] A judging module, used for judging whether the client is a malicious client according to the handshake request frequency;

[0047] A subtraction module, configured to reduce the cumulative number of updates by 1 if the client is not a malicious client;

[0048] The blocking module is used to block the client Internet Protocol address in the handshake request if the client is a malicious client.

[0049] According to another aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the malicious client defense method described in any embodiment of the present application.

[0050] According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored, and the computer program is executed by a processor to implement the malicious client defense method described in any embodiment of the present application.

[0051] The technical solution provided by one aspect of the embodiments of the present application may have the following beneficial effects:

[0052] The malicious client defense method provided in the embodiment of the present application responds to receiving a Transport Layer Security / Secure Sockets Layer protocol handshake request from a client, records the reception time, adds 1 to the cumulative number of handshake requests of the client, and obtains an updated cumulative number; obtains the handshake request frequency of the client according to the updated cumulative number and the reception time of each handshake request in the updated cumulative number, and determines whether the client is a malicious client; if the client is not a malicious client, reduces 1 by the updated cumulative number; if the client is a malicious client, blocks the client Internet Protocol address in the handshake request, so that a refined control method based on a posteriori method to distinguish between attacks and normal handshake requests can be implemented.

[0053] The above description is only an overview of the technical solution of the embodiment of the present application. In order to more clearly understand the technical means of the embodiment of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the embodiment of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0055] Figure 1 A schematic diagram showing the basic process of establishing a TCP connection and the basic process of establishing a TLS / SSL connection between a client and a server in the related art.

[0056] Figure 2 A flow chart of a method for defending against malicious clients according to an embodiment of the present application is shown.

[0057] Figure 3 A layered diagram of the Open Systems Interconnection reference model is shown.

[0058] Figure 4 A schematic diagram of the process of establishing a connection between a client and a server according to an embodiment of the present application is shown.

[0059] Figure 5 A schematic diagram of a communication process according to an embodiment of the present application is shown.

[0060] Figure 6 A structural block diagram of a defense device for malicious clients according to an embodiment of the present application is shown.

[0061] Figure 7 A structural block diagram of an electronic device according to an embodiment of the present application is shown.

[0062] Figure 8 A schematic diagram of a computer-readable storage medium according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0064] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in general dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined as here.

[0065] refer to Figure 1 As shown, Figure 1 The following is a schematic diagram showing the basic process of TCP connection establishment (handshake) (part 0 to 56 ms) and the basic process of TLS / SSL connection establishment (handshake) (part 56 ms to 168 ms) between the client 1 and the server 2 in the related art. Figure 1 In the process shown, there are vulnerabilities in multiple parts, which can be exploited by attackers to launch attacks, such as TLS handshake attacks. One of the purposes of TLS handshake is to negotiate a symmetric key. Based on asymmetric encryption and certificate mechanisms, the client initiates a request, and the server replies with its own certificate. The client uses the certificate chain mechanism to verify the validity, generates a symmetric key S, encrypts it with the public key contained in the certificate, and sends it to the server. After receiving the ciphertext, the server uses the private key to decrypt it and obtains the key S. At this point, both ends can use S for symmetric encryption transmission. This method can ensure that the key S is only known to the communicating parties. If the private key is not leaked, the third party cannot decrypt the content. However, if the private key is leaked, all the previously transmitted content will be decrypted. This is because the private key participates in the key exchange, which does not meet the forward security (Forward Secrecy). To solve this problem, the DH key exchange protocol (Diffie–Hellman key exchange) was generated. In the DH negotiation, the server private key a can use the private key in the certificate or a temporarily generated private key. In the first case, since the private key of the certificate participates in the generation of the key, once the private key of the certificate is leaked, the previous transmission may be cracked, so it is not forward security. The use of a temporarily generated private key can solve this problem, and this method is called DHE (Diffie-Hellman ephemeral). From the process, it can be seen that the computing resources spent by the server in the first two steps of the "handshake" are far greater than those of the client. Therefore, the attacker consumes a large amount of server resources by repeating the action of "initiating a request" and ignoring the subsequent response of the server to achieve the purpose of the attack. As long as the IP that initiates the attack-type ClientHello message is identified and blocked, it can be done. However, in actual use, there are many reasons for abnormal handshake messages, such as abnormal crash of the client program, fluctuation of network connection, etc. If the client IP is directly blocked, it is easy to cause the mistaken blocking of normal clients.

[0066] Since ClientHello is the starting request for all TLS / SSL connections, it is impossible to determine whether a client is good or bad through a single ClientHello message. Therefore, a method is needed to distinguish between normal and attack situations without having to determine whether the client is good or bad.

[0067] The essence of a handshake attack is to consume the computing resources of the server by initiating a large number of requests, thus reaching an "unserviceable" state. In related technologies, based on the setting that "normal clients will not initiate a large number of TLS / SSL handshake requests in a short period of time", request rate statistics can be made in the TLS handshake phase (presentation layer). A normal threshold for normal requests is usually set. For example, "initiating TLS / SSL connection requests within 10 seconds or less" is normal. If the number of TLS handshake requests (Client Hello messages) exceeds this normal threshold within a period of time, it is considered abnormal behavior, and the corresponding client is banned. The banning strategies in related technologies are relatively rough and lack refinement, and the set normal thresholds are difficult to adapt to and meet complex business scenarios.

[0068] In view of this, an embodiment of the present application provides a method for defending against malicious clients. In response to receiving a Transport Layer Security / Secure Sockets Layer protocol handshake request from a client, the receiving time is recorded, the cumulative number of handshake requests of the client is increased by 1, and an updated cumulative number is obtained. According to the updated cumulative number and the receiving time of each handshake request in the updated cumulative number, the handshake request frequency of the client is obtained, and it is determined whether the client is a malicious client. If the client is not a malicious client, the updated cumulative number is reduced by 1. If the client is a malicious client, the client Internet Protocol address in the handshake request is blocked. In this way, a refined management and control method based on a posteriori method for distinguishing between attacks and normal handshake requests can be implemented, and the set normal threshold value can fully adapt to and meet complex business scenarios.

[0069] A method for defending against malicious clients according to an embodiment of the present application is described below in conjunction with the accompanying drawings.

[0070] refer to Figure 2 As shown, an embodiment of the present application provides a method for defending against malicious clients, and the execution subject of the method may be a server. The method may include:

[0071] S10. In response to receiving a transport layer security / secure socket layer protocol handshake request from the client, record the receiving time, add 1 to the cumulative number of handshake requests from the client, and obtain an updated cumulative number.

[0072] Transport Layer Security is Transport Layer Security, referred to as TLS; Secure Socket Layer is Secure Socket Layer, referred to as SSL. Transport Layer Security / Secure Socket Layer protocol can be referred to as TLS / SSL. The Transport Layer Security / Secure Socket Layer protocol handshake request is the ClientHello message.

[0073] refer to Figure 3 As shown, the open system interconnection reference model provides a functional structure framework for open interconnected information systems, which includes 7 layers, from low to high: physical layer, data link layer, network layer, transport layer, session layer, presentation layer and application layer. Due to the layering of the network model, the presentation layer logic related to the "TLS / SSL handshake" is actually separated from the "application layer" logic of the business server, and data and information are often not shared. The presentation layer only does data formatting and encryption and decryption, and does not pay attention to the "good or bad" of the client; while the application layer does not pay attention to the encryption and decryption process, but only pays attention to the actual business of the customer, and can identify the good or bad of the client through the application layer request content such as HTTP. In the mechanism of the related technology, the counter is only controlled by the presentation layer and is "increment-only"; while in the method of this embodiment, the presentation layer and the application layer are combined to jointly control the counter, and a "subtraction" operation is introduced. For example, the reception time can be recorded in the application layer and presentation layer of the open system interconnection reference model, and the cumulative number of handshake requests from the client is increased by 1 to obtain the updated cumulative number.

[0074] For example, when the server receives a TLS / SSL handshake request (ClientHello message), it can first increase the client's IP count by 1 at the presentation layer, and then send Server Hello, the server's default certificate, and Server Hello Done according to the provisions of the TLS / SSL protocol, and start waiting for the client's subsequent response.

[0075] Timestamps can be used to record the reception time at the application layer and presentation layer of the Open Systems Interconnection Reference Model. When the application layer receives data, the program triggers the corresponding processing event. When the data reception event is triggered, the application uses the system time function to obtain the current time. For example, the obtained time can be stored in a data structure, usually stored together with the received data for subsequent processing or recording. For example, the timestamp can be stored in a dictionary or database with the message content. At the presentation layer, the recording of timestamps is usually related to the encoding and decoding of data. At the presentation layer, recording the reception time can be done in the following ways: When the presentation layer performs data format conversion, the reception time can be attached to the data packet. The presentation layer can define a special timestamp field to record the reception time of the data packet. The timestamp field can be in a custom format to ensure that the timestamp can be correctly parsed during decoding.

[0076] S20. According to the updated cumulative number of times and the receiving time of each handshake request in the updated cumulative number of times, obtain the handshake request frequency of the client, and determine whether the client is a malicious client.

[0077] Exemplarily, obtaining the handshake request frequency of the client according to the updated cumulative number and the receiving time of each handshake request in the updated cumulative number may include:

[0078] S201, obtaining the total number of receptions within a preset time period according to the updated cumulative number and the reception time of each handshake request in the updated cumulative number;

[0079] S202: Calculate the ratio of the total number of reception times within a preset period to the preset period to obtain a handshake request frequency.

[0080] Exemplarily, determining whether the client is a malicious client may include:

[0081] S203: If the handshake request frequency is greater than or equal to a preset value, the client is determined to be a malicious client;

[0082] The preset value may be pre-set based on historical data. For example, the number of malicious clients corresponding to each handshake request frequency may be counted from historical data, and the handshake request frequency corresponding to the largest number of malicious clients may be used as the preset value.

[0083] S204: If the handshake request frequency is less than a preset value, perform a handshake operation with the client according to the handshake request.

[0084] S205 . In response to receiving an encrypted Hypertext Transfer Protocol (HTTP) request from the client, determine whether the client is a malicious client according to the encrypted HTTP request; the encrypted HTTP request is generated by the client based on a handshake operation.

[0085] In some embodiments, performing a handshake operation with a client according to a handshake request may include: generating a reply message corresponding to the handshake request; sending the reply message and the server certificate, so that the client can perform a transport layer security / secure socket layer protocol connection establishment operation based on the reply message and the server certificate; in response to receiving a connection establishment operation completion message from the client within a preset time period, sending encrypted parameter data to the client, so that the client can encrypt the HTTP request based on the encrypted parameter data to obtain an encrypted HTTP request.

[0086] In some implementations, determining whether a client is a malicious client based on an encrypted HTTP request may include: parsing the encrypted HTTP request at the application layer of an open systems interconnection reference model to obtain parsing information; the encrypted HTTP request is obtained by the client encrypting the HTTP request based on a handshake operation; determining whether the handshake request is a malicious request based on the parsing information; if the handshake request is a malicious request, determining that the client is a malicious client; if the handshake request is not a malicious request, determining that the client is not a malicious client.

[0087] In some implementations, parsing an encrypted HTTP request to obtain parsed information may include: parsing ciphertext in the encrypted HTTP request based on a server private key and encryption suite in encrypted parameter data to obtain first information; parsing plaintext in the encrypted HTTP request based on the HTTP protocol to obtain second information; the parsed information includes the first information and the second information.

[0088] During the encryption process of HTTP requests, keys are exchanged between the client and the server, which is usually implemented through an asymmetric encryption algorithm such as RSA. The server's public key can be used by the client to encrypt information, and then the server uses the private key to decrypt. During the SSL / TLS handshake process, the client and the server will negotiate to select a cryptographic suite. The cryptographic suite defines the combination of algorithms used for encrypted communication, including key exchange algorithms, authentication algorithms, encryption algorithms, and message authentication code algorithms. After the key exchange is completed, the client and the server will use the negotiated symmetric encryption algorithm (such as AES) to encrypt the actual data transmission.

[0089] In the process of parsing the encrypted HTTP request, the server needs to use its private key to decrypt the encrypted information sent by the client. According to the encryption suite negotiated in the handshake phase, the server uses the corresponding algorithm to decrypt the data, processes the ciphertext through the decryption algorithm, and obtains the first information.

[0090] For example, the server obtains the ciphertext from the encrypted HTTP request. If RSA is used to encrypt the AES key, the server needs to use its private key to decrypt the AES key, and use the decrypted AES key to decrypt the ciphertext to obtain the first information.

[0091] For example, if the client encrypts an AES key using the server's public key and sends the encrypted AES key and data encrypted with the AES key to the server, the server needs to first decrypt the AES key using its own private key and then use the AES key to decrypt the data.

[0092] Exemplarily, determining whether a handshake request is a malicious request based on parsed information may include: determining whether an encrypted HTTP request is a malicious request based on the parsed information; if the encrypted HTTP request is a malicious request, determining that the handshake request is a malicious request; if the encrypted HTTP request is not a malicious request, determining that the handshake request is not a malicious request.

[0093] Exemplarily, determining whether the encrypted HTTP request is a malicious request based on the parsed information may include: detecting whether there is malicious request data in the parsed information; if so, determining that the encrypted HTTP request is a malicious request. Malicious request data includes, but is not limited to, structured query language injection, cross-site scripting attacks, local (remote) file inclusion, cross-site request forgery, etc.

[0094] Detecting whether there is structured query language (SQL) injection in the parsed information may include, for example: checking whether there is an SQL injection point in all input points in the parsed information (including URL parameters, form input, HTTP header, etc.); or constructing an SQL query statement for each input point in the parsed information, and after adding SQL keywords such as "OR", "AND", ";", etc., testing whether it affects the query results. If it affects the query results, it means that there may be SQL injection. You can also use professional security scanning tools (such as Burp Suite, OWASP ZAP) to detect whether there is SQL injection in the parsed information.

[0095] Detect whether there is a cross-site scripting attack in the parsed information. For example, you can use regular expressions to check whether the parsed information contains suspicious strings or special characters, such as <,>, script, onclick, etc. If it contains suspicious strings or special characters, it is determined that a cross-site scripting attack may exist.

[0096] S30: If the client is not a malicious client, the cumulative number of updates is reduced by 1.

[0097] S40: If the client is a malicious client, the client Internet Protocol address in the handshake request is blocked.

[0098] In some implementations, the defense method may further include: if the handshake request is a malicious request, discarding the handshake request and the encrypted HTTP request.

[0099] Exemplarily, it is possible to detect whether the client completes the subsequent connection establishment action normally. If the client does not complete the subsequent connection establishment action normally, the aforementioned TLS / SSL handshake request (Client Hello message) is considered to be a TLS / SSL handshake attack. When the counter count reaches a preset threshold, the client IP is blocked; if the client completes the subsequent connection establishment normally, an encrypted HTTP request action is sent. Specifically, refer to Figure 4 and Figure 5 As shown, after the client receives messages such as ServerHello, Certificate, and ServerHelloDone, it responds to messages such as ClientKeyExchange, ChangeCipherSpec, and Finished to confirm the selected encryption suite. After the server also responds to messages such as ChangeCipherSpec and Finished, the client can encrypt the plaintext, human-readable HTTP message according to the server public key and the negotiated encryption suite, and transmit it. The server processes the corresponding HTTP request content at the application layer, specifically including: receiving the encrypted HTTP request, and parsing the ciphertext using the server private key and the negotiated encryption suite; parsing the plaintext HTTP message content according to the HTTP protocol, and obtaining the request method, request URL, protocol number, protocol header, request content, and other parts for subsequent transmission or use by upper-layer applications; after verification by modules such as ACL, CC, and WAF, confirm whether it is an attack request; if it is an attack request, it performs actions such as blocking and blocking according to the operation configured by the application layer defense module; if it is not an attack request, the application layer performs a -1 operation on the counter.

[0100] Specifically, the blocking includes: obtaining the client's IP according to the aforementioned parsing action; if it is considered an attack request, all requests from this attack are rejected at the "network layer" (refer to the aforementioned OSI seven-layer model) for a period of time (configurable): discarding all messages of this HTTPS request; after the blocking time expires, if the subsequent client re-initiates a connection request, the server will still accept it by default.

[0101] Exemplarily, a TLS handshake attack test can be performed to obtain the blocking threshold A, and then a normal HTTPS request (including a complete TLS / SSL handshake process and a complete HTTP request) that meets the blocking threshold A can be initiated to verify whether it will be blocked, thereby verifying the effectiveness of this method.

[0102] Due to the layering of the network model, the presentation layer logic related to the TLS / SSL handshake is actually separated from the application layer logic of the business service end, and data and information are often unable to be shared. The presentation layer only performs data formatting, encryption and decryption, and does not care whether the client is a malicious client; the application layer does not care about the encryption and decryption process, but only cares about the actual business of the client, and can identify whether the client is a malicious client through the application layer request content such as HTTP. The counter in the related technology is only controlled by the presentation layer, and its count is only increasing; in this embodiment, the presentation layer and the application layer are used to jointly control the counter, and a subtraction operation is introduced for the counter. For example, if the client is not a malicious client, the cumulative number of updates can be reduced by 1 at the application layer and presentation layer of the open system interconnection reference model.

[0103] The defense method for malicious clients in the embodiment of the present application can completely verify whether the TLS / SSL handshake process is completed (if the request reaches the application layer, it can be considered that the transport layer and the presentation layer have successfully established the connection), and can verify the HTTPS message content at the application layer to verify whether it is a malicious request. If the request is a non-attack request, the count is rolled back through the -1 operation to improve the statistical accuracy of malicious requests, to ensure that only malicious requests are counted as much as possible, and to reduce the incidence of false blocking of normal clients.

[0104] The defense method for malicious clients in the embodiment of the present application can perform fine-grained control at the domain name level for SSL handshake requests without SNI (Server Name Indicator): the solutions of the related technology only perform statistical operations at the presentation layer, and requests without SNI cannot obtain domain name configurations; the statistical operations in the present technical solution are performed at both the presentation layer and the application layer, and the application layer can obtain domain name information to achieve fine-grained control at the domain name level.

[0105] The malicious client defense method of the embodiment of the present application realizes refined control at the domain name level. Specifically, the domain name information needs to be obtained first. The HTTPS request consists of two parts: one part is the TLS / SSL connection (presentation layer), and the other part is the HTTP connection (application layer). The TLS / SSL connection obtains the domain name information through the SNI in the ClientHello message, and the HTTP connection obtains the domain name information through the Host header.

[0106] The edge node of CDN (Content Delivery Network) is a reverse proxy. The necessary condition for service is that the HTTP connection must clearly identify the Host, otherwise the edge node cannot obtain the domain name information, and it cannot obtain the domain name configuration (back-to-source configuration, etc.). Therefore, the domain name information can be obtained in the HTTP connection, but there are not so many requirements for TLS / SSL connections. In order to be compatible with some old clients, CDNs in related technologies often allow ClientHello messages without SNI to pass, but because the domain name information cannot be obtained, the domain name configuration cannot be obtained at the presentation layer, and only general configuration can be used. Therefore, it is difficult for related technologies to achieve refined and scenario-based management and control at the domain name level. The attack identification and threshold control in the method of the embodiment of the present application are performed at the application layer, which is completely different from the operation mode of attack identification and threshold control at the presentation layer in the related technology. Therefore, this method can obtain domain name information (even if the client's TLS ClientHello request does not have SNI), thereby realizing refined management and control at the domain name level.

[0107] The above description of various embodiments tends to emphasize the differences between the various embodiments. The same or similar parts can be referenced to each other, and for the sake of brevity, they will not be repeated in this article.

[0108] refer to Figure 6 As shown, another embodiment of the present application provides a defense device for malicious clients, which may include:

[0109] an accumulation module, configured to, in response to receiving a transport layer security / secure socket layer protocol handshake request from a client, record a receiving time, add 1 to the accumulated number of handshake requests from the client, and obtain an updated accumulated number;

[0110] An acquisition module, used for acquiring the handshake request frequency of the client according to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates;

[0111] A judging module, used for judging whether the client is a malicious client according to the handshake request frequency;

[0112] A subtraction module, configured to reduce the cumulative number of updates by 1 if the client is not a malicious client;

[0113] The blocking module is used to block the client Internet Protocol address in the handshake request if the client is a malicious client.

[0114] Exemplarily, the judging module may include:

[0115] A first judging unit, configured to judge that the client is a malicious client if the handshake request frequency is greater than or equal to a preset value;

[0116] A second judgment unit is used to perform a handshake operation with the client according to the handshake request if the handshake request frequency is less than a preset value, and in response to receiving an encrypted Hypertext Transfer Protocol HTTP request from the client, judge whether the client is a malicious client according to the encrypted HTTP request; the encrypted HTTP request is generated by the client based on the handshake operation.

[0117] Exemplarily, the second judgment unit includes:

[0118] A reply message generating subunit, used to generate a reply message corresponding to the handshake request;

[0119] A first sending subunit, configured to send the reply message and the server certificate, so that the client performs a transport layer security / secure socket layer protocol connection establishment operation based on the reply message and the server certificate;

[0120] The second sending subunit is used to send encrypted parameter data to the client in response to receiving a connection establishment operation completion message from the client within a preset time period, so that the client encrypts the HTTP request based on the encrypted parameter data to obtain an encrypted HTTP request.

[0121] Exemplarily, the second judgment unit further includes:

[0122] A parsing subunit, configured to parse the encrypted HTTP request at an application layer of an open system interconnection reference model to obtain parsing information; the encrypted HTTP request is obtained by the client encrypting the HTTP request based on the handshake operation;

[0123] A first judging subunit, configured to judge whether the handshake request is a malicious request according to the parsing information;

[0124] If the handshake request is a malicious request, determining that the client is a malicious client;

[0125] If the handshake request is not a malicious request, it is determined that the client is not a malicious client.

[0126] Exemplarily, the parsing subunit is further specifically configured to:

[0127] Parsing the ciphertext in the encrypted HTTP request according to the server private key and the encryption suite in the encrypted parameter data to obtain the first information;

[0128] The plain text in the encrypted HTTP request is parsed according to the HTTP protocol to obtain the second information; the parsed information includes the first information and the second information.

[0129] Exemplarily, the first judgment subunit is further specifically configured to:

[0130] Determining whether the encrypted HTTP request is a malicious request according to the parsed information;

[0131] If the encrypted HTTP request is a malicious request, determining the handshake request is a malicious request;

[0132] If the encrypted HTTP request is not a malicious request, it is determined that the handshake request is not a malicious request.

[0133] Exemplarily, the first judgment subunit is further specifically used to: detect whether there is malicious request data in the parsed information; if so, determine that the encrypted HTTP request is a malicious request.

[0134] Exemplarily, the defense device further includes:

[0135] A discarding module is used to discard the handshake request and the encrypted HTTP request if the handshake request is a malicious request.

[0136] Exemplarily, the accumulation module is further specifically configured to record the receiving time at the application layer and the presentation layer of the open system interconnection reference model, add 1 to the accumulated number of handshake requests from the client, and obtain an updated accumulated number.

[0137] Exemplarily, the subtraction module is further specifically configured to reduce the cumulative number of updates by 1 at the application layer and the presentation layer of the Open Systems Interconnection Reference Model.

[0138] Exemplarily, the acquisition module is further specifically used to: acquire the total number of receptions within a preset time period based on the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates; calculate the ratio of the total number of receptions to the preset time period to obtain the handshake request frequency.

[0139] The malicious client defense device provided in the embodiment of the present application, in response to receiving a Transport Layer Security / Secure Sockets Layer protocol handshake request from the client, records the reception time, adds 1 to the cumulative number of handshake requests of the client to obtain an updated cumulative number, obtains the handshake request frequency of the client according to the updated cumulative number and the reception time of each handshake request in the updated cumulative number, and determines whether the client is a malicious client. If the client is not a malicious client, the updated cumulative number is reduced by 1. If the client is a malicious client, the client Internet Protocol address in the handshake request is blocked. In this way, a refined control method based on a posteriori method to distinguish between attacks and normal handshake requests can be implemented, and the set normal threshold value can fully adapt to and meet complex business scenarios.

[0140] Another embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the malicious client defense method of any of the above-mentioned embodiments.

[0141] refer to Figure 7 As shown, the electronic device 10 may include: a processor 100, a memory 101, a bus 102 and a communication interface 103, and the processor 100, the communication interface 103 and the memory 101 are connected via the bus 102; the memory 101 stores a computer program that can be run on the processor 100, and when the processor 100 runs the computer program, it executes the method provided in any of the aforementioned embodiments of the present application.

[0142] The memory 101 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk storage. The communication connection between the device network element and at least one other network element is realized through at least one communication interface 103 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used.

[0143] The bus 102 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. The memory 101 is used to store a program, and the processor 100 executes the program after receiving an execution instruction. The method disclosed in any implementation of the aforementioned embodiment of the present application may be applied to the processor 100, or implemented by the processor 100.

[0144] The processor 100 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 100 or an instruction in the form of software. The above processor 100 may be a general-purpose processor, which may include a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module may be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 101, and the processor 100 reads the information in the memory 101 and completes the steps of the above method in combination with its hardware.

[0145] The electronic device provided in the embodiment of the present application and the method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the method adopted, operated or implemented by them.

[0146] Another embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and the computer program is executed by a processor to implement the method of any of the above embodiments. Figure 8 As shown, the computer-readable storage medium shown is a CD 20 on which a computer program (ie, a program product) is stored. When the computer program is run by a processor, the malicious client defense method provided by any of the aforementioned embodiments will be executed.

[0147] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical or magnetic storage media, which are not listed here one by one.

[0148] The computer-readable storage medium provided in the above-mentioned embodiments of the present application and the method provided in the embodiments of the present application are based on the same inventive concept and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0149] It should be noted that:

[0150] The term "module" is not intended to be limited to a specific physical form. Depending on the specific application, a module can be implemented as hardware, firmware, software, and / or a combination thereof. In addition, different modules can share common components or even be implemented by the same components. There may or may not be clear boundaries between different modules.

[0151] The algorithm and display provided herein are not inherently related to any specific computer, virtual device or other equipment. Various general devices can also be used together with examples based on this. According to the above description, it is obvious to construct the structure required for this type of device. In addition, the application is not directed to any specific programming language yet. It should be understood that various programming languages ​​can be utilized to realize the content of the application described herein, and the description made to specific languages ​​above is for the purpose of disclosing the best mode of implementation of the application.

[0152] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0153] The above embodiments only express the implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for defending against malicious clients, characterized in that: include: In response to receiving a transport layer security / secure socket layer protocol handshake request from a client, recording a receiving time, adding 1 to a cumulative number of handshake requests from the client to obtain an updated cumulative number; According to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates, the handshake request frequency of the client is obtained to determine whether the client is a malicious client; If the client is not a malicious client, the cumulative number of updates is reduced by 1; If the client is a malicious client, the client Internet Protocol address in the handshake request is blocked.

2. The method according to claim 1, characterized in that: The determining whether the client is a malicious client includes: If the handshake request frequency is greater than or equal to a preset value, the client is determined to be a malicious client; If the handshake request frequency is less than a preset value, a handshake operation is performed with the client according to the handshake request, and in response to receiving an encrypted Hypertext Transfer Protocol HTTP request from the client, whether the client is a malicious client is determined according to the encrypted HTTP request; the encrypted HTTP request is generated by the client based on the handshake operation.

3. The method according to claim 2, characterized in that The performing a handshake operation with the client according to the handshake request includes: Generate a reply message corresponding to the handshake request; Sending the reply message and the server certificate, so that the client performs a transport layer security / secure socket layer protocol connection establishment operation based on the reply message and the server certificate; In response to receiving a connection establishment operation completion message from the client within a preset time period, encrypted parameter data is sent to the client, so that the client encrypts the HTTP request based on the encrypted parameter data to obtain an encrypted HTTP request.

4. The method according to claim 3, characterized in that The determining whether the client is a malicious client according to the encrypted HTTP request includes: Parsing the encrypted HTTP request at the application layer of the open system interconnection reference model to obtain parsing information; the encrypted HTTP request is obtained by the client encrypting the HTTP request based on the handshake operation; Determining whether the handshake request is a malicious request according to the parsed information; If the handshake request is a malicious request, determining that the client is a malicious client; If the handshake request is not a malicious request, it is determined that the client is not a malicious client.

5. The method according to claim 4, characterized in that The step of parsing the encrypted HTTP request to obtain parsing information includes: Parsing the ciphertext in the encrypted HTTP request according to the server private key and the encryption suite in the encrypted parameter data to obtain the first information; The plain text in the encrypted HTTP request is parsed according to the HTTP protocol to obtain the second information; the parsed information includes the first information and the second information.

6. The method according to any one of claims 3 to 5, characterized in that The determining whether the handshake request is a malicious request according to the parsed information includes: Determining whether the encrypted HTTP request is a malicious request according to the parsed information; If the encrypted HTTP request is a malicious request, determining the handshake request is a malicious request; If the encrypted HTTP request is not a malicious request, it is determined that the handshake request is not a malicious request.

7. The method according to claim 6, characterized in that The determining whether the encrypted HTTP request is a malicious request according to the parsed information includes: Detecting whether there is malicious request data in the parsed information; If it exists, the encrypted HTTP request is determined to be a malicious request.

8. The method according to claim 4 or 5, characterized in that: The defense method also includes: If the handshake request is a malicious request, the handshake request and the encrypted HTTP request are discarded.

9. The method according to any one of claims 1 to 5, characterized in that The recording receiving time, adding 1 to the cumulative number of handshake requests from the client to obtain an updated cumulative number, includes: The receiving time is recorded at the application layer and the presentation layer of the open system interconnection reference model, and the cumulative number of handshake requests of the client is increased by 1 to obtain an updated cumulative number.

10. The method according to any one of claims 1 to 5, characterized in that The step of reducing the cumulative number of updates by 1 includes reducing the cumulative number of updates by 1 at the application layer and the presentation layer of the open systems interconnection reference model.

11. The method according to any one of claims 1 to 5, characterized in that The acquiring the handshake request frequency of the client according to the updated cumulative number of times and the receiving time of each handshake request in the updated cumulative number of times includes: According to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates, the total number of receptions within a preset time period is obtained; The ratio of the total number of reception times to the preset time period is calculated to obtain the handshake request frequency.

12. A defense device for malicious clients, characterized in that: include: an accumulation module, configured to, in response to receiving a transport layer security / secure socket layer protocol handshake request from a client, record a receiving time, add 1 to the accumulated number of handshake requests from the client, and obtain an updated accumulated number; An acquisition module, configured to acquire the handshake request frequency of the client according to the cumulative number of updates and the reception time of each handshake request in the cumulative number of updates; A judging module, used for judging whether the client is a malicious client according to the handshake request frequency; A subtraction module, configured to reduce the cumulative number of updates by 1 if the client is not a malicious client; The blocking module is used to block the client Internet Protocol address in the handshake request if the client is a malicious client.

13. An electronic device, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the malicious client defense method as described in any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: The computer program is executed by a processor to implement the malicious client defense method according to any one of claims 1 to 11.

Images