WO2019242053A1 - 一种针对HTTP Flood攻击的防护方法及系统 - Google Patents
一种针对HTTP Flood攻击的防护方法及系统 Download PDFInfo
- Publication number
- WO2019242053A1 WO2019242053A1 PCT/CN2018/095434 CN2018095434W WO2019242053A1 WO 2019242053 A1 WO2019242053 A1 WO 2019242053A1 CN 2018095434 W CN2018095434 W CN 2018095434W WO 2019242053 A1 WO2019242053 A1 WO 2019242053A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- http request
- target http
- target
- request
- verification
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Definitions
- the present invention relates to the technical field of computer network security, and in particular, to a method and system for protecting against HTTP Flood attacks.
- Hypertext Transfer Protocol Flood (HTTP, Flood) attacks are a way of attacking servers.
- the protection method for HTTP Flood attacks is to set a protective device between the client and the server.
- TCP Transmission Control Protocol
- the client can send HTTP requests to the server to protect the device.
- the HTTP request is obtained, the HTTP request is verified, and the HTTP request is sent to the server after the verification is passed, otherwise the HTTP request is intercepted, thereby preventing the HTTP request sent by the attacker from attacking the server.
- the protection device usually can only parse out the HTTP request carried by one data packet, and when the same HTTP request is carried by multiple data packets, that is, when the same HTTP request is distributed in multiple data packets, These packets cannot be parsed completely, and a complete HTTP request cannot be parsed from these packets.
- the protection device usually forwards these unresolvable data packets directly to the server, and because the same HTTP request composed of multiple data packets may be an attacking request, the server is vulnerable to attack.
- embodiments of the present invention provide a method and system for protecting against HTTP Flood attacks.
- the technical solution is as follows:
- a method for protecting against HTTP flood attacks is provided.
- the method is applied to a server.
- the method includes:
- the verification target HTTP request includes:
- the target HTTP request includes the verification information, verify whether the verification information is correct.
- the verification target HTTP request further includes:
- the target HTTP requests corresponding to the same source address received after reaching the second threshold are discarded.
- the method further includes:
- the verification target HTTP request further includes:
- the target HTTP requests corresponding to the same combination are discarded.
- the method further includes:
- the verification target HTTP request further includes:
- the target HTTP request is an HTTP request carried by multiple data packets, determine whether the target HTTP request includes authentication information, and if the target HTTP request includes the authentication information, verify whether the authentication information Correct, otherwise send the verification information to the client that sent the target HTTP.
- the method before verifying the target HTTP request, the method includes:
- the verification target HTTP request further includes:
- the target HTTP request does not carry the identifier, determine whether the target HTTP request contains verification information, and if the target HTTP request contains the verification information, verify whether the verification information is correct, otherwise send The client sending the target HTTP sends the verification information.
- a protection system against HTTP Flood attacks includes a protection device and a server;
- the protection device is configured to receive an HTTP request sent by a client, and when an attack is determined to exist, verify the HTTP request carried by one data packet, and send the HTTP request carried by multiple data packets to the server and pass the verification HTTP request carried by a data packet;
- the server includes a receiving unit, a determining unit, a verification unit, and a response unit;
- the receiving unit is configured to receive the number of HTTP requests sent by the protection device
- the determining unit is configured to determine the number of HTTP requests sent by the protection device during each statistical time interval
- the verification unit is configured to verify a target HTTP request after the number of HTTP requests received within any statistical time interval reaches a first threshold, wherein the target HTTP request includes HTTP received after the first threshold is reached request;
- the response unit is configured to respond to a target HTTP request that passes the verification.
- the verification unit is specifically configured to:
- the target HTTP request includes the verification information, verify whether the verification information is correct.
- the verification unit is further specifically configured to:
- the target HTTP requests corresponding to the same source address received after reaching the second threshold are discarded.
- the verification unit is further configured to:
- the verification unit is further specifically configured to:
- the target HTTP requests corresponding to the same combination are discarded.
- the verification unit is further configured to:
- the verification unit is further specifically configured to:
- the target HTTP request is an HTTP request carried by multiple data packets, determine whether the target HTTP request includes authentication information, and if the target HTTP request includes the authentication information, verify whether the authentication information Correct, otherwise send the verification information to the client that sent the target HTTP.
- the receiving unit is further configured to:
- the verification unit is further specifically configured to:
- the target HTTP request does not carry the identifier, determine whether the target HTTP request contains verification information, and if the target HTTP request contains the verification information, verify whether the verification information is correct, otherwise send The client sending the target HTTP sends the verification information.
- a server includes a processor and a memory.
- the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction and the at least one program.
- the code set or instruction set is loaded and executed by the processor to implement the protection method for HTTP Flood attacks described in the first aspect
- the server has a protection function and can verify HTTP requests that cannot be verified by the protection device, that is, HTTP requests obtained by reassembly of multiple data packets, and the protection device can verify HTTP requests carried by one data packet. Cooperate with protective equipment to improve the protection effect.
- FIG. 1 is a schematic diagram of a network framework according to an embodiment of the present invention
- FIG. 2 is a flowchart of a method for protecting against HTTP flood attacks according to an embodiment of the present invention
- FIG. 3 is a structural block diagram of a server provided by an embodiment of the present invention.
- FIG. 4 is a schematic structural diagram of a server according to an embodiment of the present invention.
- An embodiment of the present invention provides a method for protecting against HTTP flood attacks.
- This method can be applied to the network framework shown in FIG. 1.
- the network framework includes a client and a protection system, that is, a protection system against HTTP flood attacks.
- the protection system includes a protection device and a server.
- the client is connected to the protective device, and the protective device is connected to the server.
- Clients include clients that send normal HTTP requests and attackers that send attacked requests.
- the server can be a server cluster.
- the protection device receives the HTTP request sent by the client to the server, and can verify the HTTP request carried by a data packet.
- the protection device When the protection device receives the HTTP request carried by multiple data packets, and cannot resolve the complete HTTP request, it forwards these data packets to the server, and the server reassembles the data packets to obtain the complete HTTP request and verifies it.
- the multiple data packets in the embodiments of the present invention refer to at least two data packets.
- a protection system composed of a protection device and a server can verify the HTTP request carried by one data packet and the HTTP request carried by multiple data packets, thereby improving the protection effect.
- the HTTP request includes a source address and a Uniform Resource Locator (URL).
- the source address is used to indicate the source of the HTTP request, and each source address corresponds to a client.
- a URL is a concise representation of the location and access method of resources that can be obtained from the Internet. It is the address of a standard resource on the Internet. Each file on the Internet has a unique URL.
- each statistical time interval may be continuous in time, that is, the end time of the last statistical time interval is the start time of the next statistical time interval.
- the time interval may also be discontinuous in time.
- the protection device receives an HTTP request sent by the client to the server.
- the HTTP request includes an HTTP request carried by one data packet and an HTTP request carried by multiple data packets.
- the protection device starts to verify the received request.
- HTTP requests carried by one data packet, and HTTP requests carried by multiple data packets are forwarded to the server at the same time.
- the verification process of the protective device includes: parsing the HTTP request carried by a data packet.
- the HTTP request does not contain authentication information, it sends the authentication information to the client. After receiving the authentication information, the client follows the response and redirects to The protection device sends an HTTP request containing authentication information.
- the protection device After receiving the HTTP request, the protection device parses out the authentication information in the HTTP request and performs verification, and sends the HTTP request to the server after the verification is passed.
- the attacker When attacking the server, the attacker is generally only responsible for sending a large number of requests without receiving the authentication information sent by the protection device or parsing after receiving, so it cannot send a new HTTP request with authentication information, and it does not pass the authentication of the protection device.
- the HTTP request is a malicious request sent by the attacker and will be discarded without being forwarded to the server.
- the HTTP request verified by the protective device can be initially judged as a normal request and will be forwarded to the server through the protective device, so the protective device can intercept Attacker sent an attacking request.
- the protection device can cope with simple attacks, such as an HTTP request carried by a data packet, but the protection device cannot complete the analysis and processing of each data packet, nor can it reassemble multiple data packets into a complete HTTP request, and the server
- the underlying send and receive data packets pass through the complete protocol stack, and can reorganize multiple data packets to obtain a complete HTTP request. Therefore, the server can verify the HTTP requests obtained by reorganizing multiple data packets.
- FIG. 2 is a flowchart of a method for protecting against HTTP flood attacks according to an embodiment of the present invention.
- the method can be applied to a server.
- the method may specifically include the following steps.
- Step 201 Determine the number of HTTP requests sent by the protection device during each statistical time interval, wherein the HTTP requests include an HTTP request carried by one data packet and an HTTP request carried by multiple data packets.
- the server After receiving the data packet sent by the protection device, the server parses the data packet, and can parse out the complete HTTP request carried by one data packet. It can also parse multiple data packets according to the protocol stack and reassemble to obtain a complete HTTP request. To further verify HTTP requests that the protection device cannot verify.
- the server can determine whether there is an attack by determining the number of HTTP requests sent by the protection device during each statistical interval. When the number of HTTP requests received within each statistical time interval is less than the first threshold, it indicates that there is no attack, and the server can directly respond to each HTTP request without verifying the received HTTP request.
- Step 202 When the number of HTTP requests received within any statistical time interval reaches the first threshold, verify the target HTTP request, where the target HTTP request includes the HTTP requests received after the first threshold is reached.
- the server When the number of HTTP requests received within any statistical time interval reaches the first threshold, it indicates that there is an attack, and the server starts to verify the received target HTTP request. Because the HTTP request carried by a data packet received by the server is a legitimate request verified by the protection device, the number of these legitimate requests is limited and does not cause the total number of HTTP requests to reach the first threshold. When the number of received HTTP requests reaches the first threshold, it is usually caused by the excessive number of HTTP requests that have not been authenticated by the protection device, that is, the number of HTTP requests obtained by reassembly of multiple data packets. Therefore, when the server verifies the target HTTP request, it can verify the legitimacy of the HTTP request obtained by reassembly of multiple data packets.
- the embodiment of the present invention verifies the HTTP request received after the first threshold is reached.
- the first threshold is 5000.
- the received 5001st HTTP requests for verification.
- the number of HTTP requests received within any statistical time interval reaches the first threshold, it is possible to respond to any currently received HTTP request that has not responded, and to reach the first threshold
- the received HTTP request is then verified. For example, when it is found that the number of HTTP requests received reaches 5,000 within a statistical time interval, and no response has been received to the currently received 4999th and 5000th HTTP requests, the 4999th HTTP request can be started. verification.
- the server may verify the HTTP request through four implementation manners.
- the target HTTP request contains authentication information.
- the The client of the target HTTP sends the authentication information. After the client receives the authentication information, it resends the target HTTP request carrying the authentication information to the server.
- the protection device receives the target HTTP request sent by the client. If the target HTTP request is carried by a data packet, it authenticates it. After the authentication is passed, the target HTTP request is sent to the server. If the target HTTP request is carried by multiple data packets, the protection device directly forwards the target HTTP request to the server.
- the server receives the target HTTP request and determines that the target HTTP request contains the verification information, it verifies whether the verification information is correct, and if it is correct, the verification is passed.
- the number of target HTTP requests corresponding to each source address received in each statistical time interval is determined.
- the target HTTP request corresponding to the same source address received after reaching the second threshold is discarded.
- the discarded target HTTP request is a request that fails the authentication.
- the statistical time interval in the "determining the number of target HTTP requests corresponding to each source address received in each statistical time interval" is the same as the "determining the HTTP sent by the protection device received in each statistical time interval
- the statistics interval in Number of Requests can be synchronized or asynchronous, and the duration of these two statistics intervals can be equal or different.
- the number of target HTTP requests corresponding to each source address received can be counted from the next statistical time interval after the number of HTTP requests reaches the first threshold.
- the first statistical time interval The starting time is the time when the number of HTTP requests reaches a first threshold.
- the embodiment of the present invention does not specifically limit the start time and duration of the statistical time interval used for counting the number of target HTTP requests corresponding to each source address.
- the same source address may be sent to the protection device, so that the protection device discards the target HTTP requests corresponding to the same source address.
- the server in addition to directly counting the number of HTTP requests received, the server can also analyze and process the logs generated by the server to obtain source addresses with a particularly large number of requests, and notify these source addresses to the protection device. , So that the protection device intercepts HTTP requests corresponding to these source addresses, thereby forming a more complete protection system.
- the number of target HTTP requests corresponding to each set of source address and URL combinations received during each statistical time interval is determined.
- the target HTTP requests corresponding to the same combination received after reaching the third threshold are discarded. For example, the number of HTTP requests with a source address of A and the URL of access to B exceeds the third threshold, indicating that this combination is a malicious combination, and the corresponding HTTP request is a malicious request, then the HTTP request corresponding to this combination is discarded.
- the statistical time interval in the manner of this embodiment may be the same as the statistical time interval in Embodiment 2, or may be different from the statistical time interval in Embodiment 2.
- the same combination may be sent to the protection device, so that the protection device discards the target HTTP requests corresponding to the same combination. That is, when the protection device receives the HTTP request and determines that the combination of the source address of the HTTP request and the pre-visited URL belongs to a malicious combination reported by the server, the HTTP request is discarded.
- the process of verifying the target HTTP request can be: When When the target HTTP request is an HTTP request carried by one data packet, determine that the target HTTP request is a legitimate request; when the target HTTP request is an HTTP request carried by multiple data packets, determine the target HTTP request Whether verification information is included in the message, and if the verification information is included in the target HTTP request, verify whether the verification information is correct; otherwise, send the verification information to a client that sends the target HTTP.
- the client After the client receives the authentication information, it resends the target HTTP request carrying the authentication information to the server, and the protection device receives the target HTTP request. Since the target HTTP request is an HTTP request carried by multiple data packets, the protection device directly forwards the target HTTP request to the server after receiving the target HTTP request.
- the server receives the target HTTP request and determines that the target HTTP request contains the verification information, it verifies whether the verification information is correct, and if it is correct, the verification is passed.
- the server after determining that there is an attack, the server only verifies the target HTTP request carried by multiple data packets by sending verification information, which can reduce the number of times the server processes the request and enable the use of one data packet.
- the client sending the HTTP request gets the response from the server faster.
- a data packet carrying the target HTTP request is received, and the target HTTP request is parsed to obtain the target HTTP request.
- the target HTTP request is marked with an identifier.
- different identifiers can also be marked. That is, after receiving a data packet carrying the target HTTP request and parsing the target HTTP request, when the data packet carrying the target HTTP request is a data packet, the target is marked with the first identifier For an HTTP request, when the data packet carrying the target HTTP request is multiple data packets, the target HTTP request is marked with a second identifier. When the target HTTP request is verified, the HTTP request carried by one data packet and the HTTP request carried by multiple data packets can be distinguished according to the first identifier and the second identifier.
- Embodiment 1 and Embodiment 2 may be used simultaneously, or Embodiment 1 and Embodiment 3 may be used simultaneously.
- the HTTP requests that do not meet the requirements can be discarded in the second embodiment, and the HTTP requests that have not been discarded can be further verified in the first embodiment.
- Embodiment 2 and Embodiment 4 may be used simultaneously, or Embodiment 3 and Embodiment 4 may be used simultaneously.
- Step 203 Respond to the authenticated target HTTP request.
- the server responds to the authenticated target HTTP request by sending the response information corresponding to the target HTTP request to the client.
- the protection device can also send an incomplete HTTP request contained in only one data packet to the server.
- the server can resolve the incomplete HTTP request, it can verify or respond to it.
- the HTTP request can be discarded.
- the server has a protection function and can verify HTTP requests that cannot be verified by the protection device, that is, HTTP requests obtained by recombining multiple data packets, and the protection device can verify HTTP requests carried by one data packet.
- the server Cooperate with protective equipment to improve the protection effect.
- the server may specifically include a receiving unit 301, a determining unit 302, a verification unit 303, and a response unit 304.
- the receiving unit 301 is configured to receive the number of HTTP requests sent by the protection device.
- the HTTP requests sent by the protection device include an HTTP request carried by one data packet and an HTTP request carried by multiple data packets. request.
- the determining unit 302 is configured to determine the number of HTTP requests sent by the protection device in each statistical time interval.
- the verification unit 303 is configured to verify a target HTTP request after the number of HTTP requests received within any statistical time interval reaches a first threshold, where the target HTTP request includes the HTTP requests received after the first threshold is reached. HTTP request.
- the response unit 304 is configured to respond to the target HTTP request that passes the verification.
- the verification unit 303 is specifically configured to:
- the target HTTP request includes the verification information, verify whether the verification information is correct.
- the verification unit 303 is further specifically configured to:
- the target HTTP requests corresponding to the same source address received after reaching the second threshold are discarded.
- the verification unit 303 is further configured to:
- the verification unit 303 is further specifically configured to:
- the target HTTP requests corresponding to the same combination are discarded.
- the verification unit 303 is further configured to: send the same combination to the protection device, so that the protection device discards the target HTTP request corresponding to the same combination.
- the verification unit 303 is further specifically configured to:
- the target HTTP request is an HTTP request carried by multiple data packets, determine whether the target HTTP request includes authentication information, and if the target HTTP request includes the authentication information, verify whether the authentication information Correct, otherwise send the verification information to the client that sent the target HTTP.
- the receiving unit 301 is further configured to: receive a data packet carrying the target HTTP request and parse to obtain the target HTTP request; when the data packet carrying the target HTTP request is a data packet, use an identifier Mark the target HTTP request.
- the verification unit 303 is further specifically configured to: when the target HTTP request carries the identifier, determine that the target HTTP request is a legitimate request; when the target HTTP request does not carry the identifier, It is determined whether the target HTTP request contains verification information, and if the target HTTP request contains the verification information, verify whether the verification information is correct; otherwise, send the verification information to a client that sends the target HTTP.
- the server has a protection function and can verify HTTP requests that cannot be verified by the protection device, that is, HTTP requests obtained by recombining multiple data packets, and the protection device can verify HTTP requests carried by one data packet.
- the server Cooperate with protective equipment to improve the protection effect.
- the server provided in the foregoing embodiment performs protection, only the division of the above functional units is used as an example. In actual applications, the above functions may be allocated by different functional units according to needs. That is, the server ’s The internal structure is divided into different functional units to complete all or part of the functions described above.
- the server provided in the foregoing embodiment belongs to the same concept as the embodiment of the method for protecting against HTTP flood attacks, and its specific implementation process is described in the method embodiment in detail, and is not repeated here.
- the server 400 may have a large difference due to different configurations or performance, and may include one or more central processing units 422 (for example, one or more processors) and a memory 432, one or more storage applications 442, or data.
- a storage medium 430 of 444 (for example, one or one storage device in Shanghai).
- the memory 432 and the storage medium 430 may be transient storage or persistent storage.
- the program stored in the storage medium 430 may include one or more units (not shown in the figure), and each unit may include a series of instruction operations on the protective equipment.
- the central processing unit 422 may be configured to communicate with the storage medium 430, and execute a series of instruction operations in the storage medium 430 on the server 400.
- the server 400 may also include one or more power sources 429, one or more wired or wireless network interfaces 450, one or more input-output interfaces 458, one or more keyboards 454, and / or, one or more operating systems 441. , Such as Windows ServerTM, Mac OSXTM, UnixTM, LinuxTM, FreeBSDTM and so on.
- the server 400 may include a memory, and one or more programs, one or more programs stored in the memory, and configured to be executed by one or more processors.
- the one or more programs include a program for performing the above. Directive on protective methods.
- the program may be stored in a computer-readable storage medium.
- the storage medium mentioned may be a read-only memory, a magnetic disk or an optical disk.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种针对HTTP Flood攻击的防护方法及系统,该方法包括:确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量,其中,所述HTTP请求包括由一个数据包承载的HTTP请求和由多个数据包承载的HTTP请求;当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求;响应通过验证的目标HTTP请求。在本发明实施例中,服务器具备防护功能,并能够验证防护设备无法验证的HTTP请求,即由多个数据包重组得到的HTTP请求,而防护设备能够验证由一个数据包承载的HTTP请求,服务器与防护设备相互配合,从而提高防护效果。
Description
本发明涉及计算机网络安全技术领域,特别涉及一种针对HTTP Flood攻击的防护方法及系统。
超文本传输协议洪水(Hyper Text Transfer Protocol Flood,HTTP Flood)攻击是一种主要针对服务器进行攻击的方式。目前,针对HTTP Flood攻击的防护方法是在客户端与服务器中间设置防护设备,当客户端与服务器建立传输控制协议(Transmission Control Protocol,TCP)连接后,客户端可以向服务器发送HTTP请求,防护设备在获取到所述HTTP请求后,对HTTP请求进行验证,验证通过后向服务器发送HTTP请求,否则进行拦截,从而防止攻击端发送的HTTP请求攻击服务器。
但是,防护设备通常只能解析出由一个数据包承载的HTTP请求,而当同一个HTTP请求由多个数据包承载时,也就是说,当同一个HTTP请求分布于多个数据包中时,无法对这些数据包进行完整解析,也就无法从这些数据包中解析出完整的HTTP请求。防护设备通常将这些无法解析的数据包直接转发给服务器,又由于由多个数据包组成的同一个HTTP请求可能是有攻击的请求,所以容易导致服务器受到攻击。
发明内容
为了解决现有技术的问题,本发明实施例提供了一种针对HTTP Flood攻击的防护方法及系统。所述技术方案如下:
第一方面,提供了一种针对HTTP Flood攻击的防护方法,所述方法应用于服务器中,所述方法包括:
确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量,其中,所述HTTP请求包括由一个数据包承载的HTTP请求和由多个数据包承载 的HTTP请求;
当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求;
响应通过验证的目标HTTP请求。
可选的,所述验证目标HTTP请求,包括:
确定所述目标HTTP请求中是否包含验证信息;
当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息;
当所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确。
可选的,所述验证目标HTTP请求,还包括:
确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量;
当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。
可选的,当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,还包括:
向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。
可选的,所述验证目标HTTP请求,还包括:
确定每个统计时间间隔内接收到的每组源地址和统一资源定位符URL的组合对应的目标HTTP请求的数量;
当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。
可选的,当同一组合对应的目标HTTP请求的数量达到第三阈值之后,还包括:
向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。
可选的,所述验证目标HTTP请求,还包括:
当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;
当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
可选的,所述验证目标HTTP请求之前,包括:
接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求;
当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求;
所述验证目标HTTP请求,还包括:
当所述目标HTTP请求带有所述标识时,确定所述目标HTTP请求为合法请求;
当所述目标HTTP请求不带有所述标识时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
第二方面,提供了一种针对HTTP Flood攻击的防护系统,所述系统包括防护设备和服务器;
所述防护设备,用于接收客户端发送的HTTP请求,当确定出存在攻击时,验证由一个数据包承载的HTTP请求,并向所述服务器发送由多个数据包承载的HTTP请求以及通过验证的由一个数据包承载的HTTP请求;
所述服务器包括接收单元、确定单元、验证单元以及响应单元;
所述接收单元,用于接收所述防护设备发送的HTTP请求的数量;
所述确定单元,用于确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量;
所述验证单元,用于当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求;
所述响应单元,用于响应通过验证的目标HTTP请求。
可选的,所述验证单元具体用于:
确定所述目标HTTP请求中是否包含验证信息;
当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息;
当所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确。
可选的,所述验证单元还具体用于:
确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量;
当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。
可选的,所述验证单元还用于:
向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。
可选的,所述验证单元还具体用于:
确定每个统计时间间隔内接收到的每组源地址和统一资源定位符URL的组合对应的目标HTTP请求的数量;
当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。
可选的,所述验证单元还用于:
向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。
可选的,所述验证单元还具体用于:
当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;
当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
可选的,所述接收单元还用于:
接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求;
当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求;
所述验证单元还具体用于:
当所述目标HTTP请求带有所述标识时,确定所述目标HTTP请求为合法请求;
当所述目标HTTP请求不带有所述标识时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
第三方面,提供了一种服务器,所述服务器包括处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现第一方面所述的针对HTTP Flood攻击的防护方法
在本发明实施例中,服务器具备防护功能,并能够验证防护设备无法验证的HTTP请求,即由多个数据包重组得到的HTTP请求,而防护设备能够验证由一个数据包承载的HTTP请求,服务器与防护设备相互配合,从而提高防护效果。
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种网络框架示意图;
图2是本发明实施例提供的一种针对HTTP Flood攻击的防护方法流程图;
图3是本发明实施例提供的服务器的结构框图;
图4是为本发明实施例提供的一种服务器的结构示意图。
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
本发明实施例提供了一种针对HTTP Flood攻击的防护方法,该方法可以应用于图1所示的网络框架中。该网络框架包括客户端以及防护系统,即针对HTTP Flood攻击的防护系统,所述防护系统包括防护设备以及服务器。客户端连接防护设备,防护设备连接服务器。客户端包括发送正常HTTP请求的客户端以及发送有攻击的请求的攻击端。该服务器可以为服务器集群。防护设备接收客户端向服务器发送的HTTP请求,并能够验证由一个数据包承载的HTTP请求。当防护设备接收到由多个数据包承载的HTTP请求时,无法解析出完整的HTTP请求时,向服务器转发这些数据包,由服务器进行数据包重组得到完整的HTTP请求,并对其进行验证。本发明实施例中的多个数据包是指至少两个数据包。在本发明实施例中,由防护设备以及服务器组成的防护系统能够验证由一个数据包承载的HTTP请求和由多个数据包承载的HTTP请求,从而提升防护效果。
HTTP请求中包括源地址和统一资源定位符(Uniform Resource Locator,URL)。源地址用于表示该HTTP请求的发送源,每个源地址对应一个客户端。URL是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示,是互联网上标准资源的地址,互联网上的每个文件都有一个唯一的URL。
当不存在攻击时,防护设备可以无需验证HTTP请求的安全性,也就是说,当接收到的HTTP请求后,直接向服务器发送该HTTP请求。防护设备确定是否存在攻击的过程为,确定每个统计时间间隔(例如,5秒)内接收到的HTTP请求的数量,当在任一统计时间间隔内接收到的HTTP请求的数量超过阈值之后,可以认为存在攻击,否则可以认为不存在攻击。需要说明的是,在本发明实施例中,每个统计时间间隔在时间上可以是连续的,也就是说上个统计时间间隔的结束时刻为下个统计时间间隔的起始时刻,每个统计时间间隔在时间上也可以是不连续的。
防护设备接收客户端向所述服务器发送的HTTP请求,该HTTP请求包括由一个数据包承载的HTTP请求以及由多个数据包承载HTTP请求,当确定出存在攻击时,防护设备开始验证接收的由一个数据包承载的HTTP请求,同时向服务器转发由多个数据包承载HTTP请求。防护设备进行验证的过程包括:解析由一个数据包承载的HTTP请求,当该HTTP请求中不包含验证信息时,向该客户端发送验证信息,客户端接收到该验证信息后跟随响应,重新向防护设备发送包含验证信息的HTTP请求,防护设备接收到HTTP请求后,解析出 HTTP请求中的验证信息并进行验证,当验证通过后向服务器发送该HTTP请求。而攻击端在攻击服务器时,一般只负责发送大量的请求,而不会接收防护设备发送的验证信息或者接收后不做解析,从而无法发送新带有验证信息的HTTP请求,没有通过防护设备验证的HTTP请求即为攻击端发送的恶意请求,将被丢弃而不会转发给服务器,通过防护设备验证的HTTP请求可初步判断为正常的请求,将通过防护设备转发给服务器,因此防护设备能够拦截攻击端发送的有攻击的请求。
防护设备能够应对简单的攻击,如一个数据包承载的HTTP请求,但防护设备无法对每个数据包进行完整的解析和处理,也就无法将多个数据包重组成完整的HTTP请求,而服务器的底层收发数据包经过完整的协议栈,能够对多个数据包进行重组,得到完整的HTTP请求,所以服务器能够对由多个数据包重组得到的HTTP请求进行验证。以下详细说明服务器的防护过程。
参见图2,为本发明实施例提供的一种针对HTTP Flood攻击的防护方法的流程图,该方法可以应用于服务器中,该方法具体可以包括以下步骤。
步骤201,确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量,其中,所述HTTP请求包括由一个数据包承载的HTTP请求和由多个数据包承载的HTTP请求。
服务器接收到防护设备发送的数据包后,对其进行解析,可以解析出由一个数据包承载的完整的HTTP请求,也可以根据协议栈对多个数据包进行解析,重组得到一个完整的HTTP请求,从而能够进一步验证防护设备无法验证的HTTP请求。
服务器可以通过确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量,来确定是否存在攻击。当每个统计时间间隔内接收到的HTTP请求的数量均小于第一阈值,说明不存在攻击,服务器可以无需验证接收到的HTTP请求,而是直接响应各HTTP请求。
步骤202,当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求。
当任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,说明存在攻击,服务器开始验证接收到的目标HTTP请求。由于服务器接收到的 由一个数据包承载的HTTP请求是经过防护设备验证过的合法请求,这些合法请求的数量有限,并不会导致HTTP请求的总数量达到第一阈值,所以当统计时间间隔内接收到的HTTP请求的数量达到第一阈值时,通常是由于没有经过防护设备验证过的HTTP请求,即由多个数据包重组得到的HTTP请求数量过大导致的。所以当服务器对目标HTTP请求进行验证时,就能够验证出由多个数据包重组得到的HTTP请求的合法性。
本发明实施例对达到第一阈值之后接收的HTTP请求进行验证,例如,第一阈值为5000,当在一个统计时间间隔内发现接收到的HTTP请求的数量达到5000,则对接收到的第5001个HTTP请求进行验证。
在具体实施中,还可以规定,当任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值时,可以对当前任一接收到的且没有响应的HTTP请求,以及对达到第一阈值之后接收到的HTTP请求进行验证。例如,当在一个统计时间间隔内发现接收到的HTTP请求的数量达到5000时,且还没对当前接收的第4999个以及第5000个HTTP请求进行响应,则可以从第4999个HTTP请求开始进行验证。
具体地,服务器可以通过四种实施方式对HTTP请求进行验证。
实施方式一
当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,确定所述目标HTTP请求中是否包含验证信息,当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息。客户端接收到验证信息后,向服务器重新发送携带有该验证信息的目标HTTP请求,防护设备接收客户端发送的目标HTTP请求,如果该目标HTTP请求由一个数据包承载时,对其进行验证,验证通过后向服务器发送该目标HTTP请求。如果该目标HTTP请求由多个数据包承载,防护设备直接向服务器转发该目标HTTP请求。当服务器接收到该目标HTTP请求,并确定出所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确,如果正确则通过验证。
前述部分已经对防护设备对HTTP请求进行验证的过程进行了详细说明,再此不再赘述。
实施方式二
当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后, 确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量,当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。丢弃的目标HTTP请求即为没有通过验证的请求。
所述“确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量”中的统计时间间隔,与所述“确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量”中的统计时间间隔可以同步,也可以不同步,这两种统计时间间隔的时长可以相等也可以不等。当同步时,可以在HTTP请求的数量达到第一阈值之后的下一个统计时间间隔开始统计接收到的每个源地址对应的目标HTTP请求的数量。当不同步时,可以在HTTP请求的数量达到第一阈值之后,即开始统计每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量,此时,第一个统计时间间隔的起始时间为所述HTTP请求的数量达到第一阈值的时刻。本发明实施例不对为统计每个源地址对应的目标HTTP请求的数量所使用的统计时间间隔的起始时间以及时长进行具体限制。
当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,可以向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。在具体实施过程中,服务器除了直接对接收到的HTTP请求进行数目统计,也可以针对服务器生成的日志进行解析和处理,得出请求量特别大的源地址,并将这些源地址通知到防护设备,以使防护设备对这些源地址对应的HTTP请求进行拦截,从而形成更加完整的防护体系。
实施方式三
当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,确定每个统计时间间隔内接收到的每组源地址和URL的组合对应的目标HTTP请求的数量,当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。例如源地址为A的HTTP请求访问URL为B的数量超过第三阈值,说明这一组合为恶意组合,其对应的HTTP请求为恶意请求,则丢弃这一组合对应的HTTP请求。
本实施例方式中的统计时间间隔可以与实施方式二中的统计时间间隔相同,也可以与实施方式二中的统计时间间隔不同。
当同一组合对应的目标HTTP请求的数量达到第三阈值之后,可以向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。也就是说,当防护设备接收到HTTP请求,并确定该HTTP请求的源地址以及预访问的URL的组合属于服务器上报的恶意组合时,丢弃该HTTP请求。
实施方式四
由于由一个数据包承载的HTTP请求已经由防护设备验证为合法请求,所以在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,对目标HTTP请求进行验证的过程可以为:当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
客户端接收到验证信息后,向服务器重新发送携带有该验证信息的目标HTTP请求,防护设备接收该目标HTTP请求。由于该目标HTTP请求为由多个数据包承载的HTTP请求,所以防护设备接收到该目标HTTP请求后直接向服务器转发该目标HTTP请求。当服务器接收到该目标HTTP请求,并确定出所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确,如果正确则通过验证。
在该实施方式中,在确定存在攻击后,服务器只对由多个数据包承载的目标HTTP请求通过发送验证信息的方式进行验证,能够减少服务器对请求的处理次数,并能够使利用一个数据包发送HTTP请求的客户端较快地得到服务器的响应。
在具体实施中,在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求,当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求。在验证目标HTTP请求的过程中,当所述目标HTTP请求带有所述标识时,说明该目标HTTP请求为由一个数据包承载的HTTP请求,可以确定所述目标HTTP请求为合法请求;当所述目标HTTP请求不带有所述标识时,说明该目标HTTP请求为由多个数据包承载的HTTP请求,可以确定 所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
用于区分由一个数据包承载的HTTP请求以及由多个数据包承载的HTTP请求时,还可以通过标记不同的标识。也就是说,在接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求后,当承载所述目标HTTP请求的数据包为一个数据包时,使用第一标识标记所述目标HTTP请求,当承载所述目标HTTP请求的数据包为多个数据包时,使用第二标识标记所述目标HTTP请求。当对目标HTTP请求进行验证时,可以根据第一标识和第二标识区分由一个数据包承载的HTTP请求以及由多个数据包承载的HTTP请求。
需要说明的是上述四种实施方式可以独立实施,也可以相互结合实施。例如,可以同时使用实施方式一与实施方式二,或者同时使用实施方式一与实施方式三。当同时使用实施方式一与实施方式二时,通过实施方式二可以丢弃不符合条件的HTTP请求,而没有被丢弃的HTTP请求可以通过实施方式一的方式进行进一步的验证。再例如,可以同时使用实施方式二与实施方式四,或者同时使用实施方式三与实施方式四。通过多种实施方式的结合,可以同时提高服务器的防护效果和防护效率。
步骤203,响应通过验证的目标HTTP请求。
对于通过验证的目标HTTP请求,服务器对其进行响应,即向客户端发送该目标HTTP请求对应的响应信息。
在具体实施过程中,防护设备也可以将只包含于一个数据包中不完整的HTTP请求发送至服务器,当服务器能够解析出该不完整的HTTP请求时,可以对其进行验证或响应,当服务器解析不出该不完整的HTTP请求时,可以丢弃该HTTP请求。
在本发明实施例中,服务器具备防护功能,并能够验证防护设备无法验证的HTTP请求,即由多个数据包重组得到的HTTP请求,而防护设备能够验证由一个数据包承载的HTTP请求,服务器与防护设备相互配合,从而提高防护效果。
以下对本发明实施例提供的防护系统中的服务器的结构进行具体说明。
参见图3,为本发明实施例提供的服务器的结构框图,所述服务器具体可以包括接收单元301、确定单元302、验证单元303以及响应单元304;
其中,所述接收单元301,用于接收所述防护设备发送的HTTP请求的数量,其中,所述防护设备发送的HTTP请求包括由一个数据包承载的HTTP请求和由多个数据包承载的HTTP请求。
所述确定单元302,用于确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量。
所述验证单元303,用于当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求。
所述响应单元304,用于响应通过验证的目标HTTP请求。
优选地,所述验证单元303具体用于:
确定所述目标HTTP请求中是否包含验证信息;
当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息;
当所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确。
优选地,所述验证单元303还具体用于:
确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量;
当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。
优选地,所述验证单元303还用于:
向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。
优选地,所述验证单元303还具体用于:
确定每个统计时间间隔内接收到的每组源地址和统一资源定位符URL的组合对应的目标HTTP请求的数量;
当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。
优选地,所述验证单元303还用于:向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。
优选地,所述验证单元303还具体用于:
当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;
当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
优选地,所述接收单元301还用于:接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求;当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求。
相应的,所述验证单元303还具体用于:当所述目标HTTP请求带有所述标识时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求不带有所述标识时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
在本发明实施例中,服务器具备防护功能,并能够验证防护设备无法验证的HTTP请求,即由多个数据包重组得到的HTTP请求,而防护设备能够验证由一个数据包承载的HTTP请求,服务器与防护设备相互配合,从而提高防护效果。
需要说明的是:上述实施例提供的服务器在进行防护时,仅以上述各功能单元的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元完成,即将服务器的内部结构划分成不同的功能单元,以完成以上描述的全部或者部分功能。另外,上述实施例提供的服务器与针对HTTP Flood攻击的防护方法的实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
参见图4,为本发明实施例提供的服务器的结构示意图。该服务器400可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器422 (例如,一个或一个以上处理器)和存储器432,一个或一个以上存储应用程序442或数据444的存储介质430(例如一个或一个以上海量存储设备)。其中,存储器432和存储介质430可以是短暂存储或持久存储。存储在存储介质430的程序可以包括一个或一个以上单元(图示没标出),每个单元可以包括对防护设备中的一系列指令操作。更进一步地,中央处理器422可以设置为与存储介质430通信,在服务器400上执行存储介质430中的一系列指令操作。
服务器400还可以包括一个或一个以上电源429,一个或一个以上有线或无线网络接口450,一个或一个以上输入输出接口458,一个或一个以上键盘454,和/或,一个或一个以上操作系统441,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等等。
服务器400可以包括有存储器,以及一个或者一个以上的程序,其中一个或者一个以上程序存储于存储器中,且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行上述防护方法的指令。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (17)
- 一种针对HTTP Flood攻击的防护方法,其特征在于,所述方法应用于服务器中,所述方法包括:确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量,其中,所述HTTP请求包括由一个数据包承载的HTTP请求和由多个数据包承载的HTTP请求;当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求;响应通过验证的目标HTTP请求。
- 根据权利要求1所述的方法,其特征在于,所述验证目标HTTP请求,包括:确定所述目标HTTP请求中是否包含验证信息;当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息;当所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确。
- 根据权利要求1所述的方法,其特征在于,所述验证目标HTTP请求,还包括:确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量;当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。
- 根据权利要求3所述的方法,其特征在于,当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,还包括:向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。
- 根据权利要求1所述的方法,其特征在于,所述验证目标HTTP请求,还包括:确定每个统计时间间隔内接收到的每组源地址和统一资源定位符URL的组合对应的目标HTTP请求的数量;当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。
- 根据权利要求5所述的方法,其特征在于,当同一组合对应的目标HTTP请求的数量达到第三阈值之后,还包括:向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。
- 根据权利要求1所述的方法,其特征在于,所述验证目标HTTP请求,还包括:当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
- 根据权利要求7所述的方法,其特征在于,所述验证目标HTTP请求之前,包括:接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求;当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求;所述验证目标HTTP请求,还包括:当所述目标HTTP请求带有所述标识时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求不带有所述标识时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
- 一种针对HTTP Flood攻击的防护系统,其特征在于,所述系统包括防护设备和服务器;所述防护设备,用于接收客户端发送的HTTP请求,当确定出存在攻击时,验证由一个数据包承载的HTTP请求,并向所述服务器发送由多个数据包承载的HTTP请求以及通过验证的由一个数据包承载的HTTP请求;所述服务器包括接收单元、确定单元、验证单元以及响应单元;所述接收单元,用于接收所述防护设备发送的HTTP请求的数量;所述确定单元,用于确定每个统计时间间隔内接收到的防护设备发送的HTTP请求的数量;所述验证单元,用于当在任一统计时间间隔内接收到的HTTP请求的数量达到第一阈值之后,验证目标HTTP请求,其中所述目标HTTP请求包括达到所述第一阈值之后接收到的HTTP请求;所述响应单元,用于响应通过验证的目标HTTP请求。
- 根据权利要求9所述的系统,其特征在于,所述验证单元具体用于:确定所述目标HTTP请求中是否包含验证信息;当所述目标HTTP请求中不包含所述验证信息时,向发送所述目标HTTP的客户端发送所述验证信息;当所述目标HTTP请求中包含所述验证信息时,验证所述验证信息是否正确。
- 根据权利要求9所述的系统,其特征在于,所述验证单元还具体用于:确定每个统计时间间隔内接收到的每个源地址对应的目标HTTP请求的数量;当同一源地址对应的目标HTTP请求的数量达到第二阈值之后,丢弃达到所述第二阈值之后接收到的所述同一源地址对应的目标HTTP请求。
- 根据权利要求11所述的系统,其特征在于,所述验证单元还用于:向所述防护设备发送所述同一源地址,以使所述防护设备丢弃所述同一源地址对应的目标HTTP请求。
- 根据权利要求9所述的系统,其特征在于,所述验证单元还具体用于:确定每个统计时间间隔内接收到的每组源地址和统一资源定位符URL的组合对应的目标HTTP请求的数量;当同一组合对应的目标HTTP请求的数量达到第三阈值之后,丢弃达到所述第三阈值之后接收到的所述同一组合对应的目标HTTP请求。
- 根据权利要求13所述的系统,其特征在于,所述验证单元还用于:向所述防护设备发送所述同一组合,以使所述防护设备丢弃所述同一组合对应的目标HTTP请求。
- 根据权利要求9所述的系统,其特征在于,所述验证单元还具体用于:当所述目标HTTP请求为由一个数据包承载的HTTP请求时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求为由多个数据包承载的HTTP请求时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
- 根据权利要求15所述的系统,其特征在于,所述接收单元还用于:接收承载所述目标HTTP请求的数据包,并解析得到所述目标HTTP请求;当承载所述目标HTTP请求的数据包为一个数据包时,使用标识标记所述目标HTTP请求;所述验证单元还具体用于:当所述目标HTTP请求带有所述标识时,确定所述目标HTTP请求为合法请求;当所述目标HTTP请求不带有所述标识时,确定所述目标HTTP请求中是否包含验证信息,如果所述目标HTTP请求中包含所述验证信息,则验证所述验证信息是否正确,否则向发送所述目标HTTP的客户端发送所述验证信息。
- 一种服务器,其特征在于,所述服务器包括处理器和存储器,所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至8任一所述的针对HTTP Flood攻击的防护方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/346,691 US11159562B2 (en) | 2018-06-19 | 2018-07-12 | Method and system for defending an HTTP flood attack |
EP18906716.8A EP3618396B1 (en) | 2018-06-19 | 2018-07-12 | Protection method and system for http flood attack |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810631487.1 | 2018-06-19 | ||
CN201810631487.1A CN108833410B (zh) | 2018-06-19 | 2018-06-19 | 一种针对HTTP Flood攻击的防护方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019242053A1 true WO2019242053A1 (zh) | 2019-12-26 |
Family
ID=64141647
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2018/095434 WO2019242053A1 (zh) | 2018-06-19 | 2018-07-12 | 一种针对HTTP Flood攻击的防护方法及系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11159562B2 (zh) |
EP (1) | EP3618396B1 (zh) |
CN (1) | CN108833410B (zh) |
WO (1) | WO2019242053A1 (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7281714B2 (ja) * | 2019-08-23 | 2023-05-26 | パナソニックIpマネジメント株式会社 | 情報処理装置、情報処理システム及びプログラム |
CN114615072B (zh) * | 2022-03-23 | 2023-01-20 | 国网山东省电力公司临清市供电公司 | 基于请求频率的安全态势感知方法、设备与系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110107412A1 (en) * | 2009-11-02 | 2011-05-05 | Tai Jin Lee | Apparatus for detecting and filtering ddos attack based on request uri type |
CN104079557A (zh) * | 2014-05-22 | 2014-10-01 | 汉柏科技有限公司 | 一种cc攻击的防护方法及装置 |
US20140317738A1 (en) * | 2013-04-22 | 2014-10-23 | Imperva, Inc. | Automatic generation of attribute values for rules of a web application layer attack detector |
CN104333529A (zh) * | 2013-07-22 | 2015-02-04 | 中国电信股份有限公司 | 一种云计算环境下http dos攻击的检测方法及系统 |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3794491B2 (ja) * | 2002-08-20 | 2006-07-05 | 日本電気株式会社 | 攻撃防御システムおよび攻撃防御方法 |
CN100531213C (zh) * | 2006-03-20 | 2009-08-19 | 赵洪宇 | 一种抵御拒绝服务攻击事件的网络安全保护方法 |
US9843596B1 (en) * | 2007-11-02 | 2017-12-12 | ThetaRay Ltd. | Anomaly detection in dynamically evolving data and systems |
US20100268932A1 (en) * | 2009-04-16 | 2010-10-21 | Deb Priya Bhattacharjee | System and method of verifying the origin of a client request |
CN101888312A (zh) * | 2009-05-15 | 2010-11-17 | 北京启明星辰信息技术股份有限公司 | 一种web网页攻击检测和响应方法及装置 |
US8789173B2 (en) * | 2009-09-03 | 2014-07-22 | Juniper Networks, Inc. | Protecting against distributed network flood attacks |
CN102045327B (zh) * | 2009-10-09 | 2013-11-27 | 杭州华三通信技术有限公司 | 防范cc攻击的方法和设备 |
KR101077135B1 (ko) * | 2009-10-22 | 2011-10-26 | 한국인터넷진흥원 | 웹 서비스 대상 응용계층 디도스 공격 탐지 및 대응 장치 |
US20120174196A1 (en) * | 2010-12-30 | 2012-07-05 | Suresh Bhogavilli | Active validation for ddos and ssl ddos attacks |
US20130151623A1 (en) * | 2011-12-07 | 2013-06-13 | Reginald Weiser | Systems and methods for translating multiple client protocols via a conference bridge |
US20130152153A1 (en) * | 2011-12-07 | 2013-06-13 | Reginald Weiser | Systems and methods for providing security for sip and pbx communications |
US8613089B1 (en) * | 2012-08-07 | 2013-12-17 | Cloudflare, Inc. | Identifying a denial-of-service attack in a cloud-based proxy service |
KR20140088340A (ko) * | 2013-01-02 | 2014-07-10 | 한국전자통신연구원 | 오픈플로우 스위치에서의 디도스 공격 처리 장치 및 방법 |
CN103297437B (zh) * | 2013-06-20 | 2016-03-16 | 中国软件与技术服务股份有限公司 | 一种移动智能终端安全访问服务器的方法 |
CN104348811B (zh) * | 2013-08-05 | 2018-01-26 | 深圳市腾讯计算机系统有限公司 | 分布式拒绝服务攻击检测方法及装置 |
US9392018B2 (en) * | 2013-09-30 | 2016-07-12 | Juniper Networks, Inc | Limiting the efficacy of a denial of service attack by increasing client resource demands |
US9148440B2 (en) * | 2013-11-25 | 2015-09-29 | Imperva, Inc. | Coordinated detection and differentiation of denial of service attacks |
US9426174B2 (en) * | 2013-12-05 | 2016-08-23 | Arbor Networks, Inc. | Protecting computing assets from segmented HTTP attacks |
FR3016456B1 (fr) * | 2014-01-13 | 2017-06-23 | Morpho | Procede de saisie de donnees confidentielles sur un terminal |
CN104092665A (zh) * | 2014-06-19 | 2014-10-08 | 小米科技有限责任公司 | 访问请求过滤方法、装置及设备 |
US10171491B2 (en) * | 2014-12-09 | 2019-01-01 | Fortinet, Inc. | Near real-time detection of denial-of-service attacks |
US20160173526A1 (en) * | 2014-12-10 | 2016-06-16 | NxLabs Limited | Method and System for Protecting Against Distributed Denial of Service Attacks |
CN105939315A (zh) * | 2015-10-20 | 2016-09-14 | 杭州迪普科技有限公司 | 一种http攻击防护方法及装置 |
CN105323259B (zh) * | 2015-12-07 | 2018-07-31 | 上海斐讯数据通信技术有限公司 | 一种防止同步包攻击的方法和装置 |
US9973528B2 (en) * | 2015-12-21 | 2018-05-15 | Fortinet, Inc. | Two-stage hash based logic for application layer distributed denial of service (DDoS) attack attribution |
US10735438B2 (en) * | 2016-01-06 | 2020-08-04 | New York University | System, method and computer-accessible medium for network intrusion detection |
CN105939326B (zh) * | 2016-01-18 | 2020-12-04 | 杭州迪普科技股份有限公司 | 处理报文的方法及装置 |
US10735382B2 (en) * | 2016-01-29 | 2020-08-04 | Zenedge, Inc. | Detecting human activity to mitigate attacks on a host |
US10432650B2 (en) * | 2016-03-31 | 2019-10-01 | Stuart Staniford | System and method to protect a webserver against application exploits and attacks |
CN105939361B (zh) * | 2016-06-23 | 2019-06-07 | 杭州迪普科技股份有限公司 | 防御cc攻击的方法及装置 |
US10075468B2 (en) * | 2016-06-24 | 2018-09-11 | Fortinet, Inc. | Denial-of-service (DoS) mitigation approach based on connection characteristics |
CN107666383B (zh) * | 2016-07-29 | 2021-06-18 | 阿里巴巴集团控股有限公司 | 基于https协议的报文处理方法以及装置 |
CN106789983B (zh) * | 2016-12-08 | 2019-09-06 | 北京安普诺信息技术有限公司 | 一种cc攻击防御方法及其防御系统 |
US10887341B2 (en) * | 2017-03-06 | 2021-01-05 | Radware, Ltd. | Detection and mitigation of slow application layer DDoS attacks |
US10735459B2 (en) * | 2017-11-02 | 2020-08-04 | International Business Machines Corporation | Service overload attack protection based on selective packet transmission |
US11212305B2 (en) * | 2018-04-27 | 2021-12-28 | Check Point Web Applications And Api Protection Ltd. | Web application security methods and systems |
-
2018
- 2018-06-19 CN CN201810631487.1A patent/CN108833410B/zh active Active
- 2018-07-12 EP EP18906716.8A patent/EP3618396B1/en active Active
- 2018-07-12 WO PCT/CN2018/095434 patent/WO2019242053A1/zh unknown
- 2018-07-12 US US16/346,691 patent/US11159562B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110107412A1 (en) * | 2009-11-02 | 2011-05-05 | Tai Jin Lee | Apparatus for detecting and filtering ddos attack based on request uri type |
US20140317738A1 (en) * | 2013-04-22 | 2014-10-23 | Imperva, Inc. | Automatic generation of attribute values for rules of a web application layer attack detector |
CN104333529A (zh) * | 2013-07-22 | 2015-02-04 | 中国电信股份有限公司 | 一种云计算环境下http dos攻击的检测方法及系统 |
CN104079557A (zh) * | 2014-05-22 | 2014-10-01 | 汉柏科技有限公司 | 一种cc攻击的防护方法及装置 |
Non-Patent Citations (1)
Title |
---|
See also references of EP3618396A4 * |
Also Published As
Publication number | Publication date |
---|---|
US20210105299A1 (en) | 2021-04-08 |
EP3618396A1 (en) | 2020-03-04 |
EP3618396B1 (en) | 2023-04-05 |
US11159562B2 (en) | 2021-10-26 |
EP3618396A4 (en) | 2020-05-20 |
CN108833410A (zh) | 2018-11-16 |
CN108833410B (zh) | 2020-11-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3481029B1 (en) | Internet defense method and authentication server | |
EP2526481B1 (en) | Intercepting malicious access | |
EP2078260B1 (en) | Detecting stolen authentication cookie attacks | |
CN109005175B (zh) | 网络防护方法、装置、服务器及存储介质 | |
CN107872445B (zh) | 接入认证方法、设备和认证系统 | |
EP3442195B1 (en) | Reliable and secure parsing of packets | |
WO2020037781A1 (zh) | 一种实现服务器防攻击方法及装置 | |
CN106656966B (zh) | 一种拦截业务处理请求的方法和装置 | |
EP4391476A1 (en) | Network traffic control method and related system | |
Huang et al. | An authentication scheme to defend against UDP DrDoS attacks in 5G networks | |
KR101020470B1 (ko) | 네트워크 침입차단 방법 및 장치 | |
EP4351086A1 (en) | Access control method, access control system and related device | |
CN110620773B (zh) | 一种tcp流量隔离方法、装置及相关组件 | |
WO2019242053A1 (zh) | 一种针对HTTP Flood攻击的防护方法及系统 | |
CN113904826B (zh) | 数据传输方法、装置、设备和存储介质 | |
KR20130035600A (ko) | 정보 유출 차단 장치 및 방법 | |
JP5911431B2 (ja) | 悪意のあるアクセスの遮断 | |
CN113225348B (zh) | 请求防重放校验方法和装置 | |
CN114172698A (zh) | 一种业务请求处理方法、Web服务器、设备及介质 | |
WO2019242052A1 (zh) | 一种针对HTTP Flood攻击的防护方法及装置 | |
CN114553452B (zh) | 攻击防御方法及防护设备 | |
CN104348785A (zh) | IPv6网中防止主机PMTU攻击的方法、装置与系统 | |
CN114567484B (zh) | 一种报文处理方法、装置、电子设备及存储介质 | |
WO2023060881A1 (zh) | 报文源地址识别方法及装置 | |
EP4044547A1 (en) | Message processing method, apparatus, and system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ENP | Entry into the national phase |
Ref document number: 2018906716 Country of ref document: EP Effective date: 20190830 |
|
ENP | Entry into the national phase |
Ref document number: 2018906716 Country of ref document: EP Effective date: 20190830 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |