Quite recently an advertising article about the anti-DDoS attacks at the application level appeared on the hub. I had a similar experience of searching for the optimal algorithm for countering attacks, who can come in handy – when a person first encounters in his website’s DDoS, it causes a shock, so it is useful to know in advance that everything is not so terrible.
DDoS – distributed attack on failure – roughly speaking, happens of several kinds. DDoS network layer – IP-TCP-HTTP, DDoS application layer – when the flow of requests greatly reduces the performance of the server or makes its operation impossible, and I would have added DDoS level of the hoster – when the site is running, but the server load exceeds the host quota, in as a result, the site owner also has problems.
If you are at the network level, then you can be congratulated that your business has risen to such heights, and you yourself certainly know what to do in this case. We will consider two other types of ddos.
Bots
Any CMS can be filled, decorated and tune so that even a single request per second will give an unacceptable load, even on the Hezner VPS. Therefore, in general, the task is to filter out as much as possible all unnecessary requests to the site. At the same time, a person should be guaranteed to hit the site and not be uncomfortable with having DDoS protection.
Bots come in several types. Useful (necessary search engines), useless (unnecessary search and spiders) and harmful (those that harm). The first two types are good bots, which in their User-Agent’e speak about themselves the truth. Useless bots are filtered out in .htaccess, useful ones are skipped to the site, and we will catch harmful ones. The case when a harmful bot is submitted to Yandex by a bot, for example, we omit it for simplicity (for it, too, there is a solution – Yandex for ip makes it possible to know whether it is a bot or not, and such ones can be banished immediately).
Not allowing harmful bots to the backend we get the necessary reduction in the load on the server.
Harmful bots can be divided into two types: smart (which understand cookie and javascript) and stupid (which do not understand). There is an opinion that there are no DOS bots that understand javascript at all, but this is for serious network DDoS attacks. In our conditions, even an overly active anonymous spider formally becomes a ddos-bot, which must be neutralized.
While we’re going to be stupid bots.
Protection
We will not give the protection code, it is simple – a few dozen lines on php; is much shorter and simpler than this article. Let’s describe the logic. We will write to the client a cookie (the method of checking for cookies is used even for protection against powerful DDoS attacks). With any name and any content, you can use the site already set by the site.
For simplicity, we assume that the site has a single entry point, we embed our ddos-shield there. Immediately check the query of our cookie: if it is – we certainly skip to the site. If not, then write the pair ip and the user agent as a separate file into a separate directory / suspected. The file is named ip-ua.txt, where user-agent is dechex (crc32 ($ _ SERVER [“HTTP_USER_AGENT”])) – just a short hash of the user agent.
In the file itself we write by separating the query time, the query page, the User-Agent, and still you can use Sypex Geo or register for maxmind.com and for five days get free access to their geoip database – by ip they issue a geographic location , it is also in this file.
If a file with the same name ip-ua.txt already exists, then add all this information of the new request to the end of the file.
Another point is the AJAX requests of our site. If they are, then they must also be skipped unconditionally, defining by their labels. The likelihood that the bots will also hit on them is minimal.
Now the missing step – before we write or append ip-ua.txt, we check that the request from this ip already came, moreover, we do not pay attention to the User-Agent:
count(glob(__DIR__ . "/suspected/$ip-*.txt")) > 0
The point is that we give each ip one chance at getting cookies. If it comes a second time without it, then this inequality works, and we redirect the client to a separate page check-human.php, where he will take the Turing test with showcases and vehicles with the help of Google Recyclers. If it does not pass – goodbye (again the recap), if passed – create the file ip-ua.txt in another special directory / whitelist. And at the very beginning, together with the verification of the cookies, we also check for the hit of the ip-ua pair in our / whitelist – these also, of course, we skip. With this tactic, we can give the chance to work on the site to those people who have cookies disabled in their browser and enabled javascript, or vice versa – javascript is disabled, but cookies are working.
Botnet
In principle, that’s all. Stupid bots were filtered, now clever. For the smart and the approach is already intelligent – open the directory / suspected, sort the files by size. Above, the biggest are tens and hundreds of kilobytes of persistent attempts to get through to us. We open and look, we are convinced that this is really a bot – for ip, for location, for query time, for query periods, for query pages, for user agent changes – it’s usually easy to see, everything is in front of your eyes. In principle, you can select all files with, for example, 10+ unsuccessful attempts, and send them ip to the ban through .htaccess. But it’s not good, it’s better to send them to captcha – after all, it happens that several people go to the Internet through one ip.
This is a very good solution to the issue of smart bots. Why? Because if you were ordered, then, most likely, to one dscer. And they too are clever and stupid. And stupid usually use for smart and stupid their bots one botnet, with some ip. Thus, you block and those bots that accept cookies and execute javascript. In addition, intelligent bots are much smaller, they are more expensive and work slower, so this method is effective for dealing with the absolute majority of the attacks under consideration.
According to my observations, this scheme through captcha had to pass about 1% -2% of real users of the site, the rest did not notice anything at all – that it was quite a friendly friend. In addition, even the first-time people do not see any “stubs” (as opposed to the way the link is at the beginning of the post), but work quietly with the site.
Certain inconveniences are possible for people using special bruser software for anonymization – dynamically changing ip and user-agent of the client, erasing cookies, but we do not consider this option.
In my case, the load on the server dropped immediately. The bots were dawdling for a while; a couple of days later I noticed that they had left – dsers also do not like to waste resources idle. He took off his defense.
Development of logic
You can vary the protection logic – add a check on javascript (it will put the cookie, for example); you can monitor those who were redirected to captcha and did not pass it to prevent a case of “bad” behavior towards a person; you can make personalized cookies, monitor the number of customers entering and, if the limit is exceeded, also send it to captcha; You can implement a system of tokens; you can run the bot through the redirect chain with time delays to slow them down; you can analyze ip bots and ban entire grids like Roskomnadzor – but that’s as far as you need. According to the law of 20-80 the simplest necessary solutions solve just everything that is needed.
The main thing – quickly isolating and banned obviously malicious ip from / suspected, you immediately noticeably reduce the load on the server and get time to prepare further actions to repel the attack.
That’s such a simple way you can punish unscrupulous competitors for money.
Disclaimer: This article is written only for easy DDoS attacks of the application level, mainly for shared hosting sites, the limit of available resources is limited.
