Клиент — сеть розничных магазинов, обратился к нам с проблемой. Сайт интернет-магазина на 1С-Битрикс столкнулся с SMS-флудом через публичный endpoint. Мы не ограничились точечным правилом на уровне веб-сервера и внедрили многоуровневую защиту в модуле «Файрвол — блокировка по ASN, GEO, UA», чтобы перекрыть атаку системно, а не временно.
Ситуация
С раннего утра атака шла на endpoint /bitrix/services/main/ajax.php. Целью была массовая отправка SMS: прямые финансовые потери, рост нагрузки и риск деградации сервиса для реальных пользователей. Примерно до обеда атака успешно блокировалась SMS-провайдером с помощью простого ограничения на количество отправленных смс с одного IP-адреса. Но по мере блокировки IP-адресов ботнет наращивал ёмкость, в результате точечные блокировки на стороне SMS-шлюза потеряли эффективность. Мы подключились к защите уже после обеда.
Масштаб за двое суток
| Час | Попыток (всего) | Успешных (200) | Блокировано | Процент успешных |
|---|---|---|---|---|
| 3 | 24 | 24 | 0 | 100 |
| 4 | 334 | 333 | 1 | 99,7 |
| 5 | 349 | 348 | 1 | 99,71 |
| 6 | 362 | 358 | 4 | 98,9 |
| 7 | 376 | 375 | 1 | 99,73 |
| 8 | 411 | 411 | 0 | 100 |
| 9 | 530 | 528 | 2 | 99,62 |
| 10 | 500 | 492 | 8 | 98,4 |
| 11 | 585 | 582 | 3 | 99,49 |
| 12 | 669 | 586 | 83 | 87,59 |
| 13 | 652 | 648 | 4 | 99,39 |
| 14 | 718 | 711 | 7 | 99,03 |
| 15 | 642 | 639 | 3 | 99,53 |
| 16 | 751 | 555 | 196 | 73,9 |
| 17 | 1090 | 18 | 1072 | 1,65 |
| 18 | 1113 | 12 | 1101 | 1,08 |
| 19 | 1246 | 11 | 1235 | 0,88 |
| 20 | 1160 | 16 | 1144 | 1,38 |
| 21 | 1178 | 9 | 1169 | 0,76 |
| 22 | 1166 | 5 | 1161 | 0,43 |
| 23 | 1013 | 12 | 1001 | 1,18 |
| 0 | 852 | 2 | 850 | 0,23 |
| 1 | 967 | 2 | 965 | 0,21 |
| 2 | 796 | 0 | 796 | 0 |
| 3 | 741 | 0 | 741 | 0 |
| 4 | 722 | 0 | 722 | 0 |
| 5 | 224 | 2 | 222 | 0,89 |
| 6 | 2 | 2 | 0 | 100 |
| 7 | 4 | 4 | 0 | 100 |
| 8 | 14 | 14 | 0 | 100 |
| 9 | 15 | 15 | 0 | 100 |
| 10 | 10 | 10 | 0 | 100 |
| 11 | 17 | 17 | 0 | 100 |
| 12 | 18 | 15 | 3 | 83,33 |
| 13 | 10 | 10 | 0 | 100 |
| 14 | 14 | 14 | 0 | 100 |
| 15 | 14 | 14 | 0 | 100 |
По часам картина была показательной: в интервале 03:00–11:00 проходило около 99% попыток (но часть блокировалась на уровне шлюза), в 12:00–16:00 — около 90%. С 15 часов мы начали изучать журналы и уже внедрили первые блокировки. После внедрения всех правил в 17:00–19:00 успешность упала примерно до 1%, при этом боты попытались нарастить свои усилия, увеличив почти в 2 раза объем ресурсов. Это не помогло.
| Показатель | Значение |
|---|---|
| Всего запросов | 19 289 |
| Успешных (HTTP 200) | 6 794 |
| Заблокировано | 12 495 |
На сайте был установлен JS-челлендж для проверки "Я не робот", на тот случай, если под блокировку попадут реальные посетители. Боты тратили ресурсы на разгадывание челленджа — теряли время и расходовали мощности, но проверку пройти не могли. При этом реальные пользователи легко проходили проверку простым нажатием кнопки, за сутки таких пользователей было более 300.
Что мы выявили в атаке
Анализ журнала показал устойчивый бот-паттерн: часто повторяющийся User-Agent Chrome/145.0.0.0, аномальная частота запросов (до 1000+ в час), распределение трафика по множеству IP и отсутствие нормального клиентского поведения (cookies, referer). Это был не одиночный источник, а распределенный ботнет, включающий как сети хостинг-провайдеров, так и крупных провайдеров проводного интернета в РФ и за рубежом.
Решение: многоуровневая защита в модуле «Файрвол для Битрикс»
Блокировка по User-Agent
Мы сразу отсекли идентифицированный бот-сигнатурный шаблон. Это дало быстрый эффект и снизило базовый шум атаки в первые часы. Конечно, такая блокировка могла зацепить и реальных пользователей, а для ботов смена UA — не проблема, поэтому нужно было идти дальше.
Блокировка по ASN
Команда выделила провайдеров и дата-центры, через которые шла основная масса автоматического трафика, и точечно закрыла эти источники. В результате просел именно «инфраструктурный» контур ботнета, а не легитимные пользователи.
GEO-фильтрация
Мы оставили доступ из целевых регионов (естественно, RU), а остальной трафик ограничили правилами. Этот уровень дал дополнительное сокращение нерелевантных запросов и усилил устойчивость защиты при смене IP ботами.
Поведенческие ограничения
Для критического endpoint были введены ограничения по частоте и повторяемости POST-сценариев. Это закрыло попытки «продавить» бизнес-логику даже при ротации IP и User-Agent.
Защитите свой сайт в два клика! Еще никогда не было так просто блокировать ботов, сканеры и парсеры. Блокируйте целые подсети и регионы без опасений за реальных пользователей.
Результат для бизнеса
После внедрения комплексных правил успешность злоупотреблений снизилась с ~99% до ~1%. SMS-спам был полностью остановлен, нагрузка на сервер заметно снизилась, а сайт продолжил работать стабильно для реальных клиентов.
Ключевой эффект здесь не в одном фильтре, а в связке уровней: UA + ASN + GEO + поведенческая логика на уровне приложения Bitrix. Именно такая архитектура защиты дает предсказуемый результат против современных распределенных бот-атак. Атака становится либо неуспешной — множество попыток блокируются с первого хита, либо финансово невыгодной — ресурсы тратятся на разгадывание капч и челленджей, что в итоге превращается в пустую трату денег без причинения существенного ущерба.
Ключевой момент защиты
Мы прошли полный цикл инцидента: оперативная диагностика по логам, выделение бот-сигнатур, проектирование правил без критичных ложных срабатываний и поэтапное внедрение с контролем метрик в динамике. Модуль «Файрвол — блокировка по ASN, GEO, UA» в этом кейсе выступил не как «еще один фильтр», а как управляемый инструмент защиты бизнес-критичных сценариев 1С-Битрикс. Мы вполне понимаем, что защита на уровне приложения должна поддерживаться и на более низких уровнях, но в данном инциденте это даже не понадобилось. Команда была готова подключить фильтрацию трафика на стороне сервера, но атакующие стали терять интерес и на вторые сутки атака прекратилась.
Вывод: для проектов на 1С-Битрикс максимальную устойчивость дает не точечная блокировка, а многоуровневая модель фильтрации. В этом кейсе именно она позволила быстро остановить атаку и защитить бизнес от повторных потерь. Нужно иметь в виду, что даже при ограничении со стороны шлюза на 2-3 СМС с одного IP-адреса это не отменяет необходимость защиты на стороне сайта — распределенная бот-сеть даже при таких жестких ограничениях на шлюзе может без проблем отправлять тысячи сообщений в сутки.