Pull to refresh

Блокировка по access_log, легкий способ прострелить ногу или устранение конкурентов

Reading time 3 min
Views 29K
Очередной пример, как легко прострелить себе ногу, на этот раз «переусердствовав» при защите сайта.
Имён как всегда не называю, однако история показательна как-таковая, т.е. в качестве примера, как не надо «защищать» свои сервера. Эх говоришь им, говоришь — а все без толку.

Пришлось тут намедни делать «аудит» одного коммерческого проекта… ну очень просили.
Упала посещаемость сайта, не совсем чтобы совсем, но довольно заметно. Смотрели логи, аналитику поисковиков и т.д. и т.п. Все вроде нормально, и кто приходит, тот даже не уходит сразу.
Но не буду ходить вокруг, да около — проанализировав логи банов по 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, как простую возможность «устранить конкурента». В любом случае, вероятность, что такая практика уже массово не взята на вооружение, отлична от нуля.

Домыслы — домыслами, однако факт «атаки» и какой-никакой урон налицо.
Поэтому будьте бдительны и включайте уже голову. Ну или зовите знакомого ресерчера…
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+35
Comments 25
Comments Comments 25

Articles