Attack protection method, terminal device, and computer-readable storage medium

Abstract

The application discloses an attack protection method, a terminal device and a computer readable storage medium. The attack protection method comprises the following steps: receiving a request of a client; obtaining a logical address of the client based on the request of the client, and searching a log file corresponding to the client according to the logical address; obtaining a communication record of the client based on the log file; determining whether the client is an abnormal client according to the number of successful communication requests and abnormal communication requests in the communication record; and if so, intercepting the request of the client. Through the method, the request of the abnormal client can be intercepted, the connection link between the abnormal client and the server is terminated, and the bandwidth flow occupation caused by the server responding to the request is reduced.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to attack protection methods, terminal devices, and computer-readable storage media. Background Technology

[0002] As more and more applications access the internet via Hypertext Transfer Protocol (HTTPS), Distributed Denial of Service (DDoS) attacks, also known as flood attacks, are emerging. Current protection measures against flood attacks involve decrypting and verifying packets, requiring high-performance intermediate traffic scrubbing equipment. While these measures can protect against traffic attacks simulating normal access, they cannot protect against traffic attacks from abnormal clients. Abnormal clients only establish a handshake connection with the server without performing normal access, maliciously occupying the server's long-lived connection resources and causing abnormal server packet traffic. Summary of the Invention

[0003] This application provides attack protection methods, terminal devices, and computer-readable storage media to solve the technical problem of abnormal server packet traffic in the prior art.

[0004] To address the aforementioned issues, this application provides a first technical solution: an attack protection method comprising: receiving a request from a client; obtaining the client's logical address based on the client's request, and searching for the client's corresponding log file according to the logical address; obtaining the client's communication records based on the log file; determining whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication records; and if so, intercepting the client's request.

[0005] The step of determining whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication record includes: obtaining the ratio of the number of successful communication requests to the number of abnormal communication requests in the communication record; confirming the client as an abnormal client when the ratio is less than or equal to a first preset threshold; and confirming the client as a normal client when the ratio is greater than the first preset threshold.

[0006] After confirming that the client is an abnormal client, the attack protection method further includes: confirming the degree of abnormality of the client based on the quantity ratio.

[0007] The step of determining whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication record includes: obtaining the ratio of the number of successful communication requests to the number of abnormal communication requests in the communication record; when the ratio is less than or equal to a first preset threshold, determining whether the number of abnormal communication requests is less than or equal to a second preset threshold; if yes, then confirming the client as the normal client; if no, then confirming the client as the abnormal client.

[0008] The communication record includes the client's request content; the abnormal communication request is a communication request whose request content only includes a handshake request; and the successful communication request is a communication request whose request content includes a non-handshake request.

[0009] The log file includes the client's request records within a preset time period, and the request records include the client's successful communication requests and abnormal communication requests.

[0010] The step of intercepting the client's request includes: writing the logical address of the abnormal client into a blacklist file, obtaining an updated blacklist file, so that the firewall node can intercept the relevant client's request according to the blacklist file.

[0011] The attack protection method further includes: obtaining the number of requests processed by all firewall nodes in the firewall cluster; and assigning the client's request processing task to an idle firewall node for execution based on the number of requests processed.

[0012] To address the aforementioned issues, this application provides a second technical solution: a terminal device comprising a processor and a memory connected to the processor, wherein the memory stores program data, and the processor retrieves the program data stored in the memory to execute the attack protection method described above.

[0013] To address the aforementioned problems, this application provides a third technical solution: a computer-readable storage medium storing program instructions, which are executed to implement the attack protection method described above.

[0014] This application proposes an attack protection method, terminal device, and computer-readable storage medium. The attack protection method includes: receiving a request from a client; obtaining the client's logical address based on the client's request, and searching the corresponding log file of the client according to the logical address; obtaining the client's communication records based on the log file; determining whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication records; if so, intercepting the client's request. This method can intercept requests from abnormal clients, terminate the connection between abnormal clients and the server, and reduce bandwidth consumption caused by the server responding to requests. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0016] Figure 1 This is a flowchart of the first embodiment of the attack protection method provided in this application;

[0017] Figure 2 This is a flowchart of the second embodiment of the attack protection method provided in this application;

[0018] Figure 3 This is a flowchart of the third embodiment of the attack protection method provided in this application;

[0019] Figure 4 This is a framework diagram of an embodiment of the terminal device provided in this application;

[0020] Figure 5 This is a framework diagram of another embodiment of the terminal device provided in this application;

