Как определять и блокировать скликивание рекламы в Яндекс?

Меня зовут Максим Кульгин, и моя компания занимается защитой от скликивания контекстной рекламы. Мы подготовили эту большую статью для тех, кто хочет разобраться с проблемой скликивания рекламы и методиками борьбы с этим печальным явлением. В статье мы рассматриваем в том числе и механизмы обнаружения автоматизированного трафика, т.к. в 90% случаев рекламу скликивают именно с помощью таких инструментов.

Забегая вперед отмечу, что поисковые системы Яндекс и Google проделывают огромную работу по обнаружению кликфрода в своих рекламных сетях и мы не претендуем на то, что наши алгоритмы работают лучше — определение скликивания это вопрос вероятностный и мы здесь исповедуем принцип «лучше перестраховаться», чем допустить «утечку» бюджетов, в отличии от поисковых систем, которые занимают более терпимую позицию (в конечном итоге ведь их цель бизнеса не борьба с фродом, а формирование рекламной биржи между продавцом и покупателем рекламы).

Информационные технологии сегодня играют большую роль в жизни человека и общества, большинство сфер жизни, которые раньше сложно было представить вне физического мира перебрались в Интернет. От онлайн-магазинов до государственных служб все постепенно переходят в сеть. Вместе с ростом количества веб-ресурсов увеличивается и количество информации, которое ими генерируется, среди этой информации может быть множество данных, которые могут представлять коммерческий интерес для злоумышленников или конкурентов. Для оперативного сбора такой информации применяются веб-роботы, генерирующие автоматизированный трафик, тек самым, создавая проблемы веб-ресурсам.

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

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

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

Цель данной статьи – обрисовать наши некоторые методы обнаружения автоматизированного трафика с рекламы, провести классификацию этих методов и предложить на её основе некую универсальную модель системы защиты от такого трафика (в основном надо защищаться от скликивания, ведь этот тип трафика несет явные финансовые убытки).

Задачи, которые необходимо было решить для достижения цели защиты:

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

Практическая значимость заключается в разработке на основе предложенной модели и с использованием рассмотренных методов, системы детектирования и блокирования скликивания рекламы на цифровых рекламных площадках Яндекса (скликивание рекламы в Google можно блокировать аналогичными механиками).

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

Из известных на данный момент решений для защиты является сервис CloudFlare. CloudFlare – американская компания, предоставляющая услуги CDN, защиту от DDoS-атак, безопасный доступ к ресурсам и серверы DNS. Сервис представляет собой облако, промежуточное звено между пользователем и сайтом, в случае обнаружения атаки система блокирует доступ к сайту для конкретного пользователя, защищая инфраструктуру веб-ресурса от падения. Принцип работы системы представлен на рисунке ниже. Защита от ботов и недобросовестного сбора информации не является главными инструментами этого сервиса, так что он не может гарантировать высокой эффективности против парсинга.

Ещё один популярный американский сервис – это Distil Networks, он нацелен на блокировку ботов, и защиту от автоматизированного сбора информации. Данная система уже нацелена на более эффективную защиту от ботов, предлагает системы защиты не только сайта, но API. Использует в своём арсенале капчу и блокировку трафика, после анализа активности.

Такие сервисы как Distil Networks хоть и предлагают хорошую систему защиты, однако работают вне России, а также не могут влиять на некоторые факторы защиты сайта, как например, доступ по логину, скрытие информации о блокировке (т.е. бот получает информацию, но не достоверную). А некоторые сферы как скликивание не имеют эффективных существующих решений. Необходимо также отметить, что все эти решения представляют собой сторонние компоненты, которые встраиваются на сайт и не дают полного контроля над ситуацией. Поэтому крайне актуально дать веб мастерам структурированные решения, модели и алгоритмы для построения собственных систем защиты, учитывающие множество факторов.

Бот-программы (или просто, «боты») всё искуснее имитируют поведение клиента на сайте: могут набрать URL, прийти с самого авторитетного ресурса и отправить товар в корзину, позвонить, заполнить анкету, добавить сайт в бот-сеть, украсть контент, опередив индексацию от Google.

