Системный журнал — практичная база знаний по VPS и Linux
security • 12 минут

Как использовать Attribution Business Insights для анализа bot‑трафика на Linux VPS

С ростом использования ИИ‑краулеров владельцы сайтов сталкиваются с новой проблемой: большая часть автоматизированного трафика не приводит к реальным переходам, а лишь потребляет ресурсы и искажает аналитику. Cloudflare представил панель Attribution Business Insights, которая помогает понять, какие боты приносят пользу, а какие наносят вред. В этой статье мы покажем, как получить эти данные на своём Linux VPS, настроить сбор логов nginx и использовать информацию для настройки правил firewall и систем мониторинга.

Что такое Attribution Business Insights

Attribution Business Insights — это дашборд, доступный всем клиентам Cloudflare Bot Management. Он предоставляет агрегированную информацию о трафике ботов, включая:

  • Объём bot‑трафика по сравнению с человеческим;
  • Коэффициент crawl‑to‑referral (сколько раз бот сканировал страницу на каждый пришедший referral);
  • Распределение ботов по оператору и стране происхождения;
  • Классификация краулеров по типу деятельности: Training (обучение моделей), Search (обновление индексов для RAG) и Agent (работа в агентных взаимодействиях).

Эти сведения позволяют перейти от простого блокирования всех неизвестных ботов к осознанной политике: разрешать полезных краулеров, ограничивать или компенсировать тех, кто извлекает контент без обратного трафика.

Подключение Cloudflare Bot Management на VPS

Прежде чем анализировать данные, необходимо направить трафик вашего сайта через Cloudflare и активировать Bot Management:

  1. Зарегистрируйте домен в Cloudflare и измените NS‑записи у регистратора.
  2. В панели Cloudflare включите режим Proxy (оранжевое облако) для всех DNS‑записей, связанных с вашим веб‑сайтом.
  3. Перейдите в раздел Security → Bots и активируйте Bot Management. После этого начнёт собираться информация о запросах, которая будет доступна в Attribution Business Insights.
  4. Убедитесь, что ваш веб‑сервер (nginx) принимает запросы только от Cloudflare IP‑диапазонов — это упрощает последующую фильтрацию логов.

Для ограничения доступа к серверу только от Cloudflare можно использовать firewall. Ниже пример правила для ufw (Uncomplicated Firewall) на Ubuntu/Debian:

# Сначала запрещаем всё входящее
sudo ufw default deny incoming
# Разрешаем SSH (порт 22) — при необходимости измените порт
sudo ufw allow 22/tcp
# Добавляем диапазоны Cloudflare (актуальный список берём с https://www.cloudflare.com/ips/)
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    sudo ufw allow from $ip to any port 80,443 proto tcp
 done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    sudo ufw allow from $ip to any port 80,443 proto tcp
 done
# Включаем firewall
sudo ufw enable

После этого все запросы к портам 80 и 443 будут приходить только через Cloudflare, а исходные IP‑адреса посетителей будут доступны в заголовке CF-Connecting-IP.

Интеграция данных с nginx

Nginx сам по себе не знает о классификации ботов от Cloudflare, но мы можем использовать переменные, которые Cloudflare передаёт в запросах:

  • $http_cf_ipcountry — код страны посетителя;
  • $http_cf_ray — уникальный идентификатор запроса;
  • $http_cf_visitor — JSON с информацией о схеме (http/https).

Более полезно для анализа bot‑трафика — заголовок $http_cf_bot_management, который содержит вердикт Bot Management (например, known_bot, likely_bot, unknown). Мы можем записывать его в лог nginx:

log_format  cloudflare_bot  '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" '
                           'cf_ipcountry=$http_cf_ipcountry '
                           'cf_bot=$http_cf_bot_management '
                           'cf_ray=$http_cf_ray';

access_log  /var/log/nginx/access.log  cloudflare_bot;

