Handle a small ddos event on nginx

Author: the load capacity of Ayounginx is super powerful. Generally, small ddos attacks cannot kill an nginx proxy. Therefore, it is no problem to use nginx to filter out some small ddos attacks. In the morning, my colleague was responsible for a server and crashed after the server was restarted. After checking, he found that there was a high access volume of a link. I checked it out, because this project is not a public project.

Author: Ayou

Nginx has high load capacity and is generally smallDdThe operating system cannot kill an nginx proxy, so it is no problem to use nginx to filter out some small ddos attacks.

In the morning, my colleague was responsible for a server and crashed after the server was restarted. After checking, he found that there was a high access volume of a link.

I checked it out, because this project is not a company project, so the application server is Windows + IIS,ArchitectureApp_squIdArchitecture. Because the no-cache header must be added to the Link Service with a large traffic volume, all of them are routed to the backend application server, which is unable to handle the problem.

I am not familiar with IIS, and the application server is basically unable to provide normal services, So I direct the attacked domain name to the middle-layer proxy on the cache, and the middle-layer proxy is then forwarded to the application server. In this way, the architecture is changed to the app_nginx_squid architecture, and then I can start the analysis normally.

Sort out your ideas and follow the steps below:

First, open the log to see what is going on. After reading the log, I found that there is indeed a large amount of Access to the link.CommandAccording to the statistics, it is found that this link is 100 times as many as all normal access requests. As we can see from the above, this is indeed a problem caused by a large amount of Access to the link, but are these visits normal? From the perspective of its ip address, it is not the same ip address, which is difficult to judge. If it is real traffic, I will drop it, then someone will chase me.

The specific cause is simply not checked. I have killed its no-cache header first, so that at least it will not crash. As maintenance personnel, you must first find a way to make the website service normal before you can find the cause.

Proxy_hide_header Cache-ConTrOl;

Well, this link will be cached to the front-end squid, and the application server will not crash. However, this is only a temporary method, not a long-term plan, because this affects business functions.

Therefore, we continue to analyze the log and add several additional parameters to the log. At this time, we can see that these large numbers of requests share one thing, that is, the user-agent is the same, all of which are MSIE 5.01, IE5 is not a mainstream browser. In this case, these requests are all maliciously initiated by the same client and do not know what spam software is used.

After finding the cause and feature, you can configure to kill it and judge the user-agent. If it is MSIE 5.01, you can drop it to another place. For example, you can pointSuDone.com. can you resist it ?!

LoCatIon =/v2/indEx.Php{
INcLude proxy. conf;
If ($ http_user_agent ~ * MSIE 5.01 ){
Proxy_pass http://www.sudone.com;
# Access_log/home/logs/1.log main;
}
Proxy_pass http://iis.xxx.com;
}

Finally, open Cache-Control and access the page. Well, this time everything is normal and the business is not modified.