[0021] Figure 6 This is a framework diagram of an embodiment of the computer-readable storage medium provided in this application. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0024] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0025] In the field of network security, secure and complete data transmission can be ensured through Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols for information transmission between different networks. SSL and TLS provide authentication, confidentiality and integrity verification functions to enable encrypted information exchange.

[0026] Because the SSL / TLS handshake process involves asymmetric encryption algorithms, symmetric encryption algorithms, and hash algorithms, asymmetric encryption and decryption are computationally intensive tasks. In practice, the computational load on the server far exceeds that on the client for most asymmetric encryption algorithms. Existing protections against SSL / TLS attacks are based on the SSL / TLS connection itself to determine attack behavior and protect against client-side attacks based on factors such as the number of key exchanges and message decryption verification. While this method can protect against traffic attacks simulating normal access, it cannot protect against DDoS attacks that simulate a normal TLS handshake but do not perform normal message requests, and the resulting traffic attacks, leading to the malicious occupation of the server's long-lived connection resources.

[0027] Therefore, this application proposes an attack protection method applied to a terminal device. Specifically, the terminal device is connected to a server providing business services to protect against traffic attacks from abnormal clients, thereby safeguarding the server's data transmission security. The terminal device in this application can be a server or a system consisting of a server and a local terminal working together. Correspondingly, the various components of the terminal device, such as units, subunits, modules, and submodules, can be entirely housed in the server or separately in the server and the local terminal.

[0028] Furthermore, the aforementioned server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules, such as software or software modules used to provide distributed servers, or as a single software program or software module; no specific limitation is made here. In some possible implementations, the attack protection method of this application embodiment can be implemented by the processor calling computer-readable instructions stored in memory.

[0029] Please see Figure 1 , Figure 1 This is a flowchart of the first embodiment of the attack protection method provided in this application. Figure 1 As shown, the attack protection method in this embodiment includes the following steps:

[0030] Step S11: Receive the client's request.

[0031] Specifically, when a client establishes a communication connection with a server, the client needs to send a request to the server. The server needs to verify and respond to the client's request so that the client can access the server's business system. When the client sends a request, the terminal device receives the client's request.

[0032] The client's requests include various request methods, such as handshake requests for establishing a connection, GET requests for retrieving resources, POST requests for submitting data, PUT requests for uploading content, DELETE requests for deleting resources, and handshake requests for closing the connection. It can be understood that a handshake request is a prerequisite for interaction between the client and the server; other business services can only be provided after a handshake connection is established. In this embodiment, the client's request can be a handshake request or other business requests. Preferably, the client's request is a handshake request.

[0033] Step S12: Obtain the client's logical address based on the client's request, and search for the log file corresponding to the client according to the logical address.

[0034] Based on the received client request, obtain the client's logical address, which is an Internet Protocol Address (IP address) used to define the client (host) on the Internet. The logical address can be used to define the sender and receiver at the network layer in network transmission.

[0035] After obtaining the client's logical address, the corresponding log file is searched according to the logical address. Specifically, in one embodiment, the log file corresponding to the client is a request log of all or some clients making requests to the server within a preset time period stored on the terminal device; in another embodiment, the log file corresponding to the client is a request log of all or some clients making requests to the server within a preset time period stored on the server, with the server interacting with the terminal device, and the terminal device continuously or intermittently obtaining the corresponding log file from the server.

[0036] The request log records client access behavior information, including the client's logical address, request time, and request content. After obtaining the client's logical address, the logical address is compared and searched against the request logs in the log file.

[0037] Step S13: Obtain the client's communication records based on the log file.

[0038] After searching for the log file corresponding to the client based on the logical address, the request logs that match the client's logical address are filtered out. In other words, the logs of requests made by the client to the server within a preset time period are filtered out to obtain the client's communication records.

[0039] Step S14: Determine whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication record.

[0040] Since the communication logs include all requests initiated by the client within a preset time period, all client-initiated requests are divided into two categories according to preset classification rules: successful communication requests and abnormal communication requests, and the number of successful and abnormal communication requests is counted separately. Specifically, the preset classification rules can classify communication requests based on whether the client has completed a communication connection with the server; the preset classification rules can also classify communication requests based on the type of request initiated by the client, without specific limitations here. Depending on the preset classification rules, the definitions of successful and abnormal communication requests differ slightly, but it can be understood that successful communication requests are request behaviors that normal clients tend to initiate, and abnormal communication requests are request behaviors that abnormal clients tend to initiate.

