Накрутка показов и кликов с вашего сервера: чем это грозит

MAATRIX

Сервер работает штатно, сайты открываются, нагрузка на первый взгляд в норме — а исходящий трафик за месяц вырос втрое, и в логах nginx или в правилах firewall мелькают домены рекламных сетей и трекеров, к которым вы никогда не обращались. Это частый почерк скомпрометированного сервера: его используют не для майнинга и не для рассылки спама, а для накрутки показов и кликов — генерации фиктивного трафика к рекламным объявлениям, часто в интересах третьих лиц, которые платят за такой «сервис» или зарабатывают на нём сами. Разбираемся, как это выглядит технически, как обнаружить и остановить, и почему это отдельная категория риска — не такая заметная, как DDoS, но не менее опасная для репутации сервера и вашего бизнеса.

Что такое click fraud и зачем кому-то ваш сервер

Клик-фрод (click fraud) — это генерация искусственных показов или кликов по рекламным объявлениям без намерения реального пользователя взаимодействовать с рекламой. Схема работает в нескольких направлениях, и все они одинаково незаконны или как минимум нарушают правила рекламных площадок:

• Накрутка в пользу владельца сайта — у злоумышленника есть свой сайт с рекламными блоками, и фиктивные показы/клики с чужих серверов увеличивают его доход напрямую.
• Накрутка против конкурента — массовые клики по его объявлениям в контекстной рекламе выжигают дневной бюджет, не давая рекламе показываться реальным клиентам. Форма недобросовестной конкуренции, иногда заказываемая целенаправленно.
• Накрутка метрик — раздувание просмотров, посещаемости или подписчиков, где IP используется как ещё один «уникальный» источник трафика среди тысяч таких же скомпрометированных машин.
• Часть схемы монетизации ботнета — сервер становится одним из множества узлов, вместе генерирующих трафик по расписанию, управляемому с C2-сервера (командного центра ботнета).

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

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

Как злоумышленник получает доступ к серверу

Накрутка показов не возникает на пустом месте — ей всегда предшествует компрометация сервера тем или иным способом:

• Уязвимость в веб-приложении — устаревшая CMS, незакрытый плагин, инъекция в форму загрузки файлов, через которую на сервер попадает веб-шелл или скрипт-загрузчик.
• Слабые или переиспользуемые пароли — брутфорс SSH, панели администрирования или базы данных с последующей установкой автоматизации.
• Скомпрометированные учётные данные от API, CI/CD или деплой-скриптов, дающие доступ в обход обычной аутентификации.
• Уязвимый или устаревший сервис на внешнем интерфейсе (Redis без пароля, открытый Docker API, забытый тестовый эндпоинт) — подробный разбор одного такого случая есть в статье сервер взломали через забытый порт: реконструкция.

После получения доступа злоумышленник разворачивает автоматизацию — не всегда «вредоносный софт» в классическом смысле, часто это вполне легальные инструменты не по назначению.

Как это выглядит технически

Накрутка кликов и показов с сервера обычно опирается на один из двух подходов, и оба оставляют разные следы.

Прямые HTTP-запросы без браузера. Простейший и самый заметный вариант — скрипт на Python, Bash или Node.js, который дёргает рекламные ссылки и трекинговые пиксели через curl, wget или HTTP-библиотеку, имитируя показ или клик. Такой трафик легко узнать по характерным признакам:

# характерный паттерн в access-логе исходящих запросов через прокси
# (если у вас есть логирование исходящих через squid/3proxy)
tail -f /var/log/squid/access.log | grep -E "ads|track|pixel|click"

У такого трафика типичные признаки автоматизации:

• Постоянный или подозрительно ровный интервал между запросами (например, ровно раз в 2-3 секунды, без человеческой хаотичности).
• Один и тот же User-Agent во всех запросах, часто дефолтный для библиотеки (python-requests/2.x, curl/8.x) или один заранее заданный «браузерный» UA без вариаций.
• Отсутствие сопутствующих запросов, которые обычно идут вместе с реальным показом рекламы — загрузки CSS, шрифтов, соседних скриптов страницы.
• Запросы идут только к рекламным и трекинговым доменам, без единого обращения к «обычным» сайтам, которые открывал бы живой пользователь.

Автоматизация headless-браузера. Более продвинутый и труднее обнаруживаемый вариант — на сервере разворачивается headless Chrome/Chromium (через Puppeteer, Playwright или Selenium), который реально загружает страницы с рекламными блоками, выполняет JavaScript, эмулирует скролл и клики мышью. Такой трафик почти неотличим от настоящего на уровне отдельного запроса, зато выдаёт себя по нагрузке и процессам:

ps aux | grep -iE "chrome|chromium|puppeteer|playwright" | grep -v grep
top -o %CPU

Если сервер использовался под что-то простое (сайт-визитка, API без рендеринга страниц), а вы вдруг видите десятки процессов headless-браузера — это почти наверняка не ваш код.

Признаки в сетевой активности, которые стоит проверять в первую очередь:

• Резкий рост исходящего трафика без изменений в вашем приложении — разница видна при сравнении с историей биллинга или графиками мониторинга, если он у вас уже настроен.
• Множество соединений к одним и тем же внешним IP или доменам рекламных сетей там, где такой трафик логически невозможен (например, с бэкенд-API, у которого нет причин ходить за рекламными пикселями).
• Соединения открываются волнами, синхронно с расписанием управляющего C2-сервера, а не равномерно в течение суток.

