DDoS attack on nginx with 1 byte packets?

Question

Nginx

Hello ladies and gentlemen!
They try to ddo me with packets of 1 byte:

189.122.179.187 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
179.218.210.189 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
83.209.48.26 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
92.249.111.231 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
179.218.185.114 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
201.81.106.183 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
179.235.253.60 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
81.190.16.114 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
31.45.118.108 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
189.120.223.34 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-" 
66.63.169.209 - - [11/Nov/2017:16:40:00 +0100] "0xF" 400 166 "-" "-" "-"

(NGINX program log)
and 500 lines per second! very powerful,
what do you recommend?

Answer 1

500 lines per second is not powerful and probably not even D DoS. If the address is the same, then just block access to it with a firewall, and if the addresses are different, then set the request limit in Nginx.
nginx.conf

http {
    ...
    limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=30r/s;
    ...
}

some_site.conf

server {
    ...
    location / {
        ...
        limit_req zone=reqlimit burst=10 nodelay;
    }
}

After that, requests from one ip-address starting from the 31st per second will be discarded.
As a cherry on the cake, you can add another filter for fail2ban:
nginx-req-limit.conf

[Definition]

failregex = limiting requests, excess: .* by zone .*, client: <HOST>
ignoreregex =

and a rule in jail.local

[nginx-req-limit]
enabled = true
port = http,https
filter = nginx-req-limit
logpath = /var/www/*/*/logs/error.log # Здесь укажите свой путь к логам виртуального хоста
findtime = 600
maxretry = 10
bantime = 7200

After that, DoS'er addresses will be automatically blocked by the firewall for two hours. What will unload Nginx from processing parasitic traffic.

Answer 2

The main problem is that your address is already exposed, and in order to go under the CDN, you need to immediately change the IP for the backend, and it is better to send the old one, the owner of the atonomy, to the blackhole.
If the channel is not clogged (ssh normally responds) try blocking directly in iptables with regions.
And if nginx manages to respond with a backend timeout (bottleneck site engine) - then you can block in nginx.
The first step is a hoster / data center. Ask how they can help, in fact, they also have no reason to keep the host under attack.
Then extract all requests from the logs during the attack, sort by number and compile a list of the 100-300 most active and calculate their autonomy networks and region. If this is one country and it is not your target - temporarily block the entire country of autonomy and so on. For starters, you can just block about 300 specific hosts.
If the site starts working, control what happens next. The attack can shift to other IPs.
If that doesn't help, go under CDN protection with DoS protection.
Immediately after that, change the IP since this one is already sleeping.
In addition, write rules in iptables that cut traffic from everywhere except for CDN networks.
Don't accidentally cut off your ssh.
CloudFlare has a free account option. But I note that we were filled up with 3 sites that were on a paid account. The attack was carried out from Vietnam, Korea, Brazil and Ukraine. We tried to block across networks directly to the CDN, but packets from blocked networks still reached our servers where we had already blocked them.
For the rest, see what about the backing that prepares pages for nginx. What about the number of processes, how they are loaded, how much they consume memory and what they are waiting for. The attack is a good opportunity to over where the bottle neck is.

Answer 3

Yes, just ban IPs in the firewall with such requests