[0041] The system determines whether a client is abnormal based on the number of successful and abnormal communication requests in the communication log. If the client is abnormal, proceed to step S15; if the client is normal, forward the client's request to the server so that the server can return the corresponding response instruction.

[0042] Step S15: Intercept the client's request.

[0043] When a client is identified as an abnormal client, the terminal device intercepts the client's requests.

[0044] When a handshake request is made, the terminal device receives a Client Hello message from the client. The terminal device analyzes log files to obtain the client's communication records and identifies malicious attack behavior based on the number of successful and abnormal communication requests in the records, thus intercepting requests from abnormal clients. Because the terminal device can intercept abnormal client requests and terminate the link, the abnormal client does not enter the TLS handshake phase. The server does not need to respond to the abnormal client's Client Hello request and send corresponding certificate information, reducing bandwidth consumption for service responses.

[0045] In this embodiment, the attack prevention method includes receiving a client's request; obtaining the client's logical address based on the client's request, and searching the corresponding log file of the client according to the logical address; obtaining the client's communication records based on the log file; determining whether the client is an abnormal client based on the number of successful communication requests and abnormal communication requests in the communication records; and if so, intercepting the client's request. This method can intercept requests from abnormal clients, terminate the connection between the abnormal client and the server, and reduce bandwidth consumption caused by the server responding to requests.

[0046] Please see Figure 2 , Figure 2 This is a flowchart of the second embodiment of the attack protection method provided in this application. Figure 2 As shown, step S14 further includes the following steps:

[0047] S21: Obtain the ratio of successful communication requests to abnormal communication requests in the communication records.

[0048] After obtaining the number of successful and abnormal communication requests, calculate the ratio of successful to abnormal communication requests. Since successful communication requests are the type of requests that normal clients tend to initiate, and abnormal communication requests are the type of requests that abnormal clients tend to initiate, the larger the ratio of successful to abnormal communication requests, the higher the probability that the client is a normal client. Therefore, the magnitude of the ratio of successful to abnormal communication requests can be used to determine whether a client is abnormal.

[0049] S22: When the quantity ratio is less than or equal to the first preset threshold, the client is identified as an abnormal client.

[0050] When the ratio of successful communication requests to abnormal communication requests is less than or equal to a first preset threshold, the client is identified as an abnormal client, and its requests are blocked. The specific value of the first preset threshold can be set based on factors such as the protection level of the terminal device and the security level of the server. If the first preset threshold is too low, some abnormal clients may not be identified, reducing the protection level of the terminal device; if the first preset threshold is too high, requests from normal clients may be blocked, resulting in a poor user experience. In an optional scheme, the number of successful communication requests from abnormal clients can be 0 to ensure the server's security level.

[0051] S23: When the quantity ratio is greater than the first preset threshold, the client is confirmed to be a normal client.

[0052] When the ratio of successful communication requests to abnormal communication requests exceeds a first preset threshold, the client is identified as a normal client, and the requests from the normal client are forwarded to the server so that the server can return the corresponding response instruction.

[0053] In this embodiment, the step of confirming whether a client is an abnormal client further includes: obtaining the ratio of successful communication requests to abnormal communication requests in the communication records; confirming the client as an abnormal client when the ratio is less than or equal to a first preset threshold; and confirming the client as a normal client when the ratio is greater than the first preset threshold. By using the method of this embodiment to determine whether a client is an abnormal client based on the ratio of successful communication requests to abnormal communication requests, it is possible to identify abnormal clients that only establish a handshake connection with the server without performing normal access, thus resolving the problem of abnormal server message traffic.

[0054] Optionally, after step S22, the ratio of the number of successful communication requests to the number of abnormal communication requests in the communication record is obtained, and the ratio of the number of successful communication requests to the number of abnormal communication requests is converted into the abnormality level of the client. The terminal device is set with multiple abnormal intervals corresponding to the abnormality level of the client. When the abnormality level of the client falls into a certain abnormal interval, the terminal device performs corresponding protection measures according to the abnormality level of the client.

[0055] For example, the terminal device is configured with a first abnormality interval and a second abnormality interval, with the degree of abnormality increasing progressively, and a first preset threshold greater than a third preset threshold. When the number ratio is less than or equal to the first preset threshold but greater than the third preset threshold, the client's abnormality level is classified as the first abnormality level. The terminal device monitors clients with the first abnormality level, for example, by forwarding the client's requests to the server and continuously receiving interaction information between the server and the client to monitor the client. When the number ratio is less than or equal to the third preset threshold, the client's abnormality level is classified as the second abnormality level, and the terminal device intercepts requests from clients with the second abnormality level. In this embodiment, implementing corresponding protection measures based on the client's abnormality level helps improve the accuracy of attack protection and reduce false positives.