Рассмотрим наиболее типичные ситуации бот-атак в сети:

Приём 1. Сбор ценной информации с сайта, для дальнейшего использования в собственных целях, регулирование ценовой политики конкурентного магазина, перепродажа данных в иной форме и другое коммерческое использование обработанной информации.

Приём 2. Накрутка поведенческого фактора. Боты, призванные совершить на сайте массовые действия за короткий промежуток времени, для того чтобы дать поисковым системам негативный сигнал. Поисковая система (Google, Яндекс), проанализировав странные переходы из другой страны, посчитает это «накруткой» поведенческого фактора – конечно, условно сто ботов, не достаточно для того чтобы отправить сайт в БАН, но может хватит, чтобы запомнить его, как ресурс с плохой репутацией и высоко не ранжировать.

Приём 3. Повышение количества отказов. Боты-даунлодеры, на первый взгляд являются самыми примитивными (просто загружают и через несколько секунд покидают страницу сайта), но вместе с тем, наиболее болезненными из-за динамической смены IP-адреса. В данном случае поисковик посчитает, что ваш сайт просто не интересен пользователям целевой аудитории. Обиднее всего, что именно они, чаще всего съедают и без того небольшой рекламный бюджет.

Приём 4. Снижение оригинальности ресурса. Бот-парсер «тихо» посещает сайт, сканирует и публикует контент на сторонних ресурсах ещё до официальной индексации, при этом не эмулируя действий посетителей. Вследствие чего сайт не поднимается в поисковой выдаче.

Приём 5. Мошеннические клики (скликивание) по рекламным объявлениям с оплатой за клик для получения незаконной платы с рекламодателя. Мошенничество с кликами связано с обманным получением денег с рекламодателей за клики по их объявлениям, отсюда и название модели. В 2017 году примерно каждый пятый клик по рекламным объявлениям был мошенническим, и это число непрерывно увеличивается с каждым месяцем. Мошенничество с кликами не только увеличивает расходы на рекламу, но также искажает аналитические данные, на которые многие компании полагаются для принятия эффективных маркетинговых решений.

На рисунке 2 можно увидеть график отношения рекламного трафика (черная линия) к общему (синяя), график показывает среднее между примерно сорока сайтами разных направленностей с установленной системой аналитики, к которым у нас есть доступ (то есть это сайты, которые мы защищаем от скликивания).

Можно заметить, что в среднем рекламный трафик – это пятьдесят процентов от общего, а значит скликивание рекламы может приносить не только финансовые потери, но и лишать большой части трафика, и как следствие, если это интернет-магазин, то он ещё и не получит прибыль от возможных продаж.

В качестве эксперимента мы провели «атаку» на собственный сайт, предварительно установив на него систему по контролю за активностью пользователей «Яндекс Метрика» со включенным вебвизором. Вебвизор – это дополнительный инструмент платформы Яндекс Метрика, позволяющий следить не только за параметрами посещений, но и за активностью пользователей на самом сайте в том числе переходы по страницам, время нахождения на сайте, а также трекинг движений мыши.

Эксперимент проводился в двух различных конфигурациях. Первая конфигурация представляла из себя многопоточную программу, использующую автоматизированное управление браузером Google Chrome, без использования прокси, переходы осуществлялись в пять потоков. Вторая конфигурация была аналогична первой за исключением того, что теперь браузеру в случайном порядке подавался список из нескольких десятков открытых прокси из разных стран.

Для начала обратимся к данным собранным вебвизором. На рисунке 3 видно, что Яндекс определил, чётко пять посещений (по одному на браузер), каждый из которых прошёлся примерно по пятидесяти страницам. Здесь сразу можно отметить одну из особенностей свойственных роботам или другим автоматизированным системам – это слишком короткое время нахождения на одной странице. Примерно семьдесят секунд на пятьдесят посещений – это меньше двух секунд на страницу, что крайне несвойственно человеку.

Перейдя к результатам парсинга с использованием прокси перед нами предстоит другая картина (рисунок 4). Здесь теперь выделено множество различных пользователей с точки зрения метрики, у каждого из которых не более десяти просмотра. Ситуация с коротким временем на страницу также сохраняется.

