1. Home > Web_defense >

Explanation of the relevant configuration of Nginx server to resist CC attacks

The basic principle of the 0x00 CC attack

  CC attack uses a proxy server to send a large number of URL requests that require a long calculation time to the website, such as database queries, etc., causing the server to perform a lot of calculations and quickly reach its own processing capacity Form DOS. Once the attacker sends a request to the agent, he will actively disconnect, because the agent does not connect to the target server because the client connection is disconnected. Therefore, the resource consumption of the attacker is relatively small, and from the perspective of the target server, the requests from the proxy are all legitimate. In order to prevent CC attacks, one of the previous methods is to limit the number of connections per IP, which is difficult to achieve when the address range is very wide; the second is to restrict proxy access, because the general proxy will be in HTTP The header contains the X_FORWARDED_FOR field, but there are limitations. Some proxy requests do not include this field. In addition, some clients do need a proxy to connect to the target server. This restriction will deny access to some normal users.    CC attack is hard to prevent with hard defense.    CC attack is more terrifying than DDOS attack, that is, CC attack is generally hard to prevent with hard defense. There are three reasons for personal analysis:    1. The IPs from the CC attack are all real and scattered;    2. The data packets of the CC attack are all normal data packets;    3. The requests of the CC attack are all valid requests and cannot be denied. Request. Anti-CC attack ideas The effectiveness of anti-CC is that the attacker does not accept the data responded by the server, and actively disconnects after sending the request. Therefore, to confirm whether the connection is CC, the server does not immediately execute the URL request command, but simply returns A page redirection response containing the new URL request address. If it is a normal visit, the client will actively connect to the redirect page again, which is transparent to the user; for the CC attacker, since it does not receive the response data, it will not reconnect and the server does not need to continue to operate. . 0x01 Verification of the simplified version of browser behavior Let's first make an analogy. The community is engaged in welfare and distributed red envelopes to everyone in the square. The bad guys sent a group of humanoid robots (without language modules) to fake red envelopes. Smart workers need to figure out ways to prevent red envelopes from being faked. So the staff will give the recipient a piece of paper before giving out the red envelope with the words "Bring the red envelope" on it. If the person can read the words on the paper, then it is a person. Give the red envelope. If you can't read it, then Please be conscious. So the robot was seen through and came back dingy. Yes, in this analogy, people are browsers and robots are attackers. We can identify them by identifying the cookie function (reading the words on paper). The following is how to write nginx configuration file. if ($cookie_say != "hbnl"){ add_header Set-Cookie "say=hbnl"; rewrite .* "$scheme://$host$uri" redirect;} Let’s take a look at the meaning of these lines, when a cookie When the middle say is empty, give a 302 redirect package with cookie say hbnl. If the visitor can carry the cookie value in the second package, then he can visit the website normally, if not, he will live forever In the 302. You can also test it, use CC attacker or webbench or directly curl the package to do the test, they are all living in the 302 world. Of course, this simple can prevent it? Of course it is not that simple. If you are careful about the enhanced version, you will surely find that the configuration file is still flawed. If the attacker sets the cookie to say=hbnl (this can be set on the CC attacker), then this defense is useless. We continue to use the analogy just now to illustrate the problem. After discovering this pattern, the bad guys installed speakers for each robot and kept repeating "Bring the red envelope, bring the red envelope", and then came to receive the red envelope mightily. At this time, the staff's countermeasure is to do this, requiring recipients to show their account book with their name, and read their name, "I am xxx, bring the red envelope." As a result, a group of robots who only buzzed "Bring red envelopes" were sent back. Of course, in order to help explain the problem, each robot has a household registration book, and the reason for being driven back is that it can't pronounce its own name, although this is a bit absurd, alas. Then, let’s take a look at the configuration file writing in this way if ($cookie_say != "hbnl$remote_addr"){ add_header Set-Cookie "say=hbnl$remote_addr"; rewrite .* "$scheme://$host$ The difference between uri" redirect;} is that the request cookie value of different IP is different. For example, if the IP is, then the cookie that needs to be set is say=hbnl1.2.3.4. Therefore, the attacker cannot bypass this restriction by setting the same cookie (such as a CC attacker). You can continue to test with the CC attacker, and you will find that all the traffic from the CC attacker has entered the 302 world.


This article is published by www.internetweblist.com and does not represent the position of www.internetweblist.com/:http://www.internetweblist.com/Web_defense/28668.html

Contact Us

Online consultation:click here to give a message