Foreign Security personnel released an interesting HTTP Dos attack tool yesterday. This tool can exhaust the available connections of servers and launch Denial of Service (Denial of Service attack) Attacks on Apache (and other servers, see below ). Although there are already many other dos tools, this tool is special because it will send incomplete HTTP request packets to the server and keep the HTTP connection open.
In this case, the server only needs to open the connection and wait for the complete message to be delivered. But the result is that the client (that is, the dostool) will not send the complete packet information at all, instead, it will continue to send some specially crafted bogus header line ), the connection cannot be closed.
The HTTP requests sent at the beginning are completely legal:
GET / HTTP/1.1 Host: host User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) Content-Length: 42 |
After sending this information, the client stops waiting for a while. Note: As a valid packet segment, it also lacks a carriage return line break to serve as the end character. The counterfeit message line sent by this tool is:
Obviously, this line of message has no meaning, and the server will ignore it and continue waiting. Of course, if you want to create an intrusion detection system (IDS) signature, you can set the content of this line by yourself.
The website that published the tool said that the tool is valid for Apache 1.x, Apache 2.x, and Squid. Moreover, considering that this tool can exhaust the number of server connections without sending a large number of packets, a user with a small bandwidth may launch an attack on a high-speed server, the potential threats to this tool are not negligible. Fortunately, users of Microsoft IIS6.0 and IIS7.0 are not affected yet.
Currently, I do not know whether the configuration in Apache can prevent its attack settings. Adding MaxClients only increases the difficulty of the attack, but cannot prevent the server from being attacked. However, one of our readers, Tomasz Miklas, said that he could solve this problem by adding a reverse proxy in front of the Apache server.
We will pay close attention to this and continue to release relevant information in the future. We expect other Web servers and load balancers to defend against such attacks.