DDoS protection at the web server level
Statistics of DDoS-attacks shows a constant growth and displacement of the vector from the network layer to the application level.
If you have a small website on a server with minimal characteristics, then you can put it in any completely legal means of stress testing. (I do not recommend this to anyone, since the IP address is easily calculated and the experimenter can fly in for damages.) Therefore, a site without DDoS protection will very soon look as wild as a Windows-98 computer without antivirus software.
The first thing that can and should be done to protect the site is to configure the iptables firewall. I use almost without any changes the iptables settings from an article on the site of one of the providers of protection against DDoS attacks. The only thing that I changed was the increase in the number of allowed connections in rules # 8 and # 10.
')
Before you run the script that changes the iptables settings, you need to make sure that there is an alternative opportunity to reset these settings to the initial state. Since if the rules are set incorrectly, no one can connect to the server, including the administrator.
The iptables firewall controls the attack at the network level. The next thing you need to configure is a web server. As a web server that is open for access from the Internet, we will consider nginx. In the nginx.conf file, you need to increase the limits on the number of files and open connections (an example is taken from Wikipedia):
Next, set up a default server that will deny access for those devices (for example, IoT), which will be addressed by IP address and not by the domain name:
Also in nginx you can configure some limits on the number of hits, but this setting will not be very flexible and not at all selective. Our goal is to make such protection at the web server level in order to extinguish requests from intruders, but to pass requests from respectable users to the server.
In order not to retell the material already available on Habré, I suggest to get acquainted with the excellent article , as well as with the module of the author of the indicated article kyprizel / testcookie-nginx-module. That allows this module to do well. But if you need to upgrade it, then it will be difficult to do it.
Today, many DDoS protection service providers use an openresty server (a bunch of nginx + Lua from Taobao). The speed of execution of good Lua code is slightly inferior to good code in C. But developing Lua is faster and easier, and besides, scripts can be changed without recompiling the server. At the next restart, they will be read, compiled by LuaJIT, and that’s all that is required.
Detailed instructions on how to install optnresty. After installation we continue to configure nginx. In the http section, we define the necessary parameters for the operation of Lua scripts:
The string lua_shared_dict creates a new dictionary (key value). This dictionary will be the same for all queries, so it is convenient to store white and blacklists in it. This dictionary, in addition to the key-value parameters, can have a time-to-live parameter, which is ideal for storing counters, if you need to limit the number of requests in a time interval.
The string lua_package_path specifies the paths to search for Lua modules, in which you need to include a directory with scripts. Two consecutive semicolons at the end of the line mean that this path is added to the current value of the path, and does not completely replace it.
The init_by_lua line sets the code that will be executed once the server is started (and not at each new request). It contains a white list of IP addresses. The second parameter of the add function, true, is simply the value that is then used in the if statement. The third parameter is no time-to-live, so the value will be stored without time limit.
The access_by_lua_file string sets the path to the script that will be executed upon each request to the server (not only at the start of the server). In it, in fact, is the whole logic of protection.
Consider some of the checks that can be done using a Lua script:
The Lua language is in many ways similar (even too much) to JavaScript, so the Lua code is intuitive to everyone who writes in JavaScript.
The ngx global variable is used to link to the nginx server context. The operator
Next, an attack is recognized based on the features of the CMS WordPress implementation. If the attack is detected, then the work ends with a special status 444 (characteristic only for nginx):
And finally, we give the "green road" search bots. Here you have to use the counter, because attackers are often faked under a search bot - so we count the number of hits.
Further recognition of bots and intruders can be conducted in different directions. As suggested in the article, such recognition is based on checking whether the client supports redirects, setting cookies and executing JavaScript code. Well, or anything else you can think of.
Typically, such a web server is used as a proxy, and the protected web server is located at a different IP address.
useful links
1. firstwiki.ru/index.php/%D0%9A%D1%80%D0%B0%D1%82%D0%BA%D0%BE%D0%B5_%D1%80%D1%83% D0%BA % D0% BE% D0% B2% D0% BE% D0% B4% D1% 81% D1% 82% D0% B2% D0% BE_% D0% BF% D0% BE_% D0% B1% D0% BE% D1 % 80% D1% 8C% D0% B1% D0% B5_% D1% 81_DDOS-% D0% B0% D1% 82% D0% B0% D0% BA% D0% B0% D0% BC% D0% B8_% D0% BD% D0% B0_http-% D1% 81% D0% B5% D1% 80% D0% B2% D0% B5% D1% 80
2. habrahabr.ru/post/139931
3. javapipe.com/ddos/blog/iptables-ddos-protection
4. github.com/apapacy/ngx_lua_anticc/tree/v-0.0.1
apapacy@gmail.com
January 22, 2018.
If you have a small website on a server with minimal characteristics, then you can put it in any completely legal means of stress testing. (I do not recommend this to anyone, since the IP address is easily calculated and the experimenter can fly in for damages.) Therefore, a site without DDoS protection will very soon look as wild as a Windows-98 computer without antivirus software.
The first thing that can and should be done to protect the site is to configure the iptables firewall. I use almost without any changes the iptables settings from an article on the site of one of the providers of protection against DDoS attacks. The only thing that I changed was the increase in the number of allowed connections in rules # 8 and # 10.
')
Before you run the script that changes the iptables settings, you need to make sure that there is an alternative opportunity to reset these settings to the initial state. Since if the rules are set incorrectly, no one can connect to the server, including the administrator.
The iptables firewall controls the attack at the network level. The next thing you need to configure is a web server. As a web server that is open for access from the Internet, we will consider nginx. In the nginx.conf file, you need to increase the limits on the number of files and open connections (an example is taken from Wikipedia):
# worker_rlimit_nofile 80000; events { # worker_connections 65536; # epoll ... } Next, set up a default server that will deny access for those devices (for example, IoT), which will be addressed by IP address and not by the domain name:
# Default server configuration # server { listen 80 default_server; listen 443 ssl default_server; deny all; } Also in nginx you can configure some limits on the number of hits, but this setting will not be very flexible and not at all selective. Our goal is to make such protection at the web server level in order to extinguish requests from intruders, but to pass requests from respectable users to the server.
In order not to retell the material already available on Habré, I suggest to get acquainted with the excellent article , as well as with the module of the author of the indicated article kyprizel / testcookie-nginx-module. That allows this module to do well. But if you need to upgrade it, then it will be difficult to do it.
Today, many DDoS protection service providers use an openresty server (a bunch of nginx + Lua from Taobao). The speed of execution of good Lua code is slightly inferior to good code in C. But developing Lua is faster and easier, and besides, scripts can be changed without recompiling the server. At the next restart, they will be read, compiled by LuaJIT, and that’s all that is required.
Detailed instructions on how to install optnresty. After installation we continue to configure nginx. In the http section, we define the necessary parameters for the operation of Lua scripts:
lua_shared_dict whitelist 10m; lua_shared_dict banlist 100m; lua_package_path '/home/username/antiddos/?.lua;;'; init_by_lua ' local whitelist = ngx.shared.whitelist whitelist:add("1.2.3.4", true) whitelist:add("5.6.7.8", true) '; access_by_lua_file /home/username/antiddos/main.lua; The string lua_shared_dict creates a new dictionary (key value). This dictionary will be the same for all queries, so it is convenient to store white and blacklists in it. This dictionary, in addition to the key-value parameters, can have a time-to-live parameter, which is ideal for storing counters, if you need to limit the number of requests in a time interval.
The string lua_package_path specifies the paths to search for Lua modules, in which you need to include a directory with scripts. Two consecutive semicolons at the end of the line mean that this path is added to the current value of the path, and does not completely replace it.
The init_by_lua line sets the code that will be executed once the server is started (and not at each new request). It contains a white list of IP addresses. The second parameter of the add function, true, is simply the value that is then used in the if statement. The third parameter is no time-to-live, so the value will be stored without time limit.
The access_by_lua_file string sets the path to the script that will be executed upon each request to the server (not only at the start of the server). In it, in fact, is the whole logic of protection.
Consider some of the checks that can be done using a Lua script:
-- if client IP is in whitelist, pass local whitelist = ngx.shared.whitelist in_whitelist = whitelist:get(ngx.var.remote_addr) if in_whitelist then return end -- HTTP headers local headers = ngx.req.get_headers(); -- wp ddos if type(headers["User-Agent"]) ~= "string" or headers["User-Agent"] == "" or ngx.re.find(headers["User-Agent"], "^WordPress", "ioj") then ngx.log(ngx.ERR, "ddos") ngx.exit(444) return end local banlist = ngx.shared.banlist local search_bot = "search:bot:count:request:per:10:s" if ngx.re.find(headers["User-Agent"], "Google Page Speed Insights|Googlebot|baiduspider|twitterbot|facebookexternalhit|rogerbot|linkedinbot|embedly|quora link preview|showyoubot|outbrain|pinterest|slackbot|vkShare|W3C_Validator", "ioj") then local count, err = banlist:incr(search_bot, 1) if not count then banlist:set(search_bot, 1, 10) count = 1 end if count >= 50 then if count == 50 then ngx.log(ngx.ERR, "bot banned") end ngx.exit(444) return end return end The Lua language is in many ways similar (even too much) to JavaScript, so the Lua code is intuitive to everyone who writes in JavaScript.
The ngx global variable is used to link to the nginx server context. The operator
return outside the body of the function means return from the module. In this example, if the IP address is in the white list, then the script ends and the usual processing of the nginx request continues.Next, an attack is recognized based on the features of the CMS WordPress implementation. If the attack is detected, then the work ends with a special status 444 (characteristic only for nginx):
ngx.exit(444) .And finally, we give the "green road" search bots. Here you have to use the counter, because attackers are often faked under a search bot - so we count the number of hits.
banlist:set(search_bot, 1, 10) initializes the counter, which will be reset in 10 seconds after creation. banlist:incr(search_bot, 1) adds one to the current value of the counter.Further recognition of bots and intruders can be conducted in different directions. As suggested in the article, such recognition is based on checking whether the client supports redirects, setting cookies and executing JavaScript code. Well, or anything else you can think of.
Typically, such a web server is used as a proxy, and the protected web server is located at a different IP address.
useful links
1. firstwiki.ru/index.php/%D0%9A%D1%80%D0%B0%D1%82%D0%BA%D0%BE%D0%B5_%D1%80%D1%83% D0%BA % D0% BE% D0% B2% D0% BE% D0% B4% D1% 81% D1% 82% D0% B2% D0% BE_% D0% BF% D0% BE_% D0% B1% D0% BE% D1 % 80% D1% 8C% D0% B1% D0% B5_% D1% 81_DDOS-% D0% B0% D1% 82% D0% B0% D0% BA% D0% B0% D0% BC% D0% B8_% D0% BD% D0% B0_http-% D1% 81% D0% B5% D1% 80% D0% B2% D0% B5% D1% 80
2. habrahabr.ru/post/139931
3. javapipe.com/ddos/blog/iptables-ddos-protection
4. github.com/apapacy/ngx_lua_anticc/tree/v-0.0.1
apapacy@gmail.com
January 22, 2018.
Source: https://habr.com/ru/post/347196/
All Articles