Инженерный блог

DDoS по-казахски и накрутка конкурентов: Как отбить атаку ботов через Google Cloud Armor и вычистить мусорный трафик из GA4

08.08.2026
Шарафутдинов Р.

Суровые реалии казахстанского e-commerce

Представьте ситуацию: вы — маркетинговый директор крупного интернет-магазина техники в Казахстане. Запускаете масштабную акцию на новые смартфоны, заливаете бюджет в Google Ads, таргетируетесь на весь Казахстан. И тут начинается магия. Трафик прет, CTR (Click-Through Rate) в рекламном кабинете просто пробивает потолок, а вот продаж... продаж ноль. Конверсия стремится к погрешности. Сервер пыхтит, база данных закипает, а в кассе пусто.

Вы открываете Google Analytics 4 (GA4) и видите странную картину: 90% пользователей заходят на сайт, проводят там ровно 2 секунды, делают один скролл и уходят. Показатель отказов (Bounce Rate) — 98%. География тоже радует: внезапно ваш локальный алматинский магазин стал дико популярен среди жителей какого-то богом забытого городка в Индии, дата-центров во Франкфурте и странных IP-адресов, которые вообще не бьются по GeoIP.

Поздравляю, вы стали жертвой типичного «DDoS по-казахски». Конкуренты не дремлют, и в ход идут самые грязные методы: скликивание рекламного бюджета (Click Fraud) и L7 DDoS-атаки (атаки на уровне приложения), цель которых не просто «положить» сервер, а испортить вам аналитику и выжечь бюджет в трубу.

Анатомия атаки: Как боты маскируются под живых людей

Современные боты — это вам не тупые скрипты на Python из 2010-х, которые долбят главную страницу GET / без юзер-агента. Сегодняшний ботнет — это умная, распределенная сеть. Они используют Headless Chrome, подделывают User-Agent, имитируют движения мышки, скроллят страницу и даже кликают по случайным ссылкам, чтобы обойти базовые защиты.

В нашем кейсе атака была многоуровневой:

  1. Скликивание рекламы (Click Fraud): Боты кликали по объявлениям в Google Search, имитируя интерес. Бюджет улетал с космической скоростью.
  2. L7 DDoS (Application Layer Attack): Боты делали тяжелые запросы. Они не просто грузили статику (которая отдается из кэша Cloud CDN), они целенаправленно долбили эндпоинты с поиском: /search?q=iphone+15+pro+max+купить. Поиск — это всегда тяжелый запрос к базе данных или ElasticSearch. 10 000 таких запросов в секунду — и ваш бэкенд ложится спать.
  3. Отравление аналитики (Analytics Poisoning): Из-за того, что боты выполняли Javascript, они успешно триггерили пиксели GA4. В итоге в аналитике образовалась огромная куча мусора, и маркетологи больше не могли принимать адекватные решения на основе данных.

Линия обороны №1: Google Cloud Armor вступает в игру

Что делать, когда вас атакуют? Первое желание — забанить все подозрительные IP-адреса через Nginx. Но когда атака идет с 50 000 разных IP из AWS, DigitalOcean и зараженных роутеров MikroTik по всему миру, ваш iptables просто треснет по швам.

На помощь приходит Google Cloud Armor. Это Enterprise-grade Web Application Firewall (WAF) и защита от DDoS, которая стоит перед вашим Load Balancer-ом на глобальной Edge-сети Google. То есть мусорный трафик отбивается еще до того, как он дойдет до вашего сервера в Казахстане (или где он у вас там хостится).

Мы настроили следующие правила (Security Policies) в Cloud Armor:

  • Geo-blocking: Так как магазин доставлял товары только по Казахстану, мы жестко зарезали (deny) весь трафик из подозрительных стран, оставив только KZ и пару соседних стран на всякий случай. Да, это грубо, но при атаке — самое то.
  • Rate Limiting (Throttle): Мы настроили ограничение: не более 100 запросов с одного IP-адреса за 1 минуту. Если кто-то превышает лимит, Cloud Armor автоматически банит этот IP на 60 минут, отдавая ошибку 429 (Too Many Requests).
  • WAF Rules (Preconfigured): Включили стандартные наборы правил от Google против SQL-инъекций, XSS и сканеров уязвимостей.
  • Custom Rules (Сигнатуры): Проанализировав логи атаки в Cloud Logging, мы заметили, что большинство ботов использовали один и тот же странный Accept-Language и стучались на определенные URL. Мы написали кастомное правило на языке CEL (Common Expression Language), чтобы дропать именно этот паттерн.
# Пример кастомного правила Cloud Armor на CEL
request.headers['user-agent'].contains('HeadlessChrome') || 
(request.headers['accept-language'] == 'en-US,en;q=0.5' && request.path.matches('/api/v1/search'))

Результат? 99% мусорного трафика было отбито на подступах. Нагрузка на базу данных упала до нормальных значений, сервер выдохнул. Но осталась одна проблема: те умные боты, которые просочились, всё еще портили нам GA4.