Если нажать на «+» можно раскрыть карту переходов (рисунок 5) и заметить, что происходить обход всех страниц сайта друг за другом в сторону увеличения. Эта особенность есть как у первой, так и у второй конфигурации, только во втором случае это отследить труднее так, как разделение на множество различных посещений не дает это понять.

Ещё одной отличительной особенностью, которую позволяет выявить вебвизор, является полное отсутствие движений мышки. У некоторых посещений треугольная кнопка серая, что означает, что мышь даже не была зафиксирована, а у тех, у которых кнопка активна, можно нажать и убедиться, что она стоит статично. Кстати, многие программы для скликивания научились делать эмуляцию движения мышкой, но при этом она не хаотичная (хотя не так уж сложно программно добавить чуть-чуть хаоса:).

Нажав клавишу с информацией возле любого из посещений, можно посмотреть его характеристики. Здесь (рисунок 6) выявляется ещё одна особенность – это прямые заходы. Обычно прямые заходы на сайт довольно редки, особенно на внутренние страницы сайта (чаще переходят по ссылкам из статей и т.п.).

Далее воспользовавшись инструментом отчёты можно посмотреть более подробную статистику по всем параметрам из метрики. Для примера выведем график по просмотрам (рисунок 7). На графике видно что при парсинге с одного ip график очень сильно выделяется на фоне остального трафика, а при использовании прокси, он как бы размывается и становится менее заметным.

Последним проанализируем такой параметр как «роботность» – это автоматически вычисляемый параметр Яндекса, показывает опознал ли Яндекс в посетителе не человека или нет. На рисунке 8 видно, что все запросы с прокси пометились как роботы, а вот два из пяти посещений без прокси определены Яндексом как реальные люди, хотя мы знаем, что это не так.

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

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

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

• Не работающий JavaScript. JavaScript (js) обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.

На данный момент js используется почти на всех интернет-ресурсах. Многие из них попросту не работают без него. Количество реальных людей не использующих js сводится к минимуму, а вот автоматизированным системам намного проще собирать данные, не интерпретируя js-код. Отсюда можно прийти к выводу что, если js на у пользователя отключён, значит вероятность того, что это не человек крайне велика.

• Selenium WebDriver – это инструмент для автоматизации действий веб-браузера. В большинстве случаев используется для тестирования Web-приложений, но этим не ограничивается. В частности, он может быть использован для решения рутинных задач администрирования сайта или регулярного получения данных из различных источников (сайтов)… или скликивания! Не хочется рекламировать мошеннические инструменты, но чтобы у читателя была полное понимание как скликивают его рекламные бюджеты советуем посмотреть следующее видео.

Если сайт ограничивает доступ к работе без js, и другие системы детектирования, то чтобы обойти эту защиту против сайта может быть использован WebDriver. Чтобы обнаружить его использование можно получить данные с navigator.webdriver() и если он будет равен true, это будет означать, что пользователь использует автоматизированное ПО, что также говорит о высокой вероятности того, что это вовсе не человек.

• Нестандартный User-Agent. User-Agent – это текстовая часть запроса, которую веб-приложения используют для сообщения сайту информации о себе. User-Agent браузера содержит название и версию приложения, а также данные об операционной системе компьютера: версия, разрядность, язык по умолчанию и другие параметры.

Поисковые роботы, такие как Google и Yandex используют специальный UserAgent, нечистые на руку разработчики могут подменить UserAgent своего бота, дабы притвориться ботом популярной сети. Для детектирования таких случаев у Google и Yandex есть способы проверки, принадлежности к их сетям. Использование таких проверок позволит со стопроцентной вероятностью выявлять автоматизированный нежелательный трафик.

Также можно блокировать все нетипичные UserAgent, которые принадлежат другим специальным сервисам (например, Postman UserAgent).

