Use Nignx to cleverly solve the DDOS attacks I encountered

1. Problem

My own APP has been online for a while, and suddenly one day I found that the online product could not send verification codes.

I logged in to the backend of the third-party SMS verification code service and found that the problem was serious.

3	youbiquan	15797	2015-12-25
4	youbiquan	57	2015-12-23
5	youbiquan	49	2015-12-22
6	youbiquan	54	2015-12-21
7	youbiquan	64	2015-12-20

I discovered that a few days ago, the SMS service actually sent out more than 15,000 text messages, which directly wiped out the service fee.

If you want to find the reason, you can only look at Nignx’s logs.

In the logs, I found a large number of accesses to the SMS interface, and when I checked, the logs were still being appended crazily, which is a typical DDoS attack. Of course, the core content is the crazy number of visits to the SMS interface

221.178.182.21 - - [05/Jan/2016:16:19:25 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.3; XM50h Build/19.1.1.C.1.2)" "-"
171.82.225.66 - - [05/Jan/2016:16:19:32 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.4; 2014812 MIUI/V6.6.3.0.KHJCNCF)" "-"
171.82.225.66 - - [05/Jan/2016:16:19:32 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.4; 2014812 MIUI/V6.6.3.0.KHJCNCF)" "-"
110.89.16.13 - - [05/Jan/2016:16:19:49 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Dalvik/1.6.0 (Linux; U; Android 4.2.2; R827T Build/JDQ39)" "-"
110.89.16.13 - - [05/Jan/2016:16:19:49 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Dalvik/1.6.0 (Linux; U; Android 4.2.2; R827T Build/JDQ39)" "-"
118.114.160.200 - - [05/Jan/2016:16:21:26 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Mozilla/5.0" "-"
118.114.160.200 - - [05/Jan/2016:16:21:39 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Mozilla/5.0" "-"
119.122.0.136 - - [05/Jan/2016:16:21:41 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Mozilla/5.0" "-"
118.114.160.200 - - [05/Jan/2016:16:21:51 +0800] "POST /myinterface?showType=smsAuthcode HTTP/1.1" 200 161 "-" "Mozilla/5.0" "-"

. Even when the number of visits is too large, she will feel that the server cannot provide services normally and is on the verge of collapse.

2. Temporary solution

Before figuring out the problem, the first thing that comes to mind is to stop the SMS service so that attackers cannot access the service, but the server cannot be turned off because online users are still using it.

So first use nginx to rewrite this interface.

if ( $request_uri ~* "showType=smsAuthcode" )
{  
    rewrite ^/ http://www.baidu.com/;
}

Of course, there may be many configuration methods. Here is just an idea to solve the problem. For specific configuration, you can also refer to more professional nginx configuration information.

First of all, I apologize to Baidu and forwarded the attack request to Baidu. In fact, just return any value, such as 200.

3. Solution based on log analysis

Of course, this problem cannot be solved, and online users cannot register new users.

The first solution I thought of was to restrict IP access. After analyzing the log, I found that some IPs have been attacked thousands of times, and of course some IPs have only a few accesses. For an IP that has been visited several times, there is actually no way to determine whether it is the IP of a real user or an attacking machine. I found a solution on the Internet that allows a certain interface to limit the number of IP accesses within a certain period of time.

iptables -A INPUT -p tcp --dport 80 -d xx.xx.xx.xx -m string --string "/myinterface?showType=smsAuthcode" --algo kmp -m recent --name httpuser --set
iptables -A INPUT -m recent --update --name httpuser --seconds 86400 --hitcount 4 -j LOG --log-level 5 --log-prefix 'HTTP attack: '
iptables -A INPUT -m string --string "/myinterface?showType=smsAuthcode" --algo kmp -m recent --update --name httpuser --seconds 86400 --hitcount 10 -j REJECT                

The basic meaning is to perform string matching on access requests. If access to the SMS interface is found, use the recent module to record the access. If accessed more than 4 times in a day, access to SMS will not be allowed. interface.​

In fact, it is also a solution with certain effects

Serial number	Account	Quantity (item)	Date
2	youbiquan	540	2016-01-08
3	youbiquan	2857	2016-01-04
4	youbiquan	3 88	2016-01-05
5	youbiquan	2469	2016-01-06

Although the prevention based on IP address is somewhat effective, it is still not completely preventable. We usually only send about 50 messages a day, IP firewall After setting up, there are still thousands of messages every day. After analysis, it was found that there were too many IP addresses used in this attack, so it seemed that there was no hope of using IP addresses to defend against it.

One day, when I was at a loss, I opened the nginx access log again, and suddenly found that the user-agent of the attack behavior was very short, which was obviously different from the user-agent of other visits.

It seems that the attacker's user-agen is "Mozila/5.0", and then it disappears. Other visits will have more information, including system version, browser, etc.

According to this conjecture, I used a program to analyze the user-agent. Sure enough, only the UA that accessed the SMS interface had a short "Mozila/5.0". This UA did not exist in other accesses, but there were some short UAs

Dalvik/1.6.0 (Linux; U; Android 4.2.2; R827T Build/JDQ39)" "-"

then searched and found that Dalvik is an Android virtual machine. It suddenly became clear. I felt that we could completely block Mozila/5.0 and the virtual machine based on UA ​​prevention, and the problem would be solved.

So I added the following pieces of code to the nginx configuration

if ($http_user_agent = "Mozilla/5.0") {
       return 503;
}

if ($http_user_agent ~* "Dalvik/1.6.0") {
       return 503;
}

The first paragraph is to strictly match Mozila/5.0. The second paragraph means the UA starting with Dalvik is the UA of the virtual machine.

Sure enough, after adopting this method of prevention, the effect was immediately obvious.

2

youbiquan

57

2016-01-09

According to the new method, after the new prevention, the number of text messages sent will directly return to the previous normal level, use it yourself I tested it on a few mobile phones and it was OK.

But don’t be happy too early. It seems that it is easy for attackers to forge UA. If you want to completely solve DDOS, you need to learn more scientific and cultural knowledge~

The above introduces the use of Nignx to cleverly solve the DDOS attacks I encountered, including the content. I hope it will be helpful to friends who are interested in PHP tutorials.