Защита сайта от DDoS и парсеров: разбор кейса интернет-магазина на OT Box и OTAPI
Владелец интернет-магазина обратился с проблемой, которую сначала описал как DDoS-атаку: сайт почти три дня работал нестабильно, процессор VPS периодически был загружен на 98-100%, а количество платных обращений к OTAPI увеличилось примерно в 6-7 раз. При этом автоматизированные посетители заходили на страницы каталога, переходили между карточками товаров и массово считывали информацию.
Ситуация осложнялась тем, что запросы поступали с множества IP-адресов, относящихся к разным странам. На сервере уже был установлен сторонний платный антибот-модуль, однако он не остановил подозрительную активность. Нагрузка оставалась высокой, а расходы на обращения к товарной платформе продолжали расти.
Почему обычного антибота оказалось недостаточно
Владелец магазина пытался ограничить доступ к карточкам товаров для неавторизованных пользователей. Это временно снижало часть обращений, но одновременно ухудшало доступность каталога для обычных покупателей и не решало проблему на уровне причины.
Важно понимать: наличие большого числа адресов и высокая загрузка процессора ещё не доказывают классическую DDoS-атаку. Вредоносная активность может быть организована иначе - например, с помощью распределённой сети автоматизированных клиентов, которые имитируют поведение обычных посетителей.
В таком случае бот не обязательно отправляет миллионы запросов к одному URL. Он может последовательно открывать поиск, категории, фильтры и карточки товаров. Для веб-сервера это выглядит как обычная работа пользователя, но в большом масштабе создаёт серьёзную нагрузку.
Как устроен магазин на OT Commerce и OTAPI
В рассматриваемом проекте используется OT Commerce - специализированное решение для интернет-магазинов, работающих с каталогами Taobao, Tmall, 1688, Alibaba, AliExpress и других торговых площадок. Готовая сборка, известная как "Коробка ОТ", устанавливается на домен владельца и включает витрину, поиск, карточки товаров, личный кабинет, корзину и оформление заказа.
Главное отличие от традиционного магазина заключается в том, что значительная часть товарных данных не хранится полностью в локальной базе сайта. Для взаимодействия с внешней платформой OpenTrade Commerce используется OTAPI - программный интерфейс, через который магазин получает информацию о товарах и продавцах.
Когда посетитель открывает карточку товара, сервер может запросить через OTAPI:
- название и описание;
- цену и характеристики;
- сведения о продавце;
- фотографии;
- доступность товара;
- данные о вариантах и комплектациях;
- информацию, необходимую для оформления заказа.
Упрощённая цепочка выглядит так:
посетитель или бот → страница магазина → серверная логика → OTAPI → внутреннее хранилище и сборщики данных → внешняя торговая площадка.
Следовательно, один запрос к веб-сайту способен вызвать дополнительную серверную работу и обращение к внешней платформе.
Что такое платный вызов OTAPI
Платный вызов OTAPI - это не просто факт подключения к серверу. Речь идёт об обращении к определённому API-методу, которое учитывается в рамках тарифной модели платформы.
Если реальный пользователь открыл одну карточку, это может привести к одному или нескольким обращениям к OTAPI. Но бот способен автоматически просмотреть тысячи страниц. В результате каждый переход превращается в дополнительную обработку, а часть запросов - в оплачиваемые операции.
Так возникает двойной эффект:
1. веб-сервер тратит процессорное время на обработку большого потока обращений;
2. внешняя платформа фиксирует рост количества вызовов, что увеличивает расходы.
Особенно быстро затраты растут, если робот последовательно перебирает весь каталог, меняет параметры фильтров, обращается к поиску и повторно запрашивает одни и те же сведения без использования кэша.
DDoS, L7-атака и парсерный трафик - не одно и то же
Термин "DDoS" часто используют для любого массового потока запросов, однако для диагностики важно разделять несколько сценариев.
Классическая сетевая атака может перегружать канал связи или сетевой стек сервера. Атака уровня L7 направлена на веб-приложение: злоумышленник отправляет HTTP-запросы к страницам, API и динамическим функциям. Парсерный трафик, в свою очередь, может быть не разрушительным в прямом смысле, но создавать серьёзную нагрузку, массово собирая данные.
В данном случае ключевой проблемой оказался автоматизированный обход сайта. Боты не просто отправляли бессмысленные пакеты, а обращались к функциональности магазина и запускали внутреннюю цепочку обработки.
Что показала диагностика
Первоначальная веб-аналитика отражала только часть роботной активности. Многие автоматизированные клиенты не выполняли JavaScript, блокировали счётчики или имитировали обычные браузеры. Поэтому данные аналитических систем создавали неполную картину.
После перевода трафика через WAF стало возможным анализировать запросы на более раннем уровне. Это позволило увидеть:
- реальное соотношение людей и роботов;
- частоту обращений с отдельных адресов;
- повторяющиеся шаблоны поведения;
- перечень наиболее востребованных URL;
- скорость обхода каталога;
- признаки автоматизации;
- распределение запросов по странам и сетям.
Выяснилось, что заметную долю нагрузки создавали не обычные покупатели и не единичные подозрительные адреса, а распределённый автоматизированный трафик.
Почему WAF оказался эффективнее локального модуля
Антибот, установленный непосредственно на VPS, работает уже после того, как запрос достиг сервера. Даже если он блокирует часть обращений, сам факт доставки запроса требует сетевых ресурсов, а иногда запускает веб-сервер, PHP, CMS или другие компоненты.
WAF действует перед инфраструктурой сайта. Он может отфильтровать подозрительный трафик до того, как тот попадёт на VPS, применить ограничения по частоте запросов, проверить поведение клиента, использовать challenge-механизмы и заблокировать очевидные шаблоны автоматизации.
Это особенно важно для проектов, где запрос к странице приводит к дорогостоящей серверной логике или обращению к внешнему API.
Что произошло после переключения трафика
После перенаправления запросов через WAF удалось отделить полезный трафик от подозрительной активности и снизить количество обращений, доходящих до приложения. Нагрузка на CPU начала возвращаться к рабочим значениям, а поток платных вызовов OTAPI уменьшился.
При этом сам WAF не является универсальным решением. Его необходимо правильно настроить: чрезмерно строгие правила могут заблокировать поисковых роботов, постоянных клиентов и пользователей с нестандартными браузерами. Слишком мягкая конфигурация, наоборот, оставит лазейки для автоматизированного обхода.
Какие меры стоит внедрить дополнительно
Для защиты магазина на OT Commerce полезно сочетать несколько уровней контроля:
- кэшировать карточки, категории и результаты поиска;
- ограничивать частоту запросов с одного клиента;
- отдельно контролировать обращение к поиску и фильтрам;
- вводить задержки или проверки при массовой навигации;
- отслеживать аномальные последовательности URL;
- ограничивать число одновременных запросов;
- сохранять логи обращений к OTAPI;
- исключать повторные вызовы при наличии свежих данных в кэше;
- настроить автоматические уведомления о резком росте расходов;
- регулярно проверять наиболее дорогие API-операции.
Полезно также разделять доступ к публичным страницам и внутренним методам. Если один и тот же API используется витриной, мобильным клиентом и внешними интеграциями, для них лучше предусмотреть отдельные правила и лимиты.
Как правильно расследовать подобные инциденты
Начинать следует не с блокировки всех зарубежных адресов и не с отключения каталога, а со сбора фактов. Необходимо сопоставить загрузку CPU, количество HTTP-запросов, время ответа, обращения к базе данных и статистику OTAPI.
Важно выяснить, какие URL вызывают максимальную нагрузку. Иногда причиной оказывается не сама карточка товара, а поиск с большим количеством параметров, сортировка или функция, которая при каждом обращении обращается к внешнему источнику.
Отдельно нужно оценить поведение клиентов: скорость переходов, глубину просмотра, повторяемость маршрутов, наличие JavaScript, cookies и заголовков браузера. Один признак редко бывает достаточным, но совокупность характеристик позволяет достаточно точно определить автоматизацию.
Главный вывод кейса заключается в том, что проблему нельзя оценивать только по слову "DDoS". Вредоносный трафик может выглядеть как обычная работа сайта, но запускать дорогостоящие операции внутри приложения и увеличивать расходы на внешние сервисы. Для интернет-магазина на OT Box и OTAPI защита должна учитывать не только сетевой уровень, но и бизнес-логику: каталог, поиск, карточки товаров и стоимость каждого API-вызова.