• Ловушки для ботов. Некоторые парсинг-боты бездумно обходят все ссылки на сайте. Для обнаружения таких ботов можно поставить на сайте ссылки-ловушки – это невидимые для человека, но видимые роботу ссылки. Детектируя несколько подобных переходов одного пользователя, можно будет с высокой вероятностью говорить о том, что это бот.
• Короткое время между запросами с одного IP-адреса. Как мы выяснили в первой главе, характерная черта бота – это малое время между запросами. Обычно человек при переходах по страницам проводит на каждой странице хотя бы несколько секунд, периодически останавливаясь на более длительное время. Бот же «атакует» сайт запросами с интервалом менее секунды. Заметив такую активность, можно с некоторой вероятностью говорить о том, что это бот. Если активность и переходы не прекращаются долгое время, то вероятность возрастает.
• Большое количество запросов с одного IP. Аналогично предыдущему пункту, обычный пользователь вряд ли будет посещать большое количество страниц (от нескольких сотен). Здесь важным моментом будет убедиться в том, что это действительно один и тот же пользователь. Для этого необходимо использовать специальные инструменты аналитики, запись fingerprint браузера, cookie и другие параметры.
• Детектирование по отпечатку браузера. То, о чём говорилось ранее. Fingerprint или отпечаток компьютера (браузера) – информация, собранная об удалённом устройстве для дальнейшей идентификации, фингерпринтинг – сбор этой информации. Отпечатки могут быть использованы полностью или частично для идентификации, даже когда cookie выключены. На данный момент появились способы однозначного детектирования не только браузера, но и компьютера пользователя, основанные на особенностях работы графической подсистемы компьютера.
• Нетипичные запросы, порядок запросов. Анализируя поведение пользователя, выявляя нетипичное поведение, переходы по страницам, можно с помощью средств аналитики построить модель действий добросовестного пользователя и при отклонении от поведения можно будет с определенной долей вероятности сделать вывод о нестандартном поведении. В данном случае будет полезно сформировать модели не только пользователей, но и поисковых роботов, чтобы не мешать их работе.
• Наличие IP в спам базах, IP- адрес принадлежит прокси. Есть множество ресурсов и баз данных, в том числе свободных, которые хранят списки IP адресов, которые зарекомендовали себя не с лучшей стороны. При заходе пользователя на сайт можно проверять входит ли его IP в эти списки, и в какое количество, в зависимости от этого фактора в совокупности с другими делать выводы о автоматизированном трафике.
• Отсутствие активности мыши. Ещё один из факторов, что был обнаружен во время эксперимента, при автоматизации трафика. Если происходят переходы по страницам, а движения мыши не фиксируются, ли они есть но наводятся не на те элементы, в которых находится следующая ссылка, то это может говорить о том, что используется автоматизированное ПО.
• IP- адреса множественных или рядом идущих запросов принадлежат одной подсети. Проверка принадлежности рядом идущих запросов пользователей к одной подсети может являться одним из фактов парсинга который нужно учитывать.
• Прямые заходы. Большое количество прямых заходов на разные страницы сайта одним и тем же пользователем может говорить о высокой вероятности того, что это бот, потому что в таких системах при переходе по страницам обычно не подставляется параметр refer.

Рассмотренные методы детектирования автоматизированного трафика можно классифицировать по следующим параметрам.

По степени однозначности детектирования:

• методы, с высокой вероятностью детектирующие ботов:
• не работающий JavaScrip;
• Webdriver;
• подмена User-Agen;
• отсутствие активности мыш;
• ловушки для ботов;
• прямые заход;
• методы, детектирующие с некоторой вероятность:
• нетипичный порядок запросов;
• наличие IP в спам базах, списках прокси;
• принадлежность ip адресов к одной подсети;
• короткое время между запросами с одного IP;
• большое количество запросов с одного IP.

По времени необходимому на детектирование:

• методы мгновенного детектирования:
• не работающий JavaScrip;
• WebDriver;
• подмена User-Agen;
• короткое время между запросами с одного IP;
• большое количество запросов с одного iP;
• наличие IP в спам базах, списках прокси;
• методы отложенного детектирования (те, для которых нужно собрать некоторую статистику):
• принадлежность ip адресов к одной подсети;
• нетипичный порядок запросо;
• ловушки для ботов;
• отсутствие активности мыши;
• прямые заход;
• детектирование на основе поведенческих факторов.