[0056] Furthermore, while determining whether a client is abnormal solely by the ratio of successful to abnormal communication requests can identify clients that only establish a handshake connection with the server without engaging in normal access, normal clients may also experience a higher proportion of abnormal communication requests than successful ones due to factors such as improper user operation, changes in user business requirements, or client network status, thus affecting the user experience of normal clients. Therefore, in this embodiment, when the ratio is less than or equal to a first preset threshold, the number of abnormal communication requests is further used to determine whether the client is abnormal.

[0057] Please see Figure 3 , Figure 3 This is a flowchart of the third embodiment of the attack protection method provided in this application. Figure 3 As shown, the attack protection method in this embodiment includes the following steps:

[0058] S31: Obtain the ratio of successful communication requests to abnormal communication requests in the communication records.

[0059] Step S31 is similar to step S21, and will not be described again here.

[0060] S32: When the number ratio is less than or equal to the first preset threshold, determine whether the number of abnormal communication requests is less than or equal to the second preset threshold.

[0061] In some real-world scenarios, a normal client may initiate a small number of abnormal communication requests within a certain period of time due to factors such as improper user operation, changes in user business requirements, or client network status, without making successful communication requests. Furthermore, if an abnormal client launches a traffic attack by consuming server long-lived connection resources, the number of abnormal communication requests from the abnormal client will generally be relatively large. Therefore, when the terminal device determines that the ratio of successful communication requests to abnormal communication requests is less than or equal to a first preset threshold, it further determines whether the number of abnormal communication requests is less than or equal to a second preset threshold.

[0062] The specific value of the second preset threshold can be set according to factors such as the protection level of the terminal device and the security level of the server. If the number of abnormal communication requests is less than or equal to the second preset threshold, proceed to step S33; if the number of abnormal communication requests is greater than the second preset threshold, proceed to step S34.

[0063] S33: The client is confirmed to be a normal client.

[0064] If the ratio of successful communication requests to abnormal communication requests on the client is less than or equal to a first preset threshold and the number of abnormal communication requests is less than or equal to a second preset threshold, then the terminal device confirms that the client is a normal client.

[0065] S34: The client has been identified as an abnormal client.

[0066] If the ratio of successful communication requests to abnormal communication requests on a client is less than or equal to a first preset threshold and the number of abnormal communication requests is greater than a second preset threshold, then the client is identified as an abnormal client, and corresponding protective measures are taken against the abnormal client.

[0067] In this embodiment, the attack protection method further includes: when the number ratio is less than or equal to a first preset threshold, determining whether the number of abnormal communication requests is less than or equal to a second preset threshold; if yes, then confirming the client as a normal client; if no, then confirming the client as an abnormal client. By using the method of this embodiment, further determining whether a client is an abnormal client based on the number of abnormal communication requests can identify clients with a higher proportion of abnormal communication requests than normal clients with successful communication requests, reducing false alarms and improving the user experience.

[0068] Optionally, in other embodiments, when the number ratio is less than or equal to a first preset threshold, clients with an abnormal number of communication requests less than or equal to a second preset threshold can also be included in the monitoring scope. For example, the client's request can be forwarded to the server, and the interaction information between the server and the client can be continuously received. The interaction information between the server and the client can be used to further determine whether the client is an abnormal client.

[0069] Optionally, the communication record includes the client's request content. An abnormal communication request is a communication request whose request content only includes a handshake request, and a successful communication request is a communication request whose request content includes a non-handshake request.

[0070] Specifically, the communication log includes records of requests initiated by the client to the server within a preset time period. The request log includes information such as the client's request content, request path, request parameters, and request time. In this embodiment, successful communication requests and abnormal communication requests are defined based on the client's request content. An abnormal communication request is a communication request in which the client only initiates a handshake request, while a successful communication request is a request initiated by the client that includes other requests besides the handshake request.

[0071] In this embodiment, successful communication requests and abnormal communication requests are defined by the client's request content, which can intuitively identify abnormal clients that only handshake with the server without performing normal access.

[0072] Optionally, the log file includes client request records within a preset time period, including successful communication requests and abnormal communication requests from the client.

