Реальный кейс: как мы поймали прокси-ботнет и SQL-инъекцию на клиенте за один день

С чего всё началось

Клиент bot-guard — интернет-магазин сантехники и освещения felicita-crimea.ru — заметил неладное: защита от ботов вроде включена, счётчики блокировок в статистике растут, а в Яндекс.Метрике всё равно видны заходы, похожие на ботов: нулевая глубина просмотра, отказы, странные интервалы между визитами. Резонный вопрос: если антибот-система работает, откуда берётся мусорный трафик?

Это частый сценарий для интернет-магазинов, каталогов и любых сайтов с публичной ценовой информацией. Боты не всегда бьют в лоб — их задача не всегда DDoS-атака или явный брутфорс формы входа. Гораздо чаще цель — незаметный парсинг каталога: конкуренты автоматически собирают ваши цены, остатки и описания товаров, чтобы демпинговать или наполнять собственный маркетплейс чужим контентом.

Разбор вживую: не одна подсеть, а целый прокси-пул

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

Стандартная защита по IP-репутации и rate-limiting (ограничение числа запросов с одного адреса) такую атаку не ловит в принципе — она рассчитана на повторные обращения с одного и того же IP. А здесь личность отправителя менялась буквально с каждым запросом.

Мы проверили эти адреса по ASN (номеру автономной системы — по сути, "прописке" IP в интернете) и получили удивительно широкий разброс: Гонконг, Турция, США, Хорватия — ни одного пересечения по провайдеру. Это не датацентр-бот в привычном смысле и не одна скомпрометированная подсеть. Это коммерческий прокси-пул, вероятно из числа сервисов резидентных или мобильных прокси, где запросы намеренно размазываются по сотням несвязанных сетей по всему миру — именно для того, чтобы обойти блокировку по IP, по подсети и по гео.

Отдельно проверили User-Agent этих визитов — версии Chrome в заголовках скакали (103, 116, 133, 150…), что на первый взгляд выглядело подозрительно. Но при ближайшей проверке оказалось нормальным: Chrome с 2026 года перешёл на двухнедельный цикл релизов, и разброс версий у живых пользователей — это ожидаемо, а не автоматический признак подделки. Хороший пример того, что не каждая аномалия — сигнатура бота; важно проверять предположения, а не действовать по интуиции.

Заодно нашли кое-что похуже простого парсинга

Разбирая access-логи того же самого трафика, мы обнаружили нечто более тревожное, чем скрейпинг цен: попытку SQL-инъекции. В одном из параметров каталога обнаружился классический пробный запрос сканера уязвимостей — логическое условие, которое всегда истинно, совмещённое с попыткой внедрить HTML/JavaScript-код. Такие «полиглот»-запросы сканеры уязвимостей используют, чтобы одним обращением проверить сразу несколько классов уязвимостей — SQL-инъекцию и межсайтовый скриптинг (XSS).

Важная деталь: этот пробный запрос шёл с того же IP, что и «безобидный» скрейпинг каталога. То есть под видом рутинного парсинга на сайт параллельно велось активное прощупывание на предмет уязвимостей веб-приложения — попытка найти брешь в фильтрации входных данных, через которую можно достать данные из базы (например, таблицу пользователей с хешами паролей) или внедрить вредоносный скрипт на страницу для остальных посетителей.

Что мы построили в ответ — за один день

Расследование не закончилось диагнозом — мы сразу довели его до конкретных изменений в движке защиты, которые получили все клиенты bot-guard, не только этот сайт:

• Обновили базу облачных и датацентр-диапазонов IP. Список успел устареть на три недели — часть реального трафика из AWS и Google Cloud проходила незамеченной просто потому, что справочник диапазонов не обновлялся.
• Добавили новых провайдеров в список известных прокси-хостингов — конкретные сети, поймавшиеся именно на этой атаке, по факту наблюдаемого трафика, а не по общим спискам.
• Новый сигнал «ротация IP» (site-wide burst detection). Если на одном сайте за короткое окно проходит аномально много разных IP-адресов, почти каждый по одному разу — сайт временно берётся под усиленный контроль: новые визиты проверяются тщательнее до тех пор, пока волна не уляжется. Ключевое отличие от классического rate-limiting — сигнал смотрит на сайт в целом, а не на отдельный IP.
• Мгновенная проверка User-Agent на правдоподобность. Если строка User-Agent даже отдалённо не похожа на настоящий браузер (а у части автоматических сканеров и скриптов она вообще не маскируется) — это теперь заметно сразу, в реальном времени, а не после ночной пакетной классификации.
• Детект SQL-инъекций и XSS в URL в реальном времени. Типовые сигнатуры атак — характерные SQL-конструкции, внедрение исполняемого кода в параметры запроса — теперь распознаются и блокируются на лету, до того как вредоносный запрос вообще доберётся до вашего сайта и базы данных. Это не замена полноценного WAF (Web Application Firewall) для сложных, целевых атак, но закрывает основную массу автоматического сканирования на типовые уязвимости.
• Отдельный виджет инцидентов безопасности в панели управления. Попытки инъекций теперь видны отдельным списком — с сайтом, IP и временем — а не тонут в общей статистике блокировок ботов.

Результат

Все изменения протестированы на реальном трафике — не в теории, а прогоном настоящих найденных атакующих запросов через движок — и выкачены в тот же день. Часть сигналов работает мягко: подозрительному, но не подтверждённо вредоносному визиту предлагается один раз незаметно подтвердить, что за ним стоит настоящий браузер (обычные посетители этого даже не замечают). Часть блокирует сразу и жёстко — как в случае с прямой попыткой SQL-инъекции, где промедление не оправдано.

Почему это важно для вас

Это не гипотетический сценарий из презентации — это реальная атака на реального клиента, разобранная и закрытая по горячим следам, с настоящими IP-адресами и настоящим деплоем в прод в течение суток. Каждая такая находка сразу становится частью защиты bot-guard для всех клиентов, а не только для сайта, где её обнаружили — будь то интернет-магазин, лендинг или корпоративный сайт.

Чем больше реального трафика проходит через систему, тем быстрее она учится отличать живых посетителей от ботов, скрейперов и сканеров уязвимостей. Если вы ещё не подключили защиту от парсинга каталога, брутфорса и SQL-инъекций на своём сайте — это ровно тот случай, когда лучше не дожидаться собственного инцидента.