• Блокировка по ip. Один из самых простых способов ограничения и блокировки – это закрыть доступ к конкретному ip адресу, чей трафик был отмечен системой аналитики как автоматизированный. Данный способ является эффективным лишь против простейших, любительских парсеров, профессиональные системы, скорее всего будут использовать пул прокси адресов и быстро смогут поменять ip адрес и продолжить работу до следующей блокировки.

Также нужно будет учесть то, что под одним ip в сеть может выходить множество пользователей, особенно это актуально для мобильной сети, поэтому есть риск таким образом заблокировать реальных пользователей.

• Блокировка по отпечатку браузера. Об этой теме говорилось ранее в способах детектирования трафика. Получив однажды отпечаток браузера или компьютера, можно будет блокировать злоумышленника независимо от его ip адреса и других систем обхода блокировок.
• Ограничивание информации по логину. Может выступать как дополнительная мера ограничения парсинга, увидев подозрительную активность от конкретного пользователя, можно быстро его заблокировать. Также можно привязать к аккаунту номер телефона, тогда злоумышленнику сложно будет создать большое количество новых и новых аккаунтов.
• Вывод капчи. Один из действенных способов «успокоить» трафик, или на время его заморозить. Однако сейчас в сети появились сервисы, которые нанимают людей расшифровывать капчи, за маленькие деньги. Поэтому наиболее эффективным будет создать свой собственный алгоритм капчи, использующий нестандартные техники ее решения, в этом случае решать такую капчу будет экономически не выгодно. Вряд ли сам злоумышленник будет это делать, ровно, как и система решения капч не будет ради одного сайта разрабатывать API.
• Подстановка ошибочных данных. Данный способ подойдет если на сайте хранится большое количество ценной информации, которую конкуренты желают скопировать. Обнаружив парсинг, сайт не будет внешне никак об этом говорить, а будет незаметно подставлять неверные данные, либо говорить, что таких данных нет. Конкурент не скоро заметит такую защиту, а понять какие условия учитываются при детектировании парсинга будет намного сложнее. Но это довольно сложно реализовать!
• Отображение важных данных в виде картинок. Может быть применено как дополнительная мера защиты важных данных. Например, номера телефонов пользователей площадки онлайн-торговли, внедрение в систему парсинга сложных систем по распознаванию изображений потребует дополнительных затрат для злоумышленников.
• Блокировка на основе Cookie. Cookie – данные хранящиеся в браузере пользователя, позволяющие сохранить параметры сессии после ухода с сайта. Данный метод может быть малоэффективным по отношению к ботам, так как могут легко очистить параметры Cookie. Однако, при построении систем защиты от автоматизированного трафика можно будет учесть этот фактор и с подозрением относится к посетителям без Cookie у которых другие параметры, например ip-адрес, говорят о том, что он уже был на сайте недавно.

Рассмотренные методы блокировки трафика можно классифицировать по следующим параметрам.

По однозначности блокировки бота:

• однозначное блокирование:
• блокировка по отпечатку браузер;
• блокировка по Cookie;
• неоднозначное блокирование (под блокировку могут попасть обычные пользователи):
• блокировка по i;
• отображение важных данных в виде картинок (все пользователи испытывают неудобства).

По эффективности действия против ботов:

• легко обойти защиту:
• отображение важных данных в виде картинок;
• блокировка по ip;
• ограничивание информации по логин;
• обход защиты требует значительных усилий:
• вывод капчи (при условии использования собственной капчи);
• блокировка по отпечатку браузера или компьютер;
• подстановка ошибочных данных.

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

На основе предложенной классификации методов защиты нами была реализована следующая модель системы обнаружения автоматизированного трафика (рисунок 9) и защиты от скликивания как следствия. Модель состоит из пяти подсистем-процессов:

1. Сбор и накопление данных

2. Система мгновенных блокировок

3. Система отложенной блокировки

4. Построение поведенческих карт

5. Система блокировки.

На основе модели построена UML диаграмма последовательности (рисунок 10), которая позволит лучше понять процессы работы системы защиты от скликивания:

• Сбор данных.

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

• Мгновенная блокировка.

