Pull to refresh

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

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

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

Articles