CC attack principles and new ideas

CC attack principles and new ideas
Author: Ice Cream firewall Website: www.bingdun.com
 
1. Basic CC principles

CC attacks use a proxy server to send a large number of URL requests that require long computing time, such as database queries. As a result, the server performs a large amount of computing and quickly reaches its processing capabilities to form dos, once a request is sent to the proxy, the attacker proactively disconnects the server because the proxy does not connect to the target server because the client is disconnected. Therefore, the resource consumption of the attacker is relatively small, from the perspective of the target server, requests from proxies are valid.

2. Previous methods

To prevent CC attacks, the previous method was to limit the number of connections of each IP address, which was difficult to implement when the IP address range was wide. The second was to restrict access by the proxy, generally, the proxy will include the x_forwarded_for field in the HTTP header, but it also has limitations. Some proxy requests do not contain this field, in addition, some clients do need a proxy to connect to the target server, which denies such legal customers.

3. New Ideas

The validity of CC is that the attacker does not accept the server response data. After sending the request, the attacker proactively disconnects the connection. Therefore, check whether the connection is CC. The server does not immediately execute the URL request command, instead, it simply returns a page redirection response containing the new URL request address. If the request is accessed normally, the client will connect to the redirection page again, which is transparent to the user; as CC attackers do not receive response data, they will not reconnect and the server does not need to perform query operations.

4. Specific implementation: CC cookie

The key to implementation is how to construct the Redirection URL. the method I designed is to add a CC cookie, that is, to add a unique cookie and text form at the end of the original URL request, as part of the URL. When the URL containing the cookie returns a new response, check whether the cookie is valid. If so, the URL is valid and then connected again, the cookie part in the URL is erased, restored to the original URL request, and then sent to the server for normal access; otherwise, the URL is rejected.

5. security considerations

To ensure the effectiveness of this method, pay attention to the following issues:

1) For cookie selection, each URL request must be different, even if the URL is the same, there are two methods, one is to calculate a cookie value based on the requested URL and client information and some random information, and check whether the cookie matches in the same way; the second method is to generate a cookie randomly and save the cookie to a database. The test is to check whether the cookie submitted by the client is in the database. No matter which method, the cookie selection must be random enough. You cannot guess the calculation rule or the current cookie library's cookies;

2) When a cookie is added to a URL, the format mark must be unique and cannot conflict with a normal URL request. This should be controllable, because the server to be protected is under its own control and the URL formats are controllable, it is feasible to design a unique cookie flag, and the logo format should be changed frequently;

3) Cookie validity period. The cookie is valid only for a certain period of time and will be deleted upon timeout. The selection time must be appropriate, not too long or too short;

4) Cookie DoS attack, if CC attackProgramIf the server uses cookie protection and preemptively carries a cookie, the server must be able to quickly check whether the cookie is valid and discard connection requests for illegal cookies; the cookie flag must be changed frequently to prevent DoS attacks;

5) How to Improve the efficiency: for HTTP/1.1 connections, there is the keep-alive option. One connection can perform multiple URL request operations. For authenticated connections, if a URL request continues to exist in the connection, you do not need to perform cookie authentication to improve efficiency. In addition, you can specify to process cookies only for some types of URLs, for example, CGI, PHP, and ASP requests. URLs such as common static text, images, and media do not need Cookie processing.

6. Conclusion

The CC cookie defense method proposed in this article can effectively defend against CC attacks without affecting normal user access. It is transparent to users. This method is suitable for implementation on the firewall or by the server itself.