Получает информацию о посетителе непосредственно от него же (с предварительным сохранением в промежуточную базу данных), в данный момент времени. Анализирует такие факторы, которые с высокой долей вероятности говорят о том, что это робот. Например, User-Agent бота, наличие webdriver, время между запросами, их количество и т. д., выявив бота, мгновенно закрывает доступ к сайту, согласно настроенной политике блокировок (например, сначала показывает капчу, потом блокирует навсегда).

• Поведенческий анализ.

Анализирует пользовательский трафик, и строит поведенческие карты пользователей, разделяя их по группам, классифицируя их. Помечает плохое и хорошее поведение. Здесь учитываются такие факторы, как порядок перехода по страницам, движения мыши и т.д.

• Отложенная блокировка.

Берет из базы данных информацию о недавних действиях пользователя (в диапазоне 30 минут) и основываясь на данных поведенческих карт делает выводы о блокировке данного пользователя.

• Блокировка.

Мониторит базу параметров блокировок и в соответствии с ним, применят против каждого бота свой способ блокировки.

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

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

Напомним, что кликфрод – это когда конкуренты за счёт автоматизированных систем скликивают рекламу конкурентов на рекламных площадках (в РСЯ например), расходуя рекламный бюджет «жертвы», тем самым «выбивая» его из рекламной выдачи. А нечестные на руку владельцы сайтов, размещающие у себя рекламу за плату, зарабатывают за счёт автоматизированных кликов. И те и другие приносят убыток и лишают сайт найти настоящих клиентов.

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

Чтобы понять, как защищать, нужно понять от чего защищаться. Система Яндекс Директа умеет защищаться от простых способов скликивания рекламы. Просто так с одно IP подряд скликать ничего не получится, Яндекс не засчитает эти клики, вернёт деньги и перестанет временно показывать рекламу. Однако важно понимать, что после возврата денег Яндекс больше не идентифицирует этого клиента как плохого, поэтому он может снова вернуться через некоторое время с кликами. Чтобы избежать детектирования со стороны Яндекса злоумышленники придумывают сложные схемы. В том числе перед кликом имитирую поведенческий трафик на сайте, переходя по ссылкам. Задачей разрабатываемой нами системы защиты от кликфрода должно служить не только детектирование подозрительного трафика с рекламных площадок, но и возможность сохранить блокировку показа рекламы этому клиенту на долгое время. Чтобы решить это проблему необходимо все подозрительные сессии отметить в Яндекс.Директе, на основе этих пометок построить сегмент и выставить этому сегменту коэффициент в Яндекс Директе минус сто процентов.

Напишем простой алгоритм, по которому может работать система на начальном уровне:

• Сбор данных о посещении сайта:
• webdriver;
• идентификатор в рекламной системе (client id);
• fingerprint.
• Анализ полученного трафика, выявление подозрительного:
• существующие базы спам адресов;
• нецелевой рекламный трафик;
• наличие Webdriver.
• Фиксируем нежелательные сессии по client id.
• Отправляем полученные client id в Яндекс Метрику для формирования сегмента.
• В Яндекс Директе устанавливаем для этого сегмента коэффициент показа -100%.

Для начала работы определяем, как будут детектироваться автоматизированные сессии. Необходимо определить минимальные условия блокировки. Учитывая специфику блокировки скликивания, было решено сначала обратить внимание на сессии, которые являются кликами на рекламу.

Так определим первое условие блокировки: посетитель пришёл с рекламы, находился на сайте менее 20 секунд, посетил только одну страницу, а его ip-адрес находится в одном из списков подозрительных адресов. Данное условие будет проверяться только на завершённых сессиях, с последнего действия в которых прошло более 30 мин. Надо понимать, что бот мог почистить cookie и снова зайти на сайт, поэтому следующим шагом ищем подобных в связке ip-адрес плюс отпечаток браузера (fingerprint), такая связка даст гарантию, что это именно тот же посетитель. Для системы мгновенной блокировки добавляем параметр webdriver, так как он нам говорит, что сессия точно автоматизированная и можно не ждать конца, по этому параметру также сверяем связку ip-отпечаток.

В итоге получаем следующий перечень из условий, которые будут первоначально учитываться в системе защиты:

