Блокировка по access_log, легкий способ прострелить ногу или устранение конкурентов
Очередной пример, как легко прострелить себе ногу, на этот раз «переусердствовав» при защите сайта.Имён как всегда не называю, однако история показательна как-таковая, т.е. в качестве примера, как не надо «защищать» свои сервера. Эх говоришь им, говоришь —, а все без толку.
Упала посещаемость сайта, не совсем чтобы совсем, но довольно заметно. Смотрели логи, аналитику поисковиков и т.д. и т.п. Все вроде нормально, и кто приходит, тот даже не уходит сразу.Но не буду ходить вокруг, да около — проанализировав логи банов по IP выяснилась одна закономерность — за короткое время в бан попадало огромное количество IP-адресов. Все поголовно по одной причине — якобы как botsearch. Отротированные логи за последний месяц тоже ужасали своими размерами и даже заглядывать туда не нужно было, и так все ясно. Т.е. случилось следующее: куча клиентов просто не могла попасть на сайт.На вопрос «что-то меняли где-то с месяц назад?» был получен отрицательный ответ.
Не буду утомлять здесь детективным чтивом, после недолгих поисков — картина маслом. Некий прямой конкурент этого сайта поспособствовал «утечке» клиентов, или вернее и организовал эту «странную непосещаемость».Описание сценария «атаки»:
- есть популярный сайт «mysite», где включили блокировку сканирующих ботов по access;
- другой, возможно сопоставимо популярный, сайт «othersite» (например, прямой конкурент «mysite» с той же целевой аудиторией), делает каким-то образом на своей странице скрытый include (например в скрытом фрейме), где вызывает например 3-и URL-адреса «mysite», соответствующих искомым для фильтра этой блокировки.
- любой визит потенциальных клиентов сначала на страницу «othersite», практически гарантирует им невозможность затем попасть на сайт «mysite». Т.е. N раз нажав где-то на странице «othersite» — браузер пользователя делает N*3 «неудачных» вызова для сайта «mysite», что приводит к блокировке IP этого пользователя (по достижения maxretry).
- как результат, для этого клиента сайт «mysite» будет недоступен (его IP-адрес был забанен)
Кстати блокировка здесь осуществлялась не по access_log, а из-за высокой загруженности серверов, напрямую из веб-сервера. Выражаясь языком nginx, в локейшен, отрабатывающей 404 и иже с ними ошибки, был воткнут постпроцессор, фоново оповещающий сервис блокировки по IP-адресу, после фильтрации определенными регулярными выражениями по урл. Ну типа nginx-botsearch фильтра fail2ban, но без утомительного распарзивания логов (что часто очень накладно).
Однако тем же самым образом можно выстрелить себе в ногу, например просто активировав в fail2ban некоторые jail, использующие такие фильтры как «nginx-botsearch», «apache-botsearch» или множество других фильтров, натравливаемых на access-log веб-сервера, в огромном количестве курсирующих в интернете для «защиты» от ботов. Вот например, очередной такой фильтр, ожидающий пул-реквестом в fail2ban. И таких сотни и описаний к ним еще больше.
Но вернемся к самой атаке. Что примечательно, скорее всего эти нехорошие люди наняли кого-то из blackhat-ов (ну не сами же они до этого дошли) вероятно для взлома сайта конкурентов. Возможно нужна была база клиентов, или искали способ для лучшего ддоса, да мало ли чего еще. Ну, а те, обнаружив такую «защиту» от дурака, уже вероятно продали им несколько URL или же сам include, как простую возможность «устранить конкурента». В любом случае, вероятность, что такая практика уже массово не взята на вооружение, отлична от нуля.
Домыслы — домыслами, однако факт «атаки» и какой-никакой урон налицо.Поэтому будьте бдительны и включайте уже голову. Ну или зовите знакомого ресерчера…