Нагрузка на сервер: До и после включения Cloud Armor

RPS (Requests Per Second) на бэкенд и количество запросов, заблокированных Cloud Armor.

Линия обороны №2: Вычищаем авгиевы конюшни в GA4 и BigQuery

Cloud Armor спас инфраструктуру, но как спасти аналитику? GA4 — классный инструмент, но он глотает все, что ему присылает фронтенд.

Рекомендуем к прочтению

Терминатор для продаж: Как мы прокачали AI Ментора для Скаутов и почему конкуренты уже плачут

31.07.2026

Здесь мы применили двухэтапный подход:

Этап 1: Server-Side GTM (sGTM) как фильтр

Мы уже упоминали sGTM в предыдущих статьях. Одно из его скрытых преимуществ — возможность фильтровать трафик до отправки в Google Analytics. Мы настроили sGTM так, чтобы он не отправлял события (hits) в GA4, если:

  • В запросе отсутствует Client ID (типично для тупых ботов).
  • IP-адрес пользователя находится в блек-листе (мы регулярно скачивали списки известных Tor-экзит-нод и спам-ботов).
  • Событие имеет аномально высокую частоту для одной сессии.

Этап 2: Суровый SQL в BigQuery

Но что делать с тем мусором, который уже попал в GA4 до настройки sGTM? Или с теми умными ботами, которые имитируют реальных пользователей? Здесь на сцену выходит BigQuery.

Сырые данные GA4 ежедневно экспортировались в BigQuery. Мы написали SQL-запрос, который помечал сессии как «фрод» на основе поведенческих паттернов. Маркетологи больше не смотрели стандартные отчеты GA4, они пользовались дашбордом в Looker Studio, который брал данные из очищенной витрины BigQuery.

-- Пример SQL-запроса для выявления бот-сессий в BigQuery
WITH session_stats AS (
  SELECT
    user_pseudo_id,
    (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    COUNT(*) AS total_events,
    COUNTIF(event_name = 'page_view') AS pageviews,
    MIN(event_timestamp) AS first_event,
    MAX(event_timestamp) AS last_event,
    -- Флаг: сессия длилась меньше 3 секунд
    TIMESTAMP_DIFF(TIMESTAMP_MICROS(MAX(event_timestamp)), TIMESTAMP_MICROS(MIN(event_timestamp)), SECOND) < 3 AS is_too_short,
    -- Флаг: только один просмотр страницы (100% bounce)
    COUNTIF(event_name = 'page_view') = 1 AS is_single_pageview
  FROM
    `your-project.analytics_123456789.events_*`
  GROUP BY
    1, 2
)

SELECT
  user_pseudo_id,
  session_id,
  CASE 
    WHEN is_too_short AND is_single_pageview THEN 'Bot'
    WHEN total_events > 500 THEN 'Scraper' -- Аномально много событий
    ELSE 'Human'
  END AS traffic_type
FROM
  session_stats;

Эта магия SQL позволила нам отделить зерна от плевел. Мы увидели, что реальная конверсия (среди людей) составляла не 0.001%, а вполне здоровые 2.5%! Оказалось, что рекламная кампания работала отлично, просто ее результаты были скрыты под слоем бот-трафика.

Качество трафика: Очистка аналитики через BigQuery

Распределение сессий после анализа поведенческих паттернов в BigQuery.

А как вернуть деньги за скликивание в Google Ads?

Самый частый вопрос от клиентов: "А можно ли вернуть деньги, которые скликали боты?". К счастью, Google Ads сам неплохо борется с фродом. У них есть встроенные алгоритмы (Invalid Clicks), которые автоматически возвращают деньги на ваш баланс, если понимают, что клик был недействительным.

Но иногда алгоритмы Google пропускают сложные атаки. В таком случае мы выгружаем логи из Cloud Armor и BigQuery, формируем детальный отчет (с IP-адресами, таймстампами и GCLID-ами) и отправляем через персонального менеджера Google в службу поддержки (Traffic Quality Team). В нашем кейсе благодаря таким железным логам клиент смог вернуть более $3000 рекламного бюджета.

Итоги: Не ждите, пока грянет гром

DDoS-атаки и скликивание конкурентами — это суровая реальность современного e-commerce в Казахстане (и не только). Если ваш бизнес зависит от стабильности сайта и эффективности рекламы, вам нужно выстраивать эшелонированную оборону.

  1. Cloud Armor — как первая линия защиты от школьников с ботнетами и брутфорсеров.
  2. Server-Side GTM — как фильтр для чистой аналитики.
  3. BigQuery — как ультимативный инструмент для поиска аномалий и очистки данных.

Не будьте жертвой. Настройте инфраструктуру правильно, и пусть ваши конкуренты тратят деньги на ботов впустую, пока ваши менеджеры по продажам закрывают реальные сделки!

Рустам Шарафутдинов

Рустам Шарафутдинов

Автор инженерного блога

Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).

Экспертность: GCP, Kubernetes, Микросервисы, React, Node.js

Комментарии (0)