• параметр webdriver;
• приход с подозрительного ip адреса и моментальный отказ;
• блокировка по связке ip-отпечаток браузера.

Для следующих версий системы планируется добавить такие вещи как:

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

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

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

Разрабатываемая система должна включать в себя:

• веб-сервер, собирающий «сырые» данные о посещениях;
• базу данных, настроенную на высокопроизводительную выдачу данных, которые могут быть использованы в ходе будущего анализа;
• модуль скриптов, размещаемых на сайте.
• микросервис, позволяющее быстро получить, обработать сырые данные и записать в базу данных;
• микросервис анализа и блокировки;

Создание сегментов в Яндекс Метрике, а также выставление отрицательных коэффициентов для этих сегментов в Директе на данном будет производиться вручную.

Проектируемая система будет представлять собой набор совместно взаимодействующих систем:

• Целевой сайт, для которого предполагается защита от автоматизированного сбора информации.
• Платформа сбора информации о посетителях ресурса.
• Локальная база данных, хранящая отформатированные данные.

Учитывая набор взаимодействующих систем, а также требования к характеристикам разрабатываемой системы, была спроектирована следующая архитектура системы (рисунок 11).

Разработанная архитектура системы позволяет быстро настроить работающее решение, а также в будущем масштабировать решение путем добавления новых обрабатывающих серверов, сервисов и баз данных. А выбранные средства разработки позволяют контролировать все этапы сбора информации, анализа и блокировки.

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

• Платформа для размещения кода на сайте клиента – Google Tag Manager.
• Система сбора данных о действиях пользователя – Matomo.
• База данных – Microsoft SQL Server.
• Платформа разработки ПО – .NET Framework, язык – C#.

Google Tag Manager – диспетчер тегов. Сервис позволяет из одного интерфейса управлять всеми тегами различных сервисов. На сайт интегрируется только один код, а остальные коды маркетолог самостоятельно добавляет в Диспетчер без участия IT-специалиста. В нашем случае данное решение помогает минимизировать контакты с клиентами при необходимости обновления кода скрипта и расширения его возможностей.

Matomo – это бесплатная система веб-аналитики с открытым исходным кодом. Система устанавливается на сервер владельца. Основное преимущество данной платформы перед такими онлайн сервисами как Яндекс Метрика является возможность полного контроля над хранящимися данными, удобный доступ ко всем данным через api, а также возможность отслеживания ip адресов и собственных параметров, в то время как решения от Яндекса не предоставляют информацию об ip адресах, а собственные параметры обрабатываются больше дня.

Microsoft SQL Server – система управления реляционными базами данных, разработанная корпорацией Microsoft. СУБД масштабируется, поэтому работать с ней можно на портативных ПК или мощной мультипроцессорной технике. Размер страниц – до 8 кб, поэтому данные извлекаются быстро, подробную и сложную информацию хранить удобнее. Система позволяет обрабатывать транзакции в интерактивном режиме. Реализован поиск по фразам, тексту, словам, можно создавать ключевые индексы – что является особым преимуществом для нашей задачи.

Система аналитики Matomo позволяет предавать для каждого визита или действия дополнительные пользовательские параметры, внедрив специальный js код на сайт. Данный инструмент позволит нам расширить базовые возможности сервиса и использовать параметры повышения точности детектирования пользователей за счёт таких средств как вычисление fingerprint браузера, вычисление использования средств автоматизации (таких как selenium web driver). Также для повышения точности, если сайт параллельно использует систему аналитики Яндекс Метрика, то мы можем в Matomo передать уникальный идентификатор, вычисленный самой метрикой.

Для того чтобы собрать все скрипты вместе, освободить клиента от установки множества файлов и дать нам возможность совершать будущие обновления в одностороннем порядке было решено использовать специальный менеджер тэгов. Таким был выбран Google tag Manager ввиду удобства и функциональности, наличию средств гибкой кастомизации (рисунок 13).

В менеджер тэгов было добавлено три скрипта: «Fingerprint», «Matomo+Ycid», «WebdriverDetect».

