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.
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.
While we’re going to be stupid bots.
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
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.
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
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.