[0073] Specifically, in one embodiment, the terminal device is also used to record request logs of clients sending requests to the server. For example, the method for obtaining the log file may include the following steps: receiving client requests; recording client request logs; storing client request logs in a buffer; and exporting the request logs from the buffer within a preset time period to generate a log file.

[0074] At this point, upon receiving a client's request, the system records the client's request log and stores it in a buffer or other preset storage path. Within a preset time period, the buffer stores the request logs of clients sending requests to the server. The terminal device then exports all its stored request logs to generate a multi-client log file. Within the preset time period, the terminal device identifies abnormal clients based on the log file and intercepts their requests.

[0075] In other implementations, the server can send the request records processed within a preset time period to the terminal device, so that the terminal device can identify abnormal clients based on the log files corresponding to the clients and periodically update the blacklist file.

[0076] Optionally, step S15 further includes: writing the logical address of the abnormal client into a blacklist file to obtain an updated blacklist file, so that the firewall node can block the requests of the relevant client according to the blacklist file.

[0077] Specifically, when a client is identified as an abnormal client, its logical address is written to a blacklist file to obtain an updated blacklist. This allows the firewall node to block requests from abnormal clients by checking if their logical addresses exist in the blacklist when a terminal device receives a request, thus refusing to establish a TLS connection with the abnormal client. The firewall node does not need to repeatedly analyze the client's corresponding log files, improving protection efficiency.

[0078] Furthermore, the terminal device is equipped with a firewall node for processing requests initiated by the client. The request processing by the firewall node includes at least any step of the attack protection method described in any of the above embodiments, and may also include a combination of the attack protection methods described in any of the above embodiments. When the server provides more business services, the number of requests received by the server increases, and a single firewall node may not be able to meet the server's traffic demands. Therefore, the attack protection method of this embodiment can be executed by a firewall cluster to solve the traffic bottleneck of a single firewall node.

[0079] Please see Figure 4 , Figure 4 This is a framework diagram of an embodiment of the terminal device provided in this application. Figure 4 As shown, the attack protection method in this embodiment further includes: obtaining the number of requests processed by all firewall nodes in the firewall cluster; and assigning the client's request processing task to an idle firewall node for execution based on the number of requests processed.

[0080] A firewall cluster consists of multiple firewall nodes, for example, a first firewall node, a second firewall node, ..., an Nth firewall node. Each firewall node is used to process requests initiated by clients. The terminal device distributes the client request processing tasks to idle firewall nodes based on the total number of requests processed by all firewall nodes in the cluster, thereby balancing the load across all firewall nodes in the cluster.

[0081] To this end, the terminal device can be equipped with an allocation module, which includes reverse proxy servers such as Nginx and OpenResty, a load-balanced network structure, and an information filtering system such as IPTABLES, to distribute client request processing tasks to idle firewall nodes based on the number of requests. In other embodiments, the allocation module can also be configured with other structural systems to achieve the above functions, which are not specifically limited here.

[0082] Optionally, after processing the requests initiated by the client, the firewall node intercepts requests from abnormal clients and forwards requests from normal clients to the server. In one embodiment, the server providing business services can be located in the terminal device, that is, the server and the firewall node are respectively located in different systems of the terminal device; in another embodiment, the server providing business services is set up independently, in which case the terminal device is used to receive requests initiated by clients and forward requests from normal clients to the server.

[0083] Optionally, the terminal device can also calculate the processing utilization rate of all firewall nodes, where the processing utilization rate is the ratio of the number of requests being processed by the firewall node to the number of requests it can process, or the ratio of the current traffic of the firewall node to its maximum traffic limit. The device then sorts the request processing volume or processing utilization rate of all firewall nodes in the firewall cluster to allocate client request processing tasks to idle firewall nodes for execution.

[0084] Optionally, the terminal device can also obtain the bandwidth usage data of the client's request based on the request content, and assign the client's request processing task to an appropriate firewall node for execution based on the bandwidth usage data. For example, if the bandwidth usage data of the request initiated by the client is 50MB, and 50MB corresponds to 5% of the firewall's processing capacity, then the request will be assigned to a firewall node with a processing capacity of less than 95% for execution.

[0085] In this embodiment, the attack protection method further includes: obtaining the number of requests processed by all firewall nodes in the firewall cluster; and allocating client request processing tasks to idle firewall nodes for execution based on the number of requests processed. By extending the firewall nodes into a cluster mode, this attack protection method can be applied to large servers or distributed server clusters, resolving the traffic bottleneck of a single firewall node.

