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

- КиТ :: Будь в СЕТИ!

Очередной пример, как легко прострелить себе ногу, на этот раз «переусердствовав» при защите сайта

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

Пришлось тут намедни делать «аудит» одного коммерческого проекта… ну очень просили.

Упала посещаемость сайта, не совсем чтобы совсем, но довольно заметно. Смотрели логи, аналитику поисковиков и т.д. и т.п. Все вроде нормально, и кто приходит, тот даже не уходит сразу.

Но не буду ходить вокруг, да около — проанализировав логи банов по IP выяснилась одна закономерность — за короткое время в бан попадало огромное количество IP-адресов. Все поголовно по одной причине — якобы как botsearch. Отротированные логи за последний месяц тоже ужасали своими размерами и даже заглядывать туда не нужно было, и так все ясно. Т.е. случилось следующее: куча клиентов просто не могла попасть на сайт.

На вопрос «что-то меняли где-то с месяц назад?» был получен отрицательный ответ.

Не буду утомлять здесь детективным чтивом, после недолгих поисков — картина маслом. Некий прямой конкурент этого сайта поспособствовал «утечке» клиентов, или вернее и организовал эту «странную непосещаемость».

Описание сценария «атаки»:

есть популярный сайт «mysite», где включили блокировку сканирующих ботов по access; другой, возможно сопоставимо популярный, сайт «othersite» (например, прямой конкурент «mysite» с той же целевой аудиторией), делает каким-то образом на своей странице скрытый require_once (например в скрытом фрейме), где вызывает например 3-и URL-адреса «mysite», соответствующих искомым для фильтра этой блокировки. любой визит потенциальных клиентов сначала на страницу «othersite», практически гарантирует им невозможность затем попасть на сайт «mysite». Т.е. N раз нажав где-то на странице «othersite» — браузер пользователя делает N*3 «неудачных» вызова для сайта «mysite», что приводит к блокировке IP этого пользователя (по достижения maxretry). как результат, для этого клиента сайт «mysite» будет недоступен (его IP-адрес был забанен)

Кстати блокировка здесь осуществлялась не по access_log, а из-за высокой загруженности серверов, напрямую из веб-сервера. Выражаясь языком nginx, в локейшен, отрабатывающей 404 и иже с ними ошибки, был воткнут постпроцессор, фоново оповещающий сервис блокировки по IP-адресу, после фильтрации определенными регулярными выражениями по урл. Ну типа nginx-botsearch фильтра fail2ban, но без утомительного распарзивания логов (что часто очень накладно).

Однако тем же самым образом можно выстрелить себе в ногу, например просто активировав в fail2ban некоторые jail, использующие такие фильтры как "", "" или множество других фильтров, натравливаемых на access-log веб-сервера, в огромном количестве курсирующих в интернете для «защиты» от ботов. Вот например, , ожидающий пул-реквестом в fail2ban. И таких сотни и описаний к ним еще больше.

Но вернемся к самой атаке. Что примечательно, скорее всего эти нехорошие люди наняли кого-то из blackhat-ов (ну не сами же они до этого дошли) вероятно для взлома сайта конкурентов. Возможно нужна была база клиентов, или искали способ для лучшего ддоса, да мало ли чего еще. Ну а те, обнаружив такую «защиту» от дурака, уже вероятно продали им несколько URL или же сам require_once, как простую возможность «устранить конкурента». В любом случае, вероятность, что такая практика уже массово не взята на вооружение, отлична от нуля.

Домыслы — домыслами, однако факт «атаки» и какой-никакой урон налицо.

Поэтому будьте бдительны и включайте уже голову. Ну или зовите знакомого ресерчера…

ПодпискаБудь в СЕТИ! Новости социальных сетей - всегда актуальное
 
Группы: ВК | OK | Tg