«Matomo+Ycid» – это основной скрипт инициализации, он запускает сбор действий на клиенте и отправляет в matomo. В дополнение к этому скрипт id Яндекс Метрики и также отправить его в matomo.

Для детектирования отпечатка браузера было выбрано свободно распространяемое решение fingerprintjs2. Данный скрипт позволяет не только получить уникальный идентификатор для браузера на основе множества параметров, но и гибко регулировать используемые параметры. Проведя некоторое время над скриптом, было решено оставить, только те параметры, которые сложно было подделать или изменить, а именно рендеринг изображений, аудиозаписей и другие параметры.

Скрипт «WebdriverDetect» написан с целью быстрого выявления браузеров, использующих средства автоматизации. Многие системы автоматизации браузеров (такие как Selenium Webdriver) внедряют для правильной работы служебные переменные, которые можно отследить с помощью js кода. Код был написан на основе сбора и компоновки воедино разных приёмов детектирования автоматизации.

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

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

• анализаторы;
• вспомогательные критерии для анализа;
• блокировщики.

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

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

Для тестирования системы был подключен веб-ресурс с ежедневной посещаемостью примерно триста тысяч посещений в день. На сайте был установлен наш GTM скрипт, который начал передавать данные в реальном времени.

Разработанные решения по оптимизации записи в базу данных, позволили добиться максимальной производительности системы и обрабатывать большие массивы поступающих данных. На данный момент к системе подключено более 60 сайтов, для распределения нагрузки используется 3 сервера Matomo. В связи чем можно сделать выводы, что разработанное решение показывает высокую работоспособность и масштабируемость.

Чтобы убедиться, что блокируются именно автоматизированные сессии мы можем вывести список заблокированных сессий с параметрами и отсортировать их по ip-адресу (рисунок 17). На рисунке видно, что хоть мы и не используем пока алгоритмов по блокировке подсети, но заблокированные сессии находятся в одной подсети, все они кликают по рекламе и сразу же уходят. Можно обратить внимание, что есть сессии с одинаковыми отпечатками браузера в разные даты, что говорит о том, что бот использует одни и те же машины на протяжении нескольких дней.

Конечно, обычный человек не будет на протяжении двух месяцев упорно кликать по рекламе и уходить с сайта, при этом всё время используя новые IP адреса – это нам даёт ясно понять, что все эти сессии автоматизированные, значит решение работает правильно, блокируя злоумышленников, вследствие чего им приходится использовать новые IP.

Для того чтобы убедиться в эффективности работы системы выгрузим дневную статистику по сайтам (рисунок 19). Выделим среди сайтов три типовых: крупный – site_id равное 7, средний site_id 3 и маленький site_id 15.

Дневная посещаемость у этих сайтов 281 101 посетитель, 28 617 и 1 580 соответственно. В последней колонке приведено общее количество заблокированных сессий за выделенный день. А в колонке visits_adv_count содержится информация о общем количестве переходов с рекламы. Посчитаем для этих сайтов относительное процентное соотношение заблокированных сессий к числу визитов с рекламы.

Из результатов подсчёта (формулы 1-3 выше в статье) видим, независимо от размера сайта процент заблокированных сессий достигает больше десяти-пятнадцати процентов для крупных и средних компаний, а для маленьких компаний этот показатель может достигать тридцати процентов. Это показывает нам то, что, даже используя базовые алгоритмы можно отсечь большое количество автоматизированного трафика, за счёт чего сэкономить рекламный бюджет в будущем. Также это говорит, что есть ещё некоторое количество автоматизированного трафика, который скрывается более тщательно. И для борьбы с ними мы разрабатываем алгоритмы машинного обучения, учитывания подсетей и других параметров, что значительно увеличит процент блокируемого автоматизированного трафика.

В ходе анализа были исследованы методы и способы борьбы с автоматизированным трафиком на веб ресурсах. На основе данной классификации реализована модель системы детектирования и блокировки автоматизированного трафика.

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

Результатом нашейработы стала эффективная система борьбы со скликиванием рекламы, которая блокирует от десяти до тридцати процентов автоматизированных сессий по рекламе и имеет большой потенциал по развитию и усовершенствованию.