[0086] Please see Figure 5 , Figure 5 This is a framework diagram of another embodiment of the terminal device provided in this application. Figure 5 As shown, this application further proposes a terminal device 200, which includes a processor 201 and a memory 202 connected to the processor 201.

[0087] Processor 201 can also be referred to as CPU (Central Processing Unit). Processor 201 may be an integrated circuit chip with signal processing capabilities. Processor 201 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor can be a microprocessor or any conventional processor.

[0088] The memory 202 is used to store program data required for the processor 201 to run.

[0089] The processor 201 is also used to execute program data stored in the memory 202 to implement the above-mentioned attack protection method.

[0090] Optionally, in one embodiment, the processor 201 is configured to execute program data to implement the following method: receiving a request from a client; obtaining the client's logical address based on the client's request, and searching for the client's corresponding log file according to the logical address; obtaining the client's communication records based on the log file; determining whether the client is an abnormal client according to the number of successful communication requests and abnormal communication requests in the communication records; if so, intercepting the client's request.

[0091] Please see Figure 6 , Figure 6 This is a framework diagram of an embodiment of the computer-readable storage medium provided in this application. Figure 6 As shown, this application further proposes a computer-readable storage medium.

[0092] The computer-readable storage medium 300 of this application embodiment stores program instructions 310, which are executed to implement the above-described attack protection method.

[0093] Specifically, program instructions 310 can be formed into a program file and stored in the aforementioned storage medium in the form of a software product, so that a terminal device (which may be a personal computer, server, or network device, etc.) or processor can execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0094] In this embodiment, the computer-readable storage medium 300 may be, but is not limited to, a USB flash drive, SD card, PD optical drive, portable hard drive, large-capacity floppy drive, flash memory, multimedia memory card, server, etc.

[0095] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a terminal device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the terminal device to perform the steps in the above method embodiments.

[0096] Furthermore, if the aforementioned functions are implemented as software functions and sold or used as independent products, they can be stored in a mobile terminal-readable storage medium. That is, this application also provides a storage device storing program data, which can be executed to implement the methods of the above embodiments. This storage device can be, for example, a USB flash drive, an optical disc, or a server. In other words, this application can be embodied in the form of a software product, which includes several instructions to cause a smart terminal to execute all or part of the steps of the methods described in the various embodiments.

[0097] Any process or method description in the flowchart or otherwise herein can be understood as representing an apparatus, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order according to the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0098] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (which may be a personal computer, server, network device, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0099] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An attack protection method characterized by, The method comprises: receiving a request from a client; acquiring a logical address of the client based on the request from the client, and searching for a log file corresponding to the client according to the logical address; acquiring a communication record of the client based on the log file; determining whether the client is an abnormal client according to a number of successful communication requests and a number of abnormal communication requests in the communication record; if so, intercepting the request from the client; wherein the step of determining whether the client is an abnormal client according to the number of successful communication requests and the number of abnormal communication requests in the communication record comprises: acquiring a number ratio of the number of successful communication requests to the number of abnormal communication requests in the communication record; when the number ratio is less than or equal to a first preset threshold, determining whether the number of abnormal communication requests is less than or equal to a second preset threshold; if so, confirming that the client is a normal client; if not, confirming that the client is the abnormal client; the communication record comprises a request content of the client, the abnormal communication request is a communication request in which the request content only comprises a handshake request, and the successful communication request is a communication request in which the request content comprises a non-handshake request.

2. The attack protection method of claim 1, wherein, After the step of confirming that the client is an abnormal client, the attack protection method further comprises confirming an abnormal degree of the client according to the number ratio.

3. The attack protection method of claim 1, wherein, The log file comprises a request record of the client within a preset time, and the request record comprises the successful communication request and the abnormal communication request of the client.

4. The attack protection method of claim 1, wherein, The step of intercepting the request from the client comprises: writing the logical address of the abnormal client into a blacklist file to obtain an updated blacklist file, so that a firewall node intercepts a request from a related client according to the blacklist file.

5. The attack protection method according to any one of claims 1 to 4, characterized in that, The attack protection method further comprises: acquiring a number of request processing of all firewall nodes in a firewall cluster; distributing a request processing task of the client to an idle firewall node for execution based on the number of request processing.

6. A terminal device, characterized by comprising: A device comprises a processor and a memory connected to the processor, wherein the memory stores program data, and the processor executes the program data stored in the memory to perform the attack protection method according to any one of claims 1-4.

7. A computer readable storage medium characterized in that, The device internally stores program instructions which are executed to implement the attack protection method according to any one of claims 1-4.

Images