Another example of how easy it is to shoot yourself in the leg, this time “overdoing” while protecting the site.
I don’t call names as always, but the story is indicative as-is, i.e. as an example, how not to "protect" their servers. Oh, tell them, say - and all to no avail.
It was necessary here the other day to do an “audit” of a commercial project ... well, they were very requested.
Site traffic has fallen, not quite at all, but quite noticeable. We looked at the logs, search engine analytics, etc. etc. Everything seems to be normal, and who comes, he does not even leave immediately.
But I will not go around and so on - after analyzing the logs of bans over IP, one pattern emerged - in a short time a huge number of IP addresses fell into the ban. All polls for one reason - ostensibly as botsearch. Logged logs for the last month, too, were horrified by their size, and it was not even necessary to look in there, and so everything is clear. Those. The following happened: a bunch of customers just could not get to the site.
The question “something changed about a month ago?” Received a negative answer.
I will not tire here with detective reading, after a brief search - oil painting. A certain direct competitor of this site contributed to the “leakage” of customers, or rather, and organized this “strange non-attendance”.
Description of the “attack” scenario:
- there is a popular site "mysite", where they included blocking scanning bots by access;
- another, possibly comparablely popular, site “othersite” (for example, a direct competitor “mysite” with the same target audience), does in some way on its page a hidden include (for example, in a hidden frame), where it calls for example the 3rd URL the “mysite” addresses corresponding to the search filter for this lock.
- Any visit by potential customers to the “othersite” page almost guarantees that they will not be able to get to the “mysite” website. Those. N times clicking somewhere on the “othersite” page - the user's browser makes N * 3 “unsuccessful” calls for the “mysite” site, which results in blocking this user's IP address (after maxretry has been reached).
- as a result, the site “mysite” will not be available for this client (its IP address was banned)
By the way, the blocking here was carried out not by access_log, but due to high server load, directly from the web server. In the language of nginx, a postprocessor was plugged into a location that was working on 404 and other errors, after the filtering of the IP address blocking service after filtering by certain regular expressions by URLs. Well, type nginx-botsearch filter fail2ban, but without the tedious rasparzivaniya logs (which is often very expensive).
')
However, in the same way, you can shoot yourself in the foot, for example, simply by activating some jail in fail2ban that use filters such as "
nginx-botsearch ", "
apache-botsearch " or many other filters set on the access-log web server in a huge the number of plying on the Internet for "protection" from bots. Here, for example,
another such filter , waiting for a pull-request in fail2ban. And there are hundreds of such descriptions and even more.
But back to the attack itself. What is remarkable, most likely these bad people hired someone from the blackhat-s (well, they didn’t come to it themselves) probably for hacking the competitors site. Perhaps you needed a customer base, or were looking for a way for a better DDoS, and you never know what else. Well, those, having discovered such a “protection” against a fool, have probably already sold them several URLs, or include it themselves, as a simple opportunity to “eliminate the competitor”. In any case, the likelihood that such a practice has not been massively adopted is different from zero.
Speculation - speculation, but the fact of "attack" and some damage there is.
Therefore, be careful and turn on the head. Well, or call a friend supervisor ...