Как обнаружить: инструменты и команды

Начинать стоит с трёх точек: сетевые соединения прямо сейчас, история исходящего трафика и список процессов.

Активные и недавние соединения:

ss -tunp | grep ESTAB

# разбивка по удалённым IP с подсчётом
ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

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

Исходящий трафик по объёму и направлению, если на сервере настроен учёт через iftop или nethogs:

sudo nethogs eth0
sudo iftop -i eth0 -P

Подозрительные процессы и автозапуск. Проверьте cron, systemd-таймеры и автозагрузку на предмет задач, которые вы не создавали:

crontab -l
cat /etc/cron.d/* 2>/dev/null
ls -la /etc/cron.daily /etc/cron.hourly

# systemd-таймеры, включая скрытые под обычными именами
systemctl list-timers --all

DNS-запросы к рекламным и трекинговым доменам. Если на сервере есть локальный resolver или вы логируете DNS через tcpdump, полезно быстро прогнать историю на аномальную концентрацию однотипных доменов:

sudo tcpdump -i eth0 -n udp port 53 -w /tmp/dns-capture.pcap -G 300 -W 1
tcpdump -r /tmp/dns-capture.pcap -n | awk '{print $NF}' | sort | uniq -c | sort -rn | head -30

Резкий перевес запросов к доменам с характерными для рекламной инфраструктуры подстроками в имени (ads., track., pixel., click. и подобные — точный набор зависит от того, чью сеть используют для накрутки, поэтому ориентируйтесь на паттерн, а не на конкретные домены) — сильный сигнал, особенно если сервер логически не должен обращаться к рекламной инфраструктуре вообще.

Если сервер уже был скомпрометирован не в первый раз или вы не уверены, что нашли все следы вторжения, разумно пройтись по более полному чек-листу — общий план разобран в статье взломали сервер: пошаговый план.

Как остановить и закрыть источник

Обнаружение — только половина дела; дальше важно не просто убить процесс, а закрыть саму дыру, иначе автоматизация вернётся при следующем чекине с C2-сервера.

1. Остановите активный процесс немедленно, чтобы прекратить генерацию трафика прямо сейчас:

pkill -f puppeteer
kill -9 <PID>

1. Изолируйте сервер от сети, если процесс переустанавливает себя автоматически или вы не уверены, что нашли всё — временно ограничьте исходящие соединения, оставив только необходимое для диагностики:

iptables -P OUTPUT DROP
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

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

find / -type f -mtime -7 -perm -u+x 2>/dev/null | grep -vE "^/(proc|sys)"
awk -F: '$3>=1000 {print $1, $3}' /etc/passwd

1. Удалите вредоносные файлы и автозапуск, обновите скомпрометированные компоненты (CMS, плагины, зависимости), смените пароли и SSH-ключи для всех учётных записей.

1. Проверьте, не осталось ли других последствий взлома — накрутка кликов редко бывает единственной активностью на скомпрометированном сервере; часто параллельно стоит майнер или бэкдор. Стоит свериться с общим планом реагирования: план реагирования на инцидент: что делать при взломе. Заодно настройте мониторинг исходящего трафика на будущее — простое правило алертинга по объёму или числу уникальных внешних соединений ловит повторный инцидент за минуты, а не за недели, когда придёт письмо от хостера.

Риски для владельца сервера

Даже если вы узнали о происходящем случайно и никогда не заказывали накрутку, последствия ложатся на вас — инфраструктурно источником трафика считается владелец IP-адреса, а не тот, кто его скомпрометировал.

Технические и операционные риски:

Юридические и репутационные риски. Клик-фрод нарушает пользовательские соглашения практически всех рекламных платформ, а в некоторых юрисдикциях подпадает под законодательство о компьютерном мошенничестве — даже если формально действовал взломавший сервер человек, а не его владелец. На практике для малого бизнеса это редко доходит до судебного преследования владельца инфраструктуры, но:

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

Сроки восстановления репутации IP и делистинга из антифрод-баз у разных площадок сильно различаются — не рассчитывайте на единый срок «N дней», у каждой платформы свой цикл проверки.

Профилактика: как снизить вероятность повторения

Полностью исключить риск компрометации нельзя, но можно резко сократить вероятность и, что важнее, время до обнаружения.

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

# разрешить исходящее только к нужным сервисам, остальное — лог и дроп
iptables -A OUTPUT -p tcp -d <your-api-ip> --dport 443 -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "BLOCKED-OUT: "
iptables -A OUTPUT -j DROP

• Настройте базовый мониторинг объёма исходящего трафика с алертом на аномальный рост — для старта достаточно простого скрипта, сверяющего текущий трафик с историческим средним раз в час.
• Ограничьте права процессов веб-приложения — веб-сервер не должен иметь возможность запускать произвольные бинарники или ставить headless-браузеры; это снижает шанс, что успешная инъекция превратится в полноценную автоматизацию.
• Используйте fail2ban или аналогичные инструменты против брутфорса на SSH и админ-панели — один из самых частых путей первичного проникновения закрывается именно так.
• Регулярно проверяйте cron, systemd-таймеры и список процессов на предмет незнакомых записей — простая привычка, которая чаще всего ловит проблему на ранней стадии, до накопления ущерба.

Частые вопросы