Такой формат позволяет позже извлекать поля cf_bot и считать, сколько запросов помечено как known_bot, likely_bot и т.д., а также соотносить их с количеством рефералов (поле $http_referer).

Получение и интерпретация данных из Attribution Business Insights

После активации Bot Management в панели Cloudflare перейдите в раздел Analytics → Attribution Business Insights. Вы увидите:

  • Общее соотношение bot‑трафика к человеческому (например, 65 % ботов, 35 % людей).
  • Среднее значение crawl‑to‑referral за выбранный период (24 ч, 7 д, 30 д). Если оно значительно выше 1 : 1, это сигнал о избыточном сканировании.
  • Таблицу «Top bots» с колонками: оператор, страна, потребляемая пропускная способность, текущее действие (Allow/Block/Challenge).
  • Разделение по типам краулеров: Training, Search, Agent. Например, вы можете обнаружить, что большая часть трафика относится к типу Search — боты обновляют индексы для RAG‑систем.

Эти цифры можно экспортировать в CSV через кнопку «Export» и дальше обрабатывать на своём VPS с помощью стандартных утилит (awk, grep, jq) или загружать в систему мониторинга (Prometheus, Grafana) для построения дашбордов.

Использование полученных данных для настройки firewall и fail2ban

Зная, какие операторы ботов потребляют наибольшую пропускную способность и имеют высокий crawl‑to‑referral, вы можете принять решение о блокировке или ограничении их доступа на уровне сетевого экрана. Ниже пример, как автоматически блокировать IP‑адреса, которые отмечены как likely_bot и превысили порог запросов за минуту:

# Скрипт /usr/local/bin/bot-block.sh
#!/bin/bash
LOG=/var/log/nginx/access.log
BLOCK_THRESHOLD=100   # запросов за минуту
BLOCK_TIME=86400      # блокировать на 24 часа

# Выбираем строки за последнюю минуту, где cf_bot=likely_bot
awk -v d="$(date -d '-1 minute' '+%d/%b/%Y:%H:%M')" '
$0 ~ d && $0 ~ /cf_bot=likely_bot/ {print $1}' "$LOG" | sort | uniq -c |
while read count ip; do
    if [ "$count" -gt "$BLOCK_THRESHOLD" ]; then
        echo "Blocking $ip ($count requests)"\n        sudo ufw insert 1 deny from $ip to any
        (sleep "$BLOCK_TIME" && sudo ufw delete deny from $ip to any) &
    fi
done

Сделайте скрипт исполняемым (chmod +x /usr/local/bin/bot-block.sh) и добавьте его в cron, например, каждые пять минут:

*/5 * * * * /usr/local/bin/bot-block.sh >> /var/log/bot-block.log 2>&1

Такой подход позволяет динамически реагировать на изменяющееся поведение ботов без постоянного ручного вмешательства.

Мониторинг и алертинг

Для постоянного контроля полезно построить простую систему оповещения:

  • С помощью prometheus-node-exporter собирайте метрику nginx_bot_requests_total{bot_type="likely_bot"} из логов (можно использовать pushgateway или скрипт‑экспортер).
  • В Grafana создайте панель, показывающую отношение bot‑запросов к человеческим в реальном времени.
  • Настройте правило alerting в Prometheus: если отношение crawl‑to‑referral превышает порог (например, 10 : 1) в течение 10 минут — отправляйте уведомление в Slack или по email.

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

Заключение

Attribution Business Insights предоставляет точные данные о том, как различные краулеры взаимодействуют с вашим контентом. Сочетая эту информацию с типичными инструментами Linux‑администрирования — nginx, firewall, fail2ban и системами мониторинга — вы можете перейти от реактивной блокировки к продуманной политике доступа, которая защищает ресурсы, сохраняет ценный трафик и открывает диалог с провайдерами ИИ о возможной компенсации за использование контента. Внедрив описанные шаги на своём VPS, вы получите прозрачность в вопросах bot‑трафика и сможете принимать обоснованные решения, основанные на фактах, а не на догадках.