|
Some time ago, the website of a Shanghai gaming and entertainment company suffered a DDOS distributed denial of service attack based on page requests. The website was completely paralyzed and was blackmailed by an anonymous letter from hackers for up to 100,000 yuan. During the blackmail process, the hackers also said that they would attack Tencent QQ and other websites. Subsequently, QQ's "server maintenance" was underway for a few days. On December 5, the global BitTorrent server was also hit by a severe DDOS attack and was paralyzed for a time. The most popular and powerful DDOS attack is the page-based DDOS and the attack tool CC that makes full use of this attack theory. This article specially invites the CC author to share with us the relevant attack principles and prevention methods of CC, hoping to let more friends understand this attack method and be able to prevent it. My thoughts on writing CC and prevention methods
Text/ Kiki
Many friends know the barrel theory. The maximum capacity of a bucket of water is not determined by its highest point, but by its lowest point. The same is true for the server. The security of the server is also determined by its most vulnerable point. The more dangerous the most vulnerable point is, the more dangerous the server is. The same is true for DDOS. As long as there is a place on your server that consumes a lot of resources and the restrictions are not enough, it will immediately become the target of others' DDOS. For example, SYN-FLOOD uses the fact that the semi-connected state of the server consumes more resources than the fully connected state, while the SYN initiator only needs to send packets continuously and does not require many resources at all. A good DDOS attack must cause the opponent to consume greater resources by consuming very little of its own resources. Otherwise, for example, ICMP-FLOOD and UDP-FLOOD require the same bandwidth as others, and you have to pay as much resources as the opponent's server consumes. This is extremely inefficient and can be easily discovered. Basically no one uses it now.
Attack Principle
CC is mainly used to attack pages. We all have this experience: when visiting a forum, if the forum is large and there are many visitors, the page will open more slowly, right? ! Generally speaking, the more people visit, the more pages there are in the forum, the larger the database is, the more frequently it is visited, and the more system resources it occupies. Now you know why many space service providers tell people not to upload forums, chat rooms and other things.
A static page does not require many resources from the server. It can even be read directly from the memory and sent to you. But it is different with a forum. When I read a post, the system needs to go to the database to determine whether I have permission to read the post. If I do, it will read the content of the post and display it. The database is accessed at least twice here. If the database is 200MB in size, the system will most likely search this 200MB data space. How much CPU resources and time does this require? If I am searching for a keyword, it will take even longer, because the previous search can be limited to a very small range, such as user permissions only check the user table, post content only check the post table, and the query can be stopped immediately after the search is found, while the search will definitely make a judgment on all the data, which consumes a considerable amount of time.
CC makes full use of this feature to simulate multiple users (the number of threads is the number of users) continuously accessing the page (accessing pages that require a large amount of data operations, that is, a large amount of CPU time). Many friends asked, why use a proxy? Because the proxy can effectively hide its identity and bypass all firewalls, because basically all firewalls will detect the number of concurrent TCP/IP connections, and if it exceeds a certain number and frequency, it will be considered a Connection-Flood. Using proxy attacks can also maintain the connection very well. We send data here, and the proxy helps us forward it to the other party's server. We can disconnect immediately, and the proxy will continue to maintain the connection with the other party (I know of a record that someone used 2,000 proxies to generate 350,000 concurrent connections).
Maybe many friends still can't understand it very well, let me describe it. We assume that server A needs 0.01S to process Search.asp (multithreading is just time division and has no effect on the conclusion), that is, it can guarantee 100 users' Search requests in one second. The maximum connection time allowed by the server is 60s, so we use CC to simulate 120 users' concurrent connections. After 1 minute, the server is requested 7200 times and processed 6000 times, so there are 1200 concurrent connections left that are not processed. Some friends will say: Lost connection! Lost connection! The problem is that the server discards them in the order of first come first served. These 1200 were initiated in the last 10 seconds. Do you want to discard them? ! It's still early. After calculation, when the server is fully loaded and starts to drop connections, there should be 7200 concurrent connections in the queue. Then the server starts to drop connections at 120/second. The connections we initiate are also 120/second. The server will never finish processing all the connections. The server's CPU is 100% and maintained for a long time. Then the server determines that it can't handle it for 60 seconds of dropped connections, and can't handle new connections. In this way, the server reaches a super busy state.
Butterfly: We assume that the server only takes 0.01 seconds, or 10 milliseconds, to process the Search (you can check this speed on various forums that display the opening hours). We only use 120 threads. The connection loss time of many servers is much longer than 60 seconds. We use far more threads than 120. You can imagine how terrible it is. Moreover, as long as the client sends a disconnect, the connection is maintained by the proxy, and when the server receives an SQL request, it will definitely enter the queue, regardless of whether the connection has been disconnected. Moreover, the server is concurrent, not sequential, which makes more requests enter the memory request, which puts a greater burden on the server.
Of course, CC can also use this method to attack FTP and implement TCP-FLOOD, which have been tested and proven to be effective.
Prevention Methods Now that we have explained the attack principle, everyone will definitely ask, how to defend against it? I don't know how to prevent it using a hardware firewall, unless you completely block page access. My approach is to implement defense by writing pages.
1. Use Cookie authentication. At this time, my friend said that Cookies are also allowed in CC, but the Cookies here are used for all connections, so just enable IP+Cookie authentication.
2. Use Session. This judgment is more convenient than Cookie. It can not only perform IP authentication, but also prevent refresh mode. It can judge whether the page is refreshed. If it is refreshed, it will not be allowed to access. If there is no refresh symbol, it will be given a refresh symbol. Give some sample code, Session:
1 then
Session("refresh") = session("refresh") + 1
Response.redirect "index.asp"
End if
In this way, the user's first visit will make Refresh=1, the second visit will be normal, and the third time, he will not be allowed to access, as it is considered a refresh. A time parameter can be added to set the time allowed for access. This will limit the access to time-consuming pages and have almost no impact on normal customers.
3. Use the HTTP_X_FORWARDED_FOR variable sent by the proxy to determine the real IP address of the machine using the proxy attack. This method can completely find the person who launched the attack. Of course, not all proxy servers send this parameter, but many proxies do. Detailed code:
This will generate CCLog.txt, and its record format is: real IP [proxy IP] time. By looking at which real IP appears more times, you will know who is attacking. Make this code into Conn.asp file and replace those files that connect to the database. In this way, all database requests will be connected to this file, and the attacker can be found immediately.
4. Another method is to put the statement that needs to query the data after the Redirect, so that the other party must first visit a judgment page and then redirect there.
5. On a server with multiple stations, strictly limiting the number of IP connections and CPU usage time allowed for each station is a very effective method.
The defense of CC should start from the code. In fact, a good page code should pay attention to these things, as well as SQL injection, which is not only an intrusion tool, but also a DDOS loophole. Everyone should pay attention to it in the code. For example, a server launched a 5,000-line CC attack, but there was no response at all, because all its database access requests must have a random parameter in the Session, and all of them are static pages, so there is no effect. Suddenly I found that it had a request to contact an external server, which took a long time and there was no authentication. I opened 800 lines of attack and the server was immediately overloaded. The code layer defense needs to be done bit by bit. An error in a script code may affect the entire site or even the